Lou is a big believer in documentation and backups. If you have an idea and don't write it down, that idea may never come to you again and it will be lost forever, so always have something nearby to record your thoughts. Regularly transcribe your ideas from the paper you wrote it down on to a computer document, and back up your hard drive regularly. Even if the idea goes nowhere right now, having it preserved lets you go back and dig up old ideas later on; they can be a source of new ideas, and you might also (years later) finally figure out how to get that old game to work. Having lost my own share of ideas over the years to lost documentation, I'm not going to disagree, and I found it interesting that he hammered on this idea quite a bit -- most game design books don't say much about it at all. I suppose this is the difference between theory and practice.
Also on the subject of documentation, Lou points out that many people don't want to read the game manual, they much prefer to have a friend show them how to play because it's easier. This is no big surprise to anyone who plays a lot of video games (nowadays it's standard for them to have an on-board tutorial that teaches you everything, so that the manual is superfluous) but the board game industry still hasn't caught on. Lou suggests that it would be very easy to audio-record a gamer explaining the rules of a board game, as if to their friends, juxtaposed with photos, diagrams or video. This provides a pretty efficient rules "document" that could either be packaged on CD with the game, or at least put on the publisher's website. Lou also mentions that this would be particularly useful for educational games; many teachers who aren't hardcore gamers would still like to integrate some games into their class, but they don't want to take the time to learn the rules.
Lastly, Lou proposes that a game can be broken down into nine atomic parts. Not all games have all these parts, but the sum of them could be used to completely describe a game His parts are:
- Theme/history/story
- Objectives or victory conditions
- Game state (he called this "data storage and information management" -- a way to record the important variables in a game such as victory points, board position, cards in hand, etc.)
- Order of play (turn-based, realtime, etc.)
- Movement and/or placement
- Information availability (that is, what information is visible or hidden from each player; this includes immediate information hiding such as a closed hand of cards or fog-of-war mechanics, but also includes unknown future information such as the outcome of a die roll)
- Interaction of game entities, including conflict resolution
- Economy: resources, the means to acquire them, and the means to exchange them
- Rules of player-player interaction outside of the game state (this includes mechanics such as trading, negotiation, auctions, and metagaming)
I find it interesting to compare this to the list of formal elements from Game Design Workshop:
- Players
- Objectives/Goals
- Procedures (I found this confusing in the text, but it essentially means the UI -- the actions available to the player allowed by the rules)
- Rules
- Resources
- Conflict
- Boundaries (that is, where does the game end and the Real World begin; includes physical boundaries such as a proscribed area of play, and conceptual boundaries that let the players know who "is playing" and who is not in the absence of physical boundaries)
- Outcome
- Dramatic elements (this includes story and narrative, but also the aesthetics created by the dynamics of the game itself, such as rising tension in a well-paced game)
There are similar elements on both lists, so it may be useful to combine them the next time I teach a theory-of-game-design class.
No comments:
Post a Comment