Disclaimer: First, let me say that this is most certainly not the only way to approach game design and balance. All I am presenting here is my approach to game design, and specifically how I approached the design of C&C: All Stars. The following are the principles that I’ve used in guiding this mod, or, maybe just the principles I’ve tried to use (the team and the fans will ultimately determine how successful they are and how successful I was at implementing them).
Part One: An Introduction to the Elements of Game Design
Teamwork and Organization
I have yet to meet a person who has exclusively good ideas. This is especially true in game design. Sometimes, you just need someone with an outside perspective to raise their hand (figuratively or literally) and declare that what you just suggested was the stupidest idea they’ve ever heard. It is better to have that said to you during the design stage when you can do something about it than during the postproduction stage when you really can’t. As such, my number one rule for good game design is to never have it occur in a vacuum, and to involve as many people as possible. Just because someone is an artist, or an INI coder, or a webmaster, or a tester, or whatever, does not mean they don’t have something to add. As a lead designer, it was often my role to start the conversation, and to decide what gets discussed when, but it should never be a lead designer’s role to prevent a discussion.
Of course, eventually, a decision must be reached, and, inevitably, if you are ultimately in charge of the design of the mod, it’s your decision. Also inevitably, some people will be happy with what you decide, and others won’t be. What I basically always tried to do was to give some sort of rationale for my decision, but to still make it clear that the decision was the decision, and for the time being, it was going to remain that way. For a minor issue, like a balance tweak late in the design cycle, it’s quite easy to playtest after the change and adjust further. For a major issue, like the composition of the side in the pre-production phrase of development, it’s a lot harder to reverse yourself and to test your decisions. For this reason, All Stars had a very fluid design for a long time, and team members were always discussing it. These conversations were not necessarily bad—indeed, conversation is better than no conversation—but as a lead designer, ultimately it becomes your job to shift the conversation and actually make progress.
The Design Document
The Design Document is the most important part of game design because it is a statement of intent. It manifestly moves an idea from the “wouldn’t it be neat if we tried this?” stage to the “we’re going to try this, with the intent of keeping it.” For those who don’t know, the Document is essentially a written out version of everything a game is going to have. For a total conversation mod, maybe it will be a few dozen pages, outlining the units, structures, upgrades, Generals Powers, etc, that are going to be added for each side, and why. If applicable, it also outlines the story and any missions that are to be added. For a commercial game, it is usually much longer, because things like 3D engine programming, art techniques, and more have to be added into the equation. The underlying similarity is that the design document has to stand by itself. Someone who is relatively well informed about games should be able to read your design document and know exactly what it is you are trying to create.
In reality, though, words are not enough, since computers do not really speak English. When you say a unit is “better than another unit x” and “fast and mobile” in your design document, for example, you need to ultimately follow that up with some more details. This involves introducing yourself to the relative number based systems used by lots of games these days. The principle is simple: the game engine renders an attribute of a unit based on an arbitrarily defined system that has meaning when it is used in a relative way (comparing one unit to another). In the design of the system, the scale doesn’t matter. As long as all units obey the same scale (that is, the units you want to be weak have the relatively worse values, and the stronger units have the relatively strong values), there shouldn’t be a problem. Of course, if you’re working with someone else’s engine (as almost all mods do), then you’ll want to figure out what scale they are using and what relatively good and bad are and adapt your numbers to that. Figuring out the scale of all the attributes can take some time and experience (I was lucky to have an experienced SAGE engine modder, CommieDog, work with me on this aspect of All Stars while I was still figuring this out).
Once you do figure out the scale you’re working in, though, it’s time to begin speccing out the unit attributes. Of course, the attributes a unit or structure has vary by engine and game type, but common ones include things like speed, health, armor, weapon type, weapon damage, etc. For every possible unit/structure attribute, you’ll want to begin quantifying and tabulating all the ideas in the design document. For All Stars, we created a series of tables based on the structure of the SAGE engine. One table, for instance, delineated every type of weapon we were adding and all the weapons’ attributes, such as range, projectile speed, damage, damage radius, etc. Of course, we had to research all the possible attributes supported by the engine and what we could do and couldn’t do in the SAGE engine before we could finish this table. We did many tables, each for a different set of attributes and each quantifying exactly how the mod would play. While it is impossible to truly get a feel for what the mod will be like in the end when it’s actually coded and ready, creating all these tables allows you to truly flesh out your design and view it from a ruthless numerical perspective. Quantifying the vision of the design document and understanding the relativistic sense of balance are two imperative parts of the design process that are important moving forward.
Read on to Part Two:
An Introduction to Balance
An Introduction to Game and Mod Design by Blbpaws
Part One: An Introduction to the Elements of Game Design
Part Two: An Introduction to Balance
Part Three: Creating Variety: All Stars as a Case Study
Part Four: How Goals Affect Balance: C&C 3 as a Case Study
Part Five: The Art of Playtesting
