How to Prototype a Game in Under 7 Days

Hailing from the the Experimental Gameplay Project at Carnegie Mellon's Entertainment Technology Center, the authors of this article give tips and insights into quickly churning out game prototypes, drawing from their experience in making 50 games in one semester with a team of only 4 grad students.

Here's a crazy game idea: Drag trash-talkin' gobs of goo to build a giant tower higher and higher. They squirm and giggle and climb upward over the backs of their brothers, but be careful! A constant battle against gravity, if you build a tower that's too unstable, it will all fall down.

"Tower of Goo" was downloaded over 100,000 times within months of hitting the net, it was dubbed “Internet Game of the Month” in one magazine, it was demoed on G4 and at the Experimental Gameplay Workshop at GDC, and it was one of over fifty games we made as a part of the Experimental Gameplay Project at Carnegie Mellon's Entertainment Technology Center.

And like the rest of them, it was made in under a week, by one person.

The project started in Spring 2005 with the goal of discovering and rapidly prototyping as many new forms of gameplay as possible. A team of four grad students, we locked ourselves in a room for a semester with three rules:

1. Each game must be made in less than seven days,
2. Each game must be made by exactly one person,
3. Each game must be based around a common theme i.e. "gravity", "vegetation", "swarms", etc.

"Tower of Goo" was downloaded over 100,000 times within months of hitting the net.

As the project progressed, we were amazed and thrilled with the onslaught of web traffic, with the attention from gaming magazines, and with industry professionals and academics all asking the same questions, "How are you making these games so quickly?" and "How can we do it too?"

We lay it all out here. Through the following tips, tricks, and examples, we will discuss the methods that worked and those that didn't. We will show you how to slip into a rapid prototyping state of mind, how to set up an effective team, and where to start if you've thought about making something new, but weren't sure how. We hope these well-tested guidelines come in useful for you and your next project, big or small!

For easy browsing, all tips and tricks are organized into four sections: Setup, Design, Development, and General Gameplay. Enjoy!

1. Setup: Rapid is a State of Mind

Rapid prototyping is more than just a useful tool in pre-production – it can be a way of life! This section will show how to set up and begin thinking like a rapid prototyper.

Embrace the Possibility of Failure - it Encourages Creative Risk Taking

It's all about that little trouble-maker we call “risk”. Fear of failure, as far as we can tell, is the reason why movie licenses and double digit franchise games keep getting made. It's like always choosing to go to McDonalds instead of an unexplored new restaurant – always safer to rely on a well-known adequate option rather than take that risky plunge into the unknown but potentially delicious.

A good rapid prototyper would realize that failure is ok! That's what prototyping is for, so go crazy! If you fail, there will be dozens more, and chances are, you'll learn something anyway. By embracing the possibility of failure, rewarding experimentation becomes possible.

Mr. Gray: “Mime After Mime” and “A Mime to Kill” were two games I made that attempted gameplay using only positional audio cues with no visuals. Although they were utter failures, the whole team was thrilled to take such a bold risk to prove the failure of audio-only gameplay, and I could point with pride to my hideous creations. As I gathered experience throughout the project, I was able to take more directed risks that lead to successful games.”

"Mime After Mine" and "A Mime to Kill" - warmly embracing failure.

Enforce Short Development Cycles (More Time != More Quality)

You only need a few days. It seems like a natural and comforting thing to say, “Hey we made a great game in one week. Therefore, if we spend TWO weeks, it will be TWICE as good!” Of course this isn't the case. We found that generally any gameplay idea can be prototyped effectively in less than one week. Extra slop time tends to yield diminishing returns. Some prototypes, for instance, took just a single evening to throw together, while others got an extra week or two of love. Surprisingly, we found that there was no correlation between time spent in development and how successful the game ultimately turned out.

Attack of the Killer Swarm” (left) took just a day to throw together and surprisingly became one of the highest rated games of the project. “Suburban Brawl” (right) received an extra week of love but became so convoluted it probably would have been more fun without the addition of giant killer robots – which wasted both cities and time alike.

Constrain Creativity to Make You Want it Even More

Our most successful games grew out of specific themes or “toys”, like “gravity” or “swarming” or “make a game targeted towards a predominantly female casual gamer demographic”. Somehow, it became easier to be creative when there were restrictions in place.

Additionally, with a team of people all simultaneously generating prototypes around a particular theme, there was some guarantee we would avoid attacking the same obvious gameplay mechanics. Instead, we were challenged to explore and really suck the theme dry for all possible gameplay uses.

We moved away from this model towards the end of the project, ultimately to our detriment. Without solid thematic constraints, the games took longer to create, had less direction, and group unity deteriorated. There was less a feeling of “we're all in it together”, and even worse, we lost the sense of friendly competition that was responsible for squeezing out those extra drops of creativity and finesse.

Some of the themes we explored were: “gravity”, “springs”, “evolution”, “sound”, “predator and prey”, “addictive games”, “drawing”, “exponential growth”, “vegetation”, “balance”, and a few others individually.

“Gravity Head” – use your gravity-powered head to grow and deliver.

Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent

Each member of the team had to be comfortable with all aspects of game development. Everyone was responsible for their own programming, art, sound, and everything else that went into the final product. But talent wasn't everything. Ideally, it was important for everyone to approach this style of development with the understanding that design is paramount – everything else from art to engineering exists only to serve the final design. A great engineer without this mindset would likely be less successful than a mediocre engineer who fully understands this point.

A word from Jesse Schell, project advisor: “I am always fascinated by the creative process for generating new game ideas, and so naturally I was thrilled when Shalin, Matt, and the Kyles proposed this project. I looked at it as an opportunity to try side-by-side controlled experiments in creativity, hoping there would be useful game design lessons learned. As faculty advisor, I tried to make sure that the team tried several different techniques, that the team was learning from their mistakes, that no one dwelled too long on an idea that wasn't working out, and that each individual was finding their optimal creative process.

“I gave suggestions along the way about how to improve the games as well, but mostly I tried to stay out of the way. I felt a bit like a gardener -- I did a little watering and weeding, but the flowering was all up to them. As this paper shows, the team was able to make some very useful conclusions – and ended up with some good games to boot! There is still more to learn about optimizing the creative process, and the Carnegie Mellon Entertainment Technology Center plans to continue this project.”

“Our team, Experimental Friends 4 Ever!

Develop in Parallel for Maximum Splatter

So once we assembled our team, what did we do? We stop working with each other! It might sound odd, but the benefits of not collaborating were too great to ignore:

  • Risk Mitigation – By developing four prototypes simultaneously, we could make risky design decisions with the comfort that at least one or two were likely to be successful
  • Friendly Competition – Everyone benefited from being kept on their toes. Like capitalism!
  • Wider Thematic Exploration - Four minds all focused on the same theme forced us to plumb the depths of each topic. How embarrassing it would be if we all made the same game! This forced us into some rewarding creative realms and allowed us to avoid obvious points of attack.
  • Sharing and Caring – Though we didn't share code (by choice, not requirement), we found it helpful to share concepts and understanding into a cumulative pool of knowledge. If one team member, for instance, discovered an effective way to represent spring systems, everyone would benefit.

As the weeks wore on, we found that having the team work together was most valuable at the beginnings and ends of each cycle. In the beginning of each cycle, the team was useful for helping to solidify and compare ideas. Once we hit development, we found each other to be more of a distraction than anything else – as each person was fully immersed in their own efforts. By the end of each cycle, we would all return to the room and work together until the wee hours of the morning for that last-minute extra taste of competition. A graph of this phenomenon might look something like this:


2. Design: Creativity and the Myth of Brainstorming

A great idea takes a split second to happen, but waiting for that lightning to strike can be excruciating. There's no such thing as forcing a great idea to squirt out, but this section should help cultivate your creative juices.

Formal Brainstorming Has a 0% Success Rate

We tried hard - boy we really wanted brainstorming to work! We scheduled “brainstorm meetings”, and “powwows”, we tried different color markers on whiteboards and oversized post-it notes, we even used motivational phrases like “blue sky” to help with our “out of the box thinking.” But in the end, out of all the games we created, not a single one was the result of sitting down as a group for a brainstorm session.

Why not? This was all very shocking to us, but after much investigation, it appears that you just cannot schedule creativity. You cannot say, “Hey everybody let's meet for a brainstormer at 4:15, and by 5:00 we'll have 4 kick-ass game ideas ready to hit the ground running!”

But it's not hopeless. There are still (at least) two reasonable things you can expect from a well-conducted brainstorm session. The first, of course, is that it gets everybody thinking. And then sometime later, maybe on the drive home, or in the shower, or while taking Poopy for a walk, a brilliant idea will erupt in your head. Or maybe not. But as far as we can tell, your mysterious brain does a lot of thinking when you least expect it.

The second way we found brainstorming to be useful was when there was something concrete to talk about. For example, “How can we improve this?” as opposed to “Hey let's come up with something arbitrary!” Given a half-formed game idea, for instance, it was moderately helpful to run it by the rest of the group to flesh it out. Everyone is a better critic than a creator, right?

Gather Concept Art and Music to Create an Emotional Target

As an alternative to brainstorming, we found that gathering art and music with some personal significance was particularly fruitful. People have commented that many of the games like “Gravity Head” or “On a Rainy Day” create a strong mood and have strong emotional appeal. It's no accident. In these and many other cases, the soundtrack and initial art created a combined feeling that drove much of the gameplay decisions, story, and final art.

Mr. Gabler: “The idea behind “Tower of Goo” came up while I was listening to (for some reason) the opening to Astor Piazzolla's “Tango Apasionado” after walking home, and had this drizzly vision of a town at sunset where everyone was leaving their houses, carrying out chairs, tables, and anything they could to build a giant tower in the center of their city. I didn't know why exactly, but they wanted to climb up and up and up - but they weren't very good civil engineers so you had to help them. The final prototype ended up a little more cheery, and I replaced the final music with Piazzolla's more upbeat “Libertango”, but here's a case where an initial emotional target basically wrote the entire game.”

Tango music and little men climbing higher and higher...

Simulate in Your Head – Pre-Prototype the Prototype

It's really easy! All you have to do is imagine your game audience saying, “Wow!” And then just work backward and fill in the blanks. What's making them enjoy your game? What emotion are they feeling? What is happening in the game to make them feel that way?

For each of our most successful games, it was never a surprise when they ended up being fun to play – in the best cases, we knew before touching a line of code that the idea was solid, because we had run a simulation of the game as a little thought experiment beforehand. The reverse is also true. There was no game that accidentally or unexpectedly became successful. We always knew ahead of time. (Unfortunately this didn't keep us from pursuing half-baked ideas.)

Simulating in your head also makes the development of the final prototype really easy. Since you will know exactly what you will be making, you won't waste time making expensive trial and error “design decisions” by noodling around in code.

One team member admits: “It wasn't unusual to blow the first 3 or 4 days of the week just fooling around watching O-Zone music videos for “inspiration” or propped upside down in a bean bag listening to music and filling my head with blood occasionally running some crappy brain simulations. Finally Thursday or Friday would roll around and I'd panic because I still had no idea what to turn in for Monday, so I'd take the strongest of the ideas and tweak it based on whatever the obsession of the week was until it felt like a fun game, then stay awake for the next few days typing it all into a computer and drawing beautiful pictures. For me, (and I think all of us) the days spent in “pre-production” were unquestionably more valuable that the days spent in actual development.”

An early paper prototype for "On a Rainy Day" - helpful while simulating in your head.

3. Development: Nobody Knows How You Made it, and Nobody Cares

Once you come up with a great idea, here are some tricks to whip up a little demo in no time!

Build the Toy First

Start with the core mechanic. Whether spring systems, swarm behavior, gravity, etc, it never took more than a few hours to get the basic theme up and running. This “toy” should be the core mechanic of the game minus any goals or decisions. There is no win or lose state, just a fun thing to play with.

Mr. Gabler: “With “Super Tummy Bubble”, the “toy” was just a bunch of bubbles suspended in a little container. After playing with the toy and flinging bubbles around for a while, I got it tuned to a point where sticking my fingers in bubbles felt really satisfying, so it was time to slap on some gameplay. Gameplay features in this case were bubbles of different parasite types, a concept of “popping”, a concept of “chains”, score counters, etc.”

"Super Tummy Bubble" - Toy (left) vs. Final Prototype (right).

If You Can Get Away With it, Fake it

This is arguably one of the most important lessons of the project. Often the “correct” solution is not the best solution. Strategically faking it will save you time and money; it will make your game faster, and your teeth whiter. Fake it liberally and often! Don't set up complicated lighting and shadowing when a simple drop shadow and baked textures will be just as effective ("Darwin Hill"). Don't set up a complicated pattern recognition system for analyzing a user's drawings when you can fudge it with the same effect ("Suburban Brawl"). Don't draw splines or create your own vector art library when quickie stretched bitmaps give same effect faster and easier ("Tower of Goo"). This rule is also a fantastic general lesson for life, we have found. Slackers, take note.

Get daily news, dev blogs, and stories from Game Developer straight to your inbox

Latest Jobs

Sucker Punch Productions

Bellevue, Washington
Combat Designer

Xbox Graphics

Redmond, Washington
Senior Software Engineer: GPU Compilers

Insomniac Games

Burbank, California
Systems Designer

Deep Silver Volition

Champaign, Illinois
Senior Environment Artist
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more