Here is the paper design I wrote for for the Halo 3 Sniper Rifle:

Sniper Rifle

Role:  Long-range instant-kill sniper rifle, but reloading makes it hard to use

• Two zoom levels (2x – 7x)
  • Reloading unzooms
• Magazine of four quick shots, with slow reload
• Does headshots, even through shields
  • kills any biped in one shot (even Players)
  • [anim] special death animation for headshots
  • kill shot accelerates units
• Does massive damage
  • kills a Player in two body shots
  • kills small bipeds in one shot
• Over-penetrates flesh, glass and soft materials
• ~0.5s delay before un-zooming to reload after the last shot of a magazine, so you can see the result of your shot

By the third iteration, the Sniper Rifle’s role and gameplay was well-established, so writing the paper design was straightforward.  However, this example shows how a good paper design can be useful, even if an element is already well-understood.

Components of a Paper Design

The Role.  The most important part of a paper design is a concise, clear description of the role the element will fill in the game.  Often this means how the player will use an element, as it is in the Sniper Rifle example.  For an element like enemy character or environmental effect, it may describe how a designer will use it.  For some elements, the role will be very narrow, but common game items may be used in a broad variety of situations.  In any case, the role should be able to summarize the main purpose of an element in one or two sentences, or the element is probably too complex and should be broken into sub-elements.

The role is so crucial it is a good idea to determine the role of every element before moving on to the other parts of the paper design.  Maybe not for everything in the entire game, but at least for the other elements of the same type.  For instance, the role of the Sniper Rifle includes a reference to reloading because there is another weapon, the Beam Rifle, that has the same range and damage traits, but overheats instead of reloading.  Understanding how the roles of different elements overlap or interact makes it easier to organize the rest of the paper design.

Strength Mechanics.  Once a role is firmly established, the paper design should explain how the element will accomplish that purpose.  What features and abilities does an element need?  How do they fit together to accomplish the goal?  What is the player’s responsibility and what is handled automatically by the game?  The strength mechanics answer all these questions with positive statements of what the element is capable of or what it is allowed to do.

This is where writing a paper design takes discipline and careful thought, because it is easy to cheat and take shortcuts.  Anyone can create a set of mechanics that might produce the desired result; a designer must go further and predict where the mechanics will break down, eliminate uncertainty and refine them until they always achieve their intended purpose.  This requires a particular sort of practical insight, and a willingness to test ideals against unyielding reality.  A good designer does not flinch from critical analysis and pessimistic feedback because they know that ultimately the player doesn’t care how good something was “in theory” if it never materializes.

This can be a source of conflict between designers and the rest of the development team.  Either the designer sabotages their obviously awesome suggestions by holding them to arbitrarily high standards, or the designer fails to hold themselves to those high standards and the game mechanics don’t actually work in the end.  It is best to take these suggestions as if they were prefaced by “Assuming you can figure out some way this would actually work, wouldn’t it be cool if…”  Then you can agree that something would be cool, but take responsibility for figuring out the game mechanics yourself.

Designers are jerks

Limiting Mechanics.  There is a medical platitude that says “Anything strong enough to help is strong enough to hurt.”  Similarly, any element strong enough to fill a role can probably be abused and used to break the game.  The limiting mechanics are usually negative statements about what an element is not capable of or not allowed to do.  It may also list situations in which an element is not even allowed to exist, as when certain weapons are not used in multiplayer, or certain enemy types do not appear in specific environments.

Limiting mechanics keep an element from being used outside of its role; they should not limit the utility of the role itself!  An element literally cannot be too good at doing what it was made for.  This may be the most common and destructive mistake a game designer can make in a paper design!  Don’t anticipate imbalances that haven’t actually happened yet and start hedging too early.  It leads to infuriating decisions like sniper rifles that are too inaccurate to use at long-range, or mages that don’t have enough Mana to use their most powerful spells, or vehicles that move at walking speed.  If a role seems like it needs to be capped, then the role should be redefined or reduced, not crippled by a limiting mechanic.  Or better yet, make all of the other elements stronger and better at their roles so there is no longer an imbalance.

Giants are cool! Make the little guy bigger!

Critical Assets.  One purpose of the paper design is to assist Production in scheduling and understanding the scope of the project.  If there is an asset or features that is absolutely required for an element to function properly, but is unique to a given element, it is a good idea to call it out explicitly.  This will ensure that it is scheduled, and will also alert everyone to the fact that the element will not function until this particular asset is finished.

Flavor Details.  Sometimes little quirks or clever details have as much impact on the player’s experience as the game mechanics or even the role.  For instance, delaying the unzoom after firing the last shot in a clip seems like a trivial detail, but it is one of the reasons the Halo Sniper Rifle feels so much mores satisfying than those found in some other games.  This is more important for staples that are found in competing games, or for elements that are so unusual they need more explanation, but stretching to include one or two in every paper design leads to more interesting game elements.

We touched on how paper designs are required for the first balance pass, but what exactly is a paper design, and how are they written?  A solid paper design streamlines the design process, focuses the team’s effort, and results in a tightly integrated game.  A poor one, however, can send the design team into a tailspin as they repeatedly polish something that nobody, not even the rest of the development team, will ever read!

Timing.  The first (and possibly most important) key to a good paper design is to write it during Pre-production.  At the dawn of the video game industry, Pre-production consisted of a ten minute meeting where the head of the company and the one developer working on a project would get together and decide if the stack of player-controlled pixels were a tank, a spaceship or a wide receiver.

The Cleaveland Browns vs the Miami Space Invaders

Now, with budgets exceeding tens of millions of dollars and schedules spanning several years, the planning stage needs to be a little longer.  A disciplined designer will have a firm idea of how the game will play and what the elements will be before asking a team of artists and programmers to start working.

However, the goal of Pre-production is not to come up with a perfect plan ready to be implemented.  Game design is an iterative process; progress is made by generating ideas and solutions, prototyping and testing those ideas, and then using the results to generate more ideas.  Since there is no way to test a paper design, any iteration will be based on the designer’s imagination, and be very speculative.  A disciplined designer will exit Pre-production as soon as they have a firm idea, so the artists and programmers will have enough time to iterate.

Time is money. Wasted time is wasted money.

Audience.  The first rule of writing is to know your audience.  In the case of this site, I am writing for experienced game designers interested in imporving their craft.  In the case of a paper design, the audience is the members of the development team that will be implementing a particular game element.

Every designer generates ideas in different ways, brainstorming, writing stories, creating exhaustive lists or graphs, finding inspiration in other games, and if it works, use it!  But most of these methods are not appropriate for communicating those ideas to the rest of the team.  The artist responsible for modeling a weapon does not need to know about the 30 bad ideas you rejected.  The AI programmer doesn’t have time to read your 30 page backstory about how the enemy monster evolved on a planet with no liquid water.  A tool that is useful for generating an idea is rarely useful for communicating it efficiently.

Instead, try to anticipate what an artist or programmer might need to know.  What important features will need to be coded?  How should the player react to a game element?  How is it similar to other elements?  How is it different?  In what environment or situation is it likely to be encountered?  How will it be used in the game?

Length.  A paper design should be between 200-300 words, or about half a page of text.  A complex game element like an enemy character might stretch to three-quarters of a page, but no longer.  Why such an exact limit?  Because that is the amount of text that can be read in an average email client without scrolling.  Remember, the paper design does not need to exhaustively include every detail; it is intended to communicate the essentials of the design to the people working on it.  In order to understand a paper design, they have to actually read it, and most people will not read more than one screen of text.  Even if they do read a longer design, they won’t retain it or be able to express it.

Keeping a paper design extremely short will also prevent it from including information that should be recorded somewhere else.  For example, if the paper design for a weapon is too long because it explains which button is used for reloading, or how the player can upgrade weapons at the weapon shop, it addressing too many topics that ought to be written elsewhere.  A paper design should only include mechanics that are unique to that element, which allows it to be more concise.

Not only that, if your design cannot be expressed succinctly, it will be too complicated for players to understand, as well.  If there are too many unique mechanics for an element, players will be overwhelmed by the complexity.  A well-written paper design should read like a description in a game manual.  A good way to get started is to ask “If I wanted to explain this element to someone as they were playing the game, what would I say?”  In short, a paper design should be about as long as this explanation of how long a paper design should be.

Language.  A paper design should avoid emotional or vivid language in favor of specificity and clarity.  It is easy to conceal fuzzy or flawed ideas beneath beguiling prose.  If a paper design is written to be read analytically, it will be held to a higher standard. 

Using simple language without rich connotations also helps avoid two common communication problems.  First, it leaves programmers less room for interpretation.  A paper design that describes a weapon as “powerful” could be implemented in many ways, but one that says “does enough damage to kill a player in one shot” only allows for one.  Simple language also allows artists more room for interpretation.  A paper design that calls for “a spider with human hands” will probably end up with a pretty silly looking model, but one that describes “a multi-legged creature capable of carrying an infantry weapon” will give the artist more freedom to make something aesthetically interesting.

Now that have a general idea of how to write one, next time we’ll go over what specific information a paper design should contain.