Theory and Principles of Game Design

Narrative and Consequences

2010-10-15T12:00:00.007-04:00

The holy grail of narrative game design is a game with a carefully constructed narrative that players can influence to the same degree as their real lives. The goal is to have stories that are every bit as engaging as traditional narratives but created in such a way as to enable a rich variety of player experiences.

For games in which content is written primarily by human beings, creating such flexible narratives is almost certainly impossible given the number of potential choices for the player -- far too many for any author to account for. On the other hand, for games in which content might be generated dynamically with the aid of computer algorithms, current Artificial Intelligence approaches aren't advanced enough to produce engaging narratives.

A less ambitious goal, therefore, is to make games in which players' decisions are limited but significant: limited because the possible choices and outcomes are only a small subset of those that would otherwise be available, and significant because the players' choices make sense to them and have a perceptible effect upon each game's environment. Even so, merging together narrative and gameplay is difficult to accomplish successfully.

Players should be offered meaningful choices

"Is doing X a better choice than doing Y? Why?"

For players to make effective decisions they need more information than games of this type typically provide. A game's narrative should be crafted in such a way that players can, in most cases, make informed decisions. This doesn't mean that optimal choices should be obvious or require no work to ascertain, but that players should be given the chance to foresee, to a reasonable degree, the possible consequences of their actions. Always provide enough information for players to have some idea of what the outcomes of their actions might be.

Players shouldn't be afraid to make decisions

"What if I make the wrong decision? Can I try again or am I stuck with it forever?"

Players may fear the possible consequences of their actions, leading to what some people call "analysis paralysis". It may be that players lack sufficient information as to the possible outcomes of their choices, or it may be the game is designed in such a way that players expect the consequences of their actions to follow them for the rest of the game. Players should have enough confidence in the game's design to know their experiences will not be ruined by making the "wrong" choices. Avoid long-term negative consequences and allow players to recover from undesirable outcomes.

Players shouldn't feel like they're missing out

"What would've happened if I'd done Y instead of X? What if the alternate ending was better?"

Having multiple paths for players to follow means players don't get to see all of your story. While this conceivably adds to the game's replay value, there are players who would rather not play through the entire game a second time just to see the parts they missed. Alternate endings are often little more than a gimmick, a testament to the narrow set of choices offered to players. Consider whether paths not chosen really add to the player experience and keep in mind that a narrow set of choices does not truly afford a sense of freedom.

Avoid the illusion of choice

Damned if you do, damned if you don't.

It may be tempting to have a large number of alternatives for players to choose from, but if all the alternatives lead to the same outcome then all you're doing is providing the illusion of choice. As already stated, providing significant choices means that players' choices actually make a difference in the game. Avoid offering choices that don't make any difference.

Narrative puzzles

In light of the fact that players' choices are severely limited compared to real life, avoid shallow, falsely personalized narratives in the style of "Choose Your Own Adventure" stories and instead make your narrative elements integral parts of your games' puzzles -- into parts of the games' mechanics. Just like some games call for the manipulation of objects in solving puzzles, games with narrative puzzles call for the manipulation of dialogue and story elements in pursuit of each puzzle's solution. This avoids the problem of complicated branching while still providing meaningful choices in the context of each game's narrative.

Controlling Aspect Ratio in Unity

2010-09-28T19:46:00.106-04:00

Games made with Unity allow users to pick a screen resolution on startup through Unity's Display Resolution Dialog. While it's possible to disable this feature and force a game to use a particular resolution, it's generally not a good idea to deny users the ability to set the game's resolution to whatever they think is best. Such flexibility comes at a price, however, and one of the costs is the loss of control over the game window's aspect ratio.

Differences in aspect ratio aren't necessarily a problem, but I think it's generally a good idea to keep things as consistent as possible regardless of the system on which a game is running. For the camera, such consistency ensures that what you see during development and testing is also what players see once your game is released: Objects visible from a particular vantage point will be visible on all systems, and those that aren't visible will likewise remain out of view. A consistent view across systems means the context is the same for all players, with no player seeing more of the environment or the objects within it than intended by the game's designer.

While Unity's game editor allows developers to choose between a number of aspect ratios while developing a game, there's currently no way to specify a particular aspect ratio when a game is run outside of Unity's development environment. There is, however, a way to do this with a bit of extra effort. What follows, then, is a tutorial on how to guarantee the use a particular aspect ratio regardless of the game's resolution.

The first step is to create a camera script to adjust the camera's viewport according to the game window's current size and the desired aspect ratio. The script is created by choosing Assets -> Create and the desired script type from the editor's menu, after which the code to set the aspect ratio is added to the script's Start() function so that it's executed during the camera's initialization step. Here's some C# code that does just that:

// Use this for initialization
void Start () 
{
    // set the desired aspect ratio (the values in this example are
    // hard-coded for 16:9, but you could make them into public
    // variables instead so you can set them at design time)
    float targetaspect = 16.0f / 9.0f;

    // determine the game window's current aspect ratio
    float windowaspect = (float)Screen.width / (float)Screen.height;

    // current viewport height should be scaled by this amount
    float scaleheight = windowaspect / targetaspect;

    // obtain camera component so we can modify its viewport
    Camera camera = GetComponent<Camera>();

    // if scaled height is less than current height, add letterbox
    if (scaleheight < 1.0f)
    {  
        Rect rect = camera.rect;

        rect.width = 1.0f;
        rect.height = scaleheight;
        rect.x = 0;
        rect.y = (1.0f - scaleheight) / 2.0f;
        
        camera.rect = rect;
    }
    else // add pillarbox
    {
        float scalewidth = 1.0f / scaleheight;

        Rect rect = camera.rect;

        rect.width = scalewidth;
        rect.height = 1.0f;
        rect.x = (1.0f - scalewidth) / 2.0f;
        rect.y = 0;

        camera.rect = rect;
    }
}

Once you've saved your new camera script, add the script to the camera by dragging the script from the Project window onto the camera's listing in the Hierarchy window. Now when you run your game the camera's viewport will be scaled and positioned to match the desired aspect ratio^*.

Now the next step is to add a second camera to render the "black bar" region of the screen. While you can choose to render whatever the second camera is pointed at, in most cases you'll want to set the camera to render only a flat color such as black. To do this:

Create the camera by choosing GameObject -> Create Other -> Camera from the editor's menu.
Set the camera's depth value to -2 so it's rendered underneath the main camera (whose depth value defaults to -1).
To set the black bar region to a solid color, set the camera's Clear Flags to "Solid Color", set the Culling Mask to "Nothing", and finally the Background to the desired color.

That's all you need to do. Now your game will run with the desired aspect ratio regardless of the user's choice of resolution.

* When running your game from within Unity's editor, be sure to have the Game window open and visible in the editor when you run the game. There's currently a bug in Unity 3.0 (and possibly in earlier versions as well) where the window resolution reported to the script does not match the actual resolution of the window inside the editor if the window isn't visible at the time the play button is pressed, leading to a viewport with the wrong size.

A History of the Amiga

2010-04-15T16:24:00.009-04:00

A History of the Amiga, from Ars Technica:

Part 1: Genesis
Part 2: The birth of Amiga
Part 3: The first prototype
Part 4: Enter Commodore
Part 5: Postlaunch blues
Part 6: Stopping the bleeding
Part 7: Game on!

Saving, Reloading and Player Failure

2009-09-02T14:20:00.003-04:00

When the subject of free versus restricted saving comes up, people often end up conflating the issues of players being free to save their progress at any time and games requiring players to replay certain segments upon failure. The assumption is that the proper response to player failure is for the game to reload the latest save state, thus leading to a framing of the issue of loss of player progress in terms of free versus restricted saving.

Unrestricted saving mechanisms are essential in modern games in that they allow players to quit the game at any time without losing progress. This does not, however, mean that loss of progress upon failure is an illegitimate mechanic. Countless commercially successful game designs that purposely incorporate just such a mechanic show quite clearly that loss of progress upon failure is a perfectly legitimate mechanic. Ultimately, the answer to the "free save" dilemma is not to design a game such that progress can never be lost, but to design a game such that its response to player failure isn't coupled to the game's save system.

Therefore:

Principle: Uncouple a game's save/reload mechanism from the game's response to player failure.

Rationale: A game's response to player failure should be designed into the game rather than be defined by something as arbitrary as when was the last time the player saved the game. Instead of reloading the latest save game whenever the player fails at a particular task, restore the game to a state that is known at design time given the player's progress so far. This makes it possible to divide player progress into milestones without subjecting players to a crippled save system.

Emotions in Games

2009-07-20T20:00:00.000-04:00

Authors and filmmakers who wish to evoke particular emotions in their audience often rely on the audience's ability to empathize with the characters portrayed in the narrative, and especially with the protagonist. The author sets up situations in which characters experience particular emotions in the hope that the audience will themselves have similar feelings, or at least understand why the characters feel the way they do. The author is in control of the characters' emotions, while the audience's emotions derive from sharing in those characters' feelings and experiences.

Game designers who wish to evoke particular emotions have it somewhat more difficult. Unlike books and movies, where the author is in full control of the protagonist, it is the audience itself that is largely in control of a game's principal character or characters. Although designers can script particular emotions into a game's protagonist by taking control away from the player or reducing the number of available choices, this can feel like cheating to a player who feels his or her character should be feeling something different; An author like Shakespeare can write Romeo such that he wishes to die upon seeing an apparently dead Juliet lying in front of him, but a game designer cannot force the player to wish the same for his character.

How, then, does a game designer create emotions? Several options present themselves:

Atmosphere - Designers may encourage particular feelings in players by presenting them with emotionally suggestive images, sounds and music. This is all about transporting the player to an emotionally suggestive imaginary environment.
Subject matter - Audiences can respond emotionally to particular subjects. Games can touch upon the human condition or deal with controversial subjects to evoke strong emotions. If done incorrectly it may earn a game more critics than fans, but done correctly it may perhaps be the most crucial element in crafting mature, dramatic game experiences.
Gameplay challenges - The mechanics of games and competition encourage certain emotions in players. At the simplest level, these emotions concern the player directly rather than the player's character. In games that contain a narrative, these basic emotions can be modulated through narrative significance, in that overcoming or failing at particular challenges has specific narrative consequences designed to promote particular feelings in both characters and player.
Other characters' emotions - Just like authors can evoke particular emotions by getting the audience to empathize with the characters he creates, so can game designers evoke particular feelings by getting the player to engage emotionally with the characters in the game. Unlike in books and movies, however, it is a mistake for designers to rely on the protagonists emotions, which are perhaps best left unstated.

Moving Around in 2 and 3 Dimensions

2008-11-26T04:00:00.008-04:00

Here are some differences between ground-level 3D and top-down 2D environments, and their implications for ease of navigation:

The way the shapes of objects change as the player moves around the game environment. In 2D environments, rigid objects retain their projected shape as they change position and orientation due to player motion, while in 3D environments their apparent shape can change significantly.
The way the angles between objects change as the player orbits around a particular point or travels along a path¹, as measured from the camera's perspective. In 3D environments the apparent angles between objects are significantly affected as the player moves around, but remain fixed in 2D views.

For these reasons, a 2D view is generally more stable than a 3D view, as it doesn't change quite as radically as the 3D view when the player moves around the game world. Furthermore, since the view in top-down 2D games doesn't usually rotate as it does in 3D, a typical 2D view is remarkably stable compared to a 3D perspective. A stable view provides a more recognizable context than a more dynamic view, which makes it easier to tell where you are and which way to go.

1. If the player is moving along a straight line, angles between objects will change only if parallax is present.

[Offtopic] Software Activation and IP Ownership

2008-11-19T15:33:00.023-04:00

Softimage XSI has recently been acquired by Autodesk, the company that owns competing packages 3ds Max and Maya. Users who've purchased XSI through its former owner will now have to deal with Autodesk for any licensing and support issues.

Since XSI requires the software to be activated online before it can be used, existing users will be at Autodesk's mercy when reinstalling XSI onto their computers following catastrophic data loss or when transferring their license onto a new computer. These users, who purchased XSI with Softimage's particular activation policies in mind, will now be subject to Autodesk's activation policies and may even be required -- if Autodesk should so desire -- to agree to Autodesk's more restrictive licensing terms before Autodesk will agree to activate any copies of XSI purchased before the change of ownership.

Perhaps things will turn out okay for current XSI users, but there's no guarantee that will be the case. Whenever you use software that requires activation, you remain at the mercy of the software's copyright holder, which may change without warning and without any remedy to you, the user.

Failure by Random Numbers

2008-05-15T19:00:00.000-04:00

Failure by random numbers can occur whenever the random processes that determine failure aren't significantly influenced by the player's choices, giving players little or no meaningful control over the outcome of their actions. For the most part, games should be designed such that players may improve their chances of success according to the choices they make in the game, giving them meaningful control over their future.

Cause and Effect

2008-01-18T12:25:00.000-04:00

Principle: Avoid responding to the player's actions with behavior that is contrary to reasonable player expectations, as it breaks the implied "contract" between the player and the game designer.

Players cannot form a useful mental model of the game world when things happen unexpectedly or without an apparent cause. Players should be able to understand the laws at work in your game's environment, and to make appropriate deductions based on their understanding of those laws.

If unexpected or incongruent behavior is desired, players should ultimately be able, by virtue of the game's design, to reconcile such behavior with their operative mental model of the game world -- which by its nature is allowed to change as the game progresses.

Meaningful Mistakes

2008-01-10T23:00:00.000-04:00

Principle: Sometimes a player's mistakes aren't really mistakes. If a player has no good reason to believe a particular action might lead to failure, then failure should not be blamed on the player.

Failure by surprise occurs when the player's actions do not appear as if they should lead to failure, because the relationship between action and outcome is either obscure or counterintuitive, or because the element that makes a particular action lead to failure is presented too late for the player to react to it. King's Quest and Dragon's Lair are known for this kind of failure mechanism, where the wrong move can easily result in unexpected death or failure¹.

A game should generally provide enough clues for players to anticipate danger, and should otherwise give players a fair chance to react to any surprises.

Footnotes

1. See Ways to Die/Lose in King's Quest and Let's Fail Dragon's Lair v2.0 (not safe for work).

Walkthrough? I Don't Need No Steenking Walkthrough!

2008-01-07T01:06:00.001-04:00

Principle: If a game requires a strategy guide or walkthrough to complete, it's broken. If the game may be completed without one but nevertheless provokes a not insignificant number of players to consult one, it's just as broken as before.

Rationale: Completing a game should require no external clues. A player's failure to figure out a particular puzzle without outside help is actually the designer's failure to provide sufficient clues within the game. The game world is missing essential information; the game is broken.

Exceptions: If a game mechanic explicitly involves the application of external information, this principle does not apply.

Game Design Questions

2007-09-27T22:08:00.000-04:00

Some questions every game designer should ask during the game development process:

Are the game's interfaces and user controls consistent throughout the game? If they're not, is there a good reason why they shouldn't be consistent? Do the inconsistencies make logical sense?
Do the controls adhere to known conventions for the game's genre? If not, in what ways is the game's control scheme superior to that of its predecessors?
Are there objects in the game that behave contrary to reasonable player expectations? Are there objects that look like they should do something they don't do? Are there objects that do things that are not suggested by their form?
Does the player feel lost ("where am I" / "what am I supposed to do next") when I don't intend him to feel that way? If I do intend it, do I have a very good reason for it? Does my approach convey the desired emotions, or is it merely frustrating?
Does the game provide sufficient cues for the player to anticipate danger? If there's any surprises, am I giving the player a fair chance to react to them?
Is the game's failure response (e.g., whatever happens once the player's avatar dies) tied to the game's save system? Wouldn't it work better if the two were uncoupled?
If the game features cutscenes or other narrative elements at the beginning of the game, how long does the player have to wait until he gains control of his character? What about other cutscenes in the game?
If players skip a cutscene or forget some important detail, can they watch it again?
If the game does not allow players to skip particular cutscenes, do I have a good reason for it? Why not just let players skip and replay these cutscenes at will?
If there's an in-game tutorial, does it interfere with the player's sense of free will? Does he feel he's being played like a puppet, or otherwise constrained?

Design Flaw: In Your Face

2007-09-01T20:15:00.001-04:00

The Game: In Your Face

The background: In Your Face is a street basketball game for the original Nintendo Game Boy. At the beginning of every game, a coin-flip animation is shown to represent the practice of flipping a coin to determine which side gets control of the ball.

The problem: The coin-flip animation is purely cosmetic, for the human player always gets initial control of the ball. The virtual coin's behavior does not agree with the player's expectation that a coin flip should produce random outcomes, thus the game's implicit promise to the player is broken.

The solution: Allow the coin flip to determine who gets control of the ball, or else get rid of the coin flip animation.

Bad Interface: Civilization IV

2007-08-26T13:55:00.001-04:00

The game: Civilization IV

The background: Numerous times over the course of the game the player is asked to choose from a list technologies that determine the units and improvements available in play. Certain items on each list are emphasized through the addition of the word "recommended" right next to those items.

The problem: The placement of the word "recommended" next to particular items introduces a bias toward those items. This is fine for new players, but for slightly more experienced players the game's recommendations can become an obstacle to uninhibited choice. After all, if the player thinks the game has selected the best of all the available choices, why should he pick anything different? This kind of player lacks the experience necessary to make the best choices on his own, and the game's interface hinders the player's acquisition of such experience by interfering with the free exploration of the game's technology tree.

The solution: One way to solve this problem is to separate the game's recommendations from the main technology selection interface, through the use of a second-level advisory interface. If that is not desired, another approach is to limit the use of such hints to the easiest difficulty levels, avoiding their use at higher difficulties.

Design Flaw: Zelda: The Wind Waker

2007-08-07T16:23:00.000-04:00

The game: Zelda: The Wind Waker

The background: One of the islands in the game, the largest of the Mother and Child Isles, is impossible to reach on foot. A talking fish that's swimming in the area tells the player he may reach the island by taking "a ride on a whirlwind":

"They say that inside the ring of rock that makes up the perimeter of that island, there lives an incredibly beautiful fairy! But the thing is, nobody's ever met her. Supposedly, the only way you'll ever meet her is to take a ride on a whilrwind and drop inside that rock perimeter from the sky above. Doesn't sound easy, fry..."

The problem: The fish's suggestion is potentially misleading. In certain areas of the game world the player can use his Deku Leaf to glide over cyclones and be lifted high up in the air, extending his gliding range. Recalling these experiences, some players will improperly deduce they're supposed to ride the small cyclone that's found in the immediate vicinity of the Mother and Child Isles.

In fact, the only way to reach the island is to play The Ballad of Gales, which players can learn by defeating Cyclos, the wind deity, using Link's bow and arrow. A player who has yet to learn The Ballad of Gales¹ is unlikely to realize it's the only way to get to the island.

The solution: One way to solve this problem is to allow the player to enter the island using only his Deku Leaf. This approach is consistent with what the player already knows about the game's mechanics, and is therefore consistent with his expectations.

If that approach is not desired, a different way to solve the problem is to get rid of the small cyclone that's swirling in the vicinity of the Mother and Child Isles. This would eliminate the primary source of confusion: the presence of a cyclone that cannot be used to get into the island.

Finally, if for some reason the cyclone should not be removed, the fish's message should be modified to make it unambiguously clear that entering the island requires something more than just a Deku Leaf.

Footnotes:

The only clue to defeating Cyclos is provided by the fish near Shark Island:

"Tell me, small fry, have you ever been caught in one of those cyclones? The wind deity, Cyclos, uses those cyclones to fly across the sea instantaneously, or so I've heard. Could be just a rumor. Boy, if you had that power, you wouldn't have to spend so much time sailing back and forth across the sea all the time. Wouldn't that be nice, fry? But let me tell you, there's no way he'll give up his power easily! You can't get near the guy, so you'll have to figure out how to shoot him from a distance. Don't you have a weapon that can pierce things from a distance? You know, fffwip? FFFWIP, I tell you! You get my point, fry?!"

Remembering Goals

2007-08-07T01:50:00.001-04:00

The issue: Certain kinds of games require that players keep one or more specific goals in mind as they play. Players who return to a game after a long absence may find it difficult to remember what they're supposed to do next, which may impede their progress.

Resolution: Provide some sort of reminder of the player's unfinished tasks. This may assume such different forms as a list of pending and completed goals (Psychonauts), an in-character reminder of pending goals (Dragon Quest VIII), or a video log of significant cutscenes (Ratchet and Clank: Going Commando). If any of the tasks require knowledge of specific details previously revealed in play, the player should likewise be reminded of those details.

Bad Interface: Dragon Quest VIII

2007-08-05T00:08:00.000-04:00

The game: Dragon Quest VIII

The background: In a battle against a group of monsters, a player who wishes to attack has to first choose the "attack" option from within the game's "fight" menu, and then pick whichever monster is the player's intended target.

The problem: Once the player has defeated every monster except for the last one, the game no longer waits for the player to pick a target. The reason that's a problem is that the player, having become accustomed to performing two actions for each attack, is now required to adapt to a different mode of operation where each attack requires only a single action. A player who presses twice on the action button while expecting a single attack will be surprised to find out that he's actually chosen to attack twice (once for each player character).

The solution: Have a consistent interface that requires the player to always pick a target for his attacks. Avoiding inconsistencies is more important than saving the player a single button press. Consistency favors the natural tendency for routine behaviors to become automatic, and avoids player confusion.

Divide Progress Into Discrete Units

2007-04-19T19:09:00.000-04:00

Defeating an enemy; overcoming an obstacle; surviving in the face of adversity: success and failure are at the very core of the game-player's experience. Games offer players a number of choices, some of which lead to success and some of which lead to failure or non-success. Together with the challenges presented to the player, the fact that the player might fail lends significance to the player's choices and actions. Although failure can be a negative experience, it is also the very thing that makes success meaningful.

There are two kinds of failure in games. One kind of failure concerns the player's inability to satisfy a particular success condition that nevertheless remains satisfiable, and another kind of failure takes place whenever the player encounters a particular failure condition. While the first kind of failure is simply a failure to succeed, the latter kind calls for a particular response to the player's actions.

The manner in which a game responds to player failure is essential to its design. A game designer can promote player tension and create a sense of danger through challenging gameplay and the careful use of failure conditions and responses. When a failure condition is met the game will respond by penalizing the player in some fashion, often through the loss of progress. Thus, the player might be forced to replay certain parts of the game or be presented with an extended challenge as a penalty.

Progress is defined as the act of moving forward toward a goal. That goal may be a physical location within the game's environment, or it may instead assume the form of a desired outcome tied to the successful performance of a particular task or the conclusion of a series of steps in the proper order. The player's choices determine whether progress is made or lost.

Many games divide progress into discrete units or milestones, where meeting a particular goal ensures that the player will not be set back any further than the current point in the game. When the player is placed in a situation that may lead to repetition or additional work upon failure, progress is said to be at risk. Once the player attains the goal at hand for the given situation, progress is said to be safe. All else being equal, the greater the separation between the two states, the greater the penalty for failure. A reasonable penalty can make the game more challenging and exciting, but too large a penalty will lead to player frustration. It is the game designer's job to achieve the proper balance between creating tension and avoiding player frustration.

Of course, it doesn't always make sense to divide a game into discrete units. Some designs call for continuous gameplay rather than division into discrete units of play. Games like Tetris and Sim City don't revolve so much around individual goals but are instead framed in terms of broad, overarching goals such as keeping the screen clear of blocks or maintaining a thriving city. Furthermore, games without failure conditions such as many nonlinear adventure games do not afford division of progress given that progress can never be lost. Nevertheless, there are many kinds of games that benefit from being divided into discrete units of play.

It is worthwhile to look at some examples of games that divide progress into discrete units. Some of the best games ever created employ this type of structure as the means of achieving a balance between the desire to make a challenging game and the need to make it manageable.

In Super Mario World the game is divided into stages. Dying at any point before the end of each stage requires the player to start over from the beginning of the stage, or from the middle of the stage if the player has broken the tape at the midway gate. Once the player has completed a particular stage he is taken to the map screen and is free to proceed to the stage that follows. Stages are connected together through the map screen, but each stage is also a self-contained unit.

In Zelda: A Link to the Past, the game is divided into dungeons or similar structures. In one particular case a yellow worm named Moldorm is able to push the player off the edge of its platform and down through a number of holes in the floors of the tower where it lives, forcing the player to climb back up to the platform whenever he's pushed off the edge. In this case, Moldorm's tower acts like a self-contained unit that is further divided into a number of floors, so that being pushed off the edge will keep the game within the confines of Moldorm's tower.

In Ratchet and Clank: Going Commando, the game is divided into stages in the form of planets that Ratchet and Clank must visit according to the mission at hand. Each planet is in turn divided into smaller sections according to a series of continue points. Whenever the player reaches a continue point his progress is saved against failure so the player is returned to this point whenever he dies.

In each of these cases, the penalty for failure is well-defined. The difference between the moment when progress is first at risk and the moment when progress is safe is explicitly designed into the game. As a known quantity, the designer has greater control over the game's difficulty than if this quantity were allowed to vary arbitrarily according to the player's choices. The game designer is able to choose the size of each unit of play, allowing the designer to fix the size of the unit and adjust the unit's difficulty by tweaking the individual challenges, or to fix the difficulty of each challenge and adjust the size of the unit to add new challenges and therefore manage the unit's overall difficulty. These two strategies are complementary and may be employed in alternating fashion for the greatest control over each unit's difficulty.

Not all game designers appreciate the value of these strategies. Some designers prefer to rely on a game's save mechanism to determine what happens once a failure condition is encountered. Since failure sets the player back to the latest save game, the player is able to manipulate the difference between the moment when progress is at risk and the moment when progress is safe. Some designers consider this to be a fair advantage insofar as the player is able adjust the game's challenge according to his abilities, but it also carries the disadvantage that it may lead players to adopt a strategy of minimal risk. In the worst case the player will save the game whenever there's an imminent threat and reload whenever he suffers any harm.

Allowing the player to minimize risk in this manner not only makes the game less challenging for some players, it also encourages sloppy design. The designer, lacking information about the size of the chosen unit of play, surrenders an important baseline upon which to judge the game's difficulty. The player, who is not familiar with the game's design, will tend to save whenever he feels uncomfortable with the amount of progress that remains at risk. Thus, if the designer assumes that the player will save at every opportunity, the result will be a game that favors or perhaps even demands frequent saving. The designer will have to make individual challenges more difficult in order to account for the expected saving pattern and may end up neglecting the overall play experience. If, on the other hand, the designer assumes that the player will save only occasionally, the result will be a game that buckles under frequent saving. While players could certainly choose to save less frequently in order to make the game more challenging, this assumes that the player is willing to play through parts of the game he has already faced and overcome when he could easily avoid them by saving the game.

One way to see how tying progress to the save mechanism can interfere with a carefully balanced game is to play such a game in an emulator, relying on the emulator's state-saving feature as the only mechanism for recovering from player failure. Even if it's convenient to be able to quit and resume the game at any point, it's a mistake to rely on a game's save mechanism as the way to protect progress against player failure. Whatever form a game's save mechanism may assume, it should not be a part of the game's response to player failure.

Further reading:

Rules of Play discusses goals on pages 259, 251 and 342 - 344, and discusses victory and failure conditions on pages 259 and 261.
In opposition to the ideas expressed in this article, Ernest Adams argues in favor of allowing players to save whenever they want to in "Bad Game Designer, No Twinkie! II", "Bad Game Designer, No Twinkie IV", "What Kind of Game Designer Are You?", and "The Bill of Players' Rights". Also, in "Difficult Questions About Videogames: How Can You Tell if a Videogame is Rubbish?" he's credited with the statement that "Any game that does not allow the player to save his or her progress, on a gameplay device equipped with a save mechanism, at the player's own convenience and at any time of the player's choosing, is rubbish."