So my GDC write-up is a wee bit late… my weak excuse is that I took a two-week vacation to New Zealand immediately afterwards, which sort of broke me out of the momentum I needed to write this post. At any rate, it was a great GDC – possibly the best I have yet atteneded. Unlike most years, a certain theme actually emerged from many of the talks I heard – namely, the advantages of prototyping. In fact, a number of talks I couldn’t go to but that had people talking – such as Chaim Gingold’s and Chris Hecker’s talk on “Advanced Prototyping” – were on the same subject. The benefits of cheap experimentation were clearly in the air.

Brian Jacobson and David Speyrer gave an excellent talk on how Valve prototyped Half-Life 2. I knew prototyping worked for dynamic games like Civ, but I had always assumed it would be tricky for linear, scripted games like Half-Life. Valve seems to have solved this problem through parallelism, by splitting the game into sub-parts, each of which could be managed by a small design team. Then, they pulled in new testers from the outside world (often, just random gamers) to provide feedback for continual iteration on the design. The fast turn-around times they established (weeks, not months) was, I believe, a direct result of this reduction in scope – by focusing on small chunks of the game, their designers could afford to nit-pick over the details. The key to successful prototyping is not how you build the prototype but how you test it. After all, that testing is the whole point! The more feedback you receive, the more you will understand about which parts of your games are working and which parts aren’t. A direct linear relationship exists became the number of iterations of the game which you can test and the final quality of the product. By forcing themselves to cycle through their prototypes so quickly, they increased that number and – therefore – the quality of the final product.

(An interesting contrast exists between the prototyping of Civ 4 and Half-Life 2. Both products made a point to get early feedback from the outside world years before release. However, for Civ 4, we relied on a set group of testers culled from our community boards – people who were able to play bi-weekly versions of Civ 4 over the long-term. In contrast, the Half-Life team used “kleenex” testers – meaning they used them once to get their impressions and then never dealt with them again. This difference is a natural extension of the different genres the two games inhabit. Civ is a game meant to be played over and over again, with a focus on experimentation and strategy. Half-Life is a narrative game meant to be played once with a focus on visceral experience. If we had focused on using kleenex testers like Valve did, the game balance would have suffered as first impressions for strategy games are often wrong.)

EA’s Neil Young supposedly spoke on “Feature IP” – which as far as I could tell was just a fancy way of saying “new ideas” – but was actually giving a talk on prototyping in disguise. Some teams at EA are beginning to adopt a new experimental phase before pre-production in which small teams focus on solving specific problems in a lo-fi environment. Most people would recognize this as prototyping (of course, being EA, they had there own name for it, one which I have promptly forgotten).

Louis Castle gave a wonderful presentation (in the dreaded last time slot on Friday) on this process at EA in practice while developing the control scheme for the Xbox 360 version of Battle for Middle Earth II. He was given the freedom to spend at least a year focusing on just one thing: how to create the feeling of an RTS with a joystick instead of a mouse. I enjoyed seeing just how quick-and-dirty some of the early versions were – a few were simply the original BFME with an Xbox controller plugged into a PC. Most importantly, they were able to work on the challenges that were important to them (the control scheme) and ignore the rest (graphics, sounds, gameplay, etc.) After many failed attempts, they seem to have hit on a system which might break new ground – we’ll see how the market takes to it.

My talk was also on prototyping. For those who missed it, the slides are available here – although we obviously can’t recreate the many demos Dorian and I presented of early versions of the game. If we had something different to say about prototyping compared with the other talks, it was that prototypes do not need to be disposable. We started with a “prototype” and finished with a “game” but there was no thick, black dividing line between the two. Because we always intended for the prototype to become the finished product, we were able to keep working until the game was playable from beginning to end – always finding tricks or shortcuts to support the gameplay if the art or engine code wasn’t quite in place yet. The result was that we had a LOT of versions we could supply to our testers, providing a very visible sign of our progress.

So, why are so many companies focusing on prototyping? Frankly, it is one of the few aspects of game development that can still be done cheaply yet with great results. Further, it helps teams focus on what should always be most important: play-testing. If a game turns out fun, it’s because people played it early and played it often.