|
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:
- Jump Height dial -> specifies jump height as a % of running speed (e.g. 50%)
- Change in Jump Height dial -> changes final jump height
- Change in Running Speed dial -> changes final jump height
- Thus, adjusting jump height can be done in more than one way.
- There is no way to set jump height in a way that is guaranteed not to be affected by something else.
Another example would be specifying "RAGE" damage as an amplification bonus to the current weapon damage.
- Change in RAGE dial -> changes final RAGE damage
- Change in Current Weapon Damage -> changes final RAGE damage
- There is no way to set RAGE damage absolutely and independently
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: changing the independent dial results in exactly the same amount of change to the dependent dial
- Linear link: changing the independent dial results in a proportional change in the dependent dial, but the proportionality isn't a direct 1-for-1 link
- Nonlinear link: changing the independent dials can result in variable changes to the dependent dial. For example, changing the independent dial from 1-2 may result in a change of 5 in the dependent dial, but changing the independent dial from 2-3 may result in a change of only 3.
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.
|
- simple systems can lead to incredible complexity (eg : the game of Go);
- adding mechanism to a system, therefore making it more complicated, can improve balance. (eg : the increasing gravity in Guilty Gear, wich avoid some kind of in air infinite combo.)
About the "links" :
There is a fairly common mathematical concept that resume your link idea: the function. For instance, linear function are all of this kind: y = a*x+b, where y is the output (the dependant variable), x the input (the previous value of the variable) and a,b are parameters (your dials).
Your rigid link is a =0, b = something ( y <-- y + b );
Your linear link is b = 0, a = something ( y <-- y * a );
You seems to have missed the most general (mathematically speaking) case of A and B not equal to zero.
Your non linear link is effectively something else. (Not really an usual math function, but nothing a drunken programmer can't do).
My point is you should use a little more math, it may open you new perspective and save your time. But I cheer you for trying to keep everything simple and elegant, even if it leads you to throw away everything I wrote before because we don't share the same notion of simplicity ;-).
Jimmy: When you have to tune/balance something that was designed entirely by someone else, it's a matter of making do with what you have and doing your best. You can still kind of use the three rules, in the sense that you look for things that you can turn dependent. For example, changing some dials to be directly affected by other dials. In the parlance of the article above, it would be changing RAGE damage from a straight +2 bonus, to a +10% bonus--thereby allowing RAGE tuning to auto-adjust when you are tuning the underlying weapon damage. The other thing you can look to do is retrofit/eliminate any systems or mechanics that are unnecessary. That all depends on how far along you are in development. But generally removing things is easier than adding things.
Eric: You are absolutely right. Sometimes I do slip in extra dials for exactly that reason--I have a feeling that later I might need more fidelity and doing the implementation now is easier than trying to retrofit later. Especially if someone else is doing the implementation--it's sometimes better to give them a list of all possible things even if I only anticipate using part of them. In those cases, I will still try to keep things simple by using as many linked dials as possible, knowing that I can always unlink them later.
Nicolas: Good observation. I am an engineer by training, so I actually do think of mechanics as functions. In fact see my article here: http://www.gamasutra.com/view/feature/4091/anatomy_of_a_game_mechanic.php
However, in my dial analogy, I am specifically trying not to use math/algebraic functions, because I find a lot of people's eyes glaze over! So I am trying to present a conceptual model that doesn't require an equation to convey (even though I actually use equations in implementation, of course!). Thanks for the comment!
One is real complexity; this can happen when you have a few simple rules which can apply to each other. Go was given as one example, but Conway’s Game of Life is another old-school favorite. Do a search on the “r pentomino” for an example of how a very simple pattern, when a few simple rules are applied, can demonstrate completely unexpected behavior.
There’s also apparent complexity, which depends on the human willingness to attribute intentionality to behaviors that can’t be explained as mechanical. Douglas Hofstadter once described an example of this: he brought into the classroom a small opaque ball. When he set it on the ground, it started rolling; when it bumped into things, it appeared to back away and try a different direction, almost as though it “wanted” to get somewhere. In reality, there was a gyroscope inside the ball. When the ball hit an obstacle, the force of the gyroscope would be applied at right angles to the direction of resistance, so the ball would then move in unexpected directions, giving it the appearance of complex intentionality.
System designers can make use of both these kinds of complexity. Real complexity from simple rules is easy enough in concept; the trick (as noted) is balancing the possible behaviors that can emerge from those interacting simple rules.
Apparent complexity can be fun to create, too -- in this case, the trick is to hide the gyroscope. This approach is about presenting an interface to a black box system. Players can’t see the inside of the box, so if the system behaves in a complex way, they will assume for you that you must have created a complex system, even if the reality inside the box is just a few simple interacting rules.
Where these approaches differ is in predictability. A real complex system may be predictable, but so large in its possibility space that only a few players will bother. This approach may be useful when you want to provide play experiences that differ among players but you don’t want to try to hide the rules.
By contrast, an apparently complex system may not be predictable at all, depending on how the hidden rules are written. This approach may be more useful when you really want players to have to solve your gameplay challenges on their own, rather than referring to a Web site listing all the answers. The danger with this approach is that it must not appear random -- if players think the system’s behavior is random, and therefore unresponsive to their inputs, then you lose all opportunity to guide their play experience.
Fun topic!