I happen to fall into the artist-designer skill set, so I often find myself trying to prototype ideas on teams rich with programmers. As such, I'm always looking for better game development techniques that work well for this particular team mix.
Here is a very lightweight prototyping process using Post-it notes that I quite enjoy.
- Initial idea: I sit down with an available programmer (and artist/UI designer depending on the system) and we chat about how to test out a new bit of gameplay. Usually this is an idea that has been bubbling about since the night or week before.
- Post-it note design: I jot down a quick bulleted list summarizing our discussion on a single post-it note. We go over it one last time so there everything is clear. The list isn't very detailed. Mostly it serves as something to jog our memories if we forget what we were talking about.
- Build it: The programmer and artist go off and build the items on the list. It might take 2 hours or two days. They are encouraged to solve problems creatively and they can always just give me a shout if something doesn't make sense.
- Play test: When most of the items on the Post-it note are playable, I get called over and we play test it the experiment together. If the results are comprehensible by mere humans, we pull in some play testers for 3-4 minutes to observe some real players interacting with the mechanic for the first time.
- Review: Afterwards, we discuss our observations and write up another Post-it note worth of improvements.
- Repeat or Stop?: The process repeats until we run out of time or give up. Sometimes we give ourselves a day per experiment, sometimes two days. In the land of Scrum, we treat the experiment like a time boxed task.
- Rate: At the end, the gameplay experiment is rated according the scale below.
- Save: The code is saved off, a few choice notes are recorded in a doc containing our 'list of experiments' and we move on. Bits of code, even from failed prototypes, are often reused in future gameplay experiments.
The rating system is delightfully crude. The goal is to triage experiments quickly.
- "A": These experiments were obviously fun. Players laughed, smiled and generally exhibited the emotions we were looking for. If in doubt, ask "Was this fun? How so?"
- "B": These experiments showed a hint of fun if you knew what you were looking for. However, it is going to take more effort to expose the fun in a manner that is visible to the players.
- "C": There wasn't any fun. The experiment fails.
One of my favorite aspects of this method is that you end up with a mini-portfolio of game design ideas. Instead of putting all the design risk in a project on one or two unproven mechanic, the team now has a half dozen or more proven bits of fun to build upon. If some don't fit into the game or get abandoned for other reasons, that's alright. You can afford to lose a few and the end product will still be fun. Think of it as designing from a position of plenty.
Contrast this with a prescriptive 'design doc' approach where you are forced to pick, without much evidence, a main mechanics for production. Even for the most experienced designer, 50% to 80% of your 'educated' selections are going to be complete dogs. Every unproven mechanic you polish ends up being a massive drain on your budget and your reputation as a designer. You might hear gentle comments like, "We spent 3 months of dev time on this lump of an idea and it isn't fun?"
It doesn't take very many expensive failures for the project's perceived 'design risk' to blossom to the point where conservative minds seek to kill the project. I think of this as designing from a position of sudden death.
Some basic observations
Here's a quick list of things I've observed when prototyping.
- Failed experiments happen a lot. Don't be surprised if C-rated experiments occur 50% to 80% of the time. Everyone on the team has to be aware that not every experiment is going to be a success, but the learning process is still worthwhile.
- Designing on your feet is a critical skill: Each consultation and analysis might last only 10 to 20 minutes and you need to leave folks with that all important sticky note filled with impactful, yet inexpensive changes. It pays to have lots of ideas and a deep understanding of game mechanics so you can quickly pull together a list of incisive comments. If you can't, you likely are not suited to be performing the designer role.
- Listening matters. The designer doesn't need to come up with all the solutions. Everyone on the team is bright and has great ideas. As a designer, your role is to herd all ideas (yours and others) into something that serves the next step in the prototype.
- You need programmers: If there aren't programmers dedicated to prototyping, the prototyping isn't going to happen. You can drop down to paper prototyping, but it usually doesn't prove out many types of mechanics (especially ones involving timing and interfaces.)
These are some notes that are a bit geekier, but can save you large amounts of pain.
- Meta game mechanics are harder to prototype: The systems that link together the various gameplay experiments are harder to playtest. They operate on longer time spans (hours instead of minutes) and often require that the core gameplay is already fun.
- Build a meta-game architecture that allows for loose coupling of gameplay experiments: Most successful games have an architecture that allows the team to plug in new bits of fun as they are found. The linear 'level-story-level' pattern used by most FPS is one example. The 'hub with many sub levels" used by Mario 64 is another. Any of these allow you to plug in a new experiment independently of the other gameplay experiments. If you don't have a modular architecture, you run into situations where a fun new system breaks many of the other bits of fun you've already discovered.
- Integrating tightly coupled gameplay experiments is a pain: If I independently find a fun new type of weapon and an interesting enemy AI, the combination of the two is often a non-trivial issue. The new weapon many work with an old AI, but be completely useless with the new one. Integration yields a whole new set of experiments. Plan for time to rediscover the fun all over again.
There are some interesting benefits to the Post-it note design method:
- Scales nicely to large prototyping efforts: One designer can serve multiple programmers. This works nicely on teams where there are more programmers than designers and you need to get a lot of prototyping done quickly.
- Failing quickly is fun and educational. You learn a lot with each failure and can move onto the next experiment with a much better idea of what doesn't work.
- Provides a quick death for bad pet ideas. It is much harder to resurrect pet ideas when you have concrete, playable proof that it won't work. Finding out early which one of my favorite ideas is idiotic saves me a lot of political pain.
- Fun prototypes are quite convincing: A fun, playable crazy idea works a lot better for winning over other team members than any amount of hand waving or documentation.
- An easier team to assemble: Finding a competent game designer and a competent programmer can often be easier than finding a competent programmer-designer. Well developed hybrid skill sets are very valuable, but can be quite rare. A side benefit of having a team is that you end up cross training your designers and programmers. You create designers who can speak to programmers and programmers who can riff on some of the design.
One often hears the negative comment that game designs are a dime-a-dozen. And in a waterfall design process, an incessant stream of ideas is indeed a problem. If you attempt to squeeze all those ideas into a typical waterfall development process, you end up with an immense amount of waste. Each designs need documentation, concepting, implementation, testing and bug fixes. In response, project owners will often ask for just one good idea.
There is another path. A lightweight prototyping method takes your flurry of crazy ideas and converts them at moderate cost into a well sorted portfolio of working designs. All those ideas are not, in fact, worthless or wasteful; they are the essential fuel that feeds a good prototyping process. Each idea either teaches you something or provides you with a success.
The way to make the process work without getting gunked up is to make prototyping incredibly lightweight. Other than our focused conversations, I spend my time on a total of two design docs: The first is the brief list of rated prototypes and the second is a set of discardable, temporary Post-it notes. Design waste in the form of unnecessary artifacts is minimal. Most of the 'programming waste' is better classified as low cost learning.
Those wild flocks of churning, swirling ideas end up not being worthless at all. They simply need to be funneled into the project with the right process for their value to be realized.
The "Post-it note design process" has likely been reinvented in one form or another hundreds of times across the history of game development. It is so basic that it feels odd to even write it up in any sort of formal fashion.
If you have a designer and a programmer, give it a shot. It is certainly a good functional alternative to the popular process of sticking a lone programmer-designer in a room and asking them to 'find the fun'. Both can produce great games. Pick the one that works best for your current team composition.
This process does have an cost since you need to devote at least two people to finding the fun instead of putting all decisions on the head of the designer. However, the end result is well worth it. After all, it is far smarter to spend team time uncovering a portfolio of the right mechanics than it is to 'save your programmers' so they can be off running really fast in the wrong direction.
In the end it really isn't about programmers, designers, design documents or features. It is about the team working together to make the right product. Everything else is just ego and waste. And for some reason, it is quite difficult to invest much ego or waste in a little disposable Post-it note.
Post-it note fanboy