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.

Exaggerated Causality

Posted on January 31, 2011 by rewardingplay

This is one of my favorite screenshots of all time:

Elaborate by Dewski14

In one frame, this screenshot tells an epic tragedy worthy of Sophocles himself. Red Sniper, furious at Blue Man for stealing the attentions of his bride, Grenadina, confronts him in an alley behind the cathedral. After a heated exchange, the jilted lover fires a single shot at his rival, who ducks out of the way, and the hateful bullet ricochets into the heart of his beloved, who was hastening to tell them they were actually brothers, separated at birth. The story can be told because the causes and effects are so cearly linked; by exaggerating the causal relationships and drawing out their interactions, a confusing or seemingly random event can be transformed into a dramatic moment.

At a basic level, a game can be interactive only because it is a simulation, a systematic collection of cause and effect relationships. It doesn’t matter if the world being simulated is rigid shapes dropping into a well, a jungle teaming with Jurassic wildlife or a city populated with tiny citizens, it’s the cause and effect nature of a simulation that allows players to make predictions, develop skills and play the game. Some game simulations have explicit causal relationships. “If you pass “Go” then collect $200 from the bank.” Others try to approximate the real world, including the complex cause and effect events, with more or less success. Unfortunately, the connections between causes and effects that are obvious in the real world are often difficult to track in a game, making them unnecessarily hard to understand and master.

The "Where the %@$# Am I Getting Shot From?!" Effect

Linking Cause and Effect

The best way to increase the intelligibility of your simulation is to increase the strength of the link between cause and effect in the player’s mind.

Don’t Poke the Lizard Brain. The human brain is not like a computer; it doesn’t have a lot of computational horsepower that can be applied to arbitrary problems. What it does have are highly specialized neural circuits designed to perform a single task very efficiently. Just like your graphics card is specifically made to render 3d scenes, there are parts of your brain devoted to almost every function you need to operate in your daily life. There are circuits for determining the direction a sound is coming from, circuits for reading the emotions behind facial expressions, circuits that use shading to determine the shape of an object, circuits for predicting the path of a falling object, and countless other abilities we rarely notice we have. The problem is, these circuits are so finely tuned for reality that the slightest deviation in a game simulation disorients them, destroying the player’s suspension of disbelief.

So, if a grenade explosion sounds like it is coming from the wrong place, players won’t understand that the grenade is what killed them. If a character’s mouth doesn’t move right, instead of conveying the emotion of a scene they enter the uncanny valley. If the lighting on an object is incorrect, or the physics system doesn’t make it behave accurately, players will not be able to predict how it will move or how they should react. If players are constantly confused by what is happening and unable to describe the cause and effect relationships in a game, it is often because the simulation is off, even by a small amount, and must be tuned properly.

Create a Visual Connection. The connection between cause and effect can be reinforced with simple visual elements. If a blue-green gun fires a blue-green projectile that explodes with a blue-green explosion that leaves a blue-green decal and causes the player’s screen to flash blue-green, they will probably be able to connect the dots. Another technique is to conserve the momentum of the cause in the effect, so if the player is melee attacked by an enemy charging from the right, throwing their body to the left in the direction of the attack helps link them in the player’s mind. If a certain spell causes an enemy to become confused, use the same little stars on the spell icon that are circling the confused enemy’s head. If one character is using mind controlling powers on another, actually draw visible waves of telepathic force between them. If an ancient artifact slows down anyone standing within 20 feet of it, attach a visible effect that extends 20 feet to indicate the range.

Avoid False Causes. It is also important to avoid creating false connections in the player’s mind between unrelated events. Entire lobes of your brain are devoted to finding patterns, and sometimes the unfamiliar experience of playing a game puts them into overdrive and your mind doesn’t just recognize patterns, it invents them. “I swear, every time I hear the sound of the timpani in the background music, I take damage. I must find a way destroy the percussion section!” Often these coincidental connections are difficult to predict, but they can be avoided by removing superfluous sounds, effects or actions that are not related to any game mechanic. Fires or explosions that are purely for dramatic effect, but can’t actually hurt the player. Enemy animations that look significant, but are actually just random variations on a walk cycle. Environmental features that stand out, like switches or doors, but are merely cosmetic. All of these are prime candidates for false causes.

Temporal Separation. One of the most effective ways to help players connect a cause to an effect is by slowing it down. If a grenade causes a vehicle to explode, delay the second explosion by a fraction of a second. If flipping a switch causes a gate to open, slow it down so the gate takes several seconds to open completely. If a headshot does more damage to an enemy, exaggerate and elongate their reaction so it is clear that something unusual is happening. These delays and exaggerations help the player perceive the two events as separate and sequential steps in a process. When two events are simultaneous, it is difficult to tell which one is the cause and which the effect, or even if they are related at all. But a repeated sequence of events is easily recognized and understood.

Call of Duty's Kill Cam delays and replays the cause of your death

Add Intermediate Steps. If I punch my younger brother and all the sudden I can’t sit down without wincing, I am unlikely to connect the two events. However, if punch my younger brother, and then my Mom yells at me, and then I have to wait for my Dad to come home, and then I have to go get the leather belt from his closet, and then bring it back and “assume the position” I will probably learn the cause and effect connection. At least after the first few dozen times. Sometimes, the easiest way to make a connection more noticeable is by adding intermediate steps to the sequence. Two events happening in the same order might just be random coincidence. Five events happening the same way every time is probably not.

Exaggerating causal connections not only helps players learn how to play a game, but it increases the dramatic context of their actions. It will allow them to construct stories instead of just experiencing a series of events. And it will make the game more appealing to people that are just watching a video on YouTube, drawing in new players.

Balance Pass: Role

Posted on January 28, 2011 by rewardingplay

One of the most important reasons to balance in passes is a practical one. The earlier an element is cut from the game, the more resources are available to the remaining elements. A good designer will always have many more ideas than they could implement, and it is tempting to push all of the ideas forward until the schedule demands cuts, but it is almost always better to trim early and avoid wasted effort. That is the primary goal of the Role balance pass.

Please pass the roles

Timing

Post Pre-Production. This is the first balance pass, and it happens immediately after pre-production. During pre-production, design should focus entirely on generating ideas and prototyping systems that are not fully understood. Prematurely worrying about schedule or scope can strain the creative process, preventing the design team from cycling through the bad ideas that eventually lead to good ones. There are many schedule pressures to keep this brainstorming stage short, but the costs of entering production without completing this process are often much greater. Changes made in pre-production are much cheaper than the ones that happen after resources have been committed to a bad idea.

A Paper Design for Every Element. The designer’s primary responsibility in pre-production is to make sure that every single game element has a paper design. It is far too easy for a designer to be vague and only fuzzily understand how a given element will work. Taking the time to think through and write out a paper design takes discipline, but will allow the designer and the rest of the team to proceed with more confidence, and minimize expensive surprises.

Defining a Role. The most important part the paper design is a description of the role that the element will play in the game. Without a clear idea of what an element is for, no amount of detail will be sufficient to describe it. On the other hand, sometimes a role so completely defines an element, that no more information is needed. Roles can be simple: “A long-range instant-kill sniper rifle.” Or more nuanced: “An enemy character that serves as the backbone of an encounter, uses every available weapon and vehicle, and provides a foil for the player to overcome.” But they should always be singular and establish a bar for what is required for the final in-game asset.

Methods

Even though they do not exist in the game, and cannot be played yet, once each game element has a paper design and a role they can begin to be balanced.

Remove Overlap. The most useful way to balance game elements at this stage is to make sure they are not filling the same roles. Two elements that have the same role are a waste of resources. Either they will be identical except for cosmetic differences, in which case they will confuse players by offering a choice with no meaningful difference. Or one will strictly dominate the other and be better in every situation, making the weaker one redundant. Or you will be forced to spend valuable time differentiating and balancing them, without actually increasing the player’s options.

Often, when elements have the same role, they can be merged into a single, stronger idea. Other times elements may appear to have the same role, but further exploration will show that they are indeed different, which provides a deeper understanding of how they will function in the game. Regardless, by the end of this balancing pass, every element should have a unique role.

Don’t Overlook Roles. Often the brainstorming process is very chaotic and undirected. We never know when a good idea will occur to us! It is easy to overlook common roles or miss very niche ones. This balance pass is a good opportunity to take stock of all of the game elements and look for any holes. For example, if the player will be fighting against snipers, but has no long-range weapon in his arsenal, he will feel like he is unfairly limited, that part of the game is missing.

The importance of filling every necessary role is precisely why the weapon selection for most shooters ends up virtually identical. Most shooters require an accurate long-range weapon, a powerful short-range weapon, a weapon that is good against multiple opponents, etc. So most shooters end up with a sniper rifle, a shotgun, an smg, etc. Players may complain about the lack of originality, but not as much as they would complain about the lack of a shotgun!

Limit the Number of Roles. The final step to this balance pass is to get a feel for the scope of the game and the overall number of elements that will be required. Determine what the absolute minimum number of elements are absolutely necessary to make a functional game. (Note: Never tell Production this number!) If the total is more than 20-30% over the minimum amount, there are probably too many elements. It is a good idea to have a buffer, in case certain elements don’t work or are harder than anticipated. But the fewer elements that make it through this pass, the more polished the remaining elements will be, the easier it will be for players to understand and use them all, and the tighter the gameplay will be.

Balance the Rolls?

Results

Confidence. As a result of this balance pass, the entire team will feel more confident in the scope of the game and the quality of the design. A disciplined design is less likely to have to be changed, wasting the time and effort of the artists and programmers. It will also make the rest of the team less resistant to changes that do need to be made, because they will know the designers took every precaution to avoid them.

Depth. Balancing the roles requires a sophisticated understanding of what each game element is for and how they will interact in the final game. By reaching that understanding early, every subsequent decision will be able to support that role, deepening it and creating complex connections between elements. The art, sound, effects and other aspects can reenforce this role, making it crystal clear to the player.

Manageability and Flexibility. When overlapping or unimportant roles are removed, the following balancing passes become much easier. Not only will there be fewer elements to balance, but they will not come into conflict as often because they will have distinct uses. Also, a disciplined balance pass will leave some room in the schedule for the great ideas that inevitably come up later in the project.

Case Study: Tribes

Posted on January 26, 2011 by rewardingplay

Previously, we have explored how the community balances a game, sometimes despite the developer’s best intentions. Tribes is a great example of how the community not only determines how the game is ultimately played, but often decides the path of future development.

Tribes shipped in 1998 to a fair amount of critical and commercial success. It featured large multiplayer battles on open terrain that were beyond anything that had been seen before. Players could choose between three armor classes (Heavy, Medium and Light), pilot vehicles, plant bases, purchase weapons and equipment… it even had jetpacks! It also had one very significant bug, an unintended side-effect of the physics system known as “skiing”.

Go Zebra Tribe!

By tapping the jump button while descending a hill, players could exploit this physics bug to accelerate to an incredible speed. Combining this technique with the jetpack would allow players to quickly cross even the largest maps, much faster than the designers anticipated. This worked even with heavy armor, meaning there was little incentive to choose the lighter, more agile classes. It was faster than vehicles, making them redundant. Since most of the weapons did not have instant travel projectiles, it became almost impossible to hit anyone outdoors. Nearly every aspect of the gameplay was affected.

In a short time, the game balance was totally wrecked… and the players loved it! They invented new strategies, found new ways of attacking bases, used old weapons in new ways. They became experts in using another physics bug called “body blocking” to physically bar enemies from escaping with their flag. The chaingun, a weapon that had been scorned, became their weapon of choice because it fired one of the few projectiles fast enough to hit a skiing player. They re-balanced the game around this new game mechanic.

The Tribe has spoken.

The developers attempted to fix the game with a patch, but the community rejected it. By that point, everyone who did not like the effect of skiing had already left the community. The remaining players where those that thought it was fun. Unfortunately, this smaller community was the only audience for a sequel, so the development team were forced to cater to them. Tribes 2 not only included an “official” version of skiing, but even explicitly taught new players how to do it!

Takeaways:

Don’t just test for bugs, but to ensure the gameplay experience is the one the designers intended.
The ultimate balance of a game lies in the hands of the community that plays it.
Fun activities are rare, and when we find one (even as the result of a bug) we ought to embrace it.

Inter-Activities?

Posted on January 24, 2011 by rewardingplay

I’m excited about the following post, not because it is especially insightful, but because it features this blog’s first interactive example! Games are so dependent on interactivy, it’s virtually impossible to explain certain key concepts without some kind of playable demonstration. Sometimes I need to make my point about game design with a game! To that end, I’m teaching myself Actionscript so I can make my own little illustrative experiences. I probably won’t have time to create too many of these, but this one was a lot of fun to make, and I hope you like it. (I’m still trying to come up with a good portmanteau… Game-onstrations? Exam-plays?)

I also registered a new domain, so now you can find this blog at www.thetipofthesphere.com. (Some PR firm is squatting on the article-less version.) Old links will still work, but this url is more memory friendly.

Definition: Game Mechanics

Posted on January 24, 2011 by rewardingplay

Game Mechanic

A single constraint on the possible gameplay actions that determine a part of the player’s experience.

According to our working definition of gameplay, the purpose of a game mechanic is to constrain a game’s interactivity so that it guides the player toward a fun experience. Tuning these contraints is one of the most important game design processes. However, in order to tune game mechanics, it is necessary to understand what mechanics are and how they combine to form gameplay.

First, let’s look at how a single game mechanic constrains the possible actions a player can take. Often these constraints are explicit rules like “If the King is put in check and cannot legally escape, the king is checkmated and the game ends in a loss for that player.” Sometimes they are limits enforced by the simulation; there are some gaps that Mario can only jump while running. The most important constraints are usually determined by the game’s control scheme. After all, the player can only perform actions which are mapped to available inputs.

Another common type of constraint is the player’s objective in the game. For instance, a goal in Pac-Man is to eat all the dots. This limits the player’s behavior because any interaction that does not involve eating dots is irrelevant to the game. This mechanic divides all the entire spectrum of possible actions the player can take into two halves, actions that are permited and those that are prohibited.

Pac-Man suffers from OCD

Game mechanics guide the player experience by removing some alternatives and emphasizing others, but by itself, a single game mechanic is not a game and cannot lead to a fun experience. In fact, a single game mechanic by itself is barely even interactive. With only one constraint, there is only one option. There is no room for choice or skill or expression. To demonstrate this point, I built a “game” based on a single dot-eating game mechanic.

(My free Flash host can no longer keep up with demand, please click this link to load the example.)

In order to actually define an experience, game mechanics must be placed in opposition to one another, much like the legs of a tripod. That way instead of creating a single boundary (and therefore no choices) they create a region of interactivity for the player to operate within. This is what Will Wright calls a possibility space. It is the sum of all the potential gameplay experiences, sort of the wave function of game design.

Triangle Man hates Pac-Man, they have a fight, Triangle wins

Or maybe the Triforce of Game Design?

Definition: Game

Posted on January 21, 2011 by rewardingplay

Game

An interactive experience constrained by mechanics designed to reliably satisfy a common teleological aspiration.

Merriam-Webster says a game is “an activity engaged in for diversion or amusement” which is hopelessly broad. Try pitching “Punching My Younger Brother: The Game” the next time you meet with a publisher.

Raph Koster claims that “fun is just another word for learning” and that therefore “all games are edutainment.” This is insightful because it attempts to define games by describing the needs they meet, but is obviously too narrow. Someone that is leveling their fifth World of Warcraft alt is not learning anything, but I dare you to try to tell them they aren’t having fun. And shouldn’t the tutorial be the most enjoyable part of a game? This definition commits a logical error called the fallacy of the undistributed middle. Even if learning is fun, that doesn’t mean that everything fun must be learning.

In Rules of Play, Katie Salen and Eric Zimmerman define games as “a system in which players engage in artificial conflict, defined by rules, that result in a quantifiable outcome.” Now, it would be unfair to quibble with specific word choices or come up with obscure examples of games that don’t fit this definition. No definition is perfect. The real difficulty of this definition, as well as many other similar efforts, is that in dissecting games into pieces they have lost the whole. It is as if, when asked to define the word weapon, you started listing types of wounds and metallurgy techniques and sources of propulsion and got bogged down trying to figure out if a baseball bat was a weapon or not. The best way to define weapons is to describe their purpose, committing or threatening violence against someone, and the same is true for games.

Ludwig Wittgenstein famously declared that there is no adequate definition for the word game and we don’t even need one! But he was not known for being a particularly fun guy, so maybe we can do better.

We’ll start with our previous definition of fun: “the positive emotion associated with fulfilling a teleological aspiration.” The first definition of game that suggests itself is “something that is fun,” or more specifically, “an experience that fulfills a teleological aspiration.” However, there are so many ways to satisfy our needs; what makes games special? Unlike many enjoyable activities, the only purpose of a game is to have fun, and since they have a singular focus, they are able to satisfy these aspirations very reliably.

Additionally, teleological needs like learning or achieving or performing cannot be satisfied passively or by proxy. They require participation, so they must be interactive and respond to the player’s actions. This interactivity is not random; it reliably leads to fun experiences because it is limited to specific set of possibilities and actions. Some games are indeed guided by explicit rules, but many games are constrained by their simulation, or by the objectives given to the player, or even by the story setting in which the game takes place. In many games the experience is actually constrained by the unpredictable actions of other players. Ultimately, it doesn’t matter what form these game mechanics take, as long as they constrain the experience in such a way as to more reliably fulfill the player’s needs.

Finally, our definition should acknowledge the fact that in order to ensure that a game’s mechanics lead to an experience that satisfies the player’s needs, they must be carefully designed to do so by a game designer. Games do not appear naturally in nature.

So, now we not only have a useful definition for the term game, we have also determined the role of the game designer and have a reasonable criteria for evaluating design skill. A game designer is someone that creates and tunes game mechanics to constrain an interactive experience such that it reliably fulfills common teleological aspirations, and the more reliably these needs are met, the more skillful the game designer.

Definition: Fun

Posted on January 19, 2011 by rewardingplay

If you are not a game designer:

Fun

(see also: Enjoyable, Cool, I Like It)

Something that I think is cool;

something that I imagine other people would think is cool, if a designer would just listen to my idea

If you are a game designer:

Fun

(see also: Blah Blah, Nice)

A completely meaningless term that should never be used;

except when describing the job responsibilities of a game designer to someone over 40

If you are a game designer writing about game design:

Fun

The positive emotion associated with fulfilling a common teleological aspiration

(I realize this definition may itself need some explanation.)

Human Needs

One way of understanding human behavior is to look at our needs. If you assume that people are basically reasonable and that they are motivated to act in a way that fulfills their needs, then you can categorize different behavior based on the need that it satisfies. The most well-known example of this technique is Maslow’s Hierarchy of Needs. It’s like the Food Pyramid of human desires. Unfortunately, neither the Hierarchy or the Pyramid are based on solid scientific research, so they tend to be misleading.

A more rigorous categorization of needs has been put forth by Edward Deci and Richard Ryan at the University of Rochester. They have researched people’s need for self-determination, specifically their needs for competence, autonomy and relatedness. They have even applied this theory to games with fascinating and practical results. (If you are interested in this topic or their research, I recommend reading Why We Do What We Do: Understanding Self-Motivation.)

When our needs are being met, we describe the resulting emotion with a variety of terms. Satisfying, Fulfilling, Relieving, Gratifying, Pleasurable, and Fun. Each of these emotions is specific to the type of need that is being met, so if we can determine which kinds of needs result in fun we will be closer to defining the word, and have a greater understanding of our goal as designers.

The Need for Fun?

An immediate objection springs to mind against linking fun to needs. Despite what you told your mom when you were a kid, you can’t die from fun deprivation. How can fun be related to needs if you don’t actually have to have it to survive? Well, psychology doesn’t make a distinction between needs and wants, in fact a better term might be desires or appetites. However, this does bring up an important distinction that will help narrow down what sorts of needs result in fun when they are satisfied.

Some needs produce a negative emotion when we lack them, but are virtually forgotten once met. These needs are requirements. Carbohydrates, for example, are a requirement. If you don’t have any, you will experience wracking hunger pangs, but if you have a sufficient supply you no longer think about them. Other needs are just the opposite. When these aspirational needs are not met, they rarely bring themselves to mind, but when they are fulfilled we experience a strong positive reaction. Pancakes, for instance, are an aspirational need. Nobody suffers greatly when pancakes are not available, but everyone enjoys them if given the opportunity.

Indisputable Proof

Having made this distinction, it’s clear that fun is the result of satisfying an aspirational need. Much like pancakes, fun experiences are not required for survival, but we still enjoy them when they are offered. However, this category is still too broad. Pancakes are delicious, but not necessarily fun.

Sorry Pancakes. We still love you.

The Need for Greek?

One characteristic that is unique to fun experiences is that they require participation. Many needs can be met by an external source, the way a mother provides for the needs of a baby. These kinds of needs are often physical objects: food, water, a place to live, a large screen TV. But they can even be psychological needs like the desire to have the respect of one’s peers, or the need to know how something works. These needs are ontological needs, meaning they are ends in and of themselves, they exist for the person.

Needs that result in fun are very different. One person cannot play or learn or rest for another person; they must do it for themselves. These teleological needs are met when we allow ourselves to be the means for some purpose beyond ourselves. That purpose may or may not be useful; work can be as fun as play, even though it also provides for many other needs. They key component is participation.

Every individual values needs differently, but with both of these axis we can arrange all needs into four quadrants:

Incontrovertible Evidence

The Need for a Conclusion

Now we have a sufficiently narrow range of needs that result in fun, specifically those in the upper-right quadrant. These needs are aspirations because we get a positive emotion when they are met, but do not necessarily suffer when they aren’t, and they are teleological because they allow us achieve some potential end and require our participation.

It remains to be seen if this will prove itself to be a useful definition, but at least it is more specific than “I know it when I see it.”

Fun and Games and Hardcore Pornography

Posted on January 17, 2011 by rewardingplay

In 1964, the Supreme Court of Ohio ruled that a certain French film called Les Amants wasn’t just risqué, it was obscene, and banned it from being shown in the state. They were reversed by the Supreme Court in Jacobellis vs Ohio, which is known not just because it restrained the ability of government to censor artists, but because of the reasoning used by Justice Potter Stewart in the case. He argued that the Constitution protected all forms of expression except hardcore pornography, writing:

“I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.”

This arbitrary and vague definition held for almost ten years until it was replaced with the “community standards” criteria that are used today. During that time it was notoriously useless as a law enforcement tool. Police and prosecutors could not use this subjective standard to determine which material to ban and which to allow. They were constantly having to wake up Justice Stewart in the middle of the night, show him some dirty pictures and get a verdict.

Obscenity or Obelisk?

Unfortunately, most designers have a similar working definition of important concepts like fun or gameplay or balance or immersion. How can you be a game designer if you don’t even have an intelligible description of what a game is? “I know one when I see it” isn’t good enough if your career depends on your ability to create experiences nobody has ever seen before.

Definitions are difficult because they often prove inadequate when you try to actually use them. This is especially true in game design because it is such a young industry. It is rife with definitions that sound good, but are flawed for a variety of reasons:

Resorting to merely supplying synonyms. You can’t define fun as “an enjoyable activity” or “the entertainment value of an event.” Those are just thesaurus entries.
Simply describing the characteristics or effects. If you define a game as “something people play” or “a contest with rules” you haven’t provided any insight into its essential nature, you are just dissecting it’s parts. It’s like defining a human as “some bones and organs inside a thin layer of skin.”
Defining too broadly. A vague definition will include too many confusing counter-examples, so any decisions based on it will be similarly fuzzy and subject to error. (“I know it when I see it” is an example of this.)
Defining too narrowly. Often a designer will have a single insight about a concept, and elevate that one aspect to the level of a definition. This narrowness creates a blind spot that will conceal possible innovations that fall outside of those artificial limits.

In order to be useful, a definition must provide enough insight and specificity to help make practical decisions regarding the term being defined. When people agree on a definition, they should not only be able to use it to communicate accurately, it should in some way guide their thinking and establish a standard against which they can judge their work. Given a sufficient definition of the ideal game, a designer should be able to objectively evaluate their game, and then improve it.

Balancing in Passes

Posted on January 14, 2011 by rewardingplay

As with any creative endeavor, balancing a game is a difficult process to predict, and even more difficult to schedule. To alleviate some of the pressure, game designers invented a circular excuse known as The Balancer’s Paradox:

Balance cannot happen until the end. Every game element and knob impacts the balance, so until they are all present and functional the game cannot be balanced (and it won’t be fun.)
Balance cannot wait until the end. Until the game is balanced it is not clear what elements are actually necessary or what knobs will be needed to balance them, so a complete list cannot be finished until the game is balanced.

This is very effective at eluding production demands, but unfortunately to ship the game the designer must actually find a way around this quandry. The best solution is to balance in passes. At several points during development, attempt to balance the elements that exist, using the knobs that are available. The resulting balance will not have much longevity, but it should give you enough information to prioritize the remaining elements and knobs.

There are several crucial points at which a designer should stop and do a balance pass:

Pass	Stage of Development	Goal
Role	The paper designs for all the game elements are finished	A manageable number of roles with no overlap
Flow	The elements can be tried in the game	Elements allow the player to achieve flow
Strengths	The game rules work well enough that elements can be tested against each other	Elements that are strong enough to be useful
Limits	Playtesters begin to abuse elements by using them outside their role	Limit every element to its intended purpose
Exceptions	The balance is stable enough for small exceptions to appear	Eliminate bugs, unexpected uses and local imbalances
Perceptions	The balance is polished, but the assets are not yet final	Support the balance with matching effects, sounds, animations, etc.

Welcome to the Soft Launch

Posted on January 13, 2011 by rewardingplay

I’ve managed to post three times a week for two weeks; I’ve even got a couple posts in the queue. I have a rough outline of future topics, blog software I like and a site design I don’t hate. I’ve already rocketed to the the top of Google’s search results* so I guess it’s time to find some readers!

This site is an experiment to see if I can write a book on game design one page at a time. The overall structure is still evolving, but I plan to continually reorganize anyway, so for now I’m focused on learning to write ~~good~~ well. I’m struggling with the tone and style of my prose, as well as the detail and depth of the content, so I’d appreciate any feedback at “spheretip at gmail dot com”. If you just want to tell me my design ideas suck, you can do that in the comments.

*if you search for “Jaime Griesemer’s definition of tuned“

Update: Well, hello twitter. You found this site a little earlier than I expected and blew out my traffic numbers. I appreciate the links and the… constructive feedback. It’s been a long time since I have written anything for public consumption and I’m pretty rusty. Just pretend this is an ARG for the next Michael Bay movie or something. And leave some comments!

Definition: Tuned

Posted on January 12, 2011 by rewardingplay

Tuned (See also: Polished, Tweaked)

A game mechanic can be considered tuned when it correctly constrains the player experience to have the desired effect

The opening four bars of “Smoke on the Water” by Deep Purple are perhaps the best example of the power chord. Nothing screams sex, drugs and rock & roll like these iconic sounds.

Smoke on the Water

But if you play them even a tiny bit incorrectly, you’ll have a discordant mess. Instead of the desired effect (impressing all the girls at the party) you will achieve the exact opposite. In the same way, game mechanics must be precisely tuned to insure they work together to produce the desired experience and prevent undesired ones.

A Fire in the Sky

Unlike balance, which must be considered across the entire community for the life of the game, a game that is tuned for one individual is probably tuned for most players. That is because the tuning process constrains the entire possibility space, not a specific experience. As it eliminates poor experiences and emphasizes or rewards the desired ones, the differences between player skill levels and choices are automatically included.

Tripping over the Starting Line

Standard | Posted on January 10, 2011 by rewardingplay

Running is risky. Your center of mass is so far in front of your feet that you are constantly falling forward, catching yourself with each stride. You appear to be in control and stable, but in reality you are always one misstep away from catastrophic failure. (Thoughts like this are why game designers are rarely world-class sprinters.)

Ready!

During development, a game can appear to be balanced, but is actually just being carried along by momentum; the instability is masked by constant change. Releasing the game at this point is like tying a runner’s shoelaces together.

Set!

When the designers cede control to the community, they quickly find the truly balanced state. Unfortunately this often results in a degenerate or random experience where entire gameplay modes are untouched, fundamental mechanics no longer have an impact, and usually the game becomes too simplified to remain interesting. Even worse, developers are often forced to incorporate the broken mechanic into a sequel or risk alienating their fan community.

Trip!

How does this happen? Often it is a result of a flaw in the development process.

Unenforced Conventions

Early in development, when the game is being prototyped, it seems inefficient to rigorously encode the game mechanics. It is easier to just ask playtesters to refrain from using certain tactics, ignore logical loopholes, and pretend the game works in a different way than it actually does. After all, the playtesters are usually on the development team, and the prototype changes faster than the code can be updated.

The problem comes when these conventions become so firmly established that the designers start making assumptions about what the community will do based on those (false) expectations. When the game is released, the community does not respect conventions, they will exploit any tactic or loophole the game allows, ultimately breaking the balance.

Isolated Game Systems

A common production tool is to organize features into prioritized lists, with the understanding that everything below a certain line has a chance of being cut. This encourages designers to create isolated game mechanics, parallel systems that do not interact with one another, so that the inevitable cuts have less impact on the surviving mechanics. These layers are frequently worked on by different designers with different goals and ideas about what the game should be.

This leads to the situation where game systems are individually balanced, but in differing, or even conflicting ways. The progression mechanics that keeps player invested in the community might break the competitive multiplayer game. Or large sections of an environment may go unused because of the way the mission objectives are placed. Usually, the most poorly balanced aspects of the game drag down the other systems, leveling any interesting nuance they might have had.

Ignoring the Skill Zenith

Designers are rarely as good at the games they develop as the people that play them. (They tend to spend more time building them than mastering them.) It is often their ability to sympathize with the “average” player that makes them good at their jobs. Unfortunately, this means that they have a blind spot and cannot always predict how the game will be played at the very highest level of skill.

Nothing wrecks game balance as fast as a community that is more skillful than the developers anticipated. Actions that were meant to be impossible or happen only through luck become fundamental to the game. The community is split between those that can execute the “impossible” tactic and those that cannot, and are no longer competitive.

No game ships with flawless balance, but by avoiding these pitfalls your game community may last long enough for you to tweak it.

Balance by Attrition

Posted on January 7, 2011 by rewardingplay

In classical physics, Newton’s Second Law of Thermodynamics states that over time, differences in temperature, pressure, and energy even out across an isolated physical system. If you leave a fresh cup of coffee on your desk in the morning, by the afternoon the coffee will be much colder and the room will be slightly warmer, leaving them both at the same temperature. (Most game designers aren’t physicists, so we are constantly surprised by mouthfuls of disgusting lukewarm dreck.)

A similar law holds for multiplayer games. Immediately after release they are in a very energetic state as the community tries every game mode, tests every tactic, exhausts every possibility. (Like a human Monte Carlo simulation.) Gradually the community activity slows down. Certain gametypes become ghost towns. Entire classes, tech trees and strategic choices are dismissed. Carefully crafted game mechanics are ignored. Map rotations shrink to a few prefered maps.

Or maybe just one

Ultimately every game is balanced by the community through this pruning process. Ideally the surviving experience is close to what the developer intended, but they will not stop until they reach one of the following stable states:

1. There is no game left.

Unfortunately, once the players remove the broken game mechanics, unfinished features, buggy networking and superfluous options from some games, there is nothing to play anymore.

Potential Community: The immediate families of the dev team and game reviewers looking for easy targets.

2. The game outcome is random.

Many games have random factors with enough impact that they determine the course of a match. (The first player always wins Tic-Tac-Toe.) Other games do not allow players to adapt or execute more skillfully, so the winner is determined by the game’s initial conditions. (All the strategies in Rock-Paper-Scissors have the same chance of winning.) Some games have an inherent imbalance that cannot be overcome, so your chance of winning is determined by who you are playing against. (Games with a severe host advantage favor players with good connections.) No matter what the cause, these games are essentially decided by dice rolls.

Potential Community: New or non-competitive players who want an equal chance of winning.

3.The game is determined only by skill.

If the players discover a single dominant strategy, or if a superior strategic choice can be overcome by faster reflexes or more skillful execution, the game will be simplified to a straightforward contest of skill. (The only strategy in the 100 yard dash is “run faster.”) Any subtle game mechanics will be ignored and the experience will become extremely predictable, allowing players to focus entirely on improving their execution.

Potential Community: “Pro” gamers who want to remove every consideration except execution skill, especially random factors.

4. The game has irreducible strategic complexity.

If there are enough choices, mechanics and contexts that nobody can completely predict them all, players must make decisions on incomplete information. This allows for mistakes and adaptations as the game plays out, and the winner is often the player that changes their strategy to fit changing circumstances.

Potential Community: Gamers that want to invest a lot of time learning a complex game and do not want it to become predictable.

If you can anticipate the eventual balance the community will reach, you can design more intentionally, avoiding features or mechanics that will be removed, and ensure that the experience is tuned properly from the beginning.

Rewarding Play

by Jaime Griesemer