Monday, April 27, 2009
The Nine Structural Subsystems of Any Game
Katamari Damacy is not a game. Solitaire (the card "game") is not a game?
How do we explain the different between game and non-game, how can we draw the line?. Following article from Lewis Pulsipher teach us about a game.
Preview:
A game can be thought of as a system (as in "systems analysis", for the computationally inclined). What I'm trying to achieve here is a list of the fundamental sub-systems that are necessarily a part of any game (excluding sports such as baseball or swimming). This list may help inexperienced designers, because if they think about all nine of these systems as they rough out their game, this will help them conceptualize and arrive at a playable idea.
We could discuss endlessly what is a game and what is not; let's just recognize that, within your definitions of "game", you can probably find an exception that doesn't have all nine characteristics. I think that's a function of definition rather than a failure of the analysis, but that must remain a matter of opinion. If one of these systems is completely missing, you might have a toy or puzzle, but not a game.
There are many examples "on the edges", such as Katamari Damacy. To me, Katamari Damacy is not a game. Solitaire (the card "game") is not a game, because there's no conflicting interest, no active opposition guided by intelligence-they are more like a puzzle or toy. But both of these activities fit the Nine Structures framework.
I want a framework that will help a designer think about games. Some people, in listing fundamentals of games, discuss "state" in considerable detail. I've tried to avoid "state" and "state-changes" as much as possible, simply because I don't think that an organization dominated by state is very useful to an inexperienced designer. "State-change", in particular, seems to lump an awful lot together in one pot. My ultimate goal is to have something that will be useful to inexperienced designers, and to be able to expand each category to exhaustively list alternatives within each structure. I want designers to be able to treat the extended list as a sort of checklist, to help them make sure they've thought about all the vital aspects of their game early in the process.
I've tried to list these subsystems in an apparently logical order, but every one is just as fundamental as every other one.
Here is the list, followed by brief explanations and some examples:
1. Theme/History/Story/Emotion/Image.
2. Player Interaction rules.
3. Objective/victory conditions.
4. "Data storage". (Information Management)
5. Sequencing.
6. Movement/Placement.
7. Information availability.
8. Conflict resolution/interaction of game entities.
9. "Economy" (resource acquisition).
Sometimes the system is assumed, or the choice is to have "none", but still a decision has been made about the category. For example, in Tic-Tac-Toe (Noughts and Crosses) there is no acquisition of resources, but it still has an economy of "unlimited pieces" -- it could have a way to gain resources, and there are variations where you do. Another example: a very abstract game has no theme/history/story, but the designer chose to take that approach, nonetheless.
Read more ...
Labels:
Game Developers Guide
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment