Economic system of VS

[jfbenck]

Hi,

I've been talking on the Wing Commander topic to spiritplumber about improving the AI of VS. I'm thinking about improving the economic system of VS as this IMHO a core feature in the game. AI of the pilots isn't great, but good enough for the moment, so this hasn't a very high priority. Before doing some actual coding I'll be looking into the code with help from spiritblumber. Also I'll put my ideas and plans on the Wiki page, the currently missing economy page in the Development section.

[klauss]

Economy I can help with. Improving economy was a project of mine... that got postponed since other ones were going.

You can start by taking a look at trading.py
It manages almost everything economy-related (except where do ships go - if you want to tie the economy to the merchant AI, that will take some work).

[jfbenck]

Exactly my idea. I'm currently in the process of editing the wiki and I'll have a look at the py file (gotta learn some python... )

[chuck_starchaser]

I think the first step would be for merchant AI's to be non-visual; --i.e.: Trade effectively, but instead of showing as a ship traveling, to simply output travel instructions to a text file, or a queue. This way they can be tested for their effect on quantities and prices without having to worry about flight ai.

[zimmon]

From reading other peoples ideas and a few of my own I think I have come up with an economic system thats much better then the current system but is shouldn't be very difficult to implement. It also should go along fairly nicely with current efforts.

Zimmon's proposed economy.

1.
The first thing needed is a list of categories and cargo to be traded. This is already exists and is being improved so the current efforts will be used. The main things needed for the cargo list is the weight, volume, and a universe wide reference price (for reference purposes only, probably will not be used in code).

2.
The next thing is closely related to the cargo list. We need a list of base types, planet types, etc (all the units you can dock with) and what they produce and what they purchase. For instance a mining base will not trade everything but will purchase food, gases, entertainment, and mining supplies and sell raw materials. Next determine the base price of all cargo traded at the mining base. Do this for every unit type, not for every unit.

3.
Now we are going to begin applying modifiers to the base price. The first modifier is going to be the supply modifier and is based on how much of that cargo type is currently on the station (or planet). This could be balanced by how much the station currently needs. For instance a mining station is rather small (compared to a planet) and doesn't need several ox loads of food over a short period of time. So the price of food should drop off more rapidly at a mining station than say a star fortress or other large station and prices should drop even slower at a planet. By slower I mean it takes a larger amount of cargo to effect the price. Also a mining station should take longer to use up the cargo sold to it and shouldn't produce new cargo very quickly.

The amounts of different cargo's individual units have could be tracked to say the last 20 (random number) places the player docked. This would do a great job of controlling the amount of data that has to be kept track of while tracking as much relevant data as possible.

4.
Now we get to the hard part, how to efficiently account for other merchants. I'm going to say that the merchant ships (the ones the player can see and attack) that are in the same system as the player only affect the amount of cargo on planets and stations that currently have their cargo amounts tracked (see above paragraph) and have no other affect on the economy.

5.
The way we really account for other merchants is by each station and planet affecting prices system wide (and possibly neighboring systems depending on resource requirements). Each planet type and base type will have a modifier for each cargo type that it trades.

For instance in the system you start in there is a oceanic planet, mining base, fighter base, and a relay. The relay, fighter base, and mining base will each individually cause an upward pressure on the cost of food in the system but the oceanic planet will push prices of food back down. In fact the oceanic planet produces more food than all the stations together can use so the price of food in the system will be below average.


How can this be implemented?
This could be calculated by combining all the individual planets and units modifiers for each cargo type. This will give one system wide modifier for each cargo type which could be calculated when the player jumps into the system. The system wide modifier along with the supply modifier would then be applied to the base modifier when the cargo screen is accessed. If their are 2 mining bases in a system the mining base modifiers would be applied twice.

Yes I realize a planet's or base's modifiers will affect it self. I don't see this as a problem, the base prices can be adjusted to compensate.


This doesn't take in to account how far apart things are with in the system. This is on purpose because I believe the spec drive makes it irreverent. However not all ships have jump drives so the next system should not be affected (or minimally affected if we think Vega Strike can handle the extra load).



If this is in the wrong forum please move this post or quote it in the correct location.

edit:
First post, Greatings and all that.

[Kerrysl]

I think an excellent base model for the economy is that used by Railroad Tycoon 2. Cargo prices are affected by conditions at the destination (RT= building types within station radius, VS= base type, current cargo volumes), distance travelled from supply to destination and delay in transit.

In VS the distance travelled is not so important because of the games non-linear gameplay. However a planet will have a lower demand for cargoes that can be supplied in-system, and higher demands for cargoes that must come inter-system. I like zimmons idea of maintaining a log of previous systems to compute current prices, but it doesn't have to be that complex.

Since the VS universe is dynamic, we can't always know what planets will be in other systems. However a simple 3 stage demand modifier would be sufficient. (eg. In-system available -15% buy price, available in previouly visited system then 0 modification, not available in current or previous system + 15% price modification. I would think that most cargo types would be available at a system 2 jumps from anywhere, so we don't need to log too much data on where the player has been.

As for delay in transit, different cargos can be more time sensitive than others. One would think food would be very sensitive, and maybe some liquours, whereas most raw materials would be very insensitive. For time sensitive cargos, a simple count of jumps since being on board could be stored. Each jump could decrease the price by a fixed percentage (eg. 5%). When you look through the cargo list, most cargoes are not time sensitive, but I would imagine that research could be time sensitive, supplies could be considered time-sensitive, and maybe even specialty wines. This would prevent loading up, flying missions and then finally selling them down the track. 10 jumps would take 50% off the value.

I haven't looked at the current code but I don't think these kind of changes would add too much to processing overhead, while they would add some nice complexity to the economic model.

[klauss]

This brings an interesting concept, but one that goes the opposite direction from the "commodities" concept: the price is attached to the item, not the type of item. That is, the item is priced X. In system A people will sell you this item for less credits, and in system B people would pay more credits. But, as you spend time enroute, the item degrades (like food), and so it's price lowers, more and more. But the same kind of object brought from closer, with less degradation, would be worth much more. So, in the end, the items are not exchangeable, they have inherent properties which vary the price.

[Kerrysl]

Yes, exactly.

And it very much approaches reality. We are willing to pay more for imported goods if they cannot be obtained locally. They are considered exotic. However if there is local competition (eg. food produce) then the imported needs to be either much better quality, or much cheaper to compete with local produce.

So in VS, local in-system food suffers no delay modification, and is therefore a better cargo, unless we bring in a food cargo that is unavailable in-system, so that it's exotic modifyer can overcome the negative delay modifier. An example might be like I previously suggested, with one slight difference.
Exotic value (In-system 0%, one system jump = +10%, two system jump = +20%)
Delay modifier (5% per jump).

So the combined result would be;
If cargo is available in-system - no modification unless jumped in which would have a nett negative effect. So domestic food stuffs preferred.

If cargo only available one system out - +10%-5% = +5% value if cargo sourced only one system away. If sourced 2 systems out, but is available one system out then zero nett effect. If sourced further out, but available closer then nett negative effect.

If cargo only availabe two systems out = +20% - 10%(for 2 jumps) = +10% nett effect, unless was sourced further out which would reduce the advantage.

Of course these numbers can be modified to change the impact, but it does demonstrate how more reality can be built in.

The other issues of building up cargos by save/loading, or stripping dodos which builds up weapons stocks, could be minimized in their effectiveness by reducing the value of cargoes when stocks go over certain levels. These limits would likely need to be different for each cargo. Another example;
Specialty Wines - limits = 10(-10% when sold by player), 20 (-20%), 30 (-30%), etc.
Coffee - limits = 100 (-10%), 200 (-20%) etc.
Seafood - limits = 130 (-10%), 260 (-20%), etc.

[Zeog]

But this would kill all in-system-trade like shipping food from an aggiculture planet to a mining base in the same system. Do we want that?

[CoffeeBot]

@Kerrysl: I think the distance/jump modifiers are a good idea, but, I think a 10% increase for one jump is a little high. Trade routes that only span one jump are still considered lucrative, because it's still a short distance. Hard percentage modifiers like this seem a little unreal to me, just because the jumps are too common and readily available. Maybe a 5% increase for each jump over two or three?

I'm not completely sure, myself. I think there needs to be a balance between klauss's commodity system and the distance/demand/decay system.

[Kerrysl]

But this would kill all in-system-trade like shipping food from an aggiculture planet to a mining base in the same system. Do we want that?

Not at all. Actually the opposite. If food is available at an in-system agricultural planet, then that is going to be the best source for the run to the mining base. If you load your food one or two systems out and then go to the mining base then you get offered less for your decayed food. Only food types that are not available at the agricultural planet that must come from elsewhere would be more profitable than the local produce.

[klauss]

In order to even talk about it, we need some things defined accurately:

a) How is time considered to go by for insystem flight? Realtime? (most probably), or is it just a gaming approximation, and, say, each minute you spend flying represents actally an hour? (I don't think anyone would want to justify that, but it's a valid approach).
b) How long does it take to land? Is it instantaneous, and the game shows it? (hardly), or does it take time, and how long a time?
c) Is it the same docking with a ship than landing at a planet, in time considerations (hardly)?
d) How is time considered to pass by at bases?
e) How long does a jump outsystem take? Instantaneous? (as the game shows it), then there is actually not much penalty for outsystem commodities, since a 10-20 minute delay is hardly worth modelling. Or does it take time, like in Elite, where you didn't experience it but it actually took a week or so to complete the jump?
f) How should the user be shown, preferrably in a clear, concise and notorious manner, time passing?

All those issues are, actually, questions for JackS... I hope he sees them, and answers them. He must have thought about those issues, and have a clear idea regarding them.

[CoffeeBot]

I've always hated accelerated time, by default. But that's just me. There's too many instances in which simulated time doesn't work. Flying from Planet A to Planet B, we say that 1 RL minute = 1 Game Hour. So, taking that, what happens when I fight with some Luddites for fifteen minutes. Were we seriously fighting for fifteen hours?! Where were the police during this time? Or any other random passers-by, for that matter?

For jumps, I really do like the idea that they take several hours to complete, but that's simply impossible to place into the game. Perhaps if we implement some kind of cutscene during the jump and system-loading period -- a cockpit or "F5-view" of the ship in some kind of psychedelic space, stretched out as if at FTL speeds.

A "landing" cutscene at dock-time would also suffice for the "Delay" when docking. Since we're already maneuvering ourselves into the docks as it is, a simple 10-15s animation of the ship being taken by clamps or gangway would be fine.

WRT time inside of bases, I think it should pass at the same speed as the rest of the universe. No reason to make things more confuzzling.

Plus, in multiplayer, everyone would have to be at the same time-scale, regardless of where they are. I think we're all okay with the willful suspension of disbelief for jump travel and docking times being fairly close to instantaneous. Adding an inordinate amount of time to it would just make the gameflow lag and offend people.

[klauss]

I think we're all okay with the willful suspension of disbelief for ... snip ... docking times being fairly close to instantaneous. Adding an inordinate amount of time to it would just make the gameflow lag and offend people.

Really? So, going from Cephid/17 to Sol stopping at every goddam station and planet would take the same time as not stopping? You really didn't take a bus lately, did you? (or did I get it wrong?)

[CoffeeBot]

No no, I meant the transition between hitting "d" for dock, and showing the interior of the base, or clicking on "launch" and being in the cockpit, ready to fly should be nigh-instantaneous. Not the actual act of walking around the base and loading up on goods -- that's all real time (so, the faster you click around getting goods and missions means the faster you can get back to space).

[klauss]

Yes, but even still, the game shouldn't act as if you could just land on a planet and say: Oops, my mistake, I was looking for the 'S' key. Sorry. Click on "Launch", and you're back in space and everything (including your cargo) is just as it was before.
Landing is a complex, lengthy procedure. If you do that, even by mistake, the game should account for like 30 min to an hour lost doing it (even if, to the player, it's instantaneous). That is, you're goods are an hour older.

[CoffeeBot]

That's true, good point. But, how do you account for those types of things in mulitplayer? We can't have one player jumping ahead 30 minutes while others don't. Using the example you just gave: I land on a planet while you're dogfighting several hostiles. Your fight shouldn't take more than 10 minutes or so, but my landing/takeoff sequence takes an hour (assuming I did a straight turn-around). So, in theory, even if you're still around after my hour of docking, the hostiles wouldn't be. How do you reconcile the time differences?

Also, a real-life docking sequence wouldn't "accidentally" happen, for the most part. It would require a series of actions that are summed up in our "D" command. Typos happen to the best of us, so should we be penalized for it?

Time increments work great for single player, but are next to impossible for mulitplayer.

Don't get me wrong, klauss. I see your point, and agree with it. But, this is one of those gameplay versus realism things. And a big one, at that.

[jackS]

a) How is time considered to go by for insystem flight? Realtime? (most probably), or is it just a gaming approximation, and, say, each minute you spend flying represents actally an hour? (I don't think anyone would want to justify that, but it's a valid approach).

Realtime.

b) How long does it take to land? Is it instantaneous, and the game shows it? (hardly), or does it take time, and how long a time?

Current Implementation:instantaneous
Canon: Should take a bit, but not too horribly long - in general, one shouldn't actually be landing one's own craft on planets, but, if one were allowed to/managed to not get shot down for doing so illegally, it'll mostly depend on how long it takes one to do the appropriate deceleration towards the landing point.

c) Is it the same docking with a ship than landing at a planet, in time considerations (hardly)?

Current Implementation:instantaneous, same
Canon: Different. Docking should generally be notably faster, although post-landing/docking(actually getting from craft to X) could well take the same or longer, depending on facilities and manner of docking. A smaller vessel docking to a significantly larger one should, in general, be a much faster process than a larger vessel docking to anything in particular. I envision a timing not unlike the time from when an airplane has landed (flaps back to normal) to when it has come to rest, but this could vary greatly depending upon the two bodies in question (docking could be very easy, or very hard given congestion, sizes, and facilities). Entirely external docking arrangements could be made more rapidly, but getting out will be much slower

d) How is time considered to pass by at bases?

Current Implementation:paused
Planning: This is a bit fuzzy - it'll pass in "real time" relative to the outside world, but such is going to be inconsistent with how long one can reasonably expect many transactions to take. There appear to be distinct tradeoffs between symbolism and realism with respect to time, and hence, player interest - unless they're interested in wandering around the base (in a manner as yet not concretely defined) while a ship is being upgraded, goods are being transferred, etc. How time passes here isn't so much the question as how much time should be spent here and how, and it's intricately tied into some other decisions wrt what will be done outside the ship.

e) How long does a jump outsystem take? Instantaneous? (as the game shows it), then there is actually not much penalty for outsystem commodities, since a 10-20 minute delay is hardly worth modelling. Or does it take time, like in Elite, where you didn't experience it but it actually took a week or so to complete the jump?

Current Implementation:instantaneous
Canon: A few seconds. The chief distinction between insystem and outsystem traffic is the operating cost and capital investments of the transportation used to bring them (at least in any meaningful quantities), not the extra few hours spent in transit. Jump drives are going to get more expensive, but that said, the player is not a pauper, to be able to own a ship, especially an interstellar capable one. Spacecraft != cars. The vast majority of people in the VS universe do not own one, even on economically active planets.

f) How should the user be shown, preferrably in a clear, concise and notorious manner, time passing?

Good question.

You did, however, leave out the biggest desynchronization - that between the player and the background simulation of universe events. This will be a much more interesting issue to tackle, and may require some degree of retconning on interstellar SPEC speed limits in order to have incursions occur on visible timescales without having most assaults be frontal/suicidal (i.e. through the heavily defended border jump - although once the border systems fall, the subsequent attacks _should_ go through the jump points...)

As for "accidental" dockings - I wouldn't advocate non-abortable landings/dockings, except for the most final portions of the procedure. One should request docking clearance, submit to docking control, and then stay at the controls until docking has completed. If docking seems to be going awry, or something else comes up, the pilot bugs out (which will probably piss off the 'tower,' but... that's life). High traffic facilites will either have streamlined, rapid docking, or they'll have a hideous traffic snarl (or both). Two freighters doing an emergency dock in deep space - there's no reason to think that'll be fast at all. In either case, active submission, or cooperation of control should be necessary, hence, readily(inertia aside ) abortable.

[klauss]

d) How is time considered to pass by at bases?

Current Implementation:paused
Planning: This is a bit fuzzy - it'll pass in "real time" relative to the outside world, but such is going to be inconsistent with how long one can reasonably expect many transactions to take. There appear to be distinct tradeoffs between symbolism and realism with respect to time, and hence, player interest - unless they're interested in wandering around the base (in a manner as yet not concretely defined) while a ship is being upgraded, goods are being transferred, etc. How time passes here isn't so much the question as how much time should be spent here and how, and it's intricately tied into some other decisions wrt what will be done outside the ship.

That's why I brought it up. Time passing inside bases is a complex issue. For instance, there's all the folklore about saveing/loading meaning you spent the night. Is that official? Those things make a big difference to the economy. One major event: asking for a ship to be brought to you. Ingame: instantaneous. That's obvious, noone would want to wait the time it would take to a) hiring someone - could be fast, but, b) that someone must get to your ship, c) takes your ship out of its hangar (with all the "paperwork" it must entail), d) fly your ship to where you are, e) contact you, end the transaction. It should take time. How to handle that? Does time go by implicitly by the mere asking of bringing you ship? Or do you have to press a "Wait" button? If while you're waiting the base/ship you're docked with gets attacked... does the wait stop? It gets ugly. Well beyond the economy, but all those considerations are prior to economy, since economy does depend a great deal of how time passes by. Since most of your "economic" interaction will be done at bases, this is the most important place where to decide how time passing should be modelled and interphased.

e) How long does a jump outsystem take? Instantaneous? (as the game shows it), then there is actually not much penalty for outsystem commodities, since a 10-20 minute delay is hardly worth modelling. Or does it take time, like in Elite, where you didn't experience it but it actually took a week or so to complete the jump?

Current Implementation:instantaneous
Canon: A few seconds. The chief distinction between insystem and outsystem traffic is the operating cost and capital investments of the transportation used to bring them (at least in any meaningful quantities), not the extra few hours spent in transit. Jump drives are going to get more expensive, but that said, the player is not a pauper, to be able to own a ship, especially an interstellar capable one. Spacecraft != cars. The vast majority of people in the VS universe do not own one, even on economically active planets.

With that model, a single jump would be a hefty sum to add for consumers, but two or three jumps wouldn't be much different than a single jump. Perhaps the main difference would be the risk factor merchants have to face, but no direct operative costs or time constraints.

f) How should the user be shown, preferrably in a clear, concise and notorious manner, time passing?

Good question.

You did, however, leave out the biggest desynchronization - that between the player and the background simulation of universe events...

I didn't mention it directly, but I was implying it. Yes, it's a problem.

As for "accidental" dockings - I wouldn't advocate non-abortable landings/dockings, except for the most final portions of the procedure. One should request docking clearance, submit to docking control, and then stay at the controls until docking has completed...

Sensible.
But I just used that as an example, as a way of saying: "in a zap".