PiratePad
Full screen

Server Notice:

hide

Public Pad Latest text of pad GpNMG9108M Saved April 28, 2015

 
     
Writeup of recent talk on the IRC about the economy.
Discussion spans several days, until 2015-04-22.
 
== Purpose ==
We want to create a relatively uncomplicated system that provides trading opportunities for the player. The system should provide the following:
- Distribution of commodities across the galaxy, if at all possible without hardcoding this in the universe data itself.
- Varying prices for each commodity by distance.
- Time-based economic events.
- A way to avoid structural get-rich-quick exploitation of the system.
 
Peripheral:
- 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.
 
Disregarded:
- NPC trading.
- Commodity dependencies.
 
=== Distribution and pricing ===
For 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.
The most straightforward way to do this is by adding a list of arbitrary metadata tags to each asset. For example:
 <metadata>
  <pollution>10</pollution>
  <fertility>-10</fertility>
  <minerals>25</minerals>
  <space_family_invalid/>
 </metadata>
The 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.[ Implementation detail, but I think it'd be better to use a consistent element name and have the type be a property, e.g. <tag name="pollution">10</tag> ]
 
[it would be better to not have negative tags, such as space_family_invalid, because then every time a new asset is created, you would have to remember to put every negative tag into it.  space_family_valid is probably better; that way you add it only if you care about it. Well in the example I assumed that this tag would only be present on exceptions, so you wouldn't add it on everything, only on the things you're explicitly interested in. Pretty much what you said.]
 
Given metadata for all assets in the galaxy (which will have to be manually created) [speaking of which, would any of them be mandatory? Unknown! Still have to think about that some more.], 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.)
An 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 [What about name/quantity/bought_price, so that the UI can show how much profit/loss you're making when you sell?] tuple is added to the save, where the name is the identifier used for trade logic.
Note though, that we will also need to handle mission cargo, which is currently also listed in commodity.xml.  [What needs to be handled, exactly?  It either won't be tradeable, or will be but for zero creds, and you fail the mission, right? I mean in terms of making it work at all. Mission cargo currently uses Lua bindings that interface with commodity.xml. That would need to go. But yes, the things you mention need to be handled too.]
 
Though 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 "cats" at a planet, and the name of this commodity is corrected to "cars" in the script, the player can end up with a hold full of cats that are 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.  [Another way would be to allow unloading of any cargo anywhere at any time for 75~90% of the bought_price.  It doesn't really make "sense", but it fixes the potential gameplay/maintenance issue.]
 
Another drawback to using a land-time script is that we have no way of reasoning about the commodity distribution as a whole. It's possible for a moon to end up as a major importer of a commodity of its primary planet, for instance.
 
''Requirements''
- Arbitrary metadata XML tags and a Lua API to read them
- Commodity tab logic for calling a Lua script and using its output
 
=== Economic events ===
An 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.
 
I 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.
Additionally 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.  [This would be nice.  I assume also, that we can tap into the News of the bar tab? That's a given, but it would be best not to rely on that as a primary info channel.]
 
''Requirements''
- Storage of arbitrary data in the player save and a Lua API to manipulate same
- Labeled map markers, usable by events
 
=== Avoidance of exploits ===
A 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:
 
1) 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. [ My concern with avoiding procedural smoothing is that assets need to fit their local region to avoid high-profit, short-distance routes. If that smoothing is implemented manually in XML, relocating an asset (or system) becomes significantly harder. My preference would be to have sparse definitions on assets (dull, backwater assets might not have any special economic properties) with smoothing filling in the blanks and influencing the manually-defined values.  Is there any reason that implementing smoothing in XML instead of code would even be considered, though?  I can't think of any reason to not put that into code. ]
 
2) 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.  [Do you want to have seperate buy/sell prices, then? Well, maybe a 5% commission on selling or something, but it doesn't need to be handled explicitly. I just meant the thing Deiz raised, where you can buy low AND sell high at the same port.]
 
[ We could also have commodity price fluctuation be inversely related to base price, e.g. a commodity priced at 1000 might commonly vary by +/- 30%, while one priced at 10000 would be something like +/- 10%, which would incentivize hauling bulk quantities of low-value cargo. Ideally the most profitable routes would be through sparsely-populated, dangerous areas, so that mindless grinding in a safe area would be much less rewarding than more dangerous routes.  I would like to point out that with your example, the max profit per good for the cheaper one is 600 and 2000 for the expensive one, so unless you're lacking the creds for the initial outlay, that doesn't incentivise the cheaper one, so you'll need to be careful with tweaking the numbers. ]