RTS Game-play Part 5: Introduction to Unit Balancing

November 26th, 2008, RTS Design

jeb <3 RTSThe most widely discussed RTS topic is without question unit balance. How to design units, their attributes and their build costs, is a game design equation with infinite solutions. This part is a short introduction to a number of basic definitions, which I will refer to when I further descend down into the topic.

Visible vs Hidden Balancing (or Concrete vs Abstract)

There are two main kinds of unit balancing, and I will write a separate blog post for each. The first one, which I will alternately call “visible” or “concrete,” is balancing which the player can see, hear or feel. Visible balancing are things such as unit speed, attack range and unit movement dimension (ground, air, water etc).

The second type of balancing is the “hidden” or “abstract” type of balancing. This kind of balancing is used in the game’s rules, changing probabilities for events or efficiencies of abilities. Examples of abstract balancing are unit health, damage/armor types and similar stats. Abstract balancing is usually presented to the player through text labels in the user interface.

As a rule of thumb, visible balancing is better than abstract balancing, but you will most likely need to use at least some kind of abstract balancing in order to tweak things.

Rock-paper-scissors vs Weakness Support

In most RTS games you would prefer if the players built several different kinds of units. A game could be interesting even with only one major unit type, but people may complain that it’s all about “massing units,” which will hurt your reviews. The standard way of enforcing this is to make sure that all units have at least one weakness. This weakness can be exploited by your opponent, and thus forcing you to mix up your units a little.

How you apply this unit mix enforcement depends on whether you want to use a rock-paper-scissors type of unit balancing, or if you want to go with “weakness support.” The first is when you design your units to be strong against a specific type of enemy unit (or type of units), and weak against another. For example, you may want your archers to be strong against infantry, but weak against cavalry (or whatever rocks your boat). This kind of balance can be created by simply using abstract balancing of unit stats (health and damage ratings), though your game will be more interesting if you are able to use visible balancing instead (more about this later).

The second option, “weakness support,” is when you make sure that all units have a certain weakness. The difference to rock-paper-scissors is that the weakness is based on an attribute of the unit, and not on the attribute of an enemy unit. For example, the weakness with infantry in the rock-paper-scissors scenario above is that it’s vulnerable to archers. In a “weakness support” scenario the infantry’s weakness would be slow movement (and maybe its inability to attack flying targets, if it’s a fantasy theme). The “support” in “weakness support” refers to how the players should reinforce the unit’s weakness. For example, if the infantry is slow-moving, then maybe its “weakness support” is wagons which can transport infantry quickly into battle. In other words, infantry lose to archers, wagons lose to archers, but infantry and wagons together win over archers thanks to the weakness support.

Adding Units to Your Design

I was going to write more in this section, but when it comes to adding new units to your game, you should probably listen to the advice of Dustin Browder, lead designer of Starcraft 2:

  1. A unit should have a cool personality. A unit must be something that is fun to play with.
  2. A unit should have their own very unique role on the battlefield.
  3. A unit should be fun for the enemy to try to deal with. Generally this means good strengths and interesting weaknesses.

What that means, essentially, is that you should create units that you think are cool and see how they fit in your design. You shouldn’t try to design new units to solve a problems in your current design, but rather see how you can make your current units work better together. Add units that feel right and remove those that don’t. Unfortunately, not everybody has the luxury of infinite development time like Blizzard…

2 Responses to “RTS Game-play Part 5: Introduction to Unit Balancing”

  1. JademusSreg :

    There is a lot that could have been said about unit balancing, so there is a lot that wasn’t said. The points you do make would benefit from further explanation and examples; this part suffers from the same issues in Part 3. I just don’t think this received as much attention as the subject warrants.

    Also, accurate crack on Blizzard. = )

  2. eliskan :

    Hello, I’ve been messing with my own RTS and am currently at the stage of design where these details matter most. It’s a homebrew game for Pythonista (a Python based app for iPad), you can view my progress here http://omz-software.com/pythonista/forums/discussion/249/minimap-and-tile-mapping-prototype-rts-for-ipad

    I am contemplating an attempt to break the typical paper-rock-scissors… without breaking it. What I mean is that I don’t want specific unit classes. I want every unit to be the same, and every unit carries its own independent experience. These units will be able to be trained and harnessed into masters of their various skills, then build a homestead and train more ‘children’ with some of the skills of the parent. Each unit may then further equip itself with certain skills, all of this costing resources. The game will be limited to about 20 units per player.

    Each unit may in fact have its own resources. The goal is to simulate more realistically a village, where units are independent creatures.

    What are your thoughts? If you’re still around (I see this article is a few years old)


Oxeye Game Studio is proudly powered by WordPress
Entries (RSS) , Comments (RSS) and YouTube Widget by Daiko.