This morning we started with a session called How to Prototype a Game in Under 7 Days. The two presenters, Kyle and Kyle, shared lessons they’d learned while working on the experimental gameplay project from Carnegie Melon University. They also showed some of the games that came out of the project. There were lessons I’d heard and some that I didn’t expect.

In the Experimental Game Play project, participants followed 3 rules:

  1. The game must be made in less than seven days.
  2. The development team for each game has a size of one. One person does concept, design, programming, art, and sound (that’s one person for all those features, not one each).
  3. The game would be built to include a previously ageed-upon theme. There were many sessions for the project over the year and each session had a theme that participants must include. Examples of themes were things like gravity or springs.

The lessons learned from the experimental gameplay project explain a lot about rapid prototyping. The presenters were expressive and their ability helped get the ideas across very well, but I’ll try to communicate the jist of it here along with m commentary.

Rapid is a State of Mind
Embrace the possibilty of failure. Some games are bound to fail, not every idea will be a winner. Take risks and be ready for the inevitible failure.

Enforce Short Development Cycles
As the end of the development cycle approaches, there’s a huge temptation to polish the game and extend the development cycle. There’s a diminishing return on time spent that pushes the time limit out. As Kyle said “more slop time means more slop.”

Develop in Parallel
The team worked together at the start of each game cycle and at the end for feedback, but in the long stretch of development in the middle, they found that it was better for each person to just work alone. Working together resulted in too much distraction. Working in parallel meant mitigating risk since there are many people working on different ideas instead of everyone focusing on a single idea. Parallel development also allowed for greater exploration of the theme for a given session. Parallel development adds a dynamic of cometition that can be healthy to keep people motivated throughout the time allowed for the prototype.

Creativity & the Myth of Brainstorming
There was a great analogy involving the X-Men and a magic key that will one day save my ass from a force field on a spaceship, but I know I couldn’t relay that effectively here. In the Experimental Gameplay Project, they tried many formal methods for brainstorming and had no success. Creativity can’t be scheduled. I have to agree with them wholeheartedly here. Brainstorming, as they described it, with an open-ended goal like “make a game” gets you nowhere slowly. I’ve said before that it’s easier to criticize something that’s been built than it is to actually build something. They came to the conclusion that it’s easier to be creative once you have some constraints, hence the idea of a theme to build games around. I think that’s a great way to get people started on the path of building ideas that can become concrete results.

Nobody Knows How You Made it and Nobody Cares
If you can get away with it, fake it. If you can do 2d that looks like 3d, then use it. If you just need vague shadow blobs, then use those instead of rendering detailed shadows. They gave a couple of examples that show examples of things they faked without losing any of the user experience. Really anything that’s done in 3D is displayed in 2D in the end anyhow. Do what you need to do to make it work.

Build the Toy First
Spend a couple hours building something that demonstrates the basics of the game. Then play with it and find out if the concept is good.

Heavy Theming Will Not Salvage Bad Design
You can’t polish a turd. Nuff said.

Learn to Cut Your Losses
People become attached to their ideas and will get drawn in to technical problems. Developers do this all the time and get sucked in to fighting problems they don’t really need to fight. If you recognize your idea was bad then you should drop it and move on. If you can get over the love you have for your idea then you can recognize when they’re no good.

Other recent posts in these categories: