Proposal: Renting, Leasing, Hijacking ships

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Proposal: Renting, Leasing, Hijacking ships

Post by chuck_starchaser »

Yeah, this IS an engine-proposal. Namely, a proposal to separate control of a ship from "ownership" of it.
Should be good for any mods, past, present or future. Advantages:

1) Most players want to *experience* flying a lot of ships; not necessarily own them. A ship could be too good
or too big to be affordable, but you might be able to rent it for 24 hours just to try it out (or to impress
the chicks :)).

2) Would enable missions such as "steal ship X and bring it here".

3) Would enable such missions as "Your current ship would not do; but we will lend you this souped-up
military spec corvette for the duration".

4) Would enable gaming paradigms such as joining a military, flying missions off a carrier, piloting
ships that belong to the military.

5) Last but not least, it would be "better programming", in the sense that hard-coding the concept of
ownership into the engine is not the best thing.

As for implementation, I've got no idea; I don't even know whether this is in Python or C++.
shadow_slicer
Merchant
Merchant
Posts: 47
Joined: Sat Jul 28, 2007 4:00 am

Post by shadow_slicer »

Could you elaborate in more detail what you see as the difference between "owning" a ship and merely controlling a ship? I'm not sure I understand the distinction, especially if we also consider temporary ownership.

What I mean by temporary ownership is this: the player has full control over the ship as if they owned it, but cannot sell it at the ship dealer. If you wanted to restrict upgrades, you could use the normal methods in units.csv to limit additional upgrades, and build in all features so they can't be sold. This would also allow the player to make repairs and restock ammo.

In order to do that, we would need to do a few things:
1) Figure out a way to discriminate between owned ships and temporarily owned ships in the save file.
2) Modify ship dealer interface to make temporarily owned ships incapable of being sold (this would be trivial if we have 1)
3) Separate the sellShip, buyShip and switchShip portions of the base interface into more generic functions and make them callable from python (to allow missions to give you ships [you buy at cost=0], and take away ships) -- actually PU already allows you to buy/sell ships from python...how do they do that?
4) Figure out what to do if the player is forced to return a ship, and they have no other ships currently at that base...
5) Find a way to remove the ship if the player cancels the mission. This is a big problem since the player will likely be trying everything to find a loophole so they can keep the Ubership after the mission.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

shadow_slicer wrote:Could you elaborate in more detail what you see as the difference between "owning" a ship and merely controlling a ship? I'm not sure I understand the distinction, especially if we also consider temporary ownership.
The difference is semantic, but semantics are critical in programming. Using an incorrect term tends to needlessly complicate thinking about how to model a problem. I would turn the tables and ask you "could you elaborate in more detail what you mean by 'temporary ownership'?"
I'll spare you the trouble: You meant "control".
Ownership means that you have permanent control, until you voluntarily relinquish it; so the term "temporary ownership" is an oxymoron.
What I mean by temporary ownership is this: the player has full control over the ship as if they owned it, but cannot sell it at the ship dealer. If you wanted to restrict upgrades, you could use the normal methods in units.csv to limit additional upgrades, and build in all features so they can't be sold. This would also allow the player to make repairs and restock ammo.
That's all fine; but why call it "temporary ownership", then?
In order to do that, we would need to do a few things:
1) Figure out a way to discriminate between owned ships and temporarily owned ships in the save file.
2) Modify ship dealer interface to make temporarily owned ships incapable of being sold (this would be trivial if we have 1)
3) Separate the sellShip, buyShip and switchShip portions of the base interface into more generic functions and make them callable from python (to allow missions to give you ships [you buy at cost=0], and take away ships) -- actually PU already allows you to buy/sell ships from python...how do they do that?
4) Figure out what to do if the player is forced to return a ship, and they have no other ships currently at that base...
5) Find a way to remove the ship if the player cancels the mission. This is a big problem since the player will likely be trying everything to find a loophole so they can keep the Ubership after the mission.
Well, let me show you the benefit of semantics, now:
By calling this "temporary ownership", you made this, in your mind, a "special case" of ownership, and proceeded to think about how to tweak the code to make it work for this special case. This is the kind of thinking process that leads to code forever getting more complex and intractable.

If, instead, we think about "control", and then "ownership" as being a special case of "control", everything becomes simpler and clearer:

We begin by coding the methods and conditions by which control of a ship is given, acquired, relinquished. This enables us to have party A transferring control of a ship to party B. Aboard a carrier, as a pilot you are given control to a ship to fly a mission, for example. We can code this simply by getting rid of the implied money transactions and thus simplifying the code!

Additionally, we gain some clarity even at the interface: Note that, currently, the My Fleet interface is confusing, because to switch ships you have to click on the Buy button, even though you've already paid for it.
So, now, that button would change to [Take] or [Pick].

And why should "control" come before "ownership"? Because it's the natural order of things: Economics, commerce, legal concepts... These are late inventions layered on top of "the law of the jungle"; but the law of the jungle is the only real law; and these layers subsume, rather than replace the law of the jungle. The law of the jungle is present at every moment: If we don't obey the laws, policemen use force on us, NOT laws. Everything boils down to force, in the end; we just don't like to see it that way, but it's how it is.
The most basic fact software needs to model is who is controlling a ship, never mind who legally owns it. Just two command functions: "void give_ctrl()" and "void take_ctrl()", and a query, "bool has_ctrl()"; the rest is coding conditions under which those two functions are called. Control is the low-level interface. Ownership is a high level interface, built on top of control.

So, once we've simplified the code to deal with nothing more and nothing less than who has control over a ship, then we can add a layer of code regarding "ownership", which will have some bearing on how control over a ship changes hands. Then we will be able to have functions such as "buy()", "sell()", "borrow()", "lend()", "rent()", "lease()" or even "steal()". (Yes, the term "stealing" recognizes ownership; otherwise it would simply be "taking".)
I say "some bearing" because pirates, for example, would be blind to issues of "ownership". They'd laugh at a piece of paper. To them all you've got is control of your ship and its cargo, and the only question is about your ability to defend this control. But if the software assumes that "ownership" is some kind of objective reality, it can only model piracy by hacking it around ownership.

And what IS "ownership", anyways? Ownership is a state of mind. The worst mistake we could make, software-wise, is to put an attribute in "ship" referring to an "owner". Being a state of mind, ownership is an attribute of owners, rather than attribute of the objects they own. Dumb programmers would charge like bulls, head-first, into hard-coding a reference to an owner in class ship; 99.9% probability they'd ironically invoke "simplicity" as an argument for doing so, and would paint themselves into a corner, as later on they'd be unable, without major refactoring, to represent the fact that ownership over something could be disputed between two or more parties; or the fact that an object could be owned "in paper" by some guy, but in reality 90% owned by the bank who loaned him the money; and ships without owners would segfault half the time.

Ownership is a state of mind, a concept, and therefore there are gray areas, exceptions and confusion. You could have different "kinds of ownership", like if you're leasing a ship with a 10 year contract, it's "almost" like owning the ship, and you'd probably be allowed, in the contract, to make hull modifications, such as adding pylons or mounts; but if you are only leasing for 1 year, you might not have such liberties.

Armed with the understanding that ownership is a vague human concept, rather than an 'objective' reality, and with the understanding that control comes first, these subtleties would be fairly easy to overlay on top of a solid software package modelling control; but it would be absolute Hell to try to implement them as a modification of the existing "ownership-based" code.

Correct semantics are essential to clear thinking, which in turn is essential to clear coding.
shadow_slicer
Merchant
Merchant
Posts: 47
Joined: Sat Jul 28, 2007 4:00 am

Post by shadow_slicer »

I'm still trying to figure out how to apply your statements on control vs ownership to the engine that is vegastrike. I'm not sure that ownership as your describing even exists in vegastrike (or even exists in the real world for that matter).

We're probably just looking at things from a different point of view. You're coming from the abstract without any preconceived notions of how VS handles ships. I've recently looked at how VS handles owned ships in quite a bit of detail, since I'm working on a patch to allow owned ships to be carried as cargo.

In VS, units have no owner attribute. They have factions, and flightgroups and orders. The ship the player is currently controlling has special orders that tell it to do what the joystick or keyboard or mouse says. When you are using cargo wingmen and switch to another unit, it merely switches you to another unit in your flightgroup with the same faction (which is why sometimes people ended up inside of missiles this way). There is no real difference between control and ownership here.

"Ownership" in VS is not really a bidirectional relation. There is a list of the names of the ships that the player owns (std::vector<std::string>). I think there is also a function that also tells you if the player is currently controlling a certain ship. But that's as far as ownership goes in VS: just a simple list of ship names. Note that since this is just a list of ship names it is impossible to determine which ship is which if you were to own more than one with a certain name (which is why you are only allowed to own one of each type).

As for the shipdealer interface "buying" your own ships, that is purely a GUI simplification. The ships don't exist at the base. They are artificially added after the rest of the cargo, and treated differently in the code, and only appear that way so they can use the same interface. If you want I could probably make it so it shows "Pick" or "Take" or "Transport" or "Use that Ship" on the buy button when you select one of your own ships.

In any case, if we wish to have the player gain control of a ship at a certain time, and then be forced to lose control of the ship at another time there are a few of the things that need to be done:
1) Figure out a way to discriminate between the ships the player will eventually involuntarily lose control over and the other ships in the save file.
2) Ensure that ships the player will eventually involuntarily lose control over incapable of being sold (this would be trivial if we have 1)
3) Separate the sellShip, buyShip and switchShip portions of the base interface into more generic functions (loseControlAndGainCredits, gainControlandLostCredits, swapControl) and make them callable from python (to allow missions to give you control of ships, and take away control of ships)
4) Figure out what to do if the player is forced to lose control of a ship, and they have no other ships currently at that base...
5) Find a way to force the player to lose control of the ship if the player cancels the mission. This is a big problem since the player will likely be trying everything to find a loophole so they can keep control of the Ubership after the mission.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

shadow_slicer wrote:I'm still trying to figure out how to apply your statements on control vs ownership to the engine that is vegastrike. I'm not sure that ownership as your describing even exists in vegastrike (or even exists in the real world for that matter).

We're probably just looking at things from a different point of view. You're coming from the abstract without any preconceived notions of how VS handles ships.
Exactly; but that's a Good Thing TM ;-)
I would say that ANY project to improve parts of the engine (or Python parts of the engine) should take at least some stepping back from the thing, and rethinking from first principles. To just look at what is done, and try to modify, does little to improve the code; all it may do is "get results" at best; but what the code needs the most is cleaning and refactoring, more so than any features. I'd be happy to live with this proposal unfulfilled if 20 lines of code were cleaned up instead. But I hope we can do both.
What I was trying to say is that having ownership at the ground level and building control features on top is ***WRONG***, IMO. This feature request calls for refactoring. Control should be implemented at the bottom; ownership on top.
I've recently looked at how VS handles owned ships in quite a bit of detail, since I'm working on a patch to allow owned ships to be carried as cargo.

In VS, units have no owner attribute.
Good!
They have factions, and flightgroups and orders.
That's weird. AI's should have those things; not "ships".
The ship the player is currently controlling has special orders that tell it to do what the joystick or keyboard or mouse says. When you are using cargo wingmen and switch to another unit, it merely switches you to another unit in your flightgroup with the same faction (which is why sometimes people ended up inside of missiles this way). There is no real difference between control and ownership here.
I hope you realize you're describing a *bug*, needing to be fixed.
"Ownership" in VS is not really a bidirectional relation. There is a list of the names of the ships that the player owns (std::vector<std::string>). I think there is also a function that also tells you if the player is currently controlling a certain ship. But that's as far as ownership goes in VS: just a simple list of ship names.
That's good.
Note that since this is just a list of ship names it is impossible to determine which ship is which if you were to own more than one with a certain name (which is why you are only allowed to own one of each type).
That's a *bug*, too.
As for the shipdealer interface "buying" your own ships, that is purely a GUI simplification.
I'd call it a "complication", rather; but I guess this is just semantics... :)
The ships don't exist at the base. They are artificially added after the rest of the cargo, and treated differently in the code, and only appear that way so they can use the same interface. If you want I could probably make it so it shows "Pick" or "Take" or "Transport" or "Use that Ship" on the buy button when you select one of your own ships.
Not sure I understand, but, just in case, let me clarify that, to whatever extent my personal wishes may matter to you, I only wish for *true fixes* or nothing, not just some hack to make it work better at the expense of making the code harder to understand.
In any case, if we wish to have the player gain control of a ship at a certain time, and then be forced to lose control of the ship at another time there are a few of the things that need to be done:
1) Figure out a way to discriminate between the ships the player will eventually involuntarily lose control over and the other ships in the save file.
2) Ensure that ships the player will eventually involuntarily lose control over incapable of being sold (this would be trivial if we have 1)
I think you're talking about hard-wiring the loss of control. This is why I was saying that control has to come first, before ownership: borrowing a ship implies that someone else owns it. This boils down to a contract between parties. Contracts can be honored or dishonored. If you were supposed to return a ship, but instead take off for aeran space, you still have control. You see? You're thinking about "hacking ownership" or "hacking control", just sticking some timers on them, flags to prevent selling and whatnot. That's not the way to do it. A contract is something at a higher level than control. Control is basic and ruthless. Contracts are soft and breakable. Different animals.
3) Separate the sellShip, buyShip and switchShip portions of the base interface into more generic functions (loseControlAndGainCredits, gainControlandLostCredits, swapControl) and make them callable from python (to allow missions to give you control of ships, and take away control of ships)
Wrong. No such thing as "loseControlANDGainCredits()". That is EXACTLY wrong. gainControl(), loseControl(), gainCredits(), loseCredits(). These four *separate* functions are basic. But separate. If I sell you an icecream, after you give me the 5 bucks I might say "sorry, I lied; no ice-cream for you", and keep your money. Or if I gave you the icecream first you might run out with it without paying. That there *should* be an exchange as agreed doesn't mean it will be so. Besides, at the low level, you only gain or lose; the concept of exchange of goods for money is a layer above that: what I was calling the "contract layer". That's why I'm saying the concept of ownership and buying needs to be *removed* from the code, first; replaced by simpler, control level code; and thirdly, the contract and exchange layer can then be built on top of the control layer.
4) Figure out what to do if the player is forced to lose control of a ship, and they have no other ships currently at that base...
Well, what happens if that happens in the real world? Tough luck. But I don't see why the player would be "forced" to lose control of a ship. By what means? Unless the lender has the means to force it, it should not be forced *by code*. Otherwise the code would be taking on god powers.
5) Find a way to force the player to lose control of the ship if the player cancels the mission.
Why force? Enforcing a contract is a problem of the parties to that contract; not a problem of the engine.
This is a big problem since the player will likely be trying everything to find a loophole so they can keep control of the Ubership after the mission.
And what's wrong with that? What I would expect is for the lender to get really pissed and send in a few mercenaries after you. Morover, I would expect the lender to require some references before renting you an expensive ship.

Same if I was flying a mission off a carrier, but instead of goin on my mission I decided to disappear with the fighter. Well, the Confeds would do their best to make my life misserable, no doubt; but it should be doable.
Heck, remember when that Korean pilot defected to Japan with a brand new Mig-29. And the Iraqui pilots that defected to Iran during the Gulf War?

The reason you're thinking about enforcing contracts is precisely that you're trying to do what I cautioned should NOT be the way of doing it: --namely, trying to hack control into the existing ownership-based system. Control needs to go *under* ownership; it is something more low level and fundamental. Ownership, buying and selling, which are now rigidly hardwired, need to be coded as the brittle things that they really are, at a higher level than control.
Psyco Diver 69
Bounty Hunter
Bounty Hunter
Posts: 129
Joined: Wed Aug 01, 2007 1:32 am
Location: Here
Contact:

Post by Psyco Diver 69 »

It would fit in with my idea of stealing ships but attacking someone, target their engines and buy and use grappling cables to haul them to a pirate or friendly base (like hauling a aera to the feds or vice versa) make some cash for steal enemy technology
Sindwiller
Merchant
Merchant
Posts: 32
Joined: Sun Aug 10, 2008 10:31 pm
Location: Zürich, Switzerland

Post by Sindwiller »

Just for the record, as nobody seems to have mentioned how other spacesims tackle with the issue of multi-ship ownership. X for example basically allows an infinite amount of ships to be owned by the player. A system where every single ship has an autopilot and can be remotely given commands, eg. "Fly to this sector", "Dock to this station", "Attack this object", "Defend me", stuff like that. Actually, in the first X, X Beyond The Frontier, you could buy ships but you couldn't fly them yourself, as you were bound to that Experimental Ship (and no, it wasn't lame, the ship was actually pretty powerful when fully packed with stuff - and X-btf had atmosphere :P), but you could command them. So when you went to fight some aliens, you could take a helpful fleet with you. Of course, this whole thing was designed with the economy-oriented gameplay in mind - the whole station owning and demand and supply thing -, meaning that you were able to build a station and let transporters automatically supply it with energy cells and other resources and eventually let other transporters automatically sell the stuff you're producing at a decent price. Moreover, stealing ships is basically getting the enemy pilot to eject and abandon his ship. You can then reactivate the ships computer system and command it to fly to the next shipyard and repair it... and voilà. On the slight technical side, in X, the "player" was handled as a separate faction, meaning there was no difference between "faction" and "owner". Thus, you could make a script (for example) that spawns a ship owned by the "faction" player (I haven't really figured that out yet how that is done right now in VS - hell, I can't even VS.launch() anything yet because it isn't working for me, neither in a mission nor as a quest, which I can't initialize right. I'm probably doing something horribly wrong)

I know that Vegastrike isn't aiming for a design like that (and that my input might be slightly off-topic for that matter :P) - I just wanted to point out how other spacesims do that and that it could be interesting to look at other concepts as well. Especially because others (like me :) ) would be really interested in refining that part of VS :)

Just my 2 cents. :P
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

@Psyco Diver 69:
Exactly. To hard-code that *all contracts are honored* would preclude all that and much more. Then we'd be brainstorming again, a year from now, how to hack contract dis-honoring and ship hijackings into it...

@Sindwiller:
Okay, so in X there's no hard-coded expectation of money being paid for a ship; they can be stolen/taken. That's good! But there's no lending/leasing? Well, it doesn't matter; it illustrates my point, anyways, that acquire_ship() and relinquish_money() shouldn't be hardcoded into one function.

That ships in X have remotely controllable autopilots, that's something I wouldn't mind to see; but that's very mod-specific, and a matter of modders' choice. Good to keep in mind that it should be possible, tho.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Post by Deus Siddis »

chuck_starchaser wrote:That ships in X have remotely controllable autopilots, that's something I wouldn't mind to see; but that's very mod-specific, and a matter of modders' choice. Good to keep in mind that it should be possible, tho.
Yes that and the ability to have those AIs fly the ships that you own, not just the ones that you have hired at outrageous fees. Those two features combined would add so much more depth to the gameplay that there's no words for it!

VS has such a tactical/strategic background and such role specific craft that it is amazing these couple of features are not already in the engine. They would also greatly benefit most of the other universes, like star trek with its arm-chair control structure and star wars with its often squadron-focused engagements.

/rant
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Well, that's because we got no AI experts around. Nobody understands the existing AI code; and those who tried ended up insane, or were swallowed by the earth. Anyways, this is getting off topic.
Post Reply