Jump Kick Designer

Posted on September 8, 2011 by rewardingplay

By this I am not describing an absurdly narrow area of expertise… I am describing my aesthetic.

It is easy to become lost in the mechanics and machinations of game design. To glorify systems and metrics and equations and definitions and exceptions and minutia — to obsess over design in detail. It is a habit hardened in the same forge as our instincts, back when we first began to hone our craft. We became accustomed to looking at our feet, wary of missteps, and now we believe the road to be the prettiest scenery. But we are no longer in danger of stubbing our toes — so look up! Beyond mere mechanics lies meaning, and deeper design requires more than technique, it demands values.

One way to understand your design values is to find your ultimate game mechanic. What gameplay action most realizes your design aesthetic? What concept always feels fresh? What tool springs to mind for every problem? For some designers, the Dialog Tree is the root of their art. Others appeal to the direct, uncompromising demands of the Headshot. Some designers have hung their entire career on the Fine-Tuned Economy or the Skill Bar, and their focus has led to many fine games.

What's better than a jump kick?

For me, it’s all about the Jump Kick. Taken individually, both the Jump and the Kick are atomic, fundamental, with an enormous variety of possibilities. The Jump because it completely analog, a fraction lies between safety and disaster. The Kick because it rests on rhythm, the right moment to strike comes at its own pace. For both, the subtlety and skill come before the action, leaving them pure and as simple as any mechanic could be.

But their complexity lies in their combination. Like rice and broth, staples that become more flavorful when enjoyed together. When performed in sequence, suddenly the Jump has an offensive purpose and a target — it becomes dangerous! And the Kick expands beyond timing and gains an element of range, even into the vertical! Like two horses yoked together, they become much more powerful than the sum of their strengths. The precision required to balance a Jump Kick, and the richness it yields when well-tuned — for me it the apex of design expression.

Beautiful in every form

So find your ultimate mechanic and explore your design values. It’s important to be intentional about choosing your aesthetic, or you’ll wander into a pit. You’ll become a Turret Sequence Designer, placing spectacle over freedom. Or a Stamina Bar Designer, with no purpose beyond controlling the player. Or the despicable Time Sink Designer, wasting the player’s time and your own. Maybe it’s acceptable to use these mechanics out of desperation, but they are hardly something to be valued. We should all aim higher! Maybe try Jump Kicking!

Treating Iterationitis

Posted on June 15, 2011 by rewardingplay

Iteration is the key to good game design. Everyone knows this, not just designers. Artists, programmers, even the producers in charge of the schedule acknowledge that iteration is a necessary evil — a gullet of unknown appetite that must be sated. However, this abstract understanding breaks down almost immediately when faced with this inflexible reality: If our plan is to iterate on the design until the game is fun, it will not be fun when we begin, and will not be fun at any point in the iteration process until literally the moment before we are done. Successful designers have accepted this reality to some extent — they have to. But non-designers, deprived of both visibility into the iterative process and ultimate responsibility for how it turns out, have not been forced to come to terms with this uncomfortable truth, and so they get nervous.

It is in the designer’s best interest to minimize the impact of their own uncertainty on the rest of the development team. Some of them do this through bravado — how dare you question my ability to produce results?! Others present design as a black art, with arcane secrets known only to themselves — an illusion which a perceptive non-designer can dispel with a few well-considered questions. Many use this uncertainty as camouflage, avoiding direct conflict by constantly iterating without revealing their ultimate goals. The problem with all of these techniques is that they can be used not only to reduce the team’s discomfort with iteration, but to conceal a lack of design discipline or creative horsepower. It becomes impossible to discern the difference between a good designer protecting the team from the difficulties of iteration and a bad designer hoping to stall long enough to get lucky. What is required are methods to iterate quickly while minimizing the team-wide anxiety.

Not how iteration works

Continuity of Iteration

If a designer stops iterating on an element or system for more than a week, other team members will assume that they are done with it. They will evaluate it as if it was finished and assume that the designer is satisfied, even though it is clearly not fun. Left unchecked, this chain of assumptions will lead them to distrust the designer’s abilities and judgement. This happens almost entirely subconsciously, so communication to the contrary is rarely effective. The only real solution is to keep iterating, even when the correct next step is unclear. Just change something so that bystanders will postpone their evaluations. This also avoids the problem of inertia, where developers — even designers, sometimes — grow accustomed to an element’s broken state and no longer notice that it isn’t fun.

Tools and Systems for Iteration

Any non-designer that is an integral part of the iteration loop will be exposed to the chill of uncertainty on a daily basis. So the simplest way to reduce their unease is to make sure the tools for iterating don’t require their constant support. With the proper tools, a designer should be able to experiment entirely on their own, without external resources. If these tools are unavailable, it may require the designer to broaden their skill-set until they can hack together what they need. That’s why most experienced designers have a working knowledge of so many tools — 3D modeling software, source code editors, Photoshop, etc. — not because they can produce shippable content or code, but so they can try off-the-wall ideas without needing help from outside the design team.

Private... not on TV

Private Iteration

Another benefit of tools that designers can use on their own is that they allow for private experimentation. Sometimes the iteration process is random and goes through an enormous number of bad ideas before discovering a good one. Again, since most non-designers are not confronted by the constant, unmitigated stream of failures required by the iterative process, watching the ones responsible for the ultimate quality of the game appear to be blindingly incompetent for months on end can be… unsettling. It takes an emotional toll that can be avoided when a designer does most of their failing in private, witnessed only by other sympathetic designers.

Herald Milestones

Of course, chronically working in private has one major disadvantage — nobody sees your successes, either. Since a lack of perceptible progress can be as damaging to team morale as public regression, it is crucial to announce any concrete improvements as soon as they happen. No need to wait for an element to be complete, so long as a decision is reasonably certain and isn’t going to change immediately, let people know! “The speed of the tank has been decided!” “Jump is definitely going to be on the ‘A’ button!” Pointing out these small, but measurable, signs of certainty will give the team a sense that there is light at the end of the iteration tunnel.

We'll get there... eventually

Even permanent failures can result in more certainty. “We have given up on the hovercraft!” “We are no longer working on the Shadow Beast!” The objective is not to demonstrate the perfection of the design team, but to show an inexorable drive toward closure. The team must understand — not just intellectually but in their bones — that if the iteration process continues as it is, at some point in the future, the game will be done.

Design Sense – Perception

Posted on May 27, 2011 by rewardingplay

Rorschach Tests

Look at this picture. What do you see?

The answer is obviously Goro

Hermann Rorschach devised the technique of using random ink blots to probe the subconscious mind, based on the idea that patients would be prone to seeing images that were more important or relevant to their mental state. They would project their internal preoccupations onto the otherwise abstract shapes, revealing clues that could be deciphered by their psychiatrist.

The reason ink blot tests work is because humans are naturally adept at seeing images and patterns. Our brains are composed of an enormous collection of highly specialized neural circuits, custom-built for finding, storing and matching patterns. Parts of our brains are devoted to sensing contrasts, finding parallel lines, extrapolating three-dimensional depth, recognizing faces, anticipating motion — the list goes on and on. In fact, so much of our cognitive potential is tied up in neural pathways that are optimized for matching specific patterns, it is actually very difficult to avoid seeing them everywhere. In video game terms, you are almost all GPU with very little CPU. It is difficult for us to simply perceive information without our specialized capabilities biasing our interpretation of it.

Completely abstract shapes

This is great for surviving in the jungle, not so great for designing games. The problem is that we begin processing before we have all the information; we draw conclusions based on patterns that may not actually exist. Did that element dominate an encounter because of a fluke, or does it represent a trend? Is this feature a little out of tune, or does it hopelessly conflict with the rest of the game? It’s impossible to tell from a single example, but that doesn’t prevent us from making judgements based on one experience. And once we have a pattern in our head, Confirmation Bias kicks in and our brain optimizes further and starts rejecting data that doesn’t support our initial conclusion, making it even harder for us to be objective.

Confirmation Bias is especially potent for game designers, because we know what is supposed to happen. We wrote the paper design, we know how a mechanic was intended to constrain the gameplay, so we play our games as if the mechanics work properly — even when they don’t! We know the picture behind the ink blot, so we are incapable of seeing with unbiased eyes. Which is why we are so often shocked during playtests; what is obvious to us proves unintuitive and confusing without the pattern already in mind.

Unfiltered Perception

So train yourself to see the ink, not the pattern. Stubbornly stare until you don’t see an image, but only what is truly there. Then, when you play your game, divest yourself of preconceived notions of what the game ought to be and strive to experience the game as it truly is. This will allow you to see through the eyes of a new player.

Another method is to find Gestalt images, pictures that abruptly change meaning based on how you look at them, and practice switching between the competing interpretations. This will allow you to hold multiple explanations of the same game experience in your mind at the same time, so you can evaluate them all fairly.

Old woman, young woman, old woman, young woman...

It may sound ridiculous to spend time deconstructing smudges and turning old women into young women, but it will help reclaim some of those specialized circuits and increase your ability to process unfiltered reality. Which will make you a more effective game designer.

He's about to have an experience he won't forget!

Put to the Question

Posted on May 25, 2011 by rewardingplay

If you want to learn something, read about it. If you want to understand something, write about it. If you want to master something, teach it.

– Yogi Bhajan

Successful designers are those that have the discipline to edit their work. Generating gameplay ideas is exciting and easy; discerning those with potential and removing the rest takes resolve and vision. But you’ll never get where you are going if you walk down every road — you must cut!

Removing game elements is usually straightforward. They are almost always part of a collection of similar elements, so they can be compared on an apples-to-apples basis. They are often specific instances of a general system — the Assault Rifle is an instance of the Weapon system, the Goblin is an instance of the enemy AI systems — which means that most of the work that goes into them can be applied to other elements and isn’t wasted. An element is associated with a certain amount of work that must be scheduled for the models, textures, effects, sounds and animations, so it is easy to measure its impact on the overall scope. And finally, since an element is by definition discrete, it can usually be removed with virtually no impact on the rest of the game.

Some elements just don't fit in

“Is this mechanic going to be fun?” is a good question, but impossible to answer. Prototyping can help, but it still takes discernment to recognize the potential in a prototype. It also represents an investment of resources, which can bias the team toward keeping a prototyped mechanic that ought to be cut. “Can we implement this mechanic?” is also a good question, but “can” is not “should” and “implemented” is not “tuned”. “Has a mechanic appeared in another game?” is a useful question, but isn’t necessarily relevant to the current game. “Does everyone agree this mechanic is good?” is a seductive, but destructive, question; it replaces a designer’s instinct with general consensus and will lead to “downhill design” where the only possible solutions are the easiest ones. The single best question for determining the potential of a mechanic is “Can the player be taught to enjoy this mechanic?”

Not everything is teachable

Answered honestly, this question has far-reaching implications. If a player never uses a mechanic, it might as well not exist in the first place. If a player fails to realize that a mechanic exists, it is too subtle or the game is overly complicated. If a player refuses to learn a mechanic, it probably doesn’t fulfill a fundamental aspiration for them — they will never be interested. If a player is unable to learn a mechanic, it is probably unintuitive or it clashes with other aspects of the game. If the designer cannot distill a mechanic down to teach it, they likely don’t understand the mechanic themselves. If a mechanic can only be learned through explicit tutorial, it probably has an awkward or obscure control scheme. Any of these problems are fundamental enough to warrant removal.

On the other hand, if a mechanic can be taught effortlessly — or better yet, players discover it on their own — or if mere awareness that an experience is possible is enough to motivate them to learn how to access it, this is a sign that a mechanic is reaching them on a subconscious level. This kind of mechanic can be integrated into their thought process and lead to a fluid flow experience.

GDC 2010: Design in Detail XV

Posted on May 20, 2011 by rewardingplay

Without anyone getting kicked in the face…

You always need to listen when people don’t like something. You are too close to the game; You probably already fixed all the things you didn’t like, so you should value a fresh perspective. Keep in mind that you can always trust someone’s emotional reactions, they are always authentic and valuable, but never just blindly take their advice. The designer’s job is to separate emotional feedback from thoughtful suggestions and treat the appropriately.

Before you can interpret someone’s feedback, you need to understand the source. Feedback means “the game in my head is different” and often times your response to feedback should be to probe about what kind of game they are imagining. You don’t necessarily need to agree on the game you are making to benefit from their feedback; they probably represent some portion of your audience.

You see Development Bias a lot with the public when the development process is very open. Playtesters know the game isn’t finished, they know you expect them to provide constructive criticism, so they become a lot more sensitive and more likely to complain. Once the game is on the shelves, those small problems fade into the background and players rarely notice them.

You also need to understand the source of feedback; If you can categorize someone’s play style, it will help you understand how to react to their feedback. You can weight their comments appropriately.
Here are some examples:
(The names have been changed to protect the guilty)

I used to balance “Easy” by playing with my nose (true story) but Steve still couldn’t beat it. I miss that guy, he was incredibly useful for balancing.

Even more important than categorizing other players, you need to understand your own playstyle. For instance, I’m a “role-player”, so I tend to ignore small balance problems if the results are still dramatic. I have to recruit “pros” that are more sensitive to useless or underpowered elements.

Against Eschatological Design

Posted on May 9, 2011 by rewardingplay

The last few months of a game’s development is a magical time. Ideally, everything is coming together, the team is firing on all cylinders, and the experience is getting better by the hour. Bugs are getting fixed, the build is more stable and performs better, the art is looking polished, and playtest results begin to climb to their highest levels right as the game is locked down. The difference between those last precious moments of post-production, where everything is happening too fast to follow, and the months (often years) of glacially slow progress at the beginning of a project are so stark, they create the perception that a switch has been thrown, that the game has suddenly become fun. The designer’s new-found power to affect change, and the positive feedback from the rest of the team, leads to a feeling of vindication and exhilaration. Finally, all the hard work has paid off and the game has crossed the Fun Barrier.

It is tempting, after the flush of this experience, to look back on a game’s development as a power curve. To retroactively smooth out the experience so it fits a nice mathematical progression, making the outcome of a fun game inevitable from the start. To pretend as if the only unknown was if the game would cross the Fun Barrier before the project ran out of time or funding. To ensure success on the next project by figuring out how to increase the exponent on the power curve, to work harder and add features faster, to run more playtests and balance earlier, so the game has time to reach the steep end of its exponential curve.

Fun = (Iterations * Time) ^Talent ?

The problem is that fun doesn’t really work that way. A player experiences fun as a binary switch, either they are having fun at a given moment or they aren’t, like a square wave. There’s no such thing as almost fun; an experience doesn’t gradually go from 90% enjoyable to 100% fun in a continuous curve. A game gets better because it sustains a fun experience for longer stretches at a time, with less unfun gaps in between.

Fun = Fun * Polish ?

An experienced game designer is sensitive to very short, almost subliminal moments where a mechanic is actually fun. Even in an early prototype phase, they can detect these snippets and predict with confidence which mechanics have potential and which ones don’t. So, instead of finding ways to be more effective at polishing hopelessly dull gameplay, they can quickly abandon mechanics that never display those glimpses of greatness and focus exclusively on eliminating or minimizing the unfun gaps in those mechanics are already fun in spurts. This is why exceptional designers tend to produce simpler, more reliably enjoyable games with fewer mechanics that feel almost effortless to play. And why the vast majority of average games are released with an abundance of features, but subject players to hours of tedium or frustration as they labor to find fleeting moments of fun on their own.

GDC 2010: Design in Detail XI

Posted on April 25, 2011 by rewardingplay

So how do you recognize strength when you see it? How can you train yourself to appreciate strength?

The first way to develop a sense for strength is to change the balance constantly. People hate it because it resets their competence, but it will prevent them from optimizing their skills and their strategies. One theory about Beginner’s Luck is that when you first attempt a new skill your brain is very engaged and thinks the entire action through very carefully. On subsequent tries, your brian gets lazy and tries to take shortcuts, so you are more likely to be successful on your first try than on subsequent tries. Also, development is hard, and deadlines are approaching, so the temptation is to lock things down as soon as possible. Resist temptation and keep the balance changing until you find the true strength of the game elements.

As you strengthen an element, the other elements become relatively weaker. After a pass through the elements, you will find that the first one can no longer compete, and must be strengthened again. Keep doing this until all the elements feel powerful.

This guy is really good at Halo…

Pro-players often complain that “The guys making decisions suck at their own game” and it’s true! I’ll admit that I’m not very good at Halo. I’ll even claim that I’m not good on purpose! The problem is that the dopamine released for being a good player is the same as the chemical reward for being a good game designer. Since you can’t tell the difference, you may mistake the thrill of winning for the satisfaction of balancing the game. You should always feel like you are learning about your game, and if you start to feel like you have mastered it you need to change something so you aren’t good again.

You must acknowledge your own tendency to optimize and ignore problems once they have become familiar. Don’t work on the same element for too long, don’t become comfortable. If something feels so familiar you stop noticing it, change it.

At the same time, if something is right, if it is just perfect and you don’t want to lose it, you need to play it so much that it becomes part of you. I can still, after years and years, drive a new Warthog and tell you if it is tuned correctly or not. I’m known in the Animation Pit as “Three Frames” Griesemer, because if they added a single extra frame to a Halo melee attack I could tell immediately. You need to hone your sensitivity by playing with a finely tuned element over and over until it is ingrained in your muscle memory.

It’s a 7.5

Posted on March 23, 2011 by rewardingplay

Uncharted 2

I recently finished Uncharted 2. I thought the acting and the pacing were excellent. The story followed a well-worn arc, but had enough unexpected set pieces to keep it fresh. The combat was dramatically improved over the first game, but still didn’t come together enough to justify the amount of fighting required. The stealth segments swerved between fantastic and frustrating, often clashing with the combat and story elements. (We can’t shoot the museum guards, but we can throw them off a roof onto paving stones five stories below?) I loved the sections where I was working with another character to solve puzzles or fight through enemy territory, partially because I know how difficult it is to do useful AI allies.

Maybe "ally" is the wrong word

My main criticism of the game is that it is crushingly linear. There is only one path, straying from it usually ends in a fail screen, and I could rarely anticipate what was going to happen. I just followed the breadcrumbs and assumed the level designer knew what they were doing. On several occasions the game goes beyond leading the player by the nose and starts dragging them by the hair. If the story required a pistol with infinite ammo, or a checkpoint to skip me through a tough section, or a hint that told me how to solve a puzzle I hadn’t even seen yet, then gameplay took a backseat.

All in all, a new high-bar for storytelling in games and a fantastic experience. I give it a 7.5! (Which according to IGN means “there are some issues, maybe it lacks ambition or it is repetitive or has too many technical glitches, but I had fun playing it nonetheless and think you will too.”)

Jumper

I also played a game based on the 2008 movie where Anikin Skywalker learns to teleport and Mace Windu tries to kill him… or something. The control scheme is unique. Instead of traditional brawler controls, each of the four face buttons represents a cardinal direction and tapping it will teleport you to that side of the targeted enemy and execute a melee attack. By using alternating buttons, you can “jump” behind an enemy, kick him into the air, and then “jump” to where he will land and hit him again from the other side. The animations are stellar, especially when you start chaining combos and beating the hair-dye out of the chumps trying to capture you.

It's a Tasersword (tm)

They use the main character’s signature ability in lots of clever ways. You can use it to travel through walls and find secret rooms or solve puzzles. There’s a finishing move where you grab an enemy and teleport you both to some remote location like a mile above the Grand Canyon or the middle of Antarctica and leave them there to die. (Of course, this makes it ridiculous when they use the tired trope of locking you in a room until all the enemies are dead. Why can’t I just teleport through the door?) There are even some enemies that are protected from certain directions, requiring you to time your attacks from different directions or risk being blocked.

A mercifully short campaign featuring unusual and well-realized combat mechanics. I give it a 7.5!

The Game Designer Review Scale

Did I just say that some budget movie tie-in schlock is just as good as the highest rated game of 2009? What kind of rating system would result in giving them both a 7.5? What are you doing reviewing games anyway, isn’t this a game design blog?! The answer is simple. In the Game Designer Review Scale every game gets a 7.5. From the latest AAA masterpiece to the quirky indie game to the bug-ridden RPG epic. Because for the game designer the goal is not to compare or judge the games themselves, but to exercise and strengthen your conscious control of your own experience.

Your own games get a 6.5

At the beginning of a project, when you are prototyping a new game mechanic, you are not going to have a polished, tuned experience. It’s going to be noisy and buggy and awkward. You are going to need the ability to spot the glimpses of fun, no matter how obscured or faint, even if they only exist for a few seconds at a time. You need to lower your flow barrier, learn to ignore distractions and technical errors, to focus in on fun gameplay instantly before it slips away. You need to spontaneously create a polished form of the game through imagination and mental tricks like making your own sound effects and storylines. All so you can snatch up those seeds and grow them until everyone on the team can see them.

You can practice this form of autoregulation by playing a deeply flawed game as if it were a 7.5.

On the other hand, at the end of the production cycle, when the game is smooth and playing it has become effortless and comfortable, you are going to need to look at it with fresh, critical eyes. You need to raise your flow barrier and become oversensitive and harsh. Every tiny flaw needs to become a glaring blight that must be fixed. Every inconsistency or imbalance, no matter how trivial, needs to break you out of the experience. You need to be able to put yourself in the shoes of a new player and find every confusing control mapping or unclear mission objective.

And you can practice by playing a truly exceptional game and fixating on the problems until it’s just a 7.5. You aren’t flattening all games to the same level, you are changing yourself and controlling your experience to learn the most possible.

Definition: Habituation

Posted on February 11, 2011 by rewardingplay

Habituation

The gradual reduction in sensitivity to a repeated stimulus

I got my teeth professionally cleaned this morning. (One cavity, apparently I need to floss more.) Now I cannot stop running my tongue back and forth over the newly polished enamel. When I woke up today, my teeth were the farthest thing from my mind, unnoticeably insignificant. But now I am obsessively, subconsciously, exhaustively exploring every crevice and gap. This is a side-effect of a neural process called habituation. As a stimulus (like “I have teeth”) is repeated, the electrical and chemical impact of the experience physically decreases to the point where it drops out of conscious thought, and then subconscious awareness, and eventually it is not felt at all.

You can get used to anything

As a human, this is a very good thing. Imagine trying to have a conversation while consciously aware of the sound of your own heart pumping, the movement of your lungs breathing in and out, every blink interrupting your train of thought, unable to stop noticing the pressure of the chair into your back or ignore the ambient noise of other conversations. It would be impossible to function. Habituation allows you tune out the vast majority of unimportant details and focus on what is new and interesting, like how smooth your molars have become. It’s a miraculously efficient process that allows our embarrassingly under-powered brains to filter enormous amounts of sensory information.

As a player, habituation is what allows us to learn to play a game and subsequently master it. Our ability to predict future events based on current conditions is inseparably dependent on our habituation to past events. A chess master learns to ignore the thousands of poor, but still possible, potential moves and consider only the strategically significant ones. A skilled Halo player moves through a multiplayer map without thinking about it, using all of his attention to scan for his opponents. When Mario reaches the edge of a ledge, pressing the “A” button always makes him jump. If chess pieces could move randomly, or a Halo map suddenly had a dead-end instead of a corridor, or the “A” button threw a fireball, the player would be unable to play the game effectively.

Alternative ways to make chess more interesting

But as a game designer, habituation is your mortal enemy. A tireless, inexhaustible foe, mindlessly obviating the best efforts of your craft, which you can only hope to delay, but never defeat. Fun gameplay is an interactive experience, and habituation inevitably reduces every experience to meaningless static. To some extent, the purpose of every design trick and tactic is to disrupt habituation, to resensetize players to the fun experience and help them continue to enjoy the game. We are hacking our own mental hardware, making it less-efficient.

The truly nefarious nature of this enemy lies in how sneaks into the design process itself. Designers can learn to ignore glaring problems that would annoy or aggravate a new player. Or they can overlook logical loopholes that will wreck the game balance because they are familiar with how the game is “supposed” to be played. Or they might wrongly believe an element has been properly tuned because they are no longer sensitive to the effect it has on gameplay. Understanding and controlling habituation, both their player’s and their own, is a crucial design skill.

Writing a Paper Design II

Posted on February 7, 2011 by rewardingplay

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.

Writing a Paper Design

Posted on February 2, 2011 by rewardingplay

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.

Football or Battles of the Revolutionary War?

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.

Rewarding Play

by Jaime Griesemer

Category Archives: Design Sense