|
Last November at the IGDA Leadership Forum, I gave a short talk on quick and dirty prototyping as a production method for small PC games. The topic was met with curiosity, as most producers were already comfortable with their existing waterfall or agile methodologies.
While our studio, Boomzap Entertainment, is agile in the simplest definition of the word ("can move fast, is flexible"), we don't follow Scrum, XP, or any of the popular frameworks. Instead, we've tweaked a process that works best for our indie studio for the past five years -- a process I like to call "quick and dirty prototyping", though no one else at Boomzap refers to it as such.
You can read a short summary of the presentation here. In this feature article, I'll expand on my original talk by discussing in depth how our studio does quick and dirty prototyping, the tools and tricks we use, and the benefits (and pitfalls) of using the method. I'll also be using examples from our latest game, Awakening: The Dreamless Castle, which was built through prototyping.
Why It Works (For Us)
To give you some context on how we work: Boomzap Entertainment is a small indie casual games developer in Southeast Asia. We are a 100% virtual studio -- we are spread across Malaysia, Singapore, Japan, and the Philippines, all working from home, without any rented office space anywhere.
The Awakening team worked with each other entirely online, from meetings and documentation to asset and build processing. The only way for us to judge another person's abilities was to look at the work they've put into the build, making us conducive to prototyping (which, by its very nature, is all about results).
We are also a small company, with a total of 19 people. We have an average team size of four or five, which usually consists of one programmer, one designer, and a few artists. Awakening, at its peak, had seven people -- mostly artists -- because the game was art-intensive.
Since our team was small, there was no need for hierarchy or bureaucracy; anyone could suggest or comment on an idea, and we approved and vetoed each other equally. This also meant anyone could prototype something into the build quickly, without facing much resistance from the rest of the team.
This combination (a results-only virtual environment plus a small team size working on a casual game) made it easy for us to use quick and dirty prototyping. That's not to say that it wouldn't work for larger studios, projects, or teams -- your studio may already be doing something similar.

How It Works
Quick and dirty prototyping involves three basic ideas:
1. We build working prototypes as fast as possible
2. We keep the assets ugly until the last possible second, and
3. We revise or scrap content until it's fun.
This method is entirely about speed and efficiency; daily builds, placeholder assets, and rapid iteration formed a routine for making all our projects, including Awakening.
|
Thanks.
Joe Cooper: That was actually artist-made. The actual crap art I made is too embarrassing to be posted on the web.
Robert Allen: You're right, it's more of the latter. You only check in work if there's something to check in - though coders and designers pretty much check in daily without fail. Another thing with our company is, if we notice that you haven't contributed anything new to the build in a few days, you're in trouble ;)
The really funny thing is that our HQ is in Thailand. We have a similar approach. Similar team makeup and inception. And I've been calling this style of development QAD (Quick And Dirty) since the late 80's.
Do we know each other from another life? ;-)
Bravo! Congratulations!
Well done!
Best of luck to you and your studio!
The specific phrasing you use to explain your "quick and dirty prototyping" is almost an exact echo of "The Cathedral and Bazaar" academic article about open source development such as Linux and various open source tools. The one difference I could see is the detail about access to the builds, where open source suggests pretty much open access and allowing vast amounts of input and revisions to evolve the project.
I have to say that I am not a complete proponent of open source for all projects, but your explanation mirrored the academic arguments for open source so much that I had to make the observation. I am about to do an article (hopefully it will be published, too) about a general topic related to these ideas, so I found Boomzap's process to be yet another of many successful examples that I could offer in support of my arguments.
I believe your work-flow is somewhat similar to the one Klaus Tauber used when designing the popular board game "Settlers of Catan". Klaus would work on the game in his basement creating prototypes and then bring it up for his family to play. He paid close attention when a particular feature resonated with his wife and kids and was eventually able to come up with one of the most popular board games around today.
Keep up the good work.
Stephen Northcott: Seriously? Maybe we do! Your acronym for it is great; I wish I'd thought of it ;)
Dave Endresak: Good luck with your article! If you need any more information, just drop me an e-mail.
Rob Schatz: I was blown away by Unity - and I don't doubt that daily prototyping could be useful for AAA development, at least for particular features. But nothing's ever that simple in the big league, is it?
Thanks for your comments, everyone :)
I especially like the Excel then export to LUA bit, which I think is a really big time saver and frees up more time for the programmers to actually do more stuff integral to game play. In our experience the programmers tend to spend quite some time a day just updating and re-embedding new assets to the resource file.
I'm taking some ideas from it to our own workflow :)
Whatever process you use to achieve it (scrum, kanban, or your own invention of quick prototyping) is a valid case of agile.