Actually Build a Game Economy Part 1
Game Design Methodology
This is part 5 of the Game Design Methodology series. You can find the series overview at Game Design Methodology.
Practical Design: Game Economics
Let’s focus on the actual process of making a game economy without talking too much theory. This article assumes you’ve already made a balanced combat and exp system for the game.
We know we are building an economy but we don’t know the purpose or function of it. We need to know our desired inputs and results before we build it. To do this we start by stating objectives and declaring system assumptions where needed.
First we’ll state the kind of game we are making an economy for. Since RPGs have robust standard economies with money and bits you buy, want, need, and can’t live without, we will use that style game for our discussion. Our game has levels you gain, creatures you kill and loot, a merchant you can sell to / buy from, but no player trading. We want to keep this example cleaner. The unique aspects of large scale MMO style economies can’t really be discussed until we show how to build a functional smaller one first.
The first objective we need to figure out is a big one. What input does the player give that allows them to use the economy. It is critically important to know the relationship of the player to the system. The most commonly used inputs in various combination are:
Winning fights / challenges – a player receives the ability to transact in the economy through winning fights. This is usually set up with a sub-system that awards more or less in a fight with the amount of risk the character was exposed to.
Time – Either in the game or not. The player earns the ability to interact in the economy the longer they are associated with or in the game.
Skills / Achievements – Impressive feats are rewarded with interaction with the economy.
Money – Cash in the real world is translated to buying potential in the virtual world.
We will base our example economy off of winning fights. With the input determined we need to begin to determine the system’s interaction with the player and its output. We will start this process by stating our desires for the player interaction with the economy. For our example game we will base our example economy off of the following:
We want players to get items fairly often
We want players to buy better items
We want higher level items to cost more
We want the player to be scrounging for items until the end of the game when we will let them have an easier time getting what they want
If we had health potions we could would state their desired supply rate here as well
Armed with these desires we have reasonable idea of what kind of relationship we are creating between the player and the system.
The Trick
The trick to putting together a balanced economy is to realize this economy isn’t real. Fortunately games are VR and not R. The way an economy acts and reacts is the same in real life but you, the designer, allow every action the player can do. You allow every action the economy can have. You don’t have to worry about competitors unless you allow them. You don’t have to worry about supply and demand you control it. You have the ability to control all of the possible actions of the player. What you enable a player to be able to do is what they will do. As Maslow, Kaplan, or Twain said, “If all you have is a hammer, everything looks like a nail.” You’re making the game; you should know what a player is going to want from the economy. For instance, you know most players will gravitate towards the most rewarding items in a visual or battle effective way.
With the trick in mind we can ask, where did I get the desire we listed above? I got them out of thin air. It doesn’t matter what we state. There are no wrong desires. You can have the players get as much or as little from the economy as you’d like. As long as you state realistic desires you should be able to create a system that meets them.
You might have noticed we haven’t talked about in-game money yet. The reason for this is that in our example economy, in-game money isn’t an output. In-game money is one path for converting battles into things we want. It isn’t the thing we actually want.
Game Economies are not big scary black boxes
Creating an economy for a game can have many steps but is actually fairly straight forward and simple. Too many people have been talking about them as a mythical system you need to hire 80 year old economists to create to ensure a proper play experience. Like most things with games, there are tricks and realizations that allow you to create the relationships of a system if you frame the problem the right way.
What are the Game items?
We need to take a quick moment and define the possible item types we will have. We can’t really setup an economy unless we specifically know what things we are pushing through it. Let’s say the game will have:
poor, average, great, and legendary quality items
Melee weapon, Ranged weapon, Torso, and Legs equipment slot.
4 character classes
Class specific and all class usable items
This gives us a small pool of possible items but we now know 1 set of items is 2 weapons and 2 armor.
Let’s take a break real quick and make sure we understand the high-level concept of the process we are working through.
The economy we are piecing together will work something like this:
Our little example economy is all about items. The shop and battles creates items. Items can be sold to the shop, equipped or horded in basic inventory.
We will start by focusing on the section of the economy that dumps in items from battles. The easy start to this is a simple question, “How often do we want players to get items from battles?” This is a question of what kind of experience do we want a player to have. Should a dropped item be a rare coveted occurrence or should all creatures be perceived as overstuffed piñatas? This is a personal choice for the game. All types of drops can be made to work with almost any game. For our game we’ll say that when a battle is won there is a 25% chance of a gold drop or item drop. These percentages will give a great pick-up feel but because of the quantity of drops most individual drops will be less in value. There is a significant amount of game theory that can be applied to choosing drop rates but I’m going to stick to practical design for now and can talk theoretical design at some other point.
Now we need to switch to the other side of the economy. How often do we want player’s to get the best set of equipment? Keep in mind once a player has the best set they are much less likely to care about the other items available at that level. For our example game we’ll say the player should be able to get a decent set of new armor once per level. There is a catch though. If we look at a part of our exp curve (not discussed here) to see how many fights we go through to gain a level we can see that level 3 has 1/20th the creatures killed as level 20. Look at this sample “Number of Monsters to kill to Level” chart to see:
Handing out items in a static fashion is a bad idea. We will want to scale it to be taking more into consideration number of fights won instead of level. Massaging our data we get a chart that looks more like this:
As you can see starting at level 5 we’ll take the entire level to pass out 1 set of armor where as at level 20 we’ll pass out a good set of armor only after 21% of the level. I constructed this chart by thinking about what type of balanced relationship I wanted between the number of fights a player needs to win versus the frequency they can get new gear to equip.
One more data point we need to determine is the ratio of dropped vs. bought items. For ease we’ll say 50/50.
As you may have noticed we haven’t used any hard values yet. What we’ve done is defined our initial thoughts for the relationships between items, battles, the shop, etc. It is critically important to know how everything interrelates before we attempt to apply hard values.
From the numbers we’ve stated above we can make this chart to start to get closer to hard numbers:
This chart was made by taking the number of enemies you need to kill to level and multiplying it by our stated desired item and gold drop rates.
Now we have two charts. One is how many drops that are useful to the player are and the other is the number of drops of items and gold we get per level. Let’s convert them into one chart. To do that we need to convert item sets into just items. We have 4 items in each set but we stated that only half of the items the player will use come from drops, the rest is going to come from the shop.
The number of item drops was taken from the chart above and the desired dropped items was created by the following process:
1 item set is 4 items
Half of an item set, 2 items, needs to come from drops
We know the total number of drops in a level
We know how many sets of items we want to hand out in a level
For each level multiply the number of sets to hand out by the half set drop (aka 2) to get how many desired items should be dropped
Divide the desired number of dropped items by the total number of items dropped to get the % to use to determine if a killed enemy drops a useful item for any stated level.
Another way to explain how we have gotten to where we are so far is like this:
enemies per item set = enemies per level / number of item sets for level
items dropped per level = enemies per level * item drop percent
desired item drops for level = desired number of item sets for level * size of item set / % of set from drops
% applicable drops = desired item drops for level / items dropped per level
We now have the percent that will be used to roll against when an item is dropped.
Here’s one of the most important bits to understand about the process. If you don’t like how only 19% of items a player gets at level 20 is usable you can increase or decrease it. Once again, it doesn’t matter you can change the percentage. By upping it you’ll see the exact number of usable items a player will receive while they are in the level. There is no confusion, it isn’t guess work, you’ll see the full cause and effect. If you are playing the game and feel the number is off, you know exactly what to change where to get the exact result you want. No guess work.
Quick Item Drop Design Example
A quick scratch pad design doc system write up for the item system could look like this:
When the character kills a generic monster the game will roll a 25% chance of dropping an item.
If the game decided to drop an item it will then roll a % chance of dropping an item of the player’s class depending on the level. For each creature killed roll against the following to determine if there is a drop:
If the roll failed to drop on the player’s class randomly roll to choose one of the three other classes all with equal chance.
Next determine which slot the item dropped will be from the table to determine slot drop is as follows:
MELEE WEAPON 25 % RANGED WEAPON 25 % TORSO 25 % LEGS 25 %
The game will then search the item table for an item that is for the chosen class and slot at the level of the killed monster. If an item is found, the game will drop the item at the location of the enemy’s corpse. If no item is found the game will re-roll the class and slot selections to try again. If no item is found after 5 attempts the game will switch to a gold drop instead.
-End simple sample design-
Obviously this system is fairly straight forward and dry but you can clearly see how this system creates outputs that match the relationships we wanted.
Continued in part 2