Gamasutra: The Art & Business of Making Gamesspacer
Quick and Dirty Prototyping: A Success Story
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Quick and Dirty Prototyping: A Success Story

April 1, 2010 Article Start Page 1 of 4 Next

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.

Article Start Page 1 of 4 Next

Related Jobs

Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States

Quality Assurance Associate
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Team Lead Online Marketing - TV (m/f)
Yoh — Vancouver, British Columbia, Canada

Build & Test Engineer
Nix Hydra
Nix Hydra — Los Angeles, California, United States



Khin Boon Chang
profile image
Great advice. Goes down as one of my fav article. I am a instant fan. :)

eyal erez
profile image
Great article. and an awesome game too!


Joe Cooper
profile image
I think I prefer your programmer art. It has more character.

Luna Cruz
profile image
Thanks, everyone!

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 ;)

Stephen Northcott
profile image
Nice article. Concise and to the point.

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? ;-)

Andrei Victor
profile image
IMHO The great thing about what you and your team has done is to actually focus on the concept of the process - the true essence of it. To do the concept, you didn't do any additional use of tool or whatever special rule just to make it "look" like you're implementing the concept. From what was described in the article, the team stuck to what is simply common sense -- something most have forgotten and end up behind buzz words of project management (e.g. agile, scrum, waterfall, whatever). I hope all things are as simple as these because these are the things that are really needed.

Bravo! Congratulations!

Kim Sellentin
profile image
As someone who attended your IGDA LF talk last year, I would like to say how admirable it is to see someone demonstrate complete ownership over their PM methodology. You actively refined your processes over time to suit Boomzap's needs, following a vision based on common sense. Well done, Luna.

Clinton Keith
profile image
I agree with Kim. Do what makes sense and change what doesn't. Too many teams get lost in the labels and terminology and don't get to understand what makes sense. Good processes, no matter what the source, should lead to similar common sense practices. For example, I loved seeing your cost-of-change curve. That's the same curve that XP-ers use to justify the value Test Driven Development.

Well done!

Mon Macutay
profile image
Great article, Luna. Concise and informative. Excel rules!

Best of luck to you and your studio!

Leroy Frederick
profile image
Go with what works not just what everyone else does. Nice piece!

Senthil Kannan
profile image
Its authentic!! Is there any requirements for a macro developer ;-)

Dave Endresak
profile image
Excellent article, Luna.

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.

Mike Frampton
profile image
Great article,

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.

Rob Schatz
profile image
Luna, thanks for sharing your best practices for the betterment of everyone, you're awesome! I wish there was some way to mesh the q&d method into AAA development. But then again, I suppose it depends on what platform you choose to develop on. For example, the dev process is way more hardcore and strict for Unreal-based games than say Flash game development, however, working in Unity might prove to be the Goldilocks answer we're all seeking.

Luna Cruz
profile image
I should really check back more often!

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 :)

Christopher Natsuume
profile image
@Rob - Actually, a lot of this work practice is based on the way we used to run the team at Crytek when I was a producer there - we used a version of it while developing the original Far Cry for PC, *especially* including a very rigorous daily build and daily playtest process. When Allan and I started Boomzap, I carried a lot of that experience over, and adapted it to use in a smaller team. But, it actually has it's roots in AAA retail game development... So I wouldn't be too quick to dismiss it's relevance to larger teams and non-virtual work environments.

Robert Cruz
profile image
Great article! Thanks for sharing.

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.

Gonzalo Nicolas
profile image
Thank you for sharing your experience and workflow.
I'm taking some ideas from it to our own workflow :)

Ferdinand Joseph Fernandez
profile image
I think there's some confusion over the term "agile". Agile is the umbrella term, its only the idea. The idea that your production is flexible to the changing requirements during mid-production.

Whatever process you use to achieve it (scrum, kanban, or your own invention of quick prototyping) is a valid case of agile.