Detailed plans and suggestions for VS

[targ collective]

DISCLAIMER: Most of the below could really be done easily, but I don't know enough about the internals of Vega Strike to do this, and don't have the time right now if I did.

Vega Strike is a very polished game right now, but feels incomplete. Here I list several things which could be done relatively easily to seriously round out and expand it. (In the trading model section things are less easy, but only so far as getting rid of exponents and real-time goods usage are concerned).

Right now in Vega Strike, the buck stops at the Goddard. You can get heavier vehicles like the Mule, Ox and Clydesdale and they will serve you well, but they are missing something (which I’ll go into later).

There's a mention about the economy on the news page. This seems as good a time as any to give my view on the economic model.

The economy should be governed by time. So profit/time from bounty hunting should have only a slight lead on profit/time trading independently, and profit/time on trading missions should be more or less the same as profit/time in bounty hunting.

The economic model should be tiered according to cost. The tiers should be based on the class of ship flown. A rough sketch of what the tiers should look like, now - Fighter (everything short of the Mule), Corvette-Class (Mule, Corvette etc) Light Capship (Ox), Medium Capship (I see the Clydesdale here), Heavy Capship, Destroyer.

The player should take approximately the same time to ascend to each tier. The profits each tier give should be approximately five, ten times the previous tier. Each tier should have at least one bounty hunter and one merchant representative. The costs to upgrade and maintain your ship in each tier should, however, have a slight lead on the previous tier relative to income for that tier.

Something more advanced, now, which will require changes to the engine to implement.

The trading model could use an overhaul. I propose that planets have, in addition to the trading values already used, goods they import and goods they export as indicated by another (Boolean) value assigned to cargo. Planets should stock enough goods to allow for trading at each tier (so planet stocks would need to be increased by the thousands).

Orbital installations are by their nature more specialised in what they buy and sell. Therefore pre-capship players and perhaps light-capship players should get more bang for their buck in orbital installations, with higher profits for mere hundreds of thousands of cargo units of goods, as opposed to millions or hundreds of millions of units to trade with smaller profit per unit but greater profit overall due to commute time saved and mass of cargo. The engine would need to be able to cope with these figures without resorting to exponents.

Most importantly, bases and planets should produce and use goods in real-time (say at 100/sec for asteroid bases, 10000/sec for planets). Goods should not increase beyond a ceiling or plummet below a bottom line. There should be an increase in cost when a planet or base is running low on a good it produces. There should be a decrease in payoff at a base or planet when there is oversupply. The difference in a trade should never go into the negatives, with a ceiling on high costs and a bottom line returns will not go beyond. Nevertheless it should be more profitable to sell goods which are in demand than goods which are filling the warehouses.

Taking the above paragraph into account, a fully upgraded Milspec Plowshare will have 4800 cargo units. Since the commute is usually more than 4800 secs, it won’t make a dent. That’s realistic. A Mule has a cargo capacity of 200000. That’s 20000 secs, and even with a mule the commute won’t take that long. You’re starting to make a dent and feel profits fall off a little, though you’re still making more money than you would planetside.

EDIT: I seem to have stumbled on the 'economy petri-net idea'. Sorry. It's still an important part of this list, and as I'm suggesting an arbritrary used/produced list with set value changes per tick rather than units produced by units consumed per tick, it should be manageable. Rather more difficult would be the dynamic price changes - however, as the universe proper is not simulated when in dock the resources that would normally go into this could be put into these calculations.

Enter the Ox (which should be priced, incidentally, to take into account rising a tier to light-capship, as well as future earnings). Now those little orbital stations won’t even rattle in your capacious cargo holds, so you’ll make more money from interplanetary trade.

That’s all I have to say on the trading model for now. Next I’ll cover upgrades.

Upgrades should always cost a substantial sum relevant to your earnings. So the capships of each class should have upgrades of their own for the class concerned, and these upgrades should be priced according to the expected earnings/time for that unit class. Price the upgrades according to how long you want the user to wait before being able to buy them. Don’t make it too long unless they really are the best upgrades. I can’t say anything more on balancing them because the profit/time figures haven’t been measured through gameplay yet. Remember: Profit/Time Is All!

Okay, I was going to cover this first originally but things haven’t fallen out that way – everything previous to this had to come first to flesh matters out. This is what the existing post-Goddard units are missing. Missions.

Now, I know this can be done because I have seen it done in Privateer Remake. Simply put, the game can detect if your ship has a massive cargo hold, fill it and pay you handsomely per item on reaching your destination. The game can also detect if you are flying an assault capship, and will give you highly paid cleansweeps and bounties against other ships of your class. This could be put in today, as could the edits to units.csv and master_parts_list.csv to implement a tiered model. (Working out what to put in them would take many months of balancing, mind). If nothing else in this post is recognised, could you Devteam wonders please please please put in some missions relevant to the capclass and corvette-class ships? This last would be the simplest of all to do, and if I did not have problems with Python and other people’s code I’d do it myself!

EDIT: Paused for breath. Forgot to mention something.

On capship handling the fact that capships don't do corners works for me. Capships would, I feel, benefit from some really heavy thrust though, and possibly some decent manueverability in upwards/downwards directions. Possibly upgrades should provide this rather than be there as stock. Either way it seems a bit odd that with all the space for an engine, capships still struggle to produce decent thrust...

Keybindings for look up/look down would be very nice, and easy to implement. It would be worth it even if it meant replacing the f7 and f8 keys, and I think there are a few free keybindings on the function keys yet. (I haven't checked.)

EDIT: Yet more food for thought, couched in ever more technical terms. Keep a textbook handy.

More thoughts on economic management, again just ideas for clever people to use – someone else suggested something similar re supply and demand in the New Users section, and while the only solution to the feedback loop in supply-demand is to calculate the prices according to a sliding scale per unit per purchase (CPU intensive, even if we operate to the nearest 10 or 100 or whatever although there are effective and cheap algorithms out there that do just that) or possibly roll the purchases by buying one by one at a rate of 100/sec or so in a scrolling system like that which occurs with acceleration – storing the number purchased and the total price in RAM and only writing to disk when the button is released – either of these would work (and the latter would look cool!). Using the same system in selling at the station, and disabling production when docked, will keep parity when deciding against a type of cargo except for the odd rounding error (always round down to prevent exploits unless you want to round alternaely up then down).

Far more demanding is the data storage of system goods, and it’s there that I get cunning about just how to make this work. First of all our storage file ignores completely stations you do not buy from or sell to – they can randomly generate cargo again when you re-enter the system, who’s going to notice or care? The game will need to flag whether or not the user visits an object but there are seldom very many of those and capships in sieges can be ignored completely as finding the same one twice is long odds. Keeping storage costs down will help keep the file from getting ‘very big very quickly’. Another space-saving tactic is to write to the file not in real time, even in RAM (which should be freed for other tasks where possible as the premier speedy data store) but only on system exit. But my favourite innovation is how the file works in the first place.

On system exit the file should store the amount of goods as a percentage of the average and attach a timestamp to the value. The percentage only needs a floating point value, obviously, and the timestamp needs to be accurate only to the closest second. These values will then be completely ignored until the file reaches a certain size (which can be checked when docked anywhere) or the user re-enters a system in the trade route (perhaps the file should be headed with a list of systems to which it applies, checked each jump and ignored past the header if the system is the wrong one). When dealing with hundreds or even thousands of millions planetside in terms of goods availability, as outlined prior to this, using percentages compared to averages will save a lot of space when compared to the raw values. It may be worthwhile saving the price fluctuation here too as if that’s too big glaring inaccuracies could result.

Which is all very well and good right until the values are needed, but what then? The game reads the relevant entries, converts the percentage and price fluctuation back into a raw value and adds goods into the stock according to the difference in current time and the timestamp. By way of example, the user transports all hundred million units of grain on the local Bio-Diverse to an Icy planet insystem in his/her Clydesdale, leaves for five minutes to visit another system for a Bounty mission then returns. In the intervening time at 10000/sec production the Bio-Diverse would produce 3,000,000 Grains (five minutes is 300 secs) which would be added to the current value in the file (0). Which makes me think there's a case for adding another 0 to production when working in such a macro scale (but let's keep on topic). While at it the game could also check for expired timestamps (timestamps would expire when enough time has passed for goods to return to average levels, at which point the system can randomly generate again, because ‘who’s gonna know’).

In summary this could be a cheap and efficient method of tracking availability and prices if implemented. Sorry for the jargon people, this post is more of a technical suggestions thread than anything else and assumes some computer knowledge. The devs will certainly understand it – if they ever get around to reading (much less replying to) it…


Thanks for listening all,

Targ Collective

[Silverain]

Still digesting the read, so apologies if you have covered targ.

While your system sounds sufficient from a single playe perspective, remember that we are moving into the multiplayer sphere of gaming.

If the server was recording your local information, it will also be doing so for everyone else. I imagine this would result in an immediate bloated file, depending on who was online at any one time.

I lately picture something of a statistical baseline the server (your computer in single player if you like) accesses any time it has a call from any player for a given base type. It could modify the baseline for base size (a statistic recorded in the generated universe file - sorry, don't recall name at the moment), then modified by economic demands modifier from timely news articles.

Example: Land at agri planet. It is randomly generated by universe file as a 'small' base, so modifier is .5, news article (base has surplus food with a timestamp within x time of your landing) modifier 1.5. So we have the agri planet baseline statistic of (say) 10000 food supply (or the random number generated within baseline range), multiply by .5 small base, multiply by news supply 1.5 = 7500 supply. Price is affected similarly. Random price generated DIVIDED by base multiplier, divided by news modifier. So price 10 /.5/1.5 = 13.33 price (idea being small base, less supply so higher price, high supply news article increases price).

In MP, when player two accesses same planet, the random generation occurs again, representing the (presumably) 100s to 1000s of other NPCs (and other players) interacting at the base at the same time, providing slight variation per player, but still within a reasonably arguable limit of each other.

From the MP perspective, we avoid the requirement to have a huge lookup per player at the same base (i.e. accessing same file), but each player gets a similar result.

[targ collective]

At last, a reply! Hallelujah!

As far as the trading model was concerned, I was thinking of bases or planets simply storing the percentage and using that globally for all players, factoring calculations for price from shortages/surpluses as a check when docked. In a case of shortage, the game would store the percentage as .23 or .54 of the maximum value. Each time a player docks the game would check to see if the shortage still applies, and adjust the price to suit.

Surpluses would be much the same, but stored as values greater than 1 - say 1.25 to 1.54 of the maximum or whatever.

If each player has individual trading tables that they use in multiplayer, which seems to be what you are proposing, then why not offload the generation of these tables to the individual machines? Personally I've always liked the concept of other players affecting the universe as well though - if I see a player's Clydesdale coming out of orbit I expect slim pickings. Total cargo in each base could be multiplied by players in game to accommodate for this.

If you want individual trading tables for each player then something like this will be needed...

[Silverain]

At last, a reply! Hallelujah!

I've known that feeling.

If each player has individual trading tables that they use in multiplayer, which seems to be what you are proposing, then why not offload the generation of these tables to the individual machines? Personally I've always liked the concept of other players affecting the universe as well though - if I see a player's Clydesdale coming out of orbit I expect slim pickings. Total cargo in each base could be multiplied by players in game to accommodate for this.

Sorry, I was actually referring to a couple of reference documents that are referenced by your server to generate prices on the fly, not individual reference documents.

That is, when you access the trade screen, the server (at that point) generates from a reference document what that base type has in terms of trade goods to sell, and demand for purchase. It then could reference a second document (say universe.xml) to determine modifiers to that baseline (because of planet size etc), then reference news for additional modifiers (suplus on x mining base!). This information is used by your local computer (stored in RAM basically) for you to personally interact with, firstly by your local generating the random numbers (if any) [this could be done by the server, but I was thinking of reducing overhead on ther server where possible]; and secondly by you actually interacting with buy/sell orders.

I suppose it comes down to our central server capability.

If it could handle maintaining, updating and storing a document that references each and every base in the universe, by name, we could have all we wish for. This document is constantly updated with buy/sell information from us, the players, plus information from NPC traders. While we - the player - are in the trade screen, we receive constantly updated buy/sell information that the server sends from this document, so we see realtime figures, which we interact with. As we interact, it updates the document, then resends that information to all players.

That sounds, to me, an absolute horror both on computation processing on the server, and dataflow over the net to each player - would be great if we could have it though.

I was looking more on having as little load bearing as possible instead. Unfortunately, what I was thinking of doesn't allow for other player/NPC alteration of figures.

Is there some middle ground? Could we get input from the coders on:
1) from the coding POV, what level of processing could be implemented fairly easily?;
2) from the server perspective, what computation load and net data transfer limits do we have?

That type of information would give us limits within which to design our processes.

As far as the trading model was concerned, I was thinking of bases or planets simply storing the percentage and using that globally for all players, factoring calculations for price from shortages/surpluses as a check when docked. In a case of shortage, the game would store the percentage as .23 or .54 of the maximum value. Each time a player docks the game would check to see if the shortage still applies, and adjust the price to suit.

Surpluses would be much the same, but stored as values greater than 1 - say 1.25 to 1.54 of the maximum or whatever.

On re-reading, this sounds like what I am talking about. The base/planet stores the percentage (modifier) in universe.xml for basetype size and in [reference document] for basetype itself, and uses that to produce a global calculation of price. Then factor shortage/surplus from news on dock (I suggest a timestamp check, such that news only has an effect from timestamp plus say 1/2 hour, where if you dock after that timestamp, that news article doesn't enter the calculation).

Maybe extend the timstamp to somehow include player/NPC interaction? Could this be included with exploding the overhead?

[Silverain]

Not sure if they are still around, but way back I created a reference document that tabled each basetype horizontally across the spreadsheet, with each cargo vertically. I then input price ranges and product number ranges for both supply and demand for each basetype. Example numbers of course, to be tweaked by testing.

Bear in mind this was singleplayer only.

My idea was your computer (during play) would reference this document when you accessed the trade screen, calculate the random numbers of price and product for buy and sell, then display this on your computer. After each transaction, it would update price and product (I think I had in mind that product number would affect the price range). In addition, news would provide temporary modifiers to either/both price and product number.

The only thing I didn't include was direct interaction from other traders, being single player only. Instead, I 'hid' this be having the computer recalculate the numbers each time you re-entered the trade screen (basically, including but not modelling the buy/sell functions of NPCs, plus usage of the product by the base itself).

[Silverain]

I'm trying to picture how we could design the system, to allow for future expansion. That is, when VS is an online MP game with 1000s of players online at a time. Well, why not eh?

Should the server hold all this information? Should it calculate it? Should it send out this information? How often?

Of course, the more processing, the more high end machine, the costlier it is. The more dataflow, the bigger the dataflow pipe, the costlier it is...

The more local machine does, the more open to hacking the game becomes.

[chuck_starchaser]

Silverain, frankly I don't care at all for multiplayer gaming, myself; but couldn't resist... The way to minimize server load is to think single player, and then add server checks and synchronizations only when absolutely necessary, and with minimal data (of course). That is, you land on a planet, go to the trading room. As soon as you click on the room a request is sent to the server for prices there. If there's another player there, the server replies with a price list. If there isn't another player there, the server simply replies "nobody here". Just one single bit. Then the client is free to make up a price list.

As per the topic of the OP, I think the ideas there are 100% good, bar none; but it seems to me, nothing that's any good will ever again be implemented for the VS engine if it has to be massively multiplayer compatible. There's a reason why most massively multiplayer games are crappy arcades: Synchronizing complex universes is an astronomical problem; and it requires powerful servers, which someone has to pay for.

As far as cheating and all that, that's a whole other problem that needs to be addressed separately and globally, rather than worry about it at each step of the way. I've no suggestions there; IMO it boils down to either a non-open source server executable running on big, powerful server farms that people pay to log into, to help pay for them; and which keep *everything* synchronized, including savegames; --plus check for cheating in various other ways...; or else you have a distributed and free system that's going to be hacked, without any doubt. I don't think you can have your cake and eat it too; but I've been wrong before.

I couldn't overstate my low opinion of the whole multiplayer thing; --not just from feasibility but from desirability concerns too. But I think the facts speak for themselves: Nothing much new in the engine for the whole past year, as every effort is devoted to this all-consuming pursuit few players care for anyways (1); and any good ideas that present themselves, like as per the OP, must be sacrificed as blood offerings to the multiplayer god. But, IMO, the multiplayer god is a hungry god that's not satisfied with ideas; and it will eventually eat the engine itself...(2)

I think that implementing just a fraction of the ideas of the OP would do more for the VS game AND engine than the best multiplayer implementation on Earth. But that's just my opinion.

Great post, Collective. Wish you success.

(1) If you don't believe me, consider this: spiritplumber implemented a multiplayer version of WCU, a few months ago; and she posted in the forum for like two weeks, asking pretty please for someone to play with her, for game testing purposes, and couldn't get a single volunteer (I refused on principle, but, nobody else?!)
(2) A metaphore for "engine becoming obsolete as its developers are spending years trying to make it multiplayer".

[Silverain]

Silverain, frankly I don't care at all for multiplayer gaming, myself;

Is my WoW addiction showing?

but couldn't resist... The way to minimize server load is to think single player, and then add server checks and synchronizations only when absolutely necessary, and with minimal data (of course). That is, you land on a planet, go to the trading room. As soon as you click on the room a request is sent to the server for prices there. If there's another player there, the server replies with a price list. If there isn't another player there, the server simply replies "nobody here". Just one single bit. Then the client is free to make up a price list.

I can accept that. So if I land and check a trade screen, it queries the server (my computer for SP, LAN server or whathaveyou server) if anyone else is accessing that base's tradescreen. If not, negative answer back to me. My client then generates the information itself. If there is... what? query the information the first player's computer calculated and pass it on?

As far as cheating and all that, that's a whole other problem that needs to be addressed separately and globally, rather than worry about it at each step of the way. I've no suggestions there; IMO it boils down to either a non-open source server executable running on big, powerful server farms that people pay to log into, to help pay for them; and which keep *everything* synchronized, including savegames; --plus check for cheating in various other ways...; or else you have a distributed and free system that's going to be hacked, without any doubt. I don't think you can have your cake and eat it too; but I've been wrong before.

I personally don't have a problem with paying a server farm to maintain a game online for me, since I'm subscribing for the online access to ONE virtual world; I think the open-source license is all about being able to access and change the code of a game (could be wrong...). You still have the ability to play a private server version, or just play your own SP version.

Of course, if I was paying a server farm, I would expect them to keep *everything* synchronised, as you mention.

As per the topic of the OP, I think the ideas there are 100% good, bar none; but it seems to me, nothing that's any good will ever again be implemented for the VS engine if it has to be massively multiplayer compatible. There's a reason why most massively multiplayer games are crappy arcades: Synchronizing complex universes is an astronomical problem; and it requires powerful servers, which someone has to pay for.

I couldn't overstate my low opinion of the whole multiplayer thing; --not just from feasibility but from desirability concerns too. But I think the facts speak for themselves: Nothing much new in the engine for the whole past year, as every effort is devoted to this all-consuming pursuit few players care for anyways (1); and any good ideas that present themselves, like as per the OP, must be sacrificed as blood offerings to the multiplayer god. But, IMO, the multiplayer god is a hungry god that's not satisfied with ideas; and it will eventually eat the engine itself...(2)

You hit the nail on the head regarding the gameplay I think.
I suppose we need to determine (at least for the VS universe) are we going for:
1) single player fully functional space sim play, with the added bonus of death match style MP (basically, a finalised version of what we have now);
2) increase (1) with co-operative play missions somehow;
3) MMO style like EVE Online where it is player persistent universe only;
4) MMO style but where players are a cog fitting in with the NPC universe (it goes on without the players)

Once we have that idea answered, we then know how far we can go (our design limits) to impliment how a system can work, and then creativity can take over.

[Silverain]

The economy should be governed by time. So profit/time from bounty hunting should have only a slight lead on profit/time trading independently, and profit/time on trading missions should be more or less the same as profit/time in bounty hunting.

No arguements here, no option should be more successful, more quickly than another. Defeats the purpose of having a choice, otherwise.

The economic model should be tiered according to cost. The tiers should be based on the class of ship flown. A rough sketch of what the tiers should look like, now - Fighter (everything short of the Mule), Corvette-Class (Mule, Corvette etc) Light Capship (Ox), Medium Capship (I see the Clydesdale here), Heavy Capship, Destroyer.

The player should take approximately the same time to ascend to each tier. The profits each tier give should be approximately five, ten times the previous tier. Each tier should have at least one bounty hunter and one merchant representative. The costs to upgrade and maintain your ship in each tier should, however, have a slight lead on the previous tier relative to income for that tier.

I think I follow you on this. Something like your bottom of the line class ships, whether hunter or merchant or hybrid variants, produce roughly the same profit, and same timeframe to generate enough cash to move up to the next tier. You then choose your ship, whether hunter or merchant and repeat. Fighter you would split into Light (bottom of the line), Medium (ships of the line) and Heavy (advanced prototypes) - ah, I'm changing their current meaning, sorry, but trying to get a grasp of the concept.

Something more advanced, now, which will require changes to the engine to implement.

The trading model could use an overhaul. I propose that planets have, in addition to the trading values already used, goods they import and goods they export as indicated by another (Boolean) value assigned to cargo. Planets should stock enough goods to allow for trading at each tier (so planet stocks would need to be increased by the thousands).

Pretty much what I have mentioned (I think). Just a different way to implement. Now, tieing in a few ideas from a couple of threads, you could also assign a value based on your tier of ship, that determines access to a higher cargo number.

Example
Tier 1 ship (value 1) gives access to 1 times the default cargo
Tier 2 ship (value 2) gives access to 2 times the default cargo
Tier 3 ship (value 3)....
Tier 4 (corvette) (value 5?)...
Tier 5 (light cap) (value 10?)...
... adjust values as necessary via tweaking.
Use something like this, so your intial trader is not accessing thousands of high value cargo at one time, but can only get a couple of leftovers as cargo. As you get 'higher', the bases are more willing to do bigger deals with you (see conversation in a couple of other threads).

Orbital installations are by their nature more specialised in what they buy and sell. Therefore pre-capship players and perhaps light-capship players should get more bang for their buck in orbital installations, with higher profits for mere hundreds of thousands of cargo units of goods, as opposed to millions or hundreds of millions of units to trade with smaller profit per unit but greater profit overall due to commute time saved and mass of cargo. The engine would need to be able to cope with these figures without resorting to exponents.

Sorry, what do you mean by exponents? Exposing ignorance here

Most importantly, bases and planets should produce and use goods in real-time (say at 100/sec for asteroid bases, 10000/sec for planets). Goods should not increase beyond a ceiling or plummet below a bottom line. There should be an increase in cost when a planet or base is running low on a good it produces. There should be a decrease in payoff at a base or planet when there is oversupply. The difference in a trade should never go into the negatives, with a ceiling on high costs and a bottom line returns will not go beyond. Nevertheless it should be more profitable to sell goods which are in demand than goods which are filling the warehouses.

Production and use over time might be a bit too difficult to model - not arguing against it, just not sure if it would be that necessary. I had looked at this myself, and came up with the basic idea of (for a base's demand side) generate a random figure of product required, and this as some sort of percentage or deviation from the average of that random number range affects the pricing determined - again a random number in a range, that is modified by the demand % adjustment. Then price can be adjusted further by news articles etc.
From supply side (product we buy), randomly generate a number of product in a given range, which determines a % adjustment; randomly generate sale price which is adjusted by % adjustment where more in stock reduces price by %, less in stock ups price.
A couple of different ways to achieve the same point, I suppose.

Taking the above paragraph into account, a fully upgraded Milspec Plowshare will have 4800 cargo units. Since the commute is usually more than 4800 secs, it won’t make a dent. That’s realistic. A Mule has a cargo capacity of 200000. That’s 20000 secs, and even with a mule the commute won’t take that long. You’re starting to make a dent and feel profits fall off a little, though you’re still making more money than you would planetside.

I think you are meaning here, production absorption by the base. I sell 4800 cargo, then my round trip to collect more of that cargo and bring it back takes longer than that base to use my last delivery. So my sale price is back to where it was for the first delivery. Selling 200000 cargo, though, means when I come back there might be (say 100000) left, which deflates my sale price. Is this as you pictured it?

EDIT: I seem to have stumbled on the 'economy petri-net idea'. Sorry. It's still an important part of this list, and as I'm suggesting an arbritrary used/produced list with set value changes per tick rather than units produced by units consumed per tick, it should be manageable. Rather more difficult would be the dynamic price changes - however, as the universe proper is not simulated when in dock the resources that would normally go into this could be put into these calculations.

Enter the Ox (which should be priced, incidentally, to take into account rising a tier to light-capship, as well as future earnings). Now those little orbital stations won’t even rattle in your capacious cargo holds, so you’ll make more money from interplanetary trade.

You went beyond my conception with implementing the value changes per tick, whereas I was assuming usage. Something like:

1) assumption of usage, so when you return, the game just randomly generates the numbers (within set ranges) again. Can get different numbers, but always within a certain range (modified by news).
2) value used per tick (base demand) and value produced per tick (base supply) to recalulate pricing after you have sold/bought from that base (to implement some notion of time relating to supply and demand).
3) connect value used and value produced (petri-net). Requires extensive modelling to make sure we don't get any hang-ups.

3) would probably be too much, 1) adequate and 2) good but requires extra coding work.

More to come

[chuck_starchaser]

I can accept that. So if I land and check a trade screen, it queries the server (my computer for SP, LAN server or whathaveyou server) if anyone else is accessing that base's tradescreen. If not, negative answer back to me. My client then generates the information itself. If there is... what? query the information the first player's computer calculated and pass it on?

Exactly. First player that enters an uninitialized (unoccupied) trading room shares its generated price-list with the server. Subsequent players get the price list from the server. Once the system is no longer occupied, after some time the occupancy status is reset and the price-list data deleted.

I personally don't have a problem with paying a server farm to maintain a game online for me, since I'm subscribing for the online access to ONE virtual world; I think the open-source license is all about being able to access and change the code of a game (could be wrong...). You still have the ability to play a private server version, or just play your own SP version.

Me neither. If I cared enough to play a multiplayer game I wouldn't mind paying for server upkeep. Quite understandable. I'd even go as far as suggesting the devs make themselves some profit out of it. Nothing wrong at all with making money. Precisely, open source is about being able to mod the client. Nothing else is implied.
But will VS Multi-Player succeed, as a multiplayer game? That's the five dollar question. I don't think so. Much less generate an income.

You hit the nail on the head regarding the gameplay I think.
I suppose we need to determine (at least for the VS universe) are we going for:
1) single player fully functional space sim play, with the added bonus of death match style MP (basically, a finalised version of what we have now);
2) increase (1) with co-operative play missions somehow;
3) MMO style like EVE Online where it is player persistent universe only;
4) MMO style but where players are a cog fitting in with the NPC universe (it goes on without the players)

Well put. Nothing can be implemented without a clear goal, in the first place. And your four categories are in fact so different they are like completely different animals: You couldn't start by implementing 1 and hope to gradually upgrade it to 4, I don't think; and, personally, number 4 is the only one that would interest me, as a player; but it's enormously hard to implement.

Once we have that idea answered, we then know how far we can go (our design limits) to impliment how a system can work, and then creativity can take over.

I would just say "forget it". Creativity will do nothing with something like deathmatch, because there's nothing to do with it except to deathmatch. There are a gazillion more interesting things that could be done with the engine, many of which would be orders of magnitude easier to implement than even the stupidest deathmatch mode, such as magazines to read in-game... A text interface, like for reading VS universe history IN the game, instead of in Acrobat.

3D bases and ship interiors, atmospheric flight, planetside walking, multiple choice conversations, chatbot ai, in-cockpit trading, emails and and distress calls, realistic damage representation, capships that blow up in a series of internal explosions spewing debris, garbage around stations, better asteroid fields (stationary but denser, using hardware fog to reduce visibility and to avoid having to draw too many asteroids), simulated economies, improved pilot ai, squadron commands, first person strategy, strategic theater displays for capship commanders, in-game books and magazines, subscriptions, a personal inventory, a personal notebook or pda, a contact list, NPC personalities that could become friends or contacts or that join you on a quest, hiring NPC's as gunners, cargo ships you can contract (a la Privateer 2), business ownership, ship design, modular missiles, improved damage system (distinguishing between piercing and explosive and irradiative), improved radar (active and passive, and various sweep modes, various frequencies: infrared and microwave), autopilot, HUD display modes --such as landing mode, that shows a crosshair for where to turn and/or speed error indication), better ways to define faction relations than just a number ranging from love to hate (such as marriage of convenience or enemy of my enemy, and separating race from profession from personal beliefs, rather than mixing them together in a one size fits all "faction" attribute), decoupling nav computer friend-foe heuristics and coloring from actual pilots' attitudes (e.g.: Confeds that are *officially* enemies because you killed a *corrupt* high official, for example, so they show red on the screen; but who personally idolize you for it and would even come to your defense), easy ways to define professions (so if a mod needs to define a "news reporter" or "explorer" jobs they don't have to code them in C++ or Python), putting all the rest of the stuff in xml files into easier to work with csv files, improving system representation so it can't be inconsistent, and better system generation, lipsynching, improving the random news generator or getting rid of it, optimizing savegames by removing news from them, ship boarding, and fixing bugs, like the upgrades space, not to speak of cleaning up and documenting the code ... I could go on and on and on...

How about in-game arcades you can walk into, planetside, where you can play deathmatch with other players online? That way you don't need separate executables; and it puts arcade gaming in its place...

Not to speak of the great ideas by the OP; plus the kind of ideas the Privateer Universe forum people have been implementing, of cargo mass affecting your acceleration...

All these ideas and many, many more, have been appearing in these forums again and again for like the past 3 years, and zilch's ever done about them because they have to wait for multiplayer... --a feature NOBODY asked for. And this is no exaggeration: People have asked for particular multiplayer modes, from time to time --usually the MMORPG type things; but I can't remember a post ever where someone said "I want multiplayer". Not that my not having seen such a post means there wasn't one; but this I can say for sure: multiplayer is nowhere nearly as recurrent a request as many others, by any stretch. So, frankly, I just can't see where this obsession with multiplayer comes from.

But even if we assume the coding of it succeeds, there's no guarantee VSMP will become a popular multiplayer game. The matter you brought up, of security, is paramount: Cheaters RUIN online gaming for everybody, and you can't prevent cheating without intrusive servers which have to be powerful and cost an arm and a leg. So you'd have to charge for online access; but you can't charge for a stupid deathmatch in space, taking place in a boringly homogeneous universe, and where there's not even a story except in pdf format. If VS-the-game was a popular hit, as games go, I could understand a multiplayer feature might take that popularity to orbital heights. But we're talking about a perpetually unfinished game (and by that I do mean it WILL NEVER be finished; hope I'm proven wrong, but I doubt it) that only attracts the casually curious. That's not a marketing recipi for a commercial online gaming venture using pricy servers. So it boils down to free, distributed servers, which by definition WILL be hacked, from the start, ruining what little joy there might have been.

To me this whole thing is a pointless exercise that is like a self defeating excuse for not doing anything good at all with the engine. Just a standard phrase to justify dismissing every suggestion ever presented in this forum: "can't do this, can't do that, not multiplayer compatible, we'll implement that after multiplayer..."; and the years keep rolling by...

[Shissui]

@Chuck & Silverain:
Currently the VS economy has a design constraint that: "because the universe is so big, we cannot retain data from one trading session to the next." You require for this policy to change before any of the models that you are discussing can be considered.

If you can propose a model that minimises retained state data, then it has a great deal more potential to actually get implemented.

[ace_garp]

Shissui,

Apologies for the laziness but I'm new to VS and I'm not sure where to look for the info myself. What data does the game currently store about bases, planets, locations, etc? I'm talking about data that is retained between game sessions, so presumably it's written to one or more of the game files.

I think there's a way you could acheive a more dynamic trading model that responded to player(s) actions in a semi-intelligent way which would only require the game to store a single integer for each cargo type for each location - does that constitute too much data to retain between sessions?

Ace

[chuck_starchaser]

@Shissui:
Indeed.

@Ace:
Not sure how you could get away with a single integer, but a few numbers might suffice, like offer/demand of product *categories*, rather than individual products, or having room for just one individual product special situation, plus a seed for a random number generator used to perturb the prices. The way the current save game is implemented is horribly inefficient: If you look at it, 90% of its size is "news", saved as plain text; --completely useless, since no one but a clinical masochist would even bother to look at the news in the first place.

[Shissui]

Apologies for the laziness but I'm new to VS and I'm not sure where to look for the info myself.

No apologies required -- you have nearly 2GB of data to poke through if you do it the hard way. Additionally, the data you are looking for is not even in the application directory.

What data does the game currently store about bases, planets, locations, etc? I'm talking about data that is retained between game sessions, so presumably it's written to one or more of the game files.

Let us focus on data that is retained from quit/restart.

All of these retained data are in your home directory in a hidden directory. VS, the SVN version & each of the mods all use variations in naming conventions to allow the directories to cohabit in your home directory. The exact data saved is only a bit different from mod to mod. Consider the following, for the 043 release:

Code: Select all

!3=LeopardDisk:~/.vegastrike043[shissui]> ll
total 232
 0 drwxr-xr-x   2   shissui    204  6 Mar 16:04 -Screenshots/
 0 drwxr-xr-x   9   shissui    510  6 Mar 16:04 ./
 0 drwxr-xr-x@ 18   shissui    918  4 May 09:55 ../
16 -rw-r--r--@  1   shissui   6148 24 Feb 00:11 .DS_Store
 0 drwxr-xr-x   2   shissui   6562 17 Mar 15:53 generatedbsp/
 0 drwxr-xr-x   3   shissui    306 31 Mar 23:00 save/
 8 -rw-r--r--   1   shissui      1 17 Apr 14:06 save.4.x.txt
 8 -rw-r--r--   1   shissui      9  6 Feb 09:29 save.4.x.txt.new
 0 drwxr-xr-x   3   shissui    136  3 Mar 15:09 sectors/
 0 drwxr-xr-x   8   shissui    340 31 Mar 23:00 serialized_xml/
 8 -rw-r--r--   1   shissui    298  3 Feb 13:13 setup.config
 0 drwxr-xr-x   2   shissui     68  3 Feb 13:15 sounds/
 0 drwxr-xr-x   3   shissui    306 31 Mar 00:44 textures/
96 -rw-r--r--   1   shissui  45533  6 Feb 09:29 vegastrike.config
96 -rw-r--r--   1   shissui  45533  6 Feb 09:29 vegastrike.config.temp

At the moment, we are only interested in a few of these --

"save/" contains all of your saved games. The saved game file has, for each game --
• your system & sector & absolute location within that system, current cash, current ship, other ships in your fleet & their system:sector (but not location in that system), . . .
• the stardate, a variety of news switches, a list of visited systems, campaign state (or states), the news that has been reported, . . .
• the location of every (durable) flightgroup & base in every system, . . .
• the current faction relations table, and a list of systems that have changed ownership.
--> In a "small" universe, like Privateer's Gemini sector, the news will be the biggest part of the file. However, in VS proper (with over 4000 stars), this file will be dominated by ship & base locations...

"serialized_xml/" contains all the data for your ships, in a subfolder for each save game & then a file for each ship. Your cargo is stored in the current ship. If you change ships from a smaller to a larger ship, your cargo goes with you. If you change from a big to a small ship, it starts at the bottom of your list & fills your hold, then leaves the remainder on the bigger ship.

"sectors/" contains system data for those systems that you have visited in any saved game for that mod of VegaStrike, and is used in common for all of your saved games in conjunction with the list of visited systems from your particular save game. The planets, jump points and bases of a given system will orbit each other, given enough time [you can find a good vantage point & hit time compression a few times to observe this]. SO, there is a fair bit of data in each system file. However, it does not include any reference to anything of so fleeting durability as a human base.

I think there's a way you could acheive a more dynamic trading model that responded to player(s) actions in a semi-intelligent way which would only require the game to store a single integer for each cargo type for each location - does that constitute too much data to retain between sessions?

The correct place for economic data, if any were to be retained, is in your specific game save file. These files can easily reach 5MB or more (per game) and there is some degree of fear that if economic data were also retained, then that the file would grow appreciably larger.

My point was that current policy says that *nothing* shall be retained. Thus, the less retained data demanded by a new model, the more willing that people might be to consider it and a model that requires no retained data that is not already saved would be looked on MUCH more favourably.

[ace_garp]

Thanks for the explanation Shissui. I did have a poke around in the game files over the weekend and found the save file - my first thought on the current structure was "Interesting...". The one thing I couldn't find actually, and I'd be grateful if you know the answer because its important for what I'm going to talk about is where and in what format the players current cargo manifest is saved.

As far as I can tell without poking around in the source code (which will have to wait till I figure out SVN) the current trading model works by having a defined list of goods available at each location type, along with a price multiplier for goods bought and sold at that location...I think. There's probably a fair amount of random elements in there as well.

Now, if we take Targ's point the whole point of trading is to assist the gameplay so what do we want the gameplay effects of trading to be? I'd suggest something along the following lines:

1)Players should be able to progress in the game, gain better ships, etc through trading. Since trading is less risky than fighting it should probably take longer to acheive the same gains by trading than by fighting.
2) It should require a degree of skill and judgement to make maximum profits - prices should obey a set of rules that players can learn over time, not be purely random.
3) The trading model should encourage travel and exploration. In general, players should receive a greater reward the further the distance they trade over.
4) The greater the risks the player takes to make a trade the greater the reward should be - trading in dangerous systems, warzones, with enemy races, etc should all be more profitible than milk runs in peaceful systems.

My original proposal was going to be to store the quantity of each type of good at each location between sessions - you could then do the things targ was suggesting about having goods be consumed / created at a set pace at each location which would let the players actions over time influence the price of the goods.Thats still something to consider, but I think there's a simple change that could be made that would allow the trading model to become more complex than it is now without significantly altering the amount of stored data.

SUGGESTION - for each unit of cargo purchased by the player store the location/system/sector that the cargo was purchased from.

With this information you could then apply a whole range of multipliers when the the player comes to sell the goods, eg:

Assuming goods from remote systems will fetch a better price than locally produced goods you could apply a multiplier to the price based on how far the system of origin is from the point of sale.

Assuming alien goods will fetch a better price than goods from the buyers own culture you could apply a multiplier based on the respective races / factions of the goods and the buyer. This multiplier could be influenced by the relationship between the two races (if two races are at war the exchange of goods between the two is likely to be very rare and therefore push up prices?)

Assuming nobody's going to buy back second-hand goods for the same price they just sold them a multiplier could be applied if a player tries to sell goods back to the same place they bought them from.

There's some other factors I think could be added in without too much complication:

If a system is in the middle of a war or other crisis prices are likely to be affected. Players could be able to buy goods very cheaply in a war zone, and sell at very good prices.

The price the player receives could be affected by the players relationship with the race/faction of the buyer - its always annoyed me in games that your player can be mortal enemies of a particular race but they're still happy to sell you stuff at a decent price. Less important this one, it just bugs me.

In general I like the idea of applying as many modifiers to the price as possible. As I see it the economy could function in a very simple manner:
1) Every good has a base price
2) Every location has a list of goods they produce, and goods they need. If a location needs good multiply the base price by more than 1 - if they produce it multiply by less than 1.
3) Apply a multiplier based on the size of the location - goods will be in more supply (and cheaper) at bigger locations. Again, multiply by more than 1 for small locations, less than 1 for big locations.
4) Apply a multiplier based on the players relationship with the faction/race that owns the base - for a good relationship give the player a better price, for a bad relationship make it worse (oh this is assuming that players get different prices for buying and selling - see my other post in the Contributors how-to forum on that point)
5) If the player is selling goods apply a multipler based on the system / race of origin of the goods he's selling
6) Apply a modifier based on how dangerous the system is - this could be done by hooking into the news system as suggested by other posters

By the time you've got through all that what I think you'd have is a system that generated complex results, in terms of the prices it gave, without actually being that hard to implement or requiring much in the way of data to be stored between sessions.

Things it wouldn't address:

1) The impact of the player on prices. I'm with the camp that says the player SHOULD be able to influence prices - I think space transport is so dangerous in VS its going to be used as sparingly as possible, which means goods shipments aren't likely to be that frequent or reliable. To model this though you need to retain the stock level at each location in the save file, which is potentially a lot of data.
2) The issue of scale, and how you handle the potential big disparity between the cargo capacity of different ships / players. I quite like the idea of actually having two trading systems at a location, one for small traders (say < 1000 units) and one for big traders. that way pricing, stocks, availability, etc can be different for players with different ships. (In fact I'd go further and have 3 trading systems, one for small traders, one for large traders and one for contraband but thats just me)
3) Little things about the current system that annoy me, like the use of decimal points in the prices (why? - just round it up or down) and displaying the quantity of a good in stock to the player (I know there's a gameplay reason for doing it in terms of the player knowing how much is available but its not realistic, and it would also be problematic if we did implement pricing based on stock levels at any point).

[Shissui]

The one thing I couldn't find actually, and I'd be grateful if you know the answer because its important for what I'm going to talk about is where and in what format the players current cargo manifest is saved.

First -- you will need a CVS editor of some form. References to several of these are posted elsewhere on this site. I will not recommend any, as I have not tried any. I view the data in OpenOffice & change it in emacs (2 windows on the same file).

Next. The file that you want is the ship that has all of your cargo. Usually that is your current ship, but it can be another ship if your current ship does not have the space to hold all your accumulated purchases. Open this file with whatever program you decided upon from the first paragraph

Go to the segment labelled "Cargo". Here, you will find all of your ship cargo AND installed upgrades AND upgrades available for trade --> Go wild.

. . . the current trading model works by having a defined list of goods available at each location type, along with a price multiplier for goods bought and sold at that location...I think. There's probably a fair amount of random elements in there as well.

Yes, except the random element may be smaller than you think. Trading is a bit more balanced in the recent SVN builds because there is a fair bit of work currently going into rebalancing these numbers.

*****
I really have nothing against your ideas. After all, I have argued very similarly in the past. But, here are some counter arguments to them that might as well be addressed now as later.

SUGGESTION - for each unit of cargo purchased by the player store the location/system/sector that the cargo was purchased from.

Certainly this is better than storing all of the cargo available for each of 100 or so items at 3-10 locations within each of 4000 star systems.

Currently, this too has some implications that would require appreciable changes to the legacy format. When you see how all of the cargo & upgrades are stored together, you may see that it would make this massively over used data field into an even bigger mess.

Then what happens when I buy a particular item at two or more locations? Currently, if I buy widgets from location A & also from location B, then they are pooled. If they are to be kept separate from each other, I will need a unique identifier for each source and a new format for storing data. Additionally, if I bought this cargo from a passing ship, I need to retain where that ship was at the time (as opposed to where it is now).

Assuming goods from remote systems will fetch a better price than locally produced goods you could apply a multiplier to the price based on how far the system of origin is from the point of sale.

OR, I could argue that your cargo of fish is *less* valuable than it was 5 systems ago because all of your perishables have perished.

Assuming alien goods will fetch a better price than goods from the buyers own culture you could apply a multiplier based on the respective races / factions of the goods and the buyer. This multiplier could be influenced by the relationship between the two races (if two races are at war the exchange of goods between the two is likely to be very rare and therefore push up prices?)

Or, I could look at you blankly & ask "why should I buy THAT junk from you? If we had any Rlaan to feed in this town, I would call up my friends & we would run them out."

Assuming nobody's going to buy back second-hand goods for the same price they just sold them a multiplier could be applied if a player tries to sell goods back to the same place they bought them from.

And, then, how am I to create an artificial scarcity by buying everything?.

If a system is in the middle of a war or other crisis prices are likely to be affected. Players could be able to buy goods very cheaply in a war zone, and sell at very good prices.

How do you intend to know if a system is in such a crisis ?

The price the player receives could be affected by the players relationship with the race/faction of the buyer

This is already done, but I think it could be done better.