4 of 5 people found the following review helpful
on 2 October 2007
This book, though well worth reading, is definitely a mixed bag. Split broadly between game design and game production, both are covered quite extensively but with a lot of repetition.
It starts well when describing different aspects of game design, listing some key concerns and doing well at steering clear of the "first, pick a genre" trap. But when it comes to the details of low level design, it seems to settle on the "everything is rock-paper-scissors" approach. There are some interesting variations on this theme, but some alternative perspectives would have been welcome, especially those that might hold true beyond the RTS/FPS ground that the mathematical approaches model well.
When it comes to the production process, the book seems to be squarely aimed at the underperforming team rather than the average or good one, as much of the advice seems to assume dysfunctional relationships, poor management, and a team of selfish developers. In fact, several of the tips given are tempered by telling us that top sellers like Doom and Starcraft "probably didn't use" some of these tricks, because they were too good to need to. In other words, Rollings and Morris go down the route that many others use when advocating their methodology, extolling it as a system to get the most out of a mediocre developer, rather than a way to create a great product.
Later parts of the book tend to repeat a few general themes, such as iterative development, focusing on creating working components and code-reuse, the merits of design patterns, etc. Most of these things are well-known to the educated developer, and repeated insistences that they are worth using (with graphs of arbitrary data to help convince us) are not going to change any minds.
Some parts seem opinionated and dogmatic, and sometimes even contradictory. Why suggest that imposing an arbitrary dress code will somehow make people work harder in the absence of cited evidence? Why waste time caricaturing five different types of 'problem developer' (which in this case is assumed to be synonymous with 'problem coder' - artists and designers are obviously perfect!) instead of just tackling the individual issues? Why use the phrase "start with a well-designed product, and then plan the marketing" in a sample design document, but in the very previous chapter make it very clear that you think the Marketing department should be treated by the developers as the end client for the product?
This last point is perhaps the most important one; this book is not about how to make good games as such, but about how to make enough of the resources at your disposal to make a game that is good enough and marketable enough to keep you in business. There is enough common sense here to turn any randomly-assembled rabble of developers into a group that can probably ship something, given management with enough determination. But if you're already at that standard, or are able to work outside the constraints of a typical professional team of developers, most of the knowledge here will be of limited use.
1 of 3 people found the following review helpful
on 30 December 2009
I read this years ago and even then it seemed a little dated. Fast forward to 2010 and it doesn't bear any real resemblance to the way games are made now.
Not entirely the author's fault - the good things they advocate are now completely common place. Game development is considered a professional sphere and you expect professional behaviour from a colleague. And we all try to reuse code etc. But some of the stuff has really fallen by the wayside, and is irrelevant or wrong. This would be more than a little confusing to someone trying to learn about game production.
There's nothing on modern production methods like Scrum (because it was in its infancy when this was written).
And the design stuff is very weak, seeing everything as a glorified rock-paper-scissors. That stuff is very very out of date.
Seemed an important book at the time and you still see it on a lot of people's desks. But no-one reads it, or cites it, or recommends it.