Can you perfectly predict the weather? No, because it’s too complex — the “chaos factor” makes it impossible to perfectly predict. The same holds true of the balance of any modern MMO. This may be surprising. We create every aspect of MMOs, so why can’t we perfectly predict them? It turns out that the “chaos factor” in an MMO comes very quickly too — much more quickly than players realize — and there’s no way to model the entire possibility space.
But, like weathermen, if we put enough effort and energy into balancing a game, we can at least be more accurate than we are inaccurate. Which is usually good enough. Let’s create some simple game systems for a WoW-like MMO, and then see how balancing happens.
Pick your axiomatic values
So you’re the lead systems designer on a new MMO. Where do you start? It’s a brand new world that you can bend to your needs — and more importantly, to the needs of your target audience. Start with that target audience. Brainstorm what they might like out of your game. Write these down as statements, and call them “axioms” or “guidelines” or something like that. Assuming we wanted to make a WoW clone (wait, we do!? … but I digress…) here are some reasonable guidelines:
“The average 1-on-1 combat should involve the use of 20 attack actions per fight.”
“1-on-1 Combats should last 30 seconds on average.”
“Players should reach a new level after every 3 hours of combat.”
“Players have health bars and energy bars, and abilities which cost energy to use.”
Obviously these statements aren’t proven to be good choices. They’re going to change a lot — but for the moment, you should pretend that they’re constants — axiomatic truths. You need something to be constant in order to plug things into formulas. Of course, eventually you’ll need to change these, which will have a ripple effect across the entire game. (Which means that you really need to figure out what these constants are during pre-production… it is unacceptable to change these during production, as any change usually throws out all previous balancing efforts! But I digress again.) These are good for now! Let’s move on.
Deduce the obvious results
Next we turn these statements of “fact” into other statements about our game.
“Combats should last 30 seconds on average and there should be 20 attack actions per combat, so on average, the player uses a skill every 1.5 seconds.” (Okay. Not too button-heavy and not too slow, a fairly WoW-ish pace there.)
“Since an enemy dies after an average of 20 attacks, each attack kills the opponent by approximately 1/20th.” (Well, that’s logical, if not particularly satisfying-sounding… but it’s a good baseline.)
“Since a player must fight 3 hours to level, they must complete 360 combats to level.” (Ouch! That’s a lot of fighting! But maybe that’s okay; we haven’t considered other factors like leveling-up from completing quests.)
And so on. You do this for a while, going back and forth with your axiomatic statements and their immediate repercussions, until you’re happy with the results. The axioms and statements above need a lot more fleshing out, but let’s pretend they’re great and move on.
Create archetypal content
Now you’re ready to start prototyping. First, create the world’s most generic character, the world’s most generic ability, and any other super-generic things you need. These things are the most average things possible, and are based on your previous results.
So for our example, let’s say we create a Guy, who is the most generic possible player. Each Guy has 100 health and 100 energy. They have the archetypal skill “Stab”. Stab does 5 damage, which means that 20 Stabs will kill a Guy. After Stabbing, it takes 1.5 seconds before you can use another ability, so it will take 30 seconds to Stab 20 times. Let’s also say that using Stab costs 5 energy, too. Since a Guy has 100 energy, after 20 stabs, the Guy will be out of energy. But his enemy will be dead.
Okay! Say, this balance thing isn’t that hard after all! Now you can create two Guys, have them fight, and sure enough — barring any user errors or lag, this is a balanced, but stupid, game. The first person to attack always wins, however. There’s no spark of excitement to this!
Create variants to see what happens
Next we create more abilities. Let’s see, we’ll make Kick. Kick is like a double-stab. So it costs 10 energy, does 10 damage, and can be used every 3 seconds. Sounds perfect! Let’s play with this. Your Guy can use Stab and my Guy can use Kick. Who wins? I do, every time.
At first, we’re even. I Kick you for 10 damage, and before I go again, you stab me twice for 10 damage. Seems fair! But when we’re both down to our last 10 health, I will Kick you and you will Stab me, and you will die while I still have 5 health left. Sure, you died with 5 energy and I’ve got none, but who cares? You’re dead now, and I get to loot your corpse, assuming we had loot or corpses yet, which we don’t.
So we’ve discovered the first balance issue: the more damage you can do at once, the better off you are, all other things being equal.
And so it begins: you must leave the comforting realm of perfect logic and begin rampantly making shit up. How do we balance Kick versus Stab? Since our model only has one other variable in it, Energy, the easiest way to balance Kick is by making it cost more Energy than Stab.
What we do is create a fudge formula, which is any formula that correlates one game mechanic to another. Our fudge formula will dictate how energy relates to damage. Let’s start with this one:
“If you deal n damage, it should cost (n*n)/5 energy.” (This is a terrible formula for a real game, but it’s a starting point for our prototype.)
So now Stab, which does 5 damage, should cost 5 energy. (Great, no change there.) Kick, which does 10 damage, should cost 20 energy. Now Kick is quite expensive to use! Let’s try it out and see how it does.
Now if I Kick while you Stab, I am going to run out of energy while you have 50 health left. And since there’s no way to regain energy, your weak-but-cheap Stab attack finishes me off. Hmm, now Kick is too expensive to use and feels dumb. Let’s fix it by giving both players 150 Energy instead of 100. Now if I use Kick over and over, I’ll be winning until I am down to just 10 Energy… and you have 30 health left! Then you win. Okay, that feels about right: now if we give players both Stab and Kick, Stab will be the main attack, and Kick will be a great “finishing move.” We have differentiated the roles of our attack abilities! Woo.
But when we playtest, it won’t take but a moment to realize there’s a “best strategy” to playing this game (“Stab until the end, then Kick”). So once again, the winner of every fight is the guy who goes first.
We’ve got two different attacks, and they’re both situationally useful, but there’s no fun here yet. What now?
Add Things Til Fun Happens
We could fiddle with these two abilities a while — tweak the timing and energy costs and so on — but no amount of adjustment is going to make those two abilities fun by themselves. It’s too simple a system.
Let’s add a third ability, called Heal. This restores 5 health to us, and costs 5 energy. After using it, we need to wait 1.5 seconds before we can do anything else. In essence, it’s like its a “reverse stab.” What happens when we test it? Turns out that this Heal is mostly useless. Sure, Heal gives you health, but it does so at the same rate that you could be taking health from the other guy.
We’ve accidentally created a fudge formula here without even noticing. We’ve implicitly stated that “1 point of healing is worth 1 point of damage”. This fudge factor makes healing seem useless on its own… why heal when you can deal damage instead? So we may want to change this fudge formula. But let’s not do that yet… the simulation is still too simple; we can’t tell what to change it to yet. So instead of fiddling with Heal, let’s add some more complexity that will make Heal more useful.
Let’s add a fourth skill: Mesmerize. This 1.5-second attack makes the opponent unable to do anything for three seconds… unless you hit them first, which breaks the effect. In other words, it’s just like a “sheep” ability in WoW or a “mez” in EQ2.
With the existence of this skill, Heal becomes somewhat useful. Now the best combat strategy is to Mesmerize your opponent and then Heal yourself while he’s unable to do anything. This is better than just standing there duking it out, because your mezzed opponent isn’t able to expend his Energy in any useful fashion, but you are.
So how much Energy should Mesmerize cost? Well, while the other guy is mesmerized, we’ll get to Heal 1 time, and the other guy will be unable to Stab (or Kick) us once. That means that we’ll be able to create at least a 10-point health difference from this: if I use Heal I’ll regain 5 and the other guy won’t Stab me, effectively giving me 5 more. So we could price it as something that restores 10 health… except it doesn’t really restore 10 health, does it? We still have to pay for the Heal. So let’s price it somewhere in between — we’ll make it cost 7 health. We previously said 1 point of healing = 1 point of damage, so our old damage fudge-factor applies, making Mesmerize cost (7*7)/5= about 10 Energy.
If you playtest this you’ll find it’s fun for a minute or two, so we suspect there might be longer-lasting fun down this road. So we add some more traditional MMO abilities: a damage-over-time ability, a way to regain energy in combat, a “knock down” move, and so on. As we add more abilities, we keep doing this process of creating fudge formula that correlate new mechanics to our old mechanics. After we have a few dozen abilities, we can divvy them up into “classes”: Damager Guy, Healer Guy, and so on. Then we can play with these “classes” to see how they interact with each other. (And now that there are a dozen buttons to press, it will take us quite a few playthroughs to figure out the “best” way to play.)
But at last we have the crude beginnings of a class-based MMO combat system. Each class is interesting, and plays off the other classes in unique ways. Hooray, we win… right?
Looking at More Than One Angle
The thing is, we’ve only considered gameplay from one angle. We’ve looked at single players beating each other up, and we’ve come up with a system where that’s entertaining. But what happens when we have TWO people fighting two other people? Or one person fighting two people? Or one guy who’s sole objective is to just stay alive for two consecutive fights?
Any of these questions throw the whole house of cards into disarray. If two Healer Guys fight two Damager Guys, it may turn out the healers win every time, because their abilities are more synergistic than the damager guys’. Is that okay? And another damning thing: if we consider what happens when players fight two battles back to back, the Healer Guy is way better than the Damager Guy, who is always nearly-dead after the fight.
Although it previously seemed like Heal was underpowered, now it sounds like Healer Guys are more powerful than Damager Guys after all. So let’s adjust one of the fudge formula involved. We’ll say “healing 1 point of health is worth dealing 1.25 damage.” Now we redo all our tests. One on one, the damager guy is deadlier than the healer guy, but the Healer Guy fares better over the long haul … assuming he survives. After playing with it for a while we decide it works okay.
Then we look at another angle. What happens if two seconds of lag get involved in combat? Oh crap, now the healer guy is way better again thanks to his Heal Over Time power. How often will the game lag? Is that important?
On and on we go, making fudge formulas and tweaking them again and again. You’ll notice there’s not a lot of science here. For some games, we can actually mathematically balance the game from a certain angle, but only the most boring of MMOs has one angle. Once you start looking at multiple encounter scenarios (1-vs-1, 2-vs-2, 1-player-vs-10-weak monsters, 1 laggy player vs 1 non-laggy player, etc.), it becomes far too complex to represent it all mathematically.
Not balanceable?! This can be surprisingly hard for some people to believe. But a modern MMO has over 1000 distinct combat verbs alone, each with intentionally-different strengths and weaknesses. You can’t hope to model it all perfectly. “Ah, but what you do is actually make most of those 1000 verbs be the same with only cosmetic changes!” Yeah, uh, this isn’t the early 90s anymore. Players easily see through mathematically-identical mechanics, and they find them less fun. Games have to be fun first and balanced second. A fun game will keep customers… a perfectly balanced but un-fun game won’t. So you have to add all kinds of crazy unbalanceable mechanics into your game, and then correlate them all with fudge formulas.
The reason they’re called “fudge formulas” is because they fudge the balance in a way that serves your design goals. If you want to encourage grouping, for instance, you would change the fudge factors differently than if you wanted to encourage soloing or exploring or anything else. Each fudge formula serves a purpose, and a lot of the art of game balancing is figuring out how to create formulas that make players play the way you want them to. (And by the way, don’t forget to document the goals of each formula for posterity!)
After the Game Ships, Start Crying
All through beta you adjusted the formulas, which in turn changed how the classes worked. As you watched beta-testers play your game, you found even more angles than before: players start using combinations of skills and items and terrain in ways you hadn’t expected, and you work feverishly to compensate for those. This causes a ripple effect in other mechanics, so beta-testing is a tedious, repetitive time for mechanics designers. (And also secretly incredibly fun, but we will never admit that, because it’s also a super stressful time.) But finally the day comes when you launch!
Assuming you did your job well, the game feels both fun and balanced, at least on day 1. But it doesn’t last. Soon you realize that Healer Guys collect more money over the long term because one of their abilities costs slightly less to maintain than Damager Guys. After three months, players notice too, and start getting upset that Healer Guys have more money than Damager Guys. It’s not a dramatic effect, but players noticed it, and it’s screwing up the whole balance of things! You’ve got to fix it.
And at the same time, that jerk the producer comes up to you and says, “We’re going to need some quick interim content in a few months, so can you create a new class? Lou the engineer has this new code routine for spells that affect ten people at once, so some of the new abilities should use that. And Stacy the artist has this great animation of a guy drinking blood from the jugular of his enemies, so if you can work that in…”
So you begin working on yet more game mechanics, all the while tweaking the old game mechanics to counteract new situations that players keep coming up with. And once you launch this new class, it gets worse! Now there’s even more complexity in the game world and even more new angles to look at. Instead of winding down your balancing efforts, you seem to be making more and more adjustments every day!
Why Are The Players Screaming ‘Nerf’? Can They Not See That Fire Damage Is 8.5% Too Powerful?
What’s wrong with the picture above? The trouble is that you haven’t made the leap between developing for beta and developing for a live game. During beta, you made constant changes to your simulation every few minutes to try to get it just right, and now that it’s live, you’ll want to keep doing that. But players are not as happy about this. From their point of view, your changes are incomprehensible. “Why the hell did the designer nerf my ability to make 5 silver pieces an hour? It’s irrelevant. What a dick move!”
The bigger problem is that you can’t keep up with the players. Players are far more numerous than developers, and given the astonishing complexity of your combat simulation, they will find holes in your rebalanced efforts almost immediately. And then you need to rebalance again because of it. (One of the better examples in recent memory is the Death Knight, which immediately required huge revamping as soon as it was launched, and then needed huge revamping again before it came close to kinda-sorta balanced.)
Beginning MMO balancers will think they can solve the battle of designer-versus-player by creating better and better combat simulations. This is especially likely if they’ve previously balanced other types of games — combat-simulators are an important element of balancing an RTS, after all. But it is largely ineffective for fine-tuning MMOs. This is the curse of MMOs: they are so blessedly, beautifully complex that the possibility space dwarfs almost any other kind of game. Plus, all the other developers working on the game will be constantly affecting balance in ways your simulation can’t predict… well, you could code individual adjustments in, but there are countless numbers of them.
For instance, players will quickly learn that the landscape of a popular hunting area lets them stand on a nearby rock to gain two extra ranged attacks before monsters reach them because the pathing to that rock is bad. And then the player can backflip off that rock and over the river, which gives them a few more shots because the monster has to use its “swim” animation instead of “run”, which has a slow transition sequence. There are going to be tons of ways the players can manipulate the system, and you won’t even know what all of them are let alone have time to counter them in your simulation.
But systems designers will try anyway… that’s kind of their job. (Well, usually, play-balance is only about 1/4th of their job, but it’s the part that takes up all the spare time it can get because it’s never quite right ARGH I need to fix this now!) So designers will create the best simulation they can, either in spreadsheets or in code, but as they tune it they will also be adding five new variables each month, because Tony the content designer stopped by to say “hey, the engineers coded some unique boots for my quest, can you balance them? It’s nothing too hard: they just let the player jump extra high.” ARGH.
The Key Is To Bundle Your Changes
What I’ve described here happens to almost every MMO. It’s an embarrassing stereotype that systems designers are obsessed with perfecting their makeshift model even though the game they’re modeling changes every month. But it’s a stereotype because it’s mostly accurate.
But all those constant small changes are torturous to players… the drag of constant change wears at them. However, a smart producer steps in and says, “I am putting a moratorium on balance changes for six months. After six months, you can roll out a lot of changes at once, rather than hundreds of tiny tweaks.” This is a brilliant move because it lets the community and PR folks build excitement for the balance changes — the changes aren’t just a constant series of maddening tweaks… now they’re a Big Deal.
It also means that the system designer won’t spend all their damned time balancing, and can work on all the other stuff they’re supposed to do, like creating new monster mechanics or improving the leveling curve or making loot drops more exciting.
But not being able to make lots of small changes is torture. Instead of making a tiny adjustment and watching how it affects things, you’re forced to perform surgery with an axe!
And that’s okay, because balance is only a moderately-important element to a game. Many tragically imbalanced games last for a very long time, because they’re fun regardless.
Eventually I realized that balancing for “fairness” was pretty unimportant compared to balancing for “awesome”. You need to get the “fairness” thing in the right ballpark, but players will never be satisfied… however, if they’re all feeling awesome, they won’t quit over it. It’s a lot easier to make sure everybody is awesome, too, as opposed to balanced.
If you focus on making sure everybody is having fun, even though they’re not perfectly balanced, it will all be okay in the end.