When you have a game system that involves the player using loot to buy rewards, I usually start calling that system an “economy.” (Note: This isn’t how some people use the word, so I just want you to know what I mean when I say it here.)

Previous Article  |  Next Article

In order to get the game to “feel” the way you want it to, you can loosen or tighten your game’s various economies. How easy or difficult it is to do so depends on how your game logically determines what reward a player gets for accomplishing a goal.

This article is not about how to make it feel the way you want it to.

This article is about how to set up the systems so that you can make it feel the way you want it. Imagine that your game is a big flat control panel covered in dials. Some dials are large and have a huge effect on a lot of things. Some dials are small, and only affect very specific things.

This article is about how to set up the control panel to make it easiest for you to do the tuning work.

I’m going to talk about two really common ways of setting this up, but these aren’t the only two ways: 1) The Small Dials Method, and 2) The Big Dials method.

Note: For the sake of brevity, I’m limiting the scope of things we’re tuning to just how much loot enemies drop when they die.

The “D&D” method (small dials)

Many games have enemies drop loot similar to the way it works in Dungeons and Dragons, or other tabletop RPGs.

Each type of enemy (Goblin, Orc, Human, Dragon, etc) has a set of loot it’s allowed to drop when it dies.

In D&D, there’s usually a random factor to it, but I have to ignore that for this article for brevity.

Example Loot Set: “When this enemy dies, it drops 10 gold”

Often, when I see it implemented in games, it’s even more specific (e.g. each enemy instance may have a variable saying how much gold it should drop).

This is an efficient setup for a tabletop game where other human beings (who are not you, the designer) do all the work of creating and balancing content in real-time. When you, as the designer, have to create and balance that content before you ship the game, this method can get really difficult to maintain.

Why is is difficult to maintain?

Here’s one example of where it’s difficult:

Ignoring randomness for a second, let’s say there are 100 identical enemies in level 1, and each enemy gives the player 10 pieces of gold when it is killed, you know that the whole level has 1000 gold in it, assuming the player kills all the enemies.

For the sake of this example, let’s say you discover/decide that 1000 gold is the perfect amount for level 1 to give. You don’t want people getting too much more because it makes later content easier than you want it to be.

If you’re anything like me, though, the number of enemies in your levels constantly changes over the course of development. As certain parts of a level are changed to make it more or less intense, enemy counts can vary wildly. I may remove an enemy from an early setup to make it easier, but then add three enemies to a later setup (and so forth).

So in this example, lets say I adjust the enemies and now there are 150 enemies in the level (each giving 10 gold) my economy is now no longer perfect, since the player will be able to get an extra 500 gold.

In the case of this very simple example, if I want to lower the gold given in the level, I now count all the enemies and reduce the amount of gold given per enemy to compensate. But I have to do this every time I change the enemies in the level.

It gets even more complex when you think how different types of enemies drop different amounts/types of treasure. Sometimes this can be so subtle it’s hard to even tell where the problem is since a problem in level 1 might have knock-on effects on level 10.

Once you start dealing with treasure tables and randomness, these problems get even harder to solve. There are just too many small dials on the control board, and you can only turn one at a time or you risk adding new problems.

 Big Dials

I’ve  worked on a number of games where the economy is balanced a different way from the D&D method. It has some advantages for use in a video game since it gives you both big and small “dials” to work with.

Because most of your daily tuning work will occur via the larger dials it provides the designer with some protections from the ravages of enemy-count escalation and randomness.

You can focus the majority of the tuning work on (for example) a per-level basis instead of a per-challenge basis.

A simple Big Dial example

Here’s a simple conversion of the D&D style to a Big Dial style:

Let’s say, as before, we want Level 1 to always have 1000 gold in it, no matter how we adjust the enemies. On the first frame of the game, when Level 1 starts, all the enemies are counted up and each enemy gets an equal share of the 1000 gold.

E.G: Lets say there are 50 enemies in level 1, each enemy would be given 20 gold to drop.

A more complex example

That simple example doesn’t sound too much more useful than the D&D method (besides abstracting out the enemy counting problem). It begins to pay real dividends once you start adding complexity.

As an example, let’s say you have a level with a mix of enemy types, instead of all identical enemies. You want each one of those enemy types to drop gold based on how hard they are to defeat — a Dragon enemy should drop more gold than an Orc, for example.

For each enemy type in that level  (Goblin, Orc, Human, Dragon, etc), we track a number that indicates what share of the loot that monster type should get, relative to the other types.

Example:

• Goblins have a value of 2
• Orcs have a value of 4
• Dragons have a value of 12

The example above would indicate that Goblins get half as many gold as Orcs, and the Dragons get three times as many gold as the Orcs. The specific numbers used have no relevance, only the relationship between the numbers is important. These are ratios, not hard numbers. When the level is run, the game counts how many enemies of each type are in the level, then divvies up the gold to each enemy based on that ratio. This means:

• Goblins as a group get a pool of x gold
• Orcs as a group get a pool of 2x gold
• Dragons as a group get a pool of 6x gold
• That’s a total of 9x

For those of you who, like me, aren’t math nerds, the example comes out something like this:

• If the level has 1000 gold, 1000/9 is about 112
  • The Goblin pool is 112 gold
  • The Orc pool is 224 gold
  • The Dragon pool 672 gold.

Each pool gets divided by the total number of enemies in the level. So if there are 28 swarmers in the level, each swarmer gets 112/28 = 4 gold.

Now lets say you go back and add/delete some enemies. When the level is run, it does the calculations with the new enemy counts and the whole economy is still set up the way you wanted it. E.G. If you took away swarmers, each remaining swarmer would now have more gold.

Besides changing prices, this gives us two large dials we could use to balance the economy:

1. How much gold is in the level in total
2. How much gold one enemy archetype gets relative to another

If necessary, we can always go down and micromanage individual enemies, just like with the old system. I find it doesn’t happen often, but it’s an option that’s there.