40Rd1AYX

1Writeup of recent talk on the IRC about the economy.
2First relevant message: http://colabti.org/irclogger/irclogger_log/naev?date=2015-04-17#l8
3Discussion spans several days, until 2015-04-22.
4
5==Purpose==
6We want to create a relatively uncomplicated system that provides trading opportunities for the player. The system should provide the following:
7- Distribution of commodities across the galaxy, if at all possible without hardcoding this in the universe data itself.
8- Varying prices for each commodity by distance.
9- Time-based economic events.
10- A way to avoid structural get-rich-quick exploitation of the system.
11
12Peripheral:
13- UI for the player to gain information about prices and economic events, in order to make an informed decision about what to trade and where.
14
15Disregarded:
16- NPC trading.
17- Commodity dependencies.
18
19===Distribution and pricing===
20For distribution, I (BTAxis) have proposed elsewhere a layer of metadata for assets. In a nutshell this metadata is used to crudely model the long-term circumstances of each asset, which can then be used by dynamic systems such as scripts or the economy to make informed decisions about that asset.
21The most straightforward way to do this is by adding a list of arbitrary metadata tags to each asset. For example:
22 <metadata>
23  <pollution>10</pollution>
24  <fertility>-10</fertility>
25  <minerals>25</minerals>
26  <space_family_invalid/>
27 </metadata>
28The last tag is an example of how metadata can be used by scripts. In this (hypothetical) case the asset is flagged as invalid for the Space Family mission, for whatever reason. The tag does nothing by itself; it is up to the mission script to check if it exists.
29
30Given metadata for all assets in the galaxy (which will have to be manually created), distribution and pricing for commodities can be performed at runtime by a Lua script. The way I imagine it, this script is called when the player lands, and returns a table, each element of which is a table containing the name of a commodity, possibly the unit volume of the commodity, and the price of that commodity at this asset. If a commodity/price pair is not in the table, the commodity is not available for trade. (Alternatively, all commodities could be sellable everywhere, but only for standard prices that allow for reduced profit at best.)
31An opportunity exists here to get rid once and for all of commodity.xml, which is more hindrance than help at this point. If we treat a commodity name as its unique identifier, there need not be a fixed database for commodities at all. A planet will trade whatever commodities the script returns. If a player buys these commodities, a name/volume/quantity tuple is added to the save, where the name is the identifier used for trade logic.
32
33Though I'd love for things to work this way, there is a drawback to this approach, to wit there can be NO sanity checking of the player's inventory. Since no comprehensive commodity list exists it is impossible to tell if the player's cargo can be traded anywhere at all. If a player bought a quantity of "fewd" at a planet, and the name of this commodity is corrected to "food" in the script, the player can end up with a hold full of fewd that is unsellable. Perhaps a way around this could be to call the commodity script in a special way that returns a list of all the commodities it knows.
34
35''Requirements''
36- Arbitrary metadata XML tags
37- Lua API to read metadata tags
38- Commodity tab logic for calling a Lua script and using its output
39
40===Economic events===
41An economic event is a modifier that artificially inflates or deflates prices of one or more commodities at one or more trading ports. These modifiers will have to be explicitly stored in the player's save (unidiff really isn't suitable for this). The modifier will have to specify a start date, an end date, the commodity affected, and the adjustment of the price.
42I think we can do this entirely in Lua. A resident event can run a timer that contains the economic event code, while the effects of the events can be directly factored in by the commodity Lua described above. We only need a single extra tool, namely the ability to store arbitrary data in the player's save. In fact we already have a rudimentary tool like that, var.push() and var.pop(). These are not suitable for our purpose though, as we're going to need to store strings and, ideally, Lua tables.
43Additionally and optionally, we might want labeled mission markers for events. These can indicate the location of an economic event on the galaxy map, where the label tells the player which commodity is affected, and where.
44
45''Requirements''
46- Storage of arbitrary data in the player save and a Lua API to manipulate same.
47
48===Avoidance of exploits===
49A problem with (mostly) static pricing is that there will be some routes that are more profitable than others, which means a player can grind these routes and ignore all the others. So far we have identified these ways to combat this:
50
511) Smoothing over distance: by varying prices only so much per jump we can ensure the player will need to travel significant distances to turn significant profit. This does not seem compatible with the metadata-and-script approach outlined above, as that is all completely local and does not store economic information. Perhaps we want a different approach where the distribution is created at load time? If so, please specify.
52
532) Player induced price correction: whenever the player buys commodities the price for that commodity is adjusted upward. Whenever the player sells, the price is adjusted downward. The effect is that when the player runs a route, that route will become less profitable with each trip. These adjustments must be stored in the player save, and as time passes in the game they should slowly dissipate, returning the prices to normal. Care must be taken that the player should not be able to exploit this behavior by buying and then re-selling large quantities at a time. Also, this will have to be handled by the commodity tab's C.