I may not fully grok what patterns are all about; I've read about software engineering patterns, and I've read Kreimeier's article, but Kreimeier's examples seemed far too general for me. On the other hand, I may be getting far too specific with these:
Problem: We want to allow the player to quit the game at any time to go to sleep, do something else, or whatever.
Solution: Allow the player to save the full current state of the game to a file.
Consequences: Player can quit at any time, but now he can "cheat", by saving the game, trying something, and then restoring the game if it didn't work out. (See EliminateCheating.) Player will be able to rapidly explore the game space, by experimenting with different strategies and then rewinding to before he made certain choices. This is technically a difficult task; sloppy coding early in a game project can make recording a persistent state intractable. (We had this problem with *Die By The Sword*, one of the main reasons we had an autosave instead of a full-state save.)
Examples: Most PC games.
Problem: Player wants to be able to quit the game to go to sleep, do something else, whatever and turn it back on later, but we don't want to let the player cheat by repeating an encounter over and over again.
Solution: When the player quits, save the game. Only one save game is allowed for a single continuous session. When the player loses, delete the save game.
Consequences: Tension is increased because the consequences of the player's actions are higher; they could lose everything they've worked for. For games where death is the way you lose, it creates a sort of empathy with the avatar - the avatar loses its simulated life, the player loses his avatar. On the other hand, this creates frustration; the player, when he realizes he has to restart from the beginning, may quit playing. (See rule PositiveReinforcement--as opposed to punishment.) On the gripping hand--(I'm such a geek)--if the player's goal is to rapidly explore the game space, these restarts merely serve to frustrate that goal.
Examples: All the Hack/Rogue type games, Wizardry, Uplink, Steel Battalions.
Problem: We want the player to be able to turn the game off, but we don't want the player to cheat, and we still want the player to be able to rapidly explore the game state and not get frustrated. Or, we have technical limitations (memory, possibly) preventing us from storing a full state.
Solution: Save the game automatically (Jak & Daxter)(this also solves the problem of 'players tend to forget to save') or allow the game to be saved at specific points in the player's progress. The checkpoint could be a game element (the save rooms of Metroid) or part of the 2D UI shell (Zelda). The player only has one save file; the latest checkpoint bashes the previous one.
Consequences: A compromise between the hardcore pattern and the full-state pattern, there's some tension (I have to restart at the last checkpoint if I blow it) and less frustration (at least I don't have to start at the beginning.) It is technically easy to implement. For example, in a linear level-by-level game, you could have a checkpoint at the beginning of each level and all you have to store in the save file is an integer. If save games are a game element it can blow immersiveness / the willing suspension of disbelief. If the player is low on resources right before they get to a checkpoint, they could be very screwed. (Halo - Halo solves this problem by also allowing you to restart at the beginning of the mission, which isn't too bad.)
Examples: Spider-Man, Zelda, Mario, Metroid, Jak & Daxter, Halo.
It's possible for a game to have both the game element checkpoint pattern AND the full state save! (System Shock 2. Wack. The result being if you've forgotten to save in a long time, you'll get zapped to your last checkpoint without losing your progress, just a few resources.)
This is the checkpoint save pattern but you can have three different games on your memory card. Had to get it in there.
Problem: We like the Checkpoint pattern, but don't like the ran-out-of-resources-just-as-I-got-to-a-checkpoint problem.
Solution: Store several checkpoints.
Consequences: If the player hits a checkpoint with low resources, they have the choice of trying to make it to the next checkpoint on low resources, or going back and trying again, conserving resources this time. (MeaningfulChoices.) The UI can become klunky for this kind of thing.
Examples: Splinter Cell.
Problem: We want the player to be able to turn the game off, but we don't want the player to cheat, but we want the player to be able to control the resolution of how often they get to save as they see fit.
Solution: Provide a 'save game resource'; you have a certain number of save games that you can use at your discretion. The game may provide a certain number per mission (Hitman 2) or it could be an item you actually find in the game (Resident Evil 2) or both (Mark of Kri).
Consequences: Save games become a resource that must be managed, creating MeaningfulChoices with IrreversibleConsequences. On the other hand, player may not realize that they should have used a save-game until it is too late. In a game where resource management is important this could particularly be a problem. (I'm down to one bullet...better save the game.) Thereby getting frustrated, and quitting. (Which is what I did with Resident Evil 2.)
Examples: Hitman 2, Resident Evil 2, Mark of Kri. (System Shock 2 charged you some nanites when you used the cellular-reconstruction thingy, also, making SS2 the grand-high-king of save-game-pattern diversity.)
Problem: We want the player to be able to fully explore the game space without the clunky interface of a save game system.
Solution: Allow the player to undo moves indefinitely.
Consequences: Player can fully explore the game space.
Examples: Most chess programs. I hear The Last Express allowed you to rewind to any previous point, which is kind of the same thing, as well, but I haven't played it myself.
That's all I can think of. Is that the lot of them?
CategoryPattern?