Divide Progress Into Discrete Units
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:
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."
Comments