Once upon a time the country was filled with teenage whiz-kids feverishly programming away in their bedrooms hoping to become the next Jeff Minter or Scott Adams. Back then an individual working on their own could produce a massive hit game bringing them fame and fortune. Alas, those halcyon days are gone. How can someone get to grips with the new look corporate driven game industry?
At over 700 pages, this may look like a scary book. However, the nuggets it keeps between its covers might just turn out to be priceless. Throughout this title there are case studies to show how well known games have dealt with different issues. Some worked, some didn’t. You’ll recognise most but others I suspect have had their names changed to protect the people concerned. Additional comments and thoughts from industry veterans such as Ian Bell, Peter Molyneux and Glen Corpes are used to illustrate key points.
Most games start with an idea. Turning that idea into a structured proposal and then on to a more concrete set of specifications is covered first. The thought processes involved with designing the mechanics of a game are examined in depth. By the end of the section you’ll have a feel for documenting the specification plus getting the game balance and look and feel right.
From this point on you may be forgiven if you thought you’d picked up a business management book by mistake. The authors look at team building and the different needs and drivers of the programmers, designers and artists. Good project management, testing and quality assurance all get examined in detail. One point that I feel might be contentious is that the authors feel a dress code is essential. They argue that allowing people to dress at work as they do at home fails to differentiate one environment from another. People can end up treating work time as home time and spend too much time playing and getting distracted. Having spoken to a few people who work in the industry about this I got the impression that being forced to wear a shirt & trousers would result in them changing firms pretty quickly!
Good software engineering principles and the concepts of re-use and the ‘software factory’ are discussed at length as are the best approaches to bug fixing. It costs up to 200 times more to fix a bug in the final code that it does to do it at design time. A sobering thought for those who like to jump in with the coding without designing the game architecture up front. Other examples cite projects which for the sake of an extra months design time at the beginning ended up taking an additional year to be finished. There’s even a few C++ coding examples to show good style and a few techniques for pro-active coding to help eliminate common bugs altogether.
As the game nears completion you’ll be at the mercy of feature-creep and getting small details like the internationalisation right. As an example, German tends to be 40% longer than English on average. If your initial design work up front wasn’t done properly you may find at this stage that text doesn’t fit the space allowed for it on screen or that the speech in video clips is longer than the clip itself runs for.
Once the game is complete, it’s not quite time to sit back and relax. The all important postmortem needs to happen where the project is dissected and examined to see what could have been done better, what the highlights were and what can be learned for next time.
The book finishes off with some samples of design documents plus a short bibliography.
This is a fine book. The experience of the authors shines through and the mix of good solid business and project management combined with themes specific to the games industry is skilfully handled.