# Building a (partially) player-driven economy based on demand/supply [closed]

I've got a rough concept for a trading game in my head and I can't figure out what seems to be basic math.

My cities / space stations / trading posts shall have the following rules:

1. supply and demand are limited
2. prices adjust according to it
3. players as well as NPC traders drive the prices

So the idea is that if X produces less food than it consumes, then over time the price of food rises, and when it's almost empty, it skyrockets. While Y is a net producer, and the price falls over time. This creates a trade opportunity Y -> X whose profitability depends on how many people run the route - if many people trade Y -> X then the prices equal out.

To ensure that players don't simply collude on hoarding food just outside of X, waiting until prices rise and then selling, NPC traders would jump on the most profitable trade routes to keep price differences and demand within reasonable parameters.

I've thought about storage sizes and how prices can swing, but every formula I come up with fails some simple tests. For example, if the total storage of X is 1000 units when the player arrives, he can just buy 500, wait for the price to rise, then sell it again - profit. Obviously, that shouldn't work.

I tried several searches both on Google and here and on Gamasutra and while I found some ideas, I didn't find what seems to me should be a simple formula.

## closed as off-topic by Aify, kingledion, Bellerophon, Hohmannfan, James♦Dec 5 '16 at 7:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "This question does not appear to be about worldbuilding, within the scope defined in the help center." – Aify, kingledion, Bellerophon, Hohmannfan, James
If this question can be reworded to fit the rules in the help center, please edit the question.

• This is related to Worldbuilding but it focuses on players and gameplay mechanics as opposed to, say, designing the economy in a novel. It may be better suited to the RPG SE. – Zxyrra Dec 4 '16 at 23:28
• It's not for an RPG, it's for a strategy game. Yes, it doesn't fit perfectly unless there's a Game Design SE that I missed. – Tom Dec 5 '16 at 0:20
• @Tom Sounds like the player economy in Eve Online. Maybe head over there and take a look. – Snowlockk Dec 5 '16 at 10:59
• I played EVE Online, and there are some similarities, but in EVE Online, the economy including prices is entirely player-driven, while I want to have trade with consumable goods (food, water, etc.) that is bought by NPCs, not by player characters. – Tom Dec 5 '16 at 13:46
• @ Tom: The Game Development SE seems to be a good fit, no? – Joe Bloggs Dec 5 '16 at 17:50

What you describe is a key reality of business. If you're willing to hold onto the right inventory, you make a profit. What you describe sounds like what's called "cornering the market." You buy up the entire market, wait for the demand to skyrocket, and then profit. Even if you don't fully corner the market, you're being paid for your efforts!

The real question is what does a town do when Player Moneybags comes into town and tries to buy up half of the food. What does that mean for each person in the town? Are they selling the food they need for winter? If so, prices may skyrocket when the snow starts falling. Or are they selling a surplus that would have rotted otherwise?

• Yes, I understand that. The easy way out is to put the amounts in the economy way out of players reach. If the town stores 1 mio. food, a player who can buy 1000 can't corner the market - but at that point, the economy is no longer player driven, prices will not fluctuate by any meaningful amounts, etc. - I'm exactly looking for a solution that the town would use to prevent its market being cornered. – Tom Dec 4 '16 at 6:54
• In your case you need to look at non-obvious costs. If I could buy 1000 tons of bread I could (for a short while anyway) corner bread in my city, and the price would probably go up. But when I try to sell it, I may be able to get a good price for the first loaves, but selling them will drive down prices, possibly below what I paid. Also, where am I storing my bread? Are rats eating or thieves pilfering it? Am I renting a warehouse to store it? What are the transaction costs (paying salespeople, transport costs)? Sufficient other costs may make it no longer profitable. – Mark Ripley Dec 4 '16 at 7:08
• There's a great idea there - make storage and available-for-purchase not the same number. There might be 1000 food available in the place, but they would not all be for sale, especially if production is lower than consumption. I already thought about transaction costs, together this might solve the issue. Still looking for math formulas. I can't be the first person to make an economics game. :-) – Tom Dec 4 '16 at 7:22
• @Tom you should also consider that, if you have 2000 players, the ability to buy 1000 tons of bread does drive the market. Individually they may not be able to corner it or influence it by much, but on the whole it will still be the players that drive the market. – Annonymus Dec 4 '16 at 13:16
• @Tom Look at EVE. They did exactly what Mark mentions. There's an entire caste of players who do nothing but find goods which are priced affordably at one place, buy up as many as they can before the price raises to be unaffordable, then try to sell it all off at a distant place. (And you can't just turn it around locally, because buy and sell prices are different) – Cort Ammon Dec 4 '16 at 16:31

"For example, if the total storage of X is 1000 units when the player arrives, he can just buy 500, wait for the price to rise, then sell it again - profit. Obviously, that shouldn't work."

This part of your question seems quite easy:

1) The price when player arrives is the equilibrium price, when there is 1000 units. If he buys 1 unit, there should be new equilibrium price calculated. If he tries to buy 500 units, then repeat this procedure 500 times, each unit more and more expensive. (very heavy processor use, I know, may try every ex 10 units or so) [I do not what are your starting formulas for calculating equilibrium price, so I can not make adjustment in any reasonable way]

2) Less processor heavy - on the market in any moment there is only part of goods offered - let's say 1/20. This is the maximum amount player can buy in any turn - next turn, next price

The tricky part - there is no easy formula for good algorithm for hoarding stuff for next turns by a city. It is all expectation based and anticipating actions of other agents.

(do you want an awful, simple one?)

### Delivery

Charge a fee for moving the items into and out of storage.

### Taxes

Charge a trading fee for each transaction.

### Different prices

In reality, people offer different prices for things. If you have 50 units of A for which you paid 1000, you don't want to sell 10 for 100 -- you lose money. But if you paid 100 for 15 units, you'd be happy to take 100 for 10. Anyway, if each seller has a different minimum acceptable price, then the total price is different. So if you buy 500 units, the price is higher than if you buy 5 units. Because you pay the 5 unit price for the first 5 units and then higher prices for more units.

You can make this work either by using a for loop with your pricing function where you price each unit individually, or you can average prices. The loop is more flexible and accurate but the average is simpler.

Price(500 of 1000) = 500 * (Price(at 1000) + Price(at 500)) / 2


or more generally

$$\text{price}(\text{quantity}_\text{desired}, \text{quantity}_\text{available}) = \text{quantity}_\text{desired} \cdot \frac{\text{price}(\text{quantity}_\text{available}) + \text{price}(\text{quantity}_\text{available} - \text{quantity}_\text{desired})}{2}$$

This will work best if your price function is linear. If it's something else, you may need more advanced math than a simple arithmetic average.

### Arbitrage

You are buying from and selling to warehouse owners. They don't want to sell to you at the same prices at which they buy. So they buy at one price and sell at another. The difference is their margin or profit. So create a margin factor, e.g. 1.1. Divide the sell price by the margin factor to get the buy price or multiply the buy price by the margin factor to get the sell price.

If you buy and then immediately sell anything, you will always lose money this way.