Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 30, 2014
arrowPress Releases
October 30, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

BazaarBot: An Open-Source Economics Engine
by Lars Doucet on 06/03/13 09:15:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This availability of commodity physics engines has freed designers to focus on interesting new games, powering everything from Crysis to Angry Birds.  The key is straightforward API's that let developers just throw things around and let the chips fall where they may (literally!).

For years, I've been wondering whether we could do the same with an economics engine. I remember playing strategy games where prices would rise and fall in proportion to supply and demand, but I could never find an open source engine to handle this, nor was I able to program it myself.

That is, until I found this research paper by Jonathon Doran and Ian Parberry. Entitled "Emergent Economies for Role Playing Games," it outlines exactly how to write a basic free-market simulator, in much the same style as Baraff and Witkin's seminal papers on rigid body simulations.

Over the course of two days I wrote a straight implementation of Doran and Parberry's  method, and I figure I'd share my results. Behold: bazaarBot!

The Grand Bazaar: Istanbul, Turkey


bazaarBot is a simple, open-source free market simulator written in Haxe. This means it can be easily compiled down to multiple languages, including actionscript 3, c++, javascript, and more. It's very basic for now, but I would like to eventually turn it into a sophisticated engine with a decent API that can be used for games and simulations.

Let's talk about what makes it tick.

Prices emerge from Beliefs

I knew a free market simulator needed at least the following things:

  • Some kind of market, a clearing/auction house to handle trades
  • Agents that hold and trade commodities
  • A currency to denominate commodity prices
  • Recipes and/or jobs that define how commodities are transformed

But what was I missing? For starters, I was missing price beliefs.  In a free market, goods don't have some inherent value stamped into their very being.  Instead, their value is simply whatever someone is willing to pay.  This willingness is modeled as a Price Belief that each agent maintains about each commodity in the market, defined as a range of two numbers.  This represents not only what they think the price is, but also how certain they are of that price. When it comes time to decide the cost of a good when buying or selling, the agent picks a random number within their belief range.

Each trading round, agents create "bid" (buy) and "ask" (sell) orders for various commodities, and the market fills up with orders. Then, the market resolves the orders thus:

  • Shuffle the bid and ask lists
  • Sort bids by -> highest to lowest
  • Sort asks by -> lowest to highest
  • Match bid[0] with ask[0]
  • Clear the trade:
    • clearing_price = Average of bid/ask prices
    • Trade the minimum of units offered in bid or ask @ clearing_price
    • If bid[0] units == 0, remove it from list
    • If ask[0] units == 0, remove it from list
  • Continue until either bid or ask list is empty
  • Reject all remaining offers

The "average market price" of a commodity for a given round is defined as the average clearing price for a successfully traded unit that round.

Each round, agents update their pricing models. If they had a successful trade, they become more confident in their price belief and tighten the range around the mean. If they failed, they become less confident in their price belief and expand the range. Furthermore, failed agents will look at the average market price from the last round, and translate their price beliefs towards that range.

There's a bit more to it than that (see the paper), but the result is that commodity prices rise and fall in proportion to supply and demand. Some agents will be more successful than others, so some will have a tight range and others a large one.

When supply is high, selling prices will be all over the place. If demand is low, buyers can fill their orders entirely with just the goods offered at the low end of the price spectrum.

When demand is high, buying prices are all over the place. If supply is low, sellers can offload their entire inventory with just the offers at the high end of the price spectrum.

The result of that round then reinforces price beliefs, causing next round's prices to change.

Agent AI

That's just the first step. Next, there has to be some feedback to make agents respond properly to price signals. Agents have very rudimentary AI that works like this:

  • ideal_amount = Decide how many units to buy/sell of COMMODITY 
  • curr_price = Check current market price of COMMODITY 
  • favorability = Compare curr_price to my_observed_trading_range  
  • Buy/sell (ideal_amount * favorability) units of COMMODITY

This block simply determines, "Assuming I want 10 hamburgers, how many will I actually buy if they cost $5 a pop?" It has nothing to do with how the Agent comes up with its generalized lust for hamburgers. In the paper's example (and which I model in the bazaarBot's example project), each agent just tries to maintain static, pre-defined units of each commodity in its inventory at all times. Under ideal conditions, Blacksmiths just always want X units of metal, and Farmers just always want Y units of wood, etc. During production (defined separately) they will consume these input commodities to make tools and food, and then they'll want to replenish their stocks next round.

The price signal logic simply makes the Agent buy low and sell high. How the agent determines what counts as "high" and "low" is based on its own history of successful trades. This value (my_observed_trading_range) is simply a list of trading prices per commodity. This means that more successful agents have better information and are less likely to make mistakes, but also more likely to bid conservatively and miss opportunities when prices change sharply.

There's a few other things thrown in, but that's the basics of it.

Agent Replacement

Finally, some agents will run out of money due to bad trades and/or market conditions. In this simulation, the bankrupt agent is replaced by a new one of the currently most profitable job type. This is another driver of supply and demand - if so much wood is being sold that the price collapses and woodcutters start going broke, people quit woodcutting and start farming. The supply of wood goes down, the price rises, the few remaining woodcutters stick with their jobs, and the population reaches a more stable distribution or careers.

There were a few kinks in this system. I stored each job's profitability per round in a public information list, which worked nicely for a while until a particular job was completely abandoned. At that point, that job's profit per round would be continuously logged as "0." At this point, no new agents would ever consider the job again, even if there was enormous demand (and zero supply!) of that job's chief export!

I couldn't figure out how Doran and Parberry solved this issue, so I added in a special case during agent replacement to check for a good "market opportunity," defined as any commodity with signicantly higher demand than supply. If such an opportunity existed, the new agent would favor the job that creates the most of that commodity rather than the default behavior of picking the most profitable existing job. This covered that case pretty well - any etime all the woodcutters or blacksmiths would go out of business, eventually the pent-up demand for wood or tools would become high enough to encourage a short boom in those careers.

The above formula for agent replacement works well enough, but it should probably be a lot more customizable as each game's needs will be different.

Where to Go From Here

A lot of work remains to be done to make bazaarBot the kind of open-source economics engine that can drive the strategy games of the future. Here are some futher thoughts on that.

A well designed API

Right now the engine doesn't have much of an API to speak of, it's just a simple proof-of-concept. Further work is needed to decide what should be the walled-off internal guts, and what parts should be for public consumption.  

Most physics engines work by creating two parallel universes - the game world, and the physics world, and closely linking them. Thus, every game object has a corresponding physics object, and the physics object is used to update the game object's position every frame.

bazaarBot's API would be similar - there's a game world, and an economics world, and game objects will somehow be linked to economics objects via bazaarBot instances. 

So, you could have a simple game town filled with NPC's that walk around, some are woodcutters that find and cut down trees (which grow back according to some schedule), some are miners that look for and mine ore (which is finite and unreplenishable), and at the end of each day they bring their goods to the town square, itself a game object which is linked to a bazaarBot.

Each NPC updates their economic Agent's inventories and desires, the market object runs a round of trading, and the NPC's pull their new inventories from their economic Agent's, and then go out and do another day's work before coming back to trade.

This would be one of the more simpler implementations, but you could go further.

A Tale of Two Cities

By creating multiple bazaarBot instances, you could model separate economies for cities that can then trade with one another.  Let's create two cities, Paris and London, each with their own economies. Prices for goods in each city will be different, and let's say wheat has been cheaper in Paris for the last 10 rounds.

A Londoner could notice this, and game logic could make him become a "merchant," with knowledge of both markets. This merchant checks the cost of the "travel-to-paris" token (redeemable in game for the travel-to-paris service), and it's currently favorable, so he hops on a ship across the English channel.

Next round he's in Paris, and the price of Wheat is way below his observed trading range in London, so he offers a generous price (for Paris) and buys as much as he can carry.

He buys a "travel-to-london" token as well and travels back to London the next round. He checks the price of Wheat in London, and it's well above what he paid for it in Paris, so he sells it all at slightly below the current market price.

The activity of trading merchants would eventually cause prices in each city to communicate somewhat, mediated by the time and expense of travel, as well as any policy restrictions (such as tariffs) imposed by governments.  Furthermore, the price of travel would respond to demand by merchants.

Some work might need to be done to enable the "Tale of Two Cities" example specified above. Currently bazaarBot Agents do not have any mechanism for explicitly keeping track of what they've paid for the items they currently own, this is just sort of handled implicitly via price signals and observed trading ranges.

There also might need to be first-class support for "merchants," though this could also be left entirely to the game logic side just by moving Agents from one market to another.  Support could also be added for "government policies" such as taxes, import duties, subsidies, bans, and price controls. These rules could be set on a per-market basis.

There's currently no formal support for multiple currencies, but it could be handled implicitly by how we treat the "money" in each market.  In the above example, London and Paris can freely exchange, so they might as well be cities in the same country.  Now, let's instead call a unit of "money" in London "Pounds" and units of money in Paris "Francs."

The exchange rate between a Pound and a Franc would be done by comparing the total value of goods in one country versus that of another. In a simple example, the only commodity available is wheat, so if Paris has 100 wheat trading @ 1 Franc and London has 50 wheat trading @ 1 Pound, then 1 Franc = 2 Pounds, showing that it's currently cheaper to import wheat from Paris. I'm really not sure what effect formal currency exchanges and money changers would have on things.

(Feel free to correct me if you know something about currency exchange and valuation)

Agent AI

It should be noted that Agents are kind of stupid. bazaarBot has rudimentary support for a basic data-driven scripting engine, but it's honestly some cheapo thing I hacked together letting you specify actions and conditions in JSON, so it's not ideal. In the future I might expand this, switch to an actual scripting language like lua, or just leave it entirely to the game logic side to extend Agent objects and provide your own code for handling their production logic.

Perhaps it's even best for Agents to have as little AI as possible beyond economic matters, and all the user does is update their inventory and desire for certain products, with the entire matter of HOW those values are created being entirely left to game logic.

One caveat I should mention is that AI is stupid, really stupid. This is no replacement for a real human-driven economy, nor is it likely to be an incredibly accurate simulation of one.

Complex Finance

bazaarBot has no current support for anything beyond buying and selling commodities of uniform value. It doesn't even have support for borrowing or loans, let alone interest rates, bonds, short selling, options, or credit-default swaps. Services could easily be modeled just by mapping them to a tradeable token, which could work just like a commodity.

Some or all of these could be added later, I suppose, but this brings me to my next point.

Finding the Fun

Emergent complexity is no magic formula for fun, and is often quite the opposite. I'm a data nerd at heart, and I get a huge kick out of tweaking intricate and complex systems, but I've found players are mostly interested in systems with clear inputs and outputs, and choices that are easy to understand. I think an economy engine could be really useful, but it will take special care to make a fun game out of it.

I'd recommend keeping economies simple at first before going too far down the rabbit hole with complex Agent behaviors or whacky financial instruments.

Ideological Bias

I've tried to keep things as simple as possible, but it bears mentioning that any economic simulation is going to reflect a certain bias. My hope is that bazaarBot will be flexibile enough to model many different kinds of economies, as well as demonstrate economic principles from a multitude of perspectives, be they Keynesian, Hayekian, Marxist, Georgist, etc.  Most of that high-level bias will come from the actual scenario that's modeled, as well as how the game designer decides to reduce real-world entities to economic objects.

From the engine's perspective, a commodity is just a commodity. But if you treat land as a simple commodity, you are at odds with Georgism, and if you treat labor as a simple commodity, Marxists might have something to say. 

There are already some fundamental biases, however, that I can see in the current engine. For one, it assumes that commodities are uniform in value and quality.  This is how the United States treats agricultural products on major commodities exchanges, and some would argue (including myself) that favoring commoditizable goods can have serious repurcussions for the health and welfare of humans, animals, and the environment.


However you feel about food politics, I think we can all agree there are limitations to the "commodity" model as a one-size-fits-all model for tradeable goods. Some designers might want more flexibility. I suppose one way to do that is to add quality "grades" to commodities, and treat each as separate commodity types that are still somehow linked to a parent type. For example, if you want to buy Grade-A pork bellies, but they're too expensive, you might be willing to substitute Grade-B pork bellies instead. 

Further considerations could let us define goods that don't act like commodities at all, so instead of having unique data structures in the market for each commodity type, you could have "flea market" lists that are a random grab-bags of goods, where items aren't defined by what they are but insetad by what they can do.

So, if an agent is just looking for something -anything- that is "sharp," they could make bids for axes, knives, swords, etc, based on the properties of those items. 

I'm not sure I want to dive down that rabbit hole just yet, though, but it's one possible solution.

Signing Off

Well, that's my economics engine! It only took me two days to write over the weekend, but I've been thinking about if for a long time. If anyone else has some tips for me, I'd really appreciate it, as I'm constantly looking for ways to improve this thing.

Here's the Github link again, in case you want to contribute (I'll put it under MIT license):

And here's a link to the page where I found the research paper, it's got lots of other good stuff in it!

Related Jobs

CCP — Newcastle, England, United Kingdom

Senior Backend Programmer
Guerrilla Games
Guerrilla Games — Amsterdam, Netherlands

Animation System Programmer
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Blizzard Entertainment
Blizzard Entertainment — San Francisco, California, United States

iOS Engineer, San Francisco


Jonathan Ghazarian
profile image
Do you currently have any ideas for a simple but fun use for this? I really like the idea and would be interested to see a good example of this library in action.

Lars Doucet
profile image
That's the next step, isn't it? Here's a few scenarios I can think of:

"Day Trader":
Set up some basic economy, and then the player can control one of the agents, and try to make money by speculating on the value of goods by making buy/sell orders.

"A Tale of Two Cities":
We could expand on the example in the article by the same name, and this time you are a traveling merchant, trying to buy & sell products at an opportune time and gauge the risk of travel with the possible rewards. The simplest case is doing this with just two cities (economies), but you could expand this to many more.

The classic TI-8X calculator game, "Drug Wars" basically was an example of this, but to my knowledge it just had prices change randomly. The advantage of having actual markets is you can look at supply, demand, and other activities to make educated guesses about where the price might go. There's enough chaos built into bazaarBot that you wouldn't be able to make perfect guesses, of course.

"Doomsday Prepper":
Another idea is preparing for the end of the world as we know it under various possible random scenarios (both supernatural/ridiculous and natural/plausible). You try to keep enough resources (food, guns, medicine, etc) on hand to keep yourself alive for the duration of the challenge - be it zombies, nuclear attack, etc. For instance, food is cheap under civilization, but that cheapness depends on it being produced in a factory far away and shipped long distances with cheap oil. If the price of oil were to quadruple overnight, suddenly long-distance transportation becomes unviable and the whole system breaks down.

I believe X-Com: Apocalypse had some sort of basic free market - I seem to remember that prices of things would go up and down based on supply, and that if you dumped a whole bunch of product on the market at once, the prices would go down for it. I do remember quite clearly, that actual entities were buying whatever you sold, so you had to careful about selling high-grades munitions on the open market, because they could eventually find their way into the hands of hostile entities like the cult of Sirius which would come and raid you with weapons you had put on the market yourself!

Jonathan Ghazarian
profile image
I think you forgot the most important example of Lemonade Stand! But seriously, your examples sound interesting in a way that we don't see in games too much.

Lars Doucet
profile image
Oh dude! Lemonade stand! I haven't played that in aaaages!

James Coote
profile image
Time to remake transport tycoon!

This actually would have been perfect for a game I was making a while back (now sadly abandoned / put to one side). But this sort of engine could be perfect for simulating supply and demand for the economy and trade in a 4x or space trader game (elite/freelancer/etc) or something like Tropico even. And certainly, under the hood, city builders do a lot of supply and demand simulation, so it could definitely have application there

Jonathan Lawn
profile image
Space trading like Elite sounds perfect to me. Something in which you can not only trade, but also predict (or even cause) disruptions in the market that improve your profit (like cutting off a star system to produce a shortage there before selling).

Carl Chavez
profile image
@Jonathan Lawn: "X3: Albion Prelude" does have a commodities market that can be manipulated in several ways, such as hoarding goods and then flooding the markets, or destroying trade ships so demand rises, or destroying space factories so they can no longer compete with your own factories.

Tynan Sylvester
profile image
First off, I love the fact that you attacked this problem and wrote about it! I also have a closely-related article today about the dangers of this kind of complexity:

A few thoughts about this:

-Hasn't this problem been addressed by some economists somewhere? I swear this sort of economics modeling must be a pretty well-explored problem. There must be examples we can draw from, even if they were made in academia or a Wall Street bank in the 80's.

-I think your mechanism for finding prices is wrong. I don't see a real-life analogue to "price uncertainty" expanding as people fail to accomplish their buying and selling. Real economics are driven by the fact that goods have _alternate uses_ and can be substituted for each other (or done without completely). e.g. The price of airplane tickets is really based on the airplane's relationship with cars, buses, trains, and walking, and the attendant cost of production and benefits of each, as well as the demand profile of where people want to go and how often.

-There is something odd about analogizing an econ sim to a physics sim. Here it is:

A - Physics is a system that happens _underneath_ everything else in a game. E.g. characters walking is really just a generalized simulation of the particle physics in a human body. Damage mechanics are really just a generalized simulation of the physics of bullets and walls and flesh. With enough computer power you could implement everything else in the game just with subatomic particle physics (just like real life works). So the role of a physics simulation is obvious: It is a simulation of a small piece of the game world at high detail.

B - Economics is a system that emerges _above_ and from everything else in a game. It is a generalized phenomenon that appears as a result of the interaction of characters and AI and resource collection mechanics and so forth. So if characters can make resources, take them to market, communicate, and make trading decisions, where does a separate econ engine come in? These pieces already form a working economy. There's nothing added by a new, parallel, econ sim that's not already in the game.

-You wrote "I'd recommend keeping economies simple at first before going too far down the rabbit hole with complex Agent behaviors or whacky financial instruments.". And I agree! Economies are famously enigmatic and frustrating to try to predict. They suffer all the complexity problems I outlined in my recent article. In their realistic form, they are not fun to interact with because the feedback they give is so delayed, mixed-up and downright weird.

I think an econ sim like this could be worthwhile, but only as "hair complexity" (see my article for definition) around the edge of the core game, not as something players must interact with and depend on. If it is meant to be interacted with, I think an aggregate-based system with simple rules is smarter than an agent-based system because feedback will be clearer. As you seem to have acknowledged, I think this really is an area where smarter is not better.

Lars Doucet
profile image
As mentioned at the top, the whole thing is a straight implementation of this research paper:

The authors describe their motivations and background for the method in there, citing various economists and other related work in the field.

Tynan Sylvester
profile image
Got it. I did notice you mention the paper, perhaps I should read it now :D.

Michael Joseph
profile image
if you view economics systems as psychological systems, then they too would be something inherent (or underneath everything else as you say) to human AI systems modeling.

Michael Joseph
profile image
I think i mean economic systems as being constructed on top of behavioral systems where psychological behavior influences and limits the types of social systems that can be created.

Brent Gulanowski
profile image
I think an economics sim is worthwhile because it provides a standard set of abstractions for economic behaviours (evaluating utility, calculating prices, comparing alternatives, remembering price histories, performing trades), much as a physics sim provides a abstractions for motion and collisions. The "underneath" are the mental processes which an economic agent goes through to arrive at strategies and plans for trading, as well as the actual act of trading.

It might also be useful to include concepts of ownership and other questions related to how agents understand trade, as well as intangible values. If the framework generalized what utility meant, it would allow offloading a lot of other stuff, and just using the results of calculations to help inform other systems like a general behaviour planner.

On the other hand, a higher-level abstraction in simulating the aggregate behaviour of markets might be analogous to a chemistry simulator, and would be to the trading simulator as the chemistry sim is to physics sim.

Bart Stewart
profile image
"Enginization" of systems is always worth doing. ;) Some thoughts in no special order:

1. Happily, Ian Parberry is alive and well and helping Nerd Kingdom on its recently Kickstartered "TUG" game.

2. An obvious application of an economic engine is in MMORPGs. The thing is, NPCs trading with each other or with a single human player is one thing. An economy serving many humans is quite another! How robust does an economic engine need to be in order to effectively serve lots of human players, some of whom will collude, and others of whom can be counted on to attack the engine to look for holes to exploit?

3. A key goal (maybe *the* key goal) for MMORPG economies is price stability. (Hyperinflation and severe deflation reduce fun.) Does the engine you've built produce price stability naturally? If not, what would it take to integrate that as a top-level goal guiding some of the individual market activities? Or is that something that should be left to the game's operators?

4. How would you suggest integrating metrics collection into an economics engine?

5. "Keep it simple" is a good idea for several reasons, including the point made by Tynan (and by Robert Axelrod in his "Evolution of Cooperation" experiments) that people won't invest in a system whose outputs are perceived as random... and complex designed systems often appear random. They can be made to look simple, but that's more work than using a simple system in the first place.

6. The "trade the minimum number of units per turn" rule raises some interesting questions. What about the case when a rarely-available but valued commodity is offered? Speculating that bids will continue to be high for future offerings should lead a rational agent to bid for the maximum number of units possible each round, wouldn't it? Also, this suggests it might be interesting/useful to model "future value beliefs." Rather than current price beliefs that address "how many X should I buy," future value beliefs would allow an agent to prioritize which commodities to buy first in each round.

7. As a private citizen, I think there are real-world economic systems that have demonstrably done the most good for the most people, and other systems that haven't and probably can't. But I agree that for a game engine, I'd want one that, if it didn't exclude biases, at least explicitly encoded and exposed its value assumptions. If there are engine rules defining how well or badly some pattern of trading works, it would be helpful to parameterize those rules and provide hooks for setting different values for those parameters.

8. Finally (I'm making myself stop here ;), something that frequently bugs me about game economies is that, regardless of whether the setting is magical fantasy or far-future science fiction, everything seems to come down to individuals bartering. The most advanced economic technology in the vast majority of MMORPGs is the magic generation of some form of accumulatable coinage. (I discuss different stages of economic play at
-mmorpgs.html .) It seems to me that a good general-purpose economic engine would support more organized forms of wealth generation -- banking (especially fractional reserve lending), the corporation, the factory, information brokering, and other economic processes that enable the creation of wealth beyond what individuals can physically create by looting or crafting. It's an open question whether adding some of these or other economic behaviors more advanced than "12 zorkmids for your goat" would make a game more enjoyable, but isn't part of the fun of game design exploring open questions? I'd be interested in seeing a discussion of how an engine could support economic activity beyond the Secure Trade Windows, private NPC vendors, and Auction Houses of existing games.

All that said: excellent article, and I hope we'll see more about this engine soon.

Lars Doucet
profile image
Responses as I'm able :)

1) Super cool! I should get in touch with the paper's authors.

2) I really have no clue how this thing would stand up to actual humans. My guess is the weakest point is most likely the Agent production and desire AI rather than price-signal logic.

3) So far it seems to produce natural price stability, that's the whole point of listening to price signals. If there's an over-supply of something, the price goes down and people stop selling as much of it, and the price goes back up. If there's an under-supply, the price goes up, and people stop buying as much of it, and the price goes back down. Then, agent replacement does the same thing with jobs - if there's an over supply in one job, price collapse for their chief export eventually drives some of them out of business. If there's an under-supply for a job, sharp demand for the chief export makes bankrupt agents from other jobs switch to that one.

4) Geez, where to start. The thing collects a decent amount of internal metrics just to be able to run. Ie, historical market prices, each agent's observed trades, etc. This is super noisy data though, so you'd have to be careful to find *useful* metrics.

6) Speculation is an interesting case, and I'm not sure where that logic should go. On the one hand, that could go in the "determine ideal amount desired" black-box-logic, or else special speculation logic could be built into the price-signal logic itself and adjustable with user defined data.

8) Yeah, that's definitely interesting. These more complicated financial instruments could presumably be built on top of a basic financial structure, the challenge then becomes creating robust agent AI that's "smart" enough to have complex desires that justify and then drive those entities.

Ian Parberry
profile image
Bart, I am alive and well, but no longer working for Nerd Kingdom. :)

Ian Parberry
profile image
Bart, I am alive and well, but no longer working for Nerd Kingdom. :)

Mustafa Hanif
profile image
Amazing Amazing article. My mind was blowing just by reading it!. An economic engine is a dream come true.

I dream of a game which is an extension of farmville, but in that farmers can't just buy stuff from the game's market but have to get stuff from traders from the free market of this engine.

Traders and farmers can become friends and create monopolies.

These monopolies form a single group and try to buy more land for the farmers.

This land is limited and is part of a fictional country.

The grand goal of the game is to take over the country :D ... land by land, piece by piece and become an extremely evil big corporation where everything flows through you :D

Lars Doucet
profile image
Henry George[1] and Elizabeth Magie[2] would be proud :)


Justin Pedersen
profile image
This is a really awesome idea; playing around with economies I find goes hand in hand with MMOs, but the problem is trying to 1) implement enough things for people to care about and 2) finding the people. But having an engine would make up for the barriers because it is simpler to implement.

From my prior projects, competitive real-time multiplayer is usually the cornerstone, so I think I may be thinking more on the inter-player economies that could form; economy is a stellar idea to implement games, especially from the non-violence perspective, yet having a clear competitive edge (if capitalism's your bag I suppose).

Great article, and great idea/engine!

Alexis Prayez
profile image
Excellent article ! Thx for the share and the article.

Any system on top of this one (such as a government setting up taxes and laws to define legal/illegal actions) should lead to black market and contraband. Which is present in almost any RPG and adds depth to the lore.

Depending on the tax level and/or the legality of a transaction, the agents should be able to make transactions outside the legal system. To counter it you could add a control entity which would, at the end of each economic turn compare the inventory of random agents with their transactions history. In basic system, an agent controlled positive to "illegality" is destroyed while a cheating agent that didn't get caught is more likely to feel comfortable with illegality and become even more corrupt next round.

The number of inspections and the disposition of agents to go illegal could be based on a mix of global indicator (the "corruptness" of this particular city/economic system which could go up or down depending on the choices made by players) and an agent specific level of corruptness, an art dealer is more likely to get his hands on stolen art, than a baker is going to sell stolen bread !

Moreover the player might get his hands on illegal/stolen goods that only a corrupted agent will be willing to buy. You can connect there multiples story arcs for the player to meet and gain the trust of these agents.

Sounds easy and fun described like that :)

More seriously, I would definitely contribute to this engine if you feel like coordinating the project (and eventually using a more universal language :p)

Lars Doucet
profile image
Most definitely - you basically have the basics for a smuggling game right there, whether it's something comparatively benign like avoiding taxes on Rum and Tea, or a bit more shady like running drugs or guns.

I imagine you'd implement this by creating a separate bazaarBot instance for your "black market." You might be able to calculate the "cost" of criminal activity by adding up fines / losses / cost-of-going-to-jail, etc, of captured agents and then multiply that by the chance of getting caught. Of course, you'd have to make the "cost" and the "chance" of being caught *perceptions* that vary with each agent, much like price beliefs. Then, agents willing to participate in crime could weigh the risk of smuggling activities.[1]

Of course, people come in all shapes and sizes[2]. Some are principally opposed to anything that's illegal, others are willing to break the law if it suits them, etc, so only those who are okay with the idea of crime to begin with would reduce it to a simple risk/reward calculus. It seems your "corruption" model would address this.

Another thing is exactly what sort of information trading agents and control agents have access to. Is it a police state where they can audit you without a warrant? Do you just roll a chance of being detected each time you engage in illegal activity? Is it proportional to how much stuff you're trading? I think all this stuff would work just fine on the game logic side.

[1] One challenge is in calculating risk-reward for a danger of "infinite" cost - like execution. On a computer this is infinity, but in real life it's not so. For example, Jay-walking == (you_could_totally_die * you_probably_wont_get_hit). So even though the potential cost is infinite, most of us take that risk all the time, even though the reward (save a few minutes) is of little benefit.


Jannis Froese
profile image
I really like the idea of an economics engine.

In the matter of currency exchange, my intuition would tell me that a currency is valued by (amount of currency in country)/(value of all trades). If people are trading for lots of money, but there is barely any money to go around, then it will be hard to buy that money for a foreigner.

But perhaps currency exchange will regulate itself just fine if you would implement cash as some special commodity which everyone is trading their goods against. Then the existing engine could model buying and selling currency for another currency, and exchange rates would be exposed to the same model of demand and supply.

Brent Gulanowski
profile image
This sounds excellent.

It sounds like agents are very rational. It would be great if the simulation allowed for examples of "irrational" decision making, too.

For example, preferring to deal with other agents with which they have previous experience. Perhaps as simple as a bias value which can be controlled by client code. This could simulate brand allegiance, trust, or whatever.

It might also be good to simulate factors that impede access to information about prices. And expectations on the part of agents that prices might rise again in future, causes them to hoard resources instead of accepting the current price. Especially if they are afraid of losing money on a trade, and warehousing is cheap. I suppose these are all "emotional" attitudes, but perhaps various kinds of bias which encourage or dampen willingness to trade could achieve the same result, and the client game could explain it using whatever human emotional justification suited the narrative.

Adam Buffett
profile image
This is a great idea. It sounds like a worthwhile (and tricky) challenge to "enginize" this. Lars makes a good point that the excessive saturation of FPS games can partly be explained by the plethora of FPS engines and tools available.

I have been running an indy MMO business game for almost a year called Magnate MBA and here are some of my suggestions from this experience:

Let EVERYTHING be determined by the market. It's surprising how many difficult scenarios are resolved by simply letting the market set the price. If prices get extreme, you should rely on players to change their behavior and take advantage of those extreme prices, which also corrects the prices. e.g. In Magnate, if wholesale prices get very low, players can simply buy huge amounts on the wholesale market then sell them to customers through retail stores for a huge mark-up. This naturally corrects the prices and rewards the smart players in the process. If you prevent extreme prices then the market may never give players a strong enough incentive to change their behavior, which undermines the whole point of having an economy in the first place.

In an MMO context, beware illiquid markets, when few players are online. Even with a fairly large player base, traffic fluctuations can make it hard to trade properly on the market. A "market maker" can be essential in this context to allow players to trade at a sensible price even when other players are not available to trade.

Beware computing capacity requirements as number of players grow, especially in a persistent world, where companies/players can act automatically while the player is not actually online.

Beware extreme income sources (and bugs!). Once you introduce huge wads of cash into the economy it's tricky to get it back under control.

Regarding comments about currency exchagne, I would suggest you treat currency exchanges exactly the same as any other product. I don't see any reason to complicate it by changing the dynamic.

Simplicity is essential. A simple system will often be better than a more accurate, more complex system. It's just not fun to spend too much time learning all the rules. Players want to get down to "playing" without too much learning overhead.

Ian Parberry
profile image
Lars, I am blown away by your blog post. Jon and I had a little trouble publishing our paper initially because the academic referees not only couldn't see the value of it, but seemed to doubt whether it could actually be used in a game. You have totally vindicated us. Thank you, thank you, thank you.

I should also point out that the research for this paper was done by my PhD student Jon Doran, under my direction. He deserves 99% of the credit, if not more.