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
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.
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
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.
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?"
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!
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
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
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.
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.”
Enforce Short Development Cycles (More Time != More Quality)
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.
Constrain Creativity to Make You Want it Even More
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.
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.
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.
of the themes we explored were: “gravity”, “springs”, “evolution”,
“sound”, “predator and prey”, “addictive games”, “drawing”,
“exponential growth”, “vegetation”, “balance”, and a few others
Gather a Kickass Team and an Objective Advisor – Mindset is as Important as Talent
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.
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.”
Develop in Parallel for Maximum Splatter
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:
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!
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.
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
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: