This is part of the series on book reviews.
"Patterns in Game Design" (Staffan Bjork and Jussi Holopainen)
If you've never seen a book on Patterns before, this is likely to be different from your usual experience. A "Pattern" is, more or less, a common problem and its established solution. The point of a book of Patterns is to prevent you from reinventing the wheel with each new project.
Most Patterns books are programming-related, because programming is the most expensive part of game development, so a lot of cost savings can (theoretically) come from code re-use. Applying the same concept to game design is intriguing; as far as I know, this is the only book to do so (although similar works like the 400 Project existed first).
This book's concept of a Pattern is slightly different. It is more of an encyclopedia of game design concepts; for each concept, it explains what it is, what design decisions must be made to include it, and links to other related concepts.
Unfortunately, the book has some inherent flaws due to its very nature. For one thing, the field of game design does not have an established critical vocabulary, so the authors had to invent names for a lot of concepts that will be unfamiliar to designers or students. This makes the book read like a foreign-language dictionary: every time you try to look up the definition to a new word, the definition itself contains half a dozen words that you also have to look up. This makes for frustrating and dull reading, and since it's a physical book you don't even have the benefit of having hyperlinks to click on. This would have worked much better as a wiki than a book.
To make matters worse, the publishers decided for some strange reason to put about 200 of the Patterns on an included CD instead of in the printed book. However, many of the Patterns in the book reference those on the CD (and vice versa), so when looking at references you have to go back and forth between the two media.
I found the most useful thing about this book to be the overall taxonomy of concepts, where a game is broken down into major component parts (such as goals, rules and player actions) and then each of those parts has a number of concepts (e.g. different kinds of goals, such as Chase or Capture or Evade). This would fit well into a conceptual class on game design, as it goes into more detail than any other book I've seen on the list of concepts.
Students: You can safely avoid this book for the time being. You get enough tedium from the rest of your classes; there's no need to inflict more of it on yourself. Also, there's no obvious way to tell the difference between the terminology that is in common use in the industry, and that which is purely the invention of the authors; talking about Avatars and Bosses is all fine and good, but if you mention Hovering Closures or Focus Loci in your job interview you'll probably just confuse everyone else.
Instructors: The basic concepts in this book could be used in your lesson plans to supplement a theory-based game design class, when you talk about the component parts of a game. Just don't borrow the terminology that isn't in common use. I wouldn't recommend this as a required text for any class; it's not organized in any fashion that I can imagine being useful for a class, and it doesn't lend itself well to exercises. Keep a personal copy for reference when making your lesson plans, but keep it away from students.
Professionals: The terminology and organization of this book give it a large up-front cost in time; even if you just want to use it as a reference text, it's only practical if you've already read through (or at least skimmed) most of it already. If you do put in the time, it may be a source of inspiration when you're working on the core mechanics of a game... but only if the game is highly derivative by nature, because this book only documents common game features that already exist. In other words, it may help you solve problems that have already been solved in other games, but only in exchange for actively reducing your creativity.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment