Pages 37 to 73. Thanks to Ernest Adams for his encouraging comment! The book I read comes from the first edition and until now, I have not found any typo: a nice piece of polishing... My comments stay in [brackets]. I sometimes use the acronym GD.
game design is not purely an art because it is not primarily a means of aesthetics expression. Nor is game design an act of pure engineering. Its is not bound by rigorous standards or formal methods.
Player-centric GD has two pillars: entertaining the player and stepping into the player's shoes. Entertaining is of higher priority than expressing the designer's creativity. In a player-centric approach, the designer must remember he/she is not the typical player. He/She has to ask himself/herself, for instance, "what if the player is female?" [or Russian? cf Modern Warfare 2 ...] Maintaining that you must love your game to build a good one is the opposite of player-centric. "The player is my opponent" is a vision of early arcade games where players were permanently put under pressure to put more coin to play. This is not player-centric as well. In fact, a good GD combines several characteristics.
|Market-driven||targeting a specific player segment||[Wii Fit]|
|Designer-driven||Designer's vision only||Daikatana|
|License||Based on a movie, book or existing Intellectual Property||[NHL, Fifa]|
|Technology-driven||Show off a technological achievement||Starfox|
|Art-driven||Show off artwork||Myst|
Components of GD
See figure nearby. Glossary:
- Core mechanics
- Implementable mathematical model of rules, goals and action impacts. All games stand between purely abstract (Pacman) and representational (Formula one racing games). The degree of realism depends on the game.
- Provides feedback, entertains and should be smooth to allow a direct mapping by the player between controls and actions. The UI contains the interaction model (the mapping between buttons and actions) and the perspective(s) (appropriate view of the game world).
- Game structure
- Set of gameplay modes + shell menus + links and transitions between them
- Gameplay mode
- Particular UI and/or gameplay for a particular game situation. Example: playing quaterback is different from playing receiver in Madden NFL Football, so each situation needs its own gameplay mode.
- Shell menu
- Located outside of the magic circle, do not affect the game world. Example: save/load, configurations
Some more vocabulary:
- Defines what will not change: concept, audience, genre [this phase is common with other traditional software product]
- Design details, decision refinements. One prototype per iteration. When all the designers in the team agree on the fundamentals, they share the work and part. Their tasks are: defining the primary gameplay mode, designing the protagonist, the game world, the core mechanics, aditional gameplay modes, level designing and the story.
- Polishing is substractive, not additive. Most of the time, the duration of this phase depends on how much time is left. This phase makes the difference between a good and an excellent game.
Even if no one reads these documents,
an idea written down is a decision made. Not writing often means overlooking. [A game designer from Blizzard disagreed: "you do not know what is fun on the paper"]
|High concept document||Sales tool, short, key ideas, sent to publishers||.doc|
|Game treatment document||Sales tool, a thicker volume than the high concept, a "in case you want to know about our game more deeply"|
|Character design document||Specific to one character of the game, contains concept arts, character's history, likes, strenghts, etc.||.html|
|World design document||Art and audio to give the mood of the world, can contain a map, given to level designers|
|Flowboard||Mix between flow chart and storyboard, one sheet of paper = one gameplay mode. Each sheet shows the actions available to the player. Arrows link modes to each other. Can be done with Visio [there are open-source alternatives].|
|Story and level progression document||How level follows each other and where cutscenes or dialogs should be included. Useless if there are no levels or progress in the game.|
|Game script document||It used to be the Bible, containing the whole project. Nowadays (projects are too big) it contains only rules and core mechanics. Paper-play testing the game should be technically possible with what is written in it. This includes also the target machine and the system requirements.|