Three Rules to Balance By

Game balancing and tuning are some of the most difficult parts of game design.  Thankfully(for me anyway), they are also some of the most enjoyable and rewarding parts. That's because a great game is made in the balancing and tuning. Bad tuning will wreck any great design. That's power!

I consistently rely on 3 rules to help me navigate the minefields.

All three of these rules are a bit sneaky in context of the article title. That's because they are not so much rules to balance by as rules to design the systems in the first place.  After all, the best way to help yourself balance is to avoid designing systems that are virtually unbalanceable!

Rule 1: Systems Should be as Simple as Possible to Satisfy Design Goals

I am a big fan of complexity.  Some of my favorite games of all time have very complex relationships, and I love playing grognard-style wargames on and off the computer.  As a designer, though, complexity is The Enemy! Ok, perhaps that's not entirely fair. But in my experience, a central tenet of successful systems design is to only add as much complexity as necessary.

Of course, "as necessary" is a broad term, and that's intentional.  The rule is not "never design complex systems."  Sometimes complex systems are just what the doctor ordered.  However, a lot of times, a simple approach gets the job done--that is, satisifies your design intent.

When intially designing systems, it's pretty easy to add in many different layers and mechanics.  It hasn't really cost you anything yet, and often you are guessing about gameplay features and mechanics that you might need later in development.

Down the line, though (during balancing), having unduly complex systems in place tend to have differential orders of magnitude effects on tuning complexity.  One way to save yourself some considerable pain is to be militant about keeping things as simple as possible early on. The old adage "K.I.S.S." (Keep it Simple, Stupid!) is as true in game design as anything else.

I find a layered approach generally works best: implement your core mechanics, then playtest. If you find you need another "layer" of mechanics, add that, then playtest. Repeat until the game is fun.

Sometimes, there is no way around having considerable complexity. In those cases, Rules 2 and 3 can help slant the playing field in your favor.

Rule 2: Sytems Should have as Few Independent Dials as Possible

Tuneable game mechanics can be conceptualized as a dial. Sword damage not powerful enough? Twist the dial right to boost it up. Treasure rewards too rich? Twist the dial left to drop them down.

The more tuneable mechanics you have in your game, the more dials you have to monitor and adjust.

Dials can be categorized into two classes: independent and dependent. For you math and engineery-types, this is the same as independent and dependent variables.

Independent dials: these are mechanics that are not directly affected by changes in othe rmechanics.  For example, the amount of XP awarded for killing a Sewer Rats (your game *does* have Sewer Rats, right?) is not changed if I tune how much damage a sword hit does.

XP Dial-> determines that Sewer Rats = 50 XP
Change in Sword Damage dial-> does not affect Sewer Rats XP. Nor does anything else.

Dependent dials: these are mechanics that can be directly affected by changes in other mechanics/dials. For example, if I specify final jump height as a % of Running Speed, then I have created a dependent dial. Changing the Running Speed will in essence change the Jump Height. There is no way to absolutely and independently set jump height.  For example:

Another example would be specifying "RAGE" damage as an amplification bonus to the current weapon damage.

Dependent dials are a GOOD THING, as Martha would say.

Think of your game systems. Do you want them to look like a 747 cockpit? With a zillion different dials and buttons and switches, all of which must be monitored and any one of which could sink the whole plane if toggled at the wrong time? Ideally, no.

You want as few dials as possible, so you can carefully and rigorously monitor them and tweak them to your heart's content. Less students in the class means more attention per student.

The advantage of dependent dials is that they save you from having to always change every dial. Want to increase Jump Height and also want to increase Running Speed? Turns out you can just change the Running Speed dial and get both things accomplished. However, you still have control of just jumping if you need to adjust it without affecting running speed. But often you will want to do both at once, so twisting only one dial saves some time and is easier to remember.

In practice, you want to be adjusting depenedent dials directly only about 1/2 or 1/4 as much as you are adjusting independent dials. Those savings add up over time! Once you find the right relationship between Rage amplification and core weapon damage, you leave that dial set and just tweak core weapon damage to match the other game mechanics.

This analogy still holds up with our 747 visual model.  If you examine a cockpit like that carefully, you will see that often there are dials/switches that are linked (mechanically or at least visually). Most of the time, all four engine throttles should be moved together, so there is a hard link that facilitates that. The pilots can decouple the controls if necessary (and sometimes it is), but most of the time one linked adjustment is sufficient.

Sound Engineer panels scare the living bejeezus out of me. Talk about a lot of dials! But ever notice that hard linkages exist between many of the sliders? Once the engineer gets the relative relationships correct, she can link them and then just push one single slider to get all 27 to move at the same time.

As with Rule 1, I am not suggesting "don't add independent dials." Just only put in as many as you need. "You'll know it when you need it."

Rule 3: Relationships (Links) Between the Dials Should be as Straightforward as Possible

When you have linked dials, there are a lot of ways you can link them. Here, the mechanical analogy starts to break down a bit, but essentially you can link dials with all sorts of different ways: hard links, springs, rubber bands, etc. When you twist this dial 2 notches to the right, what happens to the dependent dial? Does it twist 2 notches right as well, or 1 notch, or 5 notches to the left?

In other words, if two mechanics are related, *how* are they related?

Here again, simplicity is key. Unless you have a compelling reason, make it simple and straightforward. In rough order of simplicity:

Rigid link example:
RAGE damage = weapon damage + 5
Changing weapon damage by +2 points results in a RAGE damage increase of + 2 pts

Linear link example:
RAGE damage = weapon damage * 1.50
Changing weapon damage by +10% results in a change to RAGE damage of +10%

Non-linear link example:
RAGE damage = weapon damage * 1.50 BUT there is a minimum of 5 pts of damage and a max cap at 100 pts
Changing weapon damage MIGHT increase Rage damage, but it also might not! (if the damage is already capped)

Weird Mental Models
Your mileage may vary, but the control panel conceptual model resonates with me. And the constant strive to attain simplicity and eloquency is one that almost always pays off.

In reality, I sometimes throw in way too many dials, and violate the rules from time to time. But I typically regret it, and when I am chin deep in balancing dials, less is usually more.