Book: Game Development Principles (Alan Thorn)

I’ve recently been working with a group of teenagers, helping them learn to program for themselves, and build their own iPhone/iPad/Android games. So, when Cengage offered me a review copy of this book, I thought it would be a good idea to have a look and see if it would be helpful to a similar audience.

This blog isn’t a review site, so I’m going to pull out just the key interesting bits worth mentioning.

What’s the book for?

The blurb on the back cover claims:

1. “games that enchant players and stand the test of time [are only made by people who know the] principles of good game design”
2. “[this book has] the core theoretical knowledge”
3. “math, textures, … geometry, … lighting, sound”
4. “all your questions will be answered”

This book has nothing on game-design. There are few filler sections on this, but you’d get more detail by typing “game design blog” into Google and picking a link at random.

“Core theoretical knowledge” of game development is a big topic. If most people tried to write it down, I’d expect a thick, heavy tome. Thankfully, this book doesn’t try that. I’d say it aims for approximately 25% of the core knowledge, which is a reasonable compromise. Better to do some of it well, than do all of it badly.

On those named details:

• “math” can’t be covered in a book unless that’s 50% of your content. This book has basic vector-math (really basic: not enough for game development), and quickly moves on.
• “textures” skips all the bits about implementing textures, and instead focusses on issues to do with authoring simple 2D textures.
• “geometry” only talks about things that 3D artists need to know when making models, it misses out all the things at the engine level, at design time, etc.
• “lighting” is covered well, with a good explanation of deferred lighting (which is one of the major modern issues in lighting and 3D engines). More on this later
• “sound” has basic info on implementing and playing-back sounds in-game.

In conclusion: the blurb on the cover is about 30% accurate. The book covers both more and less than it claims. On the face of it, this looks bad – but I think the book has rather more important/better content than the marketing claims

What does this book cover well?

Introductions, not Principles

A Principle is an underlying idea, a fundamental – something that appears over and over again in different guises. You can find two very different examples of related concepts, and sometimes there’s an underlying principle that shapes both of them. Principles are deceptively simple – the description is usually brief, but to work it out takes a lot of work in experimentation, thinking, researching, etc.

By contrast, an Introduction is an observed explanation of what you can see. It requires only the ability to analyse information, and to describe it clearly and cohernetly. Introductions focus on naming and describing, giving the reader new vocabulary to start thinking about a topic. They tend to cut away large segments of a topic and say “ignore that for now; first, learn about this (smaller) part”.

This book is largely Introductions: external, descriptive, simple to digest – working on cut-down versions of each topic.

My notes above suggest that Math, Textures, Geometry are covered poorly by this book. The “principles” of these are missing. But it gives good “introductions” to each. And, for many readers, that’s more useful: practical, getting-started, stuff.

Colour, Pixels, and Aspect Ratios

This whole area is the source of many recurring problems when non-professional artists work with game-programmers. Artists often misunderstand (or forget, or ignore) rules such as:

“a power-of-two texture REALLY HAS TO BE a power-of-two in each dimension”.

There’s good, clear info here – a whole chapter on the intersection between “art” and “using that art in an engine” – that’s worth sharing with both the artists and the coders. If you’re new to game programming, it’ll give you heads-up on a few problems, and the vocabulary to explain it to your artists. If you’re new to game-art, it’ll warn / explain some things that seem a waste of time to you, but are extremely important to the programmers you work with.

Preparing to use a GameEngine (e.g. Unity)

Approximately half the time, this book provides the info you need to know before using a 3rd-party game-engine, rather than the info you need to work with your own engine. In particular, it’s pretty well-suited to Unity development, while never being Unity-specific.

(and there are some key Unity concepts that are annoyingly missing – for instance, this book ignores Quaternions, an embarassing oversight in any engine, but critical in something like Unity that makes them a first-class datatype)

There’s a lot of stuff here that my students have had to learn – specifically at the engine-level – by trial-and-error, or by watching YouTube clips and copy/pasting code. If you have no prior experience of game-dev, but want to go into Unity/UDK/etc, I think it would be worth starting here before going on to engine-specific resources. It’ll give you a more contextualised idea of the stuff you’re using (i.e. how “Unreal-specific” is a concept? is it something that every engine uses?).

What does the book describe badly?

Project Management

There’s a lot of talk about the problems of project-management, and why process is needed in game development. This is worth saying, but I found these sections thick and heavy and hard to plough through.

The only good thing I found in this section was that it name-checks key phrases in game project management that you can go put into Google and read about. Plus “Scrum” – the book forgets to mention it, even though it looks like being more widely-used (by successful teams) than all the other approaches put together.

(Bear in mind it was circa 5 years ago that CryTek gave their talk at GDC about how Scrum saved Crysis from being cancelled. Scrum’s been widely deployed and respected for a long time now)

As to the author’s proprietary system of “RAMS” … just: don’t. Project Management is a huge topic – take it seriously, use a proper methodology, not something you thought-up yourself.

Entity Systems

Of course I was going to mention this ;).

I was pleased to see that the book provides an intro to Entity Systems – or “Component Based Design” as it terms the general area. It covers the “why OOP doesn’t work very well for game-designers” part of the problem.

Sadly, it omits the technical and performance problems of OOP (Data-driven execution doesn’t get a look-in), and it doesn’t get as far as explaining Entity Systems.

I’m unashamedly prejudiced here. If you’re going to teach people game development you absolutely must teach them about Entities. Not least: Unity uses a cut-down hybrid Entity System, and that system is the main recurring source of perofrmance problems in Unity projects. People need to understand this – it’s not optional stuff.

(and it’s not difficult to learn).

Marketing and Publishing

It’s hard to write a paper book in the age of the Internet. When you stray outside your area of expertise, readers only need ten seconds with Google.com to find something better.

This chapter isn’t bad per se, but it’s clearly written by a non-expert who hasn’t done most of this themself. There’s way too much hand-waving and “here’s a concept, but I don’t have anything to say about it”. The chapter does have value – it introduces many key phrases and vocab that you can put into Google, find blog posts by experts, and read them instead.

(if that sounds mean, bear in mind that many readers won’t even know what to search for. This is a very difficult chicken-and-egg problem when you first start out; don’t underestimate the value of being given a list of “questions I should start with”!)

Overall / Summary

For £15 on Amazon (discounted price as of writing), would I buy this book? And who would I give it to?

Yes, I think I would. About half of the writing is thick and wordy, but half of it is clear and simple. It’s obvious where the author is on ground he understands well, and his writing there is great. e.g. as noted above, his explanation (with pictures) of Deferred Lighting is excellent, and I’ve shown it to a few people in lieu of explaining it myself.

For the “who”, I’d say: people who are taking their very first steps in game development. This is a good book to read while you’re writing your first Tetris clone, or implementing a simple 3D FPS in Unity – somehting where you leave the core engine alone, but make cosmetic changes to e.g. the weapons and the landscape.

I’m looking for a companion book that focusses on Unity; I think it would be interesting to have a book that someone can read after this one, and that can itself assume a lot of knowledge, and focus on just the practical and technical issues of design and development in Unity.

It would be interesting to recommend this book and a Unity book together as a matched pair.

It isn’t a book of Principles; anyone who’s spent a year or more in commercial game programming, or shipped more than about 3 techdemo games, will find little in here they haven’t already learned for themself. Some, perhaps enough to justify buying the book – but it depends where your interests lie.