Devlog #2 - Simulating a Living Economy in Unreal Engine 5

I spent the last weeks figuring out how to simulate a living economy in UE 5.3 and today I want to share how I achieved that in Blueprints.

Most games rely on static vendor prices - NPCs always have the same prices, no matter how much of something they have in stock. Sell 20 pieces of fur to them and they will still offer you the same price for the 21st piece. I can think of only a handful of games that simulate supply and demand by actually making the prices dynamic.

If you are working on a trading or economic sim and want prices to change during gameplay, then this devlog might be interesting to you!

The Design Goal

With Cargo, I started with a simple premise in mind: every settlement produces 3 things, but needs to buy everything else from merchants: like your character.

What they produce, they have in stock and it should be cheap. What they don’t produce, they would offer you a high price for. However, if you sell a lot of good X to them, the price of that good should go down - if you buy a lot of good X from them, the price of that good in that settlement should go up.

A lot of Cargo’s other systems rely on this, like haggling (you can negotiate the prices) or the reputation system (it depends on if you are charitable, fair or ruthless in your haggling). And while the basic idea of market up- and downswings seems easy enough, implementing it was a different beast…

My approach

Charlie Czerkawskis book “Game Economy Design: Metagame, Monetization and Live Operations” gives a practical overview of the elements you need to design your game economy: among them are “sources” (something that produces things) and “sinks” (something that eliminates things).

In Cargo, every settlement has production units (the sources), which output a number of item objects per time period. I am using the super-handy plugin “Game Time Manager” by Lexsonn to spawn a charge of items at a specific time of in-game day. 

Example: A Blueprint BP AmmoWorkbench produces X number of goods at a specific production time (float)

Every settlement also consumes a number of items per day (the “sink”). The logic here is the same: A number of X goods is being deleted at a specific time of day because the population of a settlement consumes it. 

Additionally, the player can buy and then consume items (food, water, fuel etc.). Spoilage would be another way of taking items out of your economy, but I am not planning to introduce that in my game right now.

If you set up any economy, make sure you have both ends (production and deletion) securely covered, otherwise items will pile up and you cannot simulate any scarcity.

The problem

How to make prices react to scarcity? In order to learn more about that, I played (and reverse engineered) the economy of Patrician III, a trading game that was quite popular in the early 2000s. It is still considered to be one of the best examples of a simulated economy, because:

• Supply & demand are fully simulated: Prices emerge from production, storage, and consumption over time, not from static buy/sell tables.

• Prices react to volume: Buying or selling large quantities as a player shifts the prices

• Time is an economic variable: Waiting for production cycles or consumption waves is often more profitable than instant trading, which requires the player to use strategy.

Patrician III’s economy is very complex, and I want to focus on the basic takeaways for now (keeping my solo dev scope in mind). Let’s break it down in simple components with the example of “fuel”.

• “Demand” (Dt) = (ideal storage - actually in storage)  + consumption

  • The population of a settlement has a demand for a good, let’s say: fuel. They have an idea of how much they should ideally have in store (50). They check how much they actually have (20); they need 30 more than they have. They also consume fuel (let’s say 10). The demand in this case would be 40.

• “Supply” (St) = settlement storage + vendor inventories

  • Each settlement has knowledge about how much fuel they currently have - in store but also in the inventory of the vendors. The sum of all is the “supply”. Let’s say that would be 20.

• Base Price (BP): I decided a base price for every good in the game, which is a bit arbitrary and trial-and-error now. For fuel, I started with a BP of 5.

• “k”: Price sensitivity factor: Prices in Patrician III behave differently for different goods, for some goods they spike up very fast in case of a shortage, other price curves are more “relaxed”. “k” is the factor that determines that. Let’s take 0.3 (medium) for fuel.

  • If k is high, small changes in supply or demand cause big price swings: → A highly volatile market where prices react sharply.

  • If k is low, prices change gradually even if supply and demand shift significantly.→ A stable market where prices adjust smoothly

  • low≈0.01; medium 0.1-0.5; very high: 1.0+;  the higher the rarity of an item, the higher is k

• log: In Patrician III  the first few trades barely matter, but exploitation quickly destabilizes the market. The logarithm makes price changes non-linear.

  • In practical terms, that means:

  • Small shortages barely move the price: If a settlement is missing just a bit of fuel, the price rises only slightly.

  • Severe shortages cause sharp price spikes: When fuel becomes truly scarce, prices increase rapidly, reflecting desperation.

Taking all of this into account, I arrived at my price function:

Price for a good at vendor​ = BP (1 + k log (1 + D t / (S t + 0.01)))

What this function does:

• If demand exceeds supply, the price rises.

• If supply exceeds demand, price falls back toward the base price

• The 0.01 prevents division by zero when St = 0 (no supply at all)

• The parameter k controls how sensitive prices are to changes in scarcity.

The logarithm ensures small price changes when shortages are mild, but creates steep price spikes under extreme scarcity.

For fuel, with a base price of 5, a demand of 40, and a supply of only 20, the resulting price would be about 6.65, a noticeable increase, but not an extreme spike. If the supply drops to 5, the price would increase to 8.30.

So losing 15 units of supply raises the price by almost 25%, reflecting scarcity pretty well..

Blueprint implementation

Tipp: Use extra functions to get demand and supply and give each good a “k” factor.

Outlook

This system is now running in the prototype, but it’s far from finished. The real test will be how players feel these price shifts moment to moment, and if they understand how to use them for their advantage.

If you have ever tried to simulate demand/supply in your game, let me know your thoughts and comments!