How to Prototype a Game in Under 7 Days

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.

	"Darwin Hill," "Suburban Brawl," "Tower of Goo" - all faked, and nobody noticed. Shhh!

Cut Your Losses and "Learn When to Shoot Your Baby in the Crib"

At the beginning of the project there was a desire to salvage everything – a little more time and effort and surely a crappy game would become a work of genius! One such doomed prototype began as a beautiful spring system that squished and stretched and made you want to grab it and pull it all over the place, but it just wasn't become a compelling game. The original spring system mechanic took just a few hours to create, but then it flared and consumed an additional wasted week of coding and re-coding in a sad attempt to force the mechanic into becoming a game.

It's important to quickly recognize dead-end game ideas, cut your losses and move on. As we found, spontaneity is more valuable than time spent trying to salvage existing code. You can always come back if lighting strikes at a later time.

Mr. Kucic: “My “Potato” ended up being a perfectly simulated soft body system built in Flash. The only problem was that it was in no way fun. It caused more headaches than death metal, wasted a week, and it didn't even really move. You've got to know when to hold ‘em and know when to fold ‘em.”

	"Matt's Potato" - bask in its glory.

Heavy Theming Will Not Salvage Bad Design (or "You Can't Polish a Turd")

We found that game players are smarter than you think, and they can tell when you're pulling a fast one on them. If the gameplay is horrible, there is no recovery - all the art, music, and product tie-ins in the world won't make it a great game. Like taking a stale gameplay mechanic and slapping the latest 3D animated movie characters on it, nobody will be fooled.

Mr. Gray: “With “Spin to Win”, the ‘gameplay' was to rotate your mouse to spin multiple circles – literally disc spinning. To hide the fact that it wasn't fun, I heavily themed the game with a '60s Bewitched art style and music. But no matter how much I polished the game, it still wouldn't shine. Despite all the extra love, it quickly became one of the site's most hated games.”

	"Spin to Win" - all dressed up with nowhere to go.

But Overall Aesthetic Matters! Apply a Healthy Spread of Art, Sound, and Music

This is actually counter to one of our original hypotheses. We didn't think art or sound would make any difference at all, but we were wrong! Playing with a well-polished game actually feels better in your hands than playing the exact same code but with careless art and poor sound. It is important to make the following distinction though – polishing the aesthetic (as in the above section) will still not salvage bad design, but it does have the power to make a good game even more playable. This does not mean that you need fancy graphics or surround sound. It does mean that you can benefit from pulling everything together into a tight cohesive compositional package. Remember, even “crappy” can be a tight winning aesthetic if you frame it the right way.

	An unrealeased prototype - art doesn't have to be complicated to feel compositionally solid

Nobody Cares About Your Great Engineering

Again, it's worth noting that a great engineer does not necessarily make a great prototyper. “Correct” or “reusable” solutions are often not what we look for in quick throwaway code. For every problem, you should be able to come up with a large handful of solutions and be prepared to pick the one that gets the job done – fast. The end user will never see your great engineering, and they don't care.

Mr. Shodhan: “By over-engineering, it's easy to end up with generic tools or technology demos that never translate into something playable. This can be likened to a rock star executing a technically brilliant but entirely self-indulgent guitar solo that leaves the audience yawning! For the “evolution” round, I made a program with subdivision surfaces and a cell shaded look for evolving 3D models by cross breeding ancestry trees. There was a lot of cool technology, but it had absolutely no gameplay!”

	"Evolution Trees" - all that technology doesn't add up to fun.