The checkpoint system has become a staple of console gaming. For the players, checkpoints provide a comfortable experience where progress is taken care of by the designers of the game. For the designers, it allows a tighter control on pacing and the experience of challenges as well as being a subtle tool for rewarding or punishing certain behaviours as well as managing tension within the game.
From a practical point of view, we call checkpoints to certain places and/or times where the game saves your progress automatically. This then becomes your new starting point should you loose/die/fail during the distance that separates one checkpoint to the next. From a game-play point of view, checkpoints constitute grand divisions between challenges or groups of challenges. The existence of checkpoints divides game-play into segments. Within these segments we can find one or more than one instance of a self contained challenge. These divisions are often quite apparent since they accompany changes in the pacing, scene structure, situation and other elements of the game.
Example – Uncharted: Drake’s Fortune
On the last section of the game we are on a ship chasing a villain and are faced with several stand-offs where we must face him along with an escort of armed men. Each of these encounters is a self contained challenge and both a mechanic and a fictional pause is provided between them. The checkpoints, however, do not always follow these natural breaks as we need to successfully completely the first two encounters to reach our first checkpoint.
By providing these grand divisions, checkpoints can combine several different challenges into a bigger challenge that exists at a meta level. This means that not only you deal with the individual challenges but also with a scenario that requires you to sometimes complete more than one of them in successful succession in order to proceed. The result of checkpoints that define segments which include several challenges is lowered margin of error for player within the particular section of the game. If we take into account that replaying sections of the game is the prime resource that designers implement to punish failure, we can see how the checkpoint structure coupled with a higher or lower margin of error defined by the challenges and by the checkpoints at a meta level, determine the punishment for failure.
Example – Ninja Gaiden Sigma*
The dreaded final section of the game includes a platforming segment where you are trying to escape from a cave which is caving in. After several acrobatics and a couple cut-scenes you reach the final battle. Failure to complete either of those segments will send you back to the start of the cave section. This means that you are not rewarded for the execution of that section until the following one is completed.
*Note: Ninja Gaiden Sigma uses a save-point system that, for all practical purposes, has the same effect than checkpoints (but with an added busywork.)
## How Do We Deal with Challenges?
Dealing with a challenge is a complex process that usually involves four different stages. Each of these stages is usually experienced in rapid succession and the player goes back and forth through them while trying to overcome the obstacle. The four different stages are:
1. Adaptation (to a new environment/tools/opposition/so on…)
2. Learning (about the characteristics of the obstacle and the goal; I.e. “What needs to happen and what’s stopping that from happening”)
3. Planning (for a course of action to disable the obstacle and meet the goal)
4. Implementation (of the course of action)
Once point 4 is reached and executed we now have new information (whether our plan seems to work or not) that takes us back to a new adaptation stage repeating the cycle until the challenge has been overcome. Therefore we can say that, at the most basic level, dealing with a challenge requires the ability to know if:
a) what we have discerned about the situation is correct/incorrect
b) our plan to disable the obstacle works/doesn’t work
The ability to fail (both partially and totally) is essential to the achievement of any challenge. Even if complete information was given to the player about the adaptation, learning and planning stages he would still need to know if his implementation is correct and thus needs to be able to access failure. Failure is both a consequence of poor implementation and, most importantly, a vital tool to deal with challenges and obstacles.
## Fail and Re-Play
Once you have successfully dealt with the adaptation, learning and planning stages of a challenge, re-doing that challenge will only put the implementation stage into play. This only changes when there are incentives (both promoted by the game or from the player himself) to maximize the levels of efficiency in the first three stages or change the rules of the challenge to make it harder for themselves. This is the source of all sorts of re-plays for better ranking/scores as well as master runs and similar challenges. These need to be supported by the game and agreed upon by the player in order to come into play. Disregarding these exceptions we can say that if the subdivision caused by a checkpoint causes the player to re-play a challenge that has previously been bested while there is another that hasn’t, the game is forcing the player to have less fun and be less challenged while more fun and a new challenge is available.
## It’s All About Consequences
Games need to have consequences for failure. These add tension and set real stakes for the performance of the player. Many times, the consequences for failure have taken the shape of punishment in the form of replaying a section of the game. While it’s not a bad idea to allow for a specific number of errors before having to replay a challenge, an unsuccessful application of the checkpoint system can cause people to repeatedly replay extended sections of the game that have already been beaten rather than focus on the unconquered challenges. This can lead to higher levels of frustration and boredom and a significant drop in the emotional involvement of the player with the game.
## Ideas for Improving the Implementation of Checkpoints.
Checkpoints should follow natural breaks both in the game-play (challenges) and in the fiction (scenes, acts, plot points and so on.)
Boss encounters are a prime example of something that makes a break both in the game-play and in the fiction. Not only do they signal a pause in the game where the protagonist must face a greater peril to continue with his journey, but often the act of defeating a boss is sufficiently involved (pattern memorization, learning what the boss can’t and can do, devising strategies and so forth) to require it’s own checkpoint. To further improve this, a second checkpoint before the boss battle is trigged should also be available for players who wish to backtrack and explore loose ends or complete optional objectives before tackling the boss. This is especially true in games where no warning is given regarding points of no return like most boss battles.
Checkpoints should be dynamic.
Game designers can offer a player that has already suffered several times the penalties for failure a more lenient checkpoint structure that let’s him tackle the precise area he still hasn’t been able to conquer. The change could merely be available for the particular segment and a normal checkpoint structure could be resumed afterwards.
Checkpoints should honour the value of the player’s time.
All game-play is, in a way, based on trial and error. When error is severely punished, however, the ability of the players to overcome the challenges is crippled. Checkpoints should be reasonable and let the players work on conquering the section that still has an obstacle (a challenge that has not been beaten) rather than (literally) wasting their time making them replay extensive sections of already beaten content.
The checkpoint system has become a staple of console gaming. For players, they provide a comfortable and immersive experience keeping them in the game . For designers, it allows a tighter control on pacing and the experience of challenges as well as being a subtle tool for rewarding or punishing certain behaviours and managing tension. However the implementation of checkpoints usually comes with its own set of problems.
From a practical point of view, we call checkpoints to certain places and/or times where the game saves your progress automatically. This then becomes your new starting point should you lose/die/fail during the distance that separates one checkpoint to the next. From a game-play point of view, checkpoints constitute grand divisions between challenges or groups of challenges. The existence of checkpoints divides game-play into segments. Within these segments we can find one or more than one instance of a self contained challenge. These divisions are often quite apparent since they accompany changes in the pacing, scene structure, situation and other elements of the game.
All this quit-saving is getting tiresome.
By providing these grand divisions, checkpoints can combine several different challenges into a bigger challenge that exists at a meta level. This means that not only you deal with the individual challenges but also with a scenario that requires you to sometimes complete more than one of them in successful succession in order to proceed. The result of checkpoints that define segments which include several challenges is lowered margin of error for player within the particular section of the game. If we take into account that replaying sections of the game is the prime resource that designers implement to punish failure, we can see how the checkpoint structure coupled with a higher or lower margin of error defined by the challenges and by the checkpoints at a meta level, determine the punishment for failure.
How Do We Deal with Challenges?
Dealing with a challenge is a complex process that usually involves four different stages. Each of these stages is usually experienced in rapid succession and the player goes back and forth through them while trying to overcome the obstacle. The four different stages are:
- Adaptation (to a new environment/tools/opposition/so on…)
- Learning (about the characteristics of the obstacle and the goal; I.e. “What needs to happen and what’s stopping that from happening”)
- Planning (for a course of action to disable the obstacle and meet the goal)
- Implementation (of the course of action)
Once point 4 is reached and executed we now have new information (whether our plan seems to work or not) that takes us back to a new adaptation stage repeating the cycle until the challenge has been overcome. Therefore we can say that, at the most basic level, dealing with a challenge requires the ability to know if:
- what we have discerned about the situation is correct/incorrect
- our plan to disable the obstacle works/doesn’t work
The ability to fail (both partially and totally) is essential to the achievement of any challenge. Even if complete information was given to the player about the adaptation, learning and planning stages he would still need to know if his implementation is correct and thus needs to be able to access failure. Failure is both a consequence of poor implementation and, most importantly, a vital tool to deal with challenges and obstacles.
Fail and Re-Play
A case of checkpoint deprivation.
Once you have successfully dealt with the adaptation, learning and planning stages of a challenge, re-doing that challenge will only put the implementation stage into play. This only changes when there are incentives (both promoted by the game or from the player himself) to maximize the levels of efficiency in the first three stages or change the rules of the challenge to make it harder for themselves. This is the source of all sorts of re-plays for better ranking/scores as well as master runs and similar challenges. These need to be supported by the game and agreed upon by the player in order to come into play. Disregarding these exceptions we can say that if the subdivision caused by a checkpoint causes the player to re-play a challenge that has previously been bested while there is another that hasn’t, the game is forcing the player to have less fun and be less challenged while more fun and a new challenge is available.
It’s All About Consequences
Games need to have consequences for failure. These add tension and set real stakes for the performance of the player. Many times, the consequences for failure have taken the shape of punishment in the form of replaying a section of the game. While it’s not a bad idea to allow for a specific number of errors before having to replay a challenge, an unsuccessful application of the checkpoint system can cause people to repeatedly replay extended sections of the game that have already been beaten rather than focus on the unconquered challenges. This can lead to higher levels of frustration and boredom and a significant drop in the emotional involvement of the player with the game.
Ideas for Improving the Implementation of Checkpoints
-
Checkpoints should follow natural breaks both in the game-play (challenges) and in the fiction (scenes, acts, plot points and so on.)
Boss encounters are a prime example of something that makes a break both in the game-play and in the fiction. Not only do they signal a pause in the game where the protagonist must face a greater peril to continue with his journey, but often the act of defeating a boss is sufficiently involved (pattern memorization, learning what the boss can’t and can do, devising strategies and so forth) to require it’s own checkpoint. To further improve this, a second checkpoint before the boss battle is trigged should also be available for players who wish to backtrack and explore loose ends or complete optional objectives before tackling the boss. This is especially true in games where no warning is given regarding points of no return like most boss battles.
-
Checkpoints should honour the value of the player’s time.
All game-play is, in a way, based on trial and error. When error is severely punished, however, the ability of the players to overcome the challenges is crippled. Checkpoints should be reasonable and let the players work on conquering the section that still has an obstacle (a challenge that has not been beaten) rather than (literally) wasting their time making them replay extensive sections of already beaten content.
Tagged as:
Design,
Videogames
{ 1 trackback }
{ 0 comments… add one now }