# Designing a trade / market system

I'm working on an idea for a trading game. Players would be traders buying in place A and selling in place B, hopefully for a profit.

I want prices to be dynamic, based on demand and supply. So if place A produces less food than it consumes, prices for food would he high and getting higher the closer they get to running out, while in place B, which has much more production than supply, prices would be near the production cost (minimum price). But if someone buys up a lot of the supply in B, prices would rise, and if someone sells a lot in place A, prices would drop.

Obviously, there are many ways to game such a system if it's not well-designed. The most easy is to empty the market, wait for the price to adjust, then sell everything back.

How could I design this system? I mean the actual math and functions, not philosophical musings. I searched a lot and haven't found anything specific.

I found this question but it and its answers are a lot more specific to the specific formula the guy uses in his game. I'm looking for a more generic approach (I want different price elasticity for different goods, maybe non-linear price curves, etc.)

• @Tom also be careful of the buy/sell demand that you don't allow it to be exploited. There is an infamous exploit in Fable (See Easy Money) where you can buy a shopkeeps entire stock, then because the game sees that stock item as in low supply you can sell the stock items straight back to the shopkeep for large amount of money. Then because the stock is in high supply, you can just buy the entire lot back for CHEAPER than bought. Rinse, lather repeat. – lozzajp Dec 8 '16 at 13:51
• @lozzajp Incredible how I never knew that...I played the hell out of Fable. – Krythic Dec 14 '16 at 16:40

A far simpler, easier to implement and easier to balance solution than the other one I proposed before (although with less gameplay depth):

• Have a function NpcSellPrice(stock) for each commodity where stock represents how many units the NPC currently owns. Any implementation would do as long as more stock means that the NPC sells at a lower price. It doesn't need to be realistic. Design it so it fits your overall gameplay balance.
• Implement the formula NpcBuyPrice(stock) as NpcSellPrice(stock + 1) so the NPC will always buy for the price it would sell for if it had one more unit of stock.
• Only allow the player to trade in increments of one unit at a time and recalculate the price after each traded unit (UI-wise you can implement this with a button which trades as long as the user holds it).

That way prices will increase and decrease when the player buys and sells commodities, but when they trade it back they will end up with exactly the same amount of money they had before. The only way for the player to make a profit is if the stock decreases for some other reason than player trading while the player is holding on to commodities. For example, by traveling to a different NPC with a smaller stock.

When the player is the only active force on the market, the player can only make money by evening out the stocks of all NPC traders in the game. After all traders have the same amount of stock, there is no profit to be made anymore. To allow the player to constantly make profit, you need to introduce some entropy into the market.

An easy way to do that is by making some NPC's "producers" whose stock constantly increases over time (up to a cap) and other NPC's "consumers" whose stock constantly decreases. The player could then make money by buying at producers and selling at consumers. For example, a farmer would be a producer of grain while the nearby bakery would be a consumer. The player could make profit by buying at the farmer and selling at the bakery.

• I'm accepting this answer as the correct one because is gives the answer to the question that I asked. Other answers are good as well and give great information, but they kind of skirt around the issue. This is straight to the point, thank you. – Tom Dec 17 '16 at 4:34

The most easy is to empty the market, wait for the price to adjust, then sell everything back.

This implies that if the price for a unit of coal while there is 100 units left in stock is at 50 gold, and you purchase the whole lot of 100 units, you'll pay 100 * 50 = 5000.

That's not the correct way to look at it.

Games such as Port Royale 3 have this as a core mechanic: the price is adjusted per unit, not as a whole.

This means that the first unit you'll buy when there are 100 left in stock will be 50, but then, it will reduce the amount of what there is left in stock to 49. The price will increase to 51 for that next unit, and so on, until it reaches the maximum price.

Here is an example written in pseudocode.

With these input variables:

maxStockThreshold      // Amount of unit in stock equal to and above which the trade price
// remains constant, no matter how many units there are.
maxStockThresholdPrice // Price of the items when there are maxStockThreshold or more in
// trade station. The price should be discouraginly low. Incentive
// to buy from station.
minStockThreshold      // Same for the maxStockThreshold, but for the minimum
minStockThresholdPrice // Prices should be high: incentive to sell to the trade station.
amountInStock          // Amount currently in stock in the trade station.


In these methods:

getTradePriceForOne( amountInStock, maxStockThreshold, maxStockThresholdPrice,
minStockThreshold, minStockThresholdPrice )
if amountInStock >= maxStockThreshold
return maxStockThresholdPrice
if amountInStock <= minStockThreshold
return minStockThresholdPrice

// Otherwise, lerp, kiss
stockThresholdRatio = amountInStock / (maxStockThreshold - minStockThreshold)
return minStockThresholdPrice
+ stockThresholdRatio * (maxStockThresholdPrice - minStockThresholdPrice)

// amountDesired: positive -> buying from stock in trade station
//                negative -> selling to trade station
// return: positive -> the cost to buy the items
//         negative -> the amount offered when selling to trade station
maxStockThreshold, maxStockThresholdPrice,
minStockThreshold, minStockThresholdPrice )
amountDesiredLeft = amountDesired
amountInStockLeft = amountInStock
cost = 0
while( amountDesiredLeft != )
thisUnitPrice = getTradePriceForOne( amountInStockLeft,
maxStockThreshold, maxStockThresholdPrice,
minStockThreshold, minStockThresholdPrice )
if amountDesiredLeft > 0
cost += thisUnitPrice
amountInStockLeft--
amountDesiredLeft--
else
cost -= thisUnitPrice
amountInStockLeft++
amountDesiredLeft++


With that, the player can't buy everything and wait for the price to adjust because the market adjusts while he buys/sells.

Sometimes, while making a game, you have to abstract a bit of realism and twist it a bit to make it fun and expected. These rules are very stiff, but it makes the expectations predictable for the players, which is what you want.

You could model your ingame market to work in the same way real-world stock and commodity exchanges work: With actors placing orders.

• Consumers place buy-orders, reading "I buy X units of food for Y credits each"
• Suppliers place sell-orders, reading "I sell X units of food for Y credits each"
• The system automatically joins orders with each other where buy-price >= sell-price and resolves them.

These consumers and suppliers can be either AI actors or players. The published "market price" is the current average at which orders get resolved. But it is no guarantee that the player can actually buy or sell at that price, because their orders have to go through the same system. AI actors should experiment by first placing orders slightly worse than market price, and if their orders don't get resolved, make better offers. That makes sure that the market prices stay dynamic.

The quantities at which AI consumers place their orders should be influenced by price elasticity of demand. That means that the higher the market price, the less goods they will order. Different goods should have different elasticity values. For example, when there is a famine, people will still buy almost as much food as they used to, even at outrageous prices. But when the prices for jewelry explode, people will order far less because they can certainly live without a gold bracelet when it costs their whole life savings.

On the side of the AI actors which produce goods, you should also simulate elasticity of supply. A high market price means a higher profit margin for producers. This will motivate AI suppliers to invest into increasing their production, which results in more sell offers being posted, which again stabilizes the market.

This makes it hard for the player to corner the market, because even when they achieve a total monopoly on a good, they still can't sell more than people are willing to buy. So it will take time for them to make money, and in that time additional AI suppliers will appear who will undercut the player.

However, if the AI suppliers are physical entities in your game world, then it might be a viable strategy for the player to drive up the prices by getting rid of them. Likewise, they could reduce prices for commodities they want by getting rid of AI consumers.

• I've thought about that (EVE Online uses such a system), but it requires considerable liquidity in the market to work properly. I'm not sure I will have that, especially in the more remote trading posts. – Tom Dec 8 '16 at 13:56
• @Tom That depends on how many AI actors you simulate. A remote trading post might have a few hundred "virtual" colonists and hydroponic farmers who constantly place buy and sell orders as well as offworld food merchants who get attracted when food prices go up. – Philipp Dec 8 '16 at 13:57

The trading system is not that interesting compared to what you do. The basics is always buy low where there is supply, sell high where there is demand.

It's more important how you place your local resources and production specialities as well as how you setup the mechanics of demand.

Patrician 3 is a brilliantly designed trading game and I recommend to everyone to at least look at the resource map.

Supply and production is pretty straightforward, but demand is more complex and can make or break your game. Patrician 3 is also great here with 3 population types with their own demand. It is also good if you can tie demand with city growth and development like in Anno 1404.

In a trading game it's all about the fight against the players optimum. There is couple of ways trading games solve this. The last thing you want is something that is too reliable that the player can do over and over again. Investments can work to reap bigger profits reliably but in that case the economy has to scale to play with the bigger boys and higher stakes.

Some examples:

Have multiple ships all over the world tackling multiple locations.

Have danger along the way that might make you reevaluate your plans like Storms or Super Strong enemy fleets that can kick your ass. It's also good to have this information beforehand otherwise the player will push his way on regardless.

In Patrician selling is incremental(or averaged out) so the more you sell the more you satisfy demand so its efficient to not sell in just one place leading to the creation of trade runs.

In Patrician it takes some time to "digest" what you sold so you have to do runs with other products.

In Patrician your competition is also selling stuff so information is important, you can setup information networks and you want to have backup plans by going on a route where you can sell in multiple places along the way.

An information network can really break your trade game so its best to balance it with recurring costs, like crew costs and taxes if you expand too much.

Supply/production and demand is generally known in one location but the current state might not be, you can make some informed choices based on time, previous information, your surroundings and predicting your competition.

In Starsector "economic disruptions" I think are a mistake since they tell you too bluntly what your opportunities are. But that is circumvented somewhat by the encounters while traveling there and having an awesome combat. Thus efficiency comes in the form of how good you are in combat.

In Starsector it does well the economy of scale well since you can invest in large ships that move cheaper product in larger volumes.

In X3 Albion/Terran the economy has "holes" that you can fill up investing in the relevant station/factory.

In X3 equipment can be directly used for outfitting your fleet so the economy is not useful only for monetary reason but also for your combat potential.

In The Guild 2 the items you make you can sell on the market, they also have functions that the competition can use. If you buy all the antidotes and then poison your competition then they cannot heal themselves.

In The Guild 2 business also have simple input output system for their product. If you can monopolize and control the input, like buying the input resources on the market, taking over the farms that generate the input and controlling the harvest points with thugs you can starve a business.

In Battle Brothers enemy forces can raid towns and target traders on the road that affect the economy of the surrounding towns. Similarly in Starsector you can target traders and blockade a planet or sector by blockading the wormholes.

In a more complex game you can do this also with the output where you can use the desirability of your output that you have cornered the market in for political advantage. In other words in a game with factions and useful equipment like in X3 you can sell to a particular faction to equip them and give them an advantage(note:this does not happen in X3 itself).

Offworld Trading Company also does this type of manipulations.

Interesting economic games: Patrician 3, X3 Terran/Albion, Starsector, Factorio, Imperialism Series, Battle Brothers, The Guild 2, Anno 1404, Cultures/Northland, Tropico, Offworld Trading Company, Space Run, Galaxy Trucker, Food Chain Magnate(not necessarily a good game).