While attending this year's GDC I'm hoping to check out this session on Advanced Prototyping by Chaim Gingold and Chris Hecker of Maxis/Electronic Arts.
Why Prototype?
Prototyping can serve a bunch of purposes, actually. First off, in a business sense, it can often be the first step in acquiring funding for a project. Second, it's the most sensible way to prove some type of new technology or to quickly implement a complex algorithm. Third, for hobbyists and students, it's a great way to build a portfolio of work that gives potential employers a basis on which they can clearly judge your talent. Finally, it's often a great way to spark enthusiasm in a project from the perspectives of development/production and even the fan community (if you make your prototype public).
I've recently prototyped work for a couple web projects. Nothing fancy or resource-heavy like console/PC games, but proving a given technology/methodology will work. i.e. putting what's in my head into practice as quick as possible to determine whether or not I should pursue a given route or not.
I would classify my recent prototypes as "uber-simple" versus the "advanced prototyping" that will likely be discussed at the Game Developer's Conference. However, I'm guessing that some of the challenges I've experienced with these prototypes are probably pretty similar to real-world examples of game prototypes.
How Much Work is Throw-Away?
Prototypes are usually done as rapidly as possible to get something out that works for one of the various reasons mentioned above. This usually means I don't spend a lot of time focusing on comprehensive modeling/design of the software. No UML, no heavy requirement specifications, no polished graphics or other resources. Not a lot of thought/planning goes into my prototypes. Then again, my prototypes for web projects are something that can be easily accomplished by any decent web developer in intervals of between 1 to 5-ish days, so that seems sensible. Things like a) dragging graphical objects using SVG and JavaScript or b) using SVG to generate pretty graphs of my web statistics. As the projects get more advanced it would make sense to plan for reuse of bits of the prototype and to do some up-front documentation. How much planning do you do?
I've recently been trying to rework my SVG web statistics into something more manageable and improve its interactivity. This has required several internal changes, genericizing the code, etc. I've moved chunks of logic from the server (in PHP) into the client (JavaScript), meaning I've had to translate code between languages. I've had to totally restructure some of the internal data structures. The list goes on. One of the great things is having the prototype "template" to use, but one of the frustrating things is having to rewrite complete sections of stuff I've already figured out. That doesn't come for free, there's a lot of debugging that goes into that.
Keep Up The Morale
Prototyping is usually the fun part. It's a great way to "get wow", but once the prototype is complete, then the real work starts (I'm only being slightly facetious here). Designers work on the software architecture and specifications. Coders have to profile their code, optimize algorithms, etc. Graphic artists get to work on production-level art. Audio engineers need to get into the studio and work with those fussy, high-profile actors. How do I (as, say, a development lead) keep up the level of enthusiasm within your team so the project crosses the goal line? Likely a form of employee rotation would serve here.
Maintaining A Grip On Reality
What about losing track of reality? It may be easy enough to design a prototype of a browser-based instant messaging system using PHP and some file locking but once you start to add hundreds or thousands or even millions of users to a real system - is your backend going to hold up? You may have to totally redesign your backend, or even deem that you don't have the necessary resources to afford such a system. In this example, how worthwhile was your prototype (likely the UI bits will still be quite useful, actually).
Anyway, how do you keep track of reality while designing your prototype so that your final product is actually achievable?
Conclusion
These are just some of the questions/answers I'll be listening for in the session. I'm sure the presenters will touch on aspects that I currently have no clue about but I hope it will give me enough useful insight into improving my prototyping experience on some of my future projects.
This post is part of a series describing some of the prep work Rob and I have done to get ready for the GDC this year. Have a look through our unofficial preview of GDC 2006 sessions to get a feel for what to expect, along with pointers into the official site.