Game Architecture And Design
Author: Andrew Rollings and Dave Morris
Publisher: Coriolis
ISBN: 1-57610-425-7
Purchasing: [Amazon.Com] [Fatbrain.Com] - RRP US$49.99
Reviewed: 26th September 2001

Front Cover Shot:

First Impressions

This isn't the normal type of book that I review in this section - The other reviewed books are all directly programming related. however, Dont let this put you off this book at all. The book itself may well not be about programming, but the content is actually going to be extremely useful to you. Well, if you're writing games anyway...

The general idea behind this book is to explain the design/creation process for a complete game. Almost everyone who's ever wanted to, or has created a complete game (small or large) will be perfectly aware that you have to have a good plan and design to make a successful product.

What no book has told you before.

This is possibly the only book that exists on this topic. Therefore the information you get within the covers of this book is fairly unique, and the only other places that you can get this type of information is the occasional article on Gamasutra.com or GameDev.net; but they never go to as much depth as this book. However, this is still in a completely different league to those articles - this 700+ pages of well structured and very informative information. This book covers all the important areas of game development in some considerable depth, and it is hard to read a chapter and have not learnt something you didn't know before (unless you're a veteran of the games industry that is).

To further this point, when I received my review copy of this book I sat down to read it - starting at the first chapter as you do. Within 10-15 minutes I was hooked on reading more and more, Within the first couple of chapters I had gotten a completely different view of the games industry - It really does (as it says on the front cover) shake up the way you think about the industry. With some of the other technical books I've reviewed so far I haven't actually needed to read every last paragraph - I always read the majority of the book, but as in the case of the game programming gems series, I didn't need to read every last little bit of the book. As a break with tradition I did read all of this book, all 24 chapters, before starting to write this review. By the end of this book I had a completely different perspective on things, I get the feeling that I now understand the games industry much better than I did before. Whilst I'm no veteran of completed game projects, I have designed and made a few small games in the last few years - the design process of each has mostly been a few scribbles on a piece of paper and the rest floating around in my head. This book will allow me to make a much better, structured and realistic design document - and then go about producing the game in a much better and much more efficient style.

Whilst it's very clear from early on in the book that the authors know what they're talking about, and the points and strategies they suggest are all very well thought out, and backed up with strong reasoning/arguments, it's the case studies that shine through. Whilst most of the case studies are entirely abstract/theoretical, there are a few based on or taken from commercial projects that you may well own or have played (Quake, Quake 2, Starcraft, Warcraft etc...), and all of them serve an interesting point or example - and further explain any points being brought up in the text itself. One of the recurring case studies is the imaginary "FlyBusters III - Beyond the fly paper" (what a great name!), at one point in the book it discusses team interaction, particularly with respect to finding/fixing bugs; The authors use two case studies here - one where things go well, and one where things go badly - and it illustrates the authors points brilliantly.

Where it falls down

One of the biggest problems with this book is that much of the critiscm of styles/games and the case studies take a very subjective viewpoint. There are quite a few sections where I would of preferred a bit more objectivity, and a more two sided discussion of the theory. This comes down in some cases simply as a preference of certain games - I think I can quite safely say that the authors liked the game "Starcraft" an awful lot (not that there's anything wrong with this), but it's this fact that stops them from saying anything bad about it, it becomes completely one-sided and biased when they start talking about it! Whilst this in itself wont annoy that many people much, it's some of the other theories that will irritate you more (maybe); They preach that certain methods are the ONLY way of getting things done properly, and I'd have to disagree in some cases. Simple as that.

The other aspect is that this book is aimed almost entirely at team-based game development, which is to be expected entirely - game development is very difficult to do as a one-man-band. But there are many different "levels" of team - from 4 people working over the internet, to 25 people in a fully kitted out office complex. This book seems to be aimed primarily at the commercial level team - people who work on games for a living, earn a salary from it and have a proper office, whilst the theories and ideas presented here are aimed at those teams it is still applicable to those working as smaller less-formal development teams. The sections on design documents and project postmortems are just as useful to the small-team developer as the full-blown commercial developer, but the sections on management are going to be of very little use to small-team/hobbyist developers...

The Bottom Line

Well, the bottom line is fairly simple really - this is a good book, you will learn lots from it. The question is whether you want to pay good money for this book, and just how much use you will get out of some sections. Check out the summary, and make your own decision...