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: