Prototyping: You’re (Probably) Doing It Wrong

You’re not alone, I was also doing prototyping wrong until a few years ago. There are probably many different ways of prototyping games correctly, and maybe your way works great for you. In that case, a more accurate title for this post could have been “Prototyping: I Was Doing It Wrong”.

A good game prototype is something fast/cheap that allows you to answer a specific question about your game. The key points there are fast/cheap and specific question. It’s not a level of a game, it’s not a “vertical slice”, and it’s certainly not an engine for the game.

Chris Hecker and Chaim Gingold gave one of the best presentations on the subject of rapid prototyping. It was hugely influential for me, and it made me re-think the way I do prototypes. If you get a chance, find the audio for the presentation, it’s definitely worth it.

Mistake #1: Going With The First Idea

proto_2.jpgEvery company I’ve ever worked at has done this mistake. The team hashes out a bunch of ideas, and somehow they pick one (or create it by committee). Maybe they’ll create a prototype to show something about the game, or maybe they’ll dive straight and start writing a design document and developing technology. If you’re lucky, or you have an extremely talented game director, the game that comes out of the other end might be fantastic. In most cases, it’s just a so-so idea and the team only realizes it when the first level comes together, years later, at around alpha time. At this point the choice is canning a project after spending millions of dollars, or patching it up to try to salvage something. Neither idea is particularly appealing.

Creating a prototype for a game you know you’ve already committed to is pointless. It’s nothing more than an exercise to keep management happy. Frankly, I even made that same mistake at Power of Two, when we prototyped the game idea we had in mind and immediately moved on into pre-production (and yes, later we realized we had to change things to make it more interesting).

What I do now is to force myself to prototype several of my top ideas before committing to any one project. I have a page (actually, a wiki page) with every game idea or thought I have. That page has way over a hundred entries, and every so often I cull and reorganize it, bringing up the most promising ideas towards the top. Whenever I’m in prototyping mode, I start grabbing them from the top and prototype them.

proto_1.jpgWith a good prototype it’s easy to see if an idea is worthwhile. If it’s not, I discard it and move on to the next one. If it has potential but it’s just so-so, I either choose to continue just a bit longer (to ask another, better question) or I shelve it back in the list of potential game ideas. Maybe at some later time, things might click in or I might have a new inspiration and the game idea might become a lot stronger.

Also, often times, after doing one prototype and deciding against it, a new idea will come up. Usually a variation on the original prototype or something directly sparked from it, so I’ll find myself jumping to that idea instead of one of the ones I had saved in my list.

Eventually, one idea will click and you’ll know that’s “the one”. If you’re lucky (or unlucky) enough to have that happen with the first one you try, I still recommend doing a few more prototypes. If nothing else, you might be prototyping future projects, so it’s certainly not wasted time. For my current project, I went through eight prototypes before finding “the one” (several of them were a collaboration with Miguel). Eight to ten prototypes per project is roughly what I’m hearing from other indies with this approach.

Mistake #2: Not having a good question

A good prototype attempts to answer a question about the game. But not all questions are created equal. First of all, a question needs to be relevant and crucial to the project. “Can I have a pretty settings screen?” isn’t a particularly difficult question to answer, so it doesn’t deserve its own prototype. “Can I control little planes by drawing smooth lines on the screen?” is a much bigger unknown (before Flight Control anyway, today you can just download the game and immediately answer yes).

proto_3.jpgAlso, a good question is concise and can be answered in a fairly unambiguous way. “Is this game awesome?” isn’t a good question because “awesome” is very vague. A better question might be “Can I come up with a tilt control scheme that is responsive and feels good?”. Feels good is a very subjective question, but it’s concrete enough that people can answer that pretty easily after playing your prototype for a bit.

Even though most questions are about game design, they can also be about any other aspect of the game. Maybe you’re doing something tricky with technology and you want to make sure it’s feasible. If not, there’s no point in even starting. It’s more uncommon to think of prototyping art, but it’s also a very valid approach: “Will this art style allow foreground objects to stand out enough?” “Will the lighting approach allow the player to see important features in enough detail?”. Often you can do these art “prototypes” directly in Photoshop or a 3D modeling package.

In the case of Flower Garden, the main unknown was the technology behind the procedural flowers. So I created a prototype to answer the question “Can I create compelling procedural flowers that grow in real-time and the user can interact with them?”. The prototype had several parts to answer that question: the geometry generation, the animation, the simulation, and the rendering. There isn’t anything else particularly ground-breaking in the rest of the Flower Garden code, so as soon as I was able to answer “yes” to that question, I green-lighted the project and started production on it.

For larger projects, you might have several major, outstanding questions, so you’ll need to do multiple prototypes. Unless they’re very closely related, I find it easier to keep them separate instead of building on top of the same prototype.

Without a good question, it’s too easy for a prototype to go on for a long time. You feel you’re making progress because new things are added, but you have no real sense of when to stop or when it’s done. You really have to focus on the question, ignore everything else, and be merciless in your approach.

Mistake #3: Taking too long

proto_4.jpgOne of the key concepts in the definition of a prototype was that it has to be fast/cheap (which are two sides of the same coin). What’s fast enough? It depends on the length of the project itself. It’s not the same thing to do a prototype for a two-month iPhone game, than for a three-year console game. Also, a larger, more expensive project probably has more complex questions to answer with a prototype than a simple iPhone game.

In my case, I shoot for one-day prototypes. If you already have the tech to create games with, one day allows you to focus 100% on answering the question. By the end of the day, or even before, I have a pretty good idea how the game is going to work out. My shortest prototype ever was a 2-hour one. I thought it was going to be longer, but I managed to complete everything to answer the question in two hours (for the record, I didn’t can that idea, but I shelved it for a possible future project).

Game jams are a great way to get over the mental block of doing quick prototypes. There you are focused on making the game on a very short time, surrounded by people trying to do the same thing. I can’t think of a more fun way to prototype than that!

Also, think beyond programming. Is there a faster way you can answer the prototype question? Maybe you can use the modding capabilities of an existing game, or even do a mockup with paper moving pieces around. Don’t fall in the trap of thinking you have to code a prototype if something simpler and faster will do.

If you find that a day is not enough, take a step back and really ask yourself why you need more time. Were you getting side-tracked on things that were irrelevant to the prototype (menus, tech, art, etc)? Are you asking a question that the prototype can’t answer? Do you have the game idea clearly defined in your head?

Mistake #4: Building a system, not a game

proto_5.jpgWhen you’re making a prototype, if you ever find yourself working on something that isn’t directly moving your forward, stop right there. As programmers, we have a tendency to try to generalize our code, and make it elegant and be able to handle every situation. We find that an itch terribly hard not scratch, but we need to learn how. It took me many years to realize that it’s not about the code, it’s about the game you ship in the end.

Don’t write an elegant game component system, skip the editor completely and hardwire the state in code, avoid the data-driven, self-parsing, XML craziness, and just code the damned thing.

When you’re prototyping, it’s a race to answer the main prototype question. Everything is expendable. Don’t even worry about memory leaks, hardwired numbers, or how you load resources. Just get stuff on the screen as quickly as you can.

And don’t ever, ever, use the argument “if we take some extra time and do this the right way, we can reuse it in the game”. EVER.


This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

  • http://twitoaster.com/country-us/snappytouch/ SnappyTouch

    New blog post: Prototyping: You’re (Probably) Doing It Wrong http://gamesfromwithin.com/prototyping-y… #idevblogaday

    • martinpi

      @SnappyTouch I”ll put your advices to use tomorrow. I’ve been teaching exactly that on universities, but keep forgetting in own projects.

  • Pingback: Tweets that mention Games from Within | Prototyping: You’re (Probably) Doing It Wrong -- Topsy.com

  • http://www.sunetos.com Doug Sjoquist

    Great tips Noel.

    I finally came pretty close to doing this when prototyping earlier this month: hardcoded magic numbers, resource hogging image loading schemes, kluges & hacks — I had it all! But, I got far enough in the hours I had to answer my first question.

    Now I need to resist the siren song of “one part is working, just build on that” and build other standalone prototypes to answer some different questions.

    Thanks for the timely reminder.

    Doug

  • http://www.quebarium.com Frederic Tessier

    Great article about prototyping Noel!

    I am also glad to see that with the new rapid prototyping we want to implement for our projects that we should stay clear of mistake #1, #3 and #4, but we might have to review our idea a little bit as it might not cover mistake #2 properly.

    Ohhh for us our biggest mistake was definitely the #3, it always took us too long to build a prototype to realize that we should have went different ways, then do another one (for avoiding the mistake #1) which then bring us to about a years later to finally decide to shelve the project :-( (realizing the scope will be too big to accomplish, the idea is not novel anymore, the platform have move on, etc…).

    Thanks for the reminder, hopefully we will do our best to avoid those problems in the future.

  • Bob Lauer

    Noel, a few posts ago you said you’d eventually write about what happened to PowerOfTwo – was it that you were not happy with the game you got? Would more prototyping have saved PowerOfTwo? Or were there any other issues worth mentioning?

  • Emil

    “Don’t write an elegant game component system, skip the editor completely and hardwire the state in code, avoid the data-driven, self-parsing, XML craziness, and just code the damned thing.”

    Especially liked this part. Endless abstractions are so common these days, but they rarely (if ever) lead to something good.

  • Jafar

    Great post Noel,
    Would you mind telling us a bit more about “It took me many years to realize that it’s not about the code, it’s about the game you ship in the end” and how did you realize this? Or even better write another article about this? :)

  • http://www.endloop.ca Garry Seto

    Great tips Noel!

    I definitely fall into these kinds of mistakes far too often.. thanks for helping me identify them and, hopefully, allow me to correct them. :)

  • http://games.greggman.com Gregg Tavares

    Taking the opposite approach….while I agree with much of this article I’ve seen this approach kill many many teams. The typical scenario goes something like this:

    *) Programmers choose between rapid prototype and using a real engine (Unreal, Source, Crytek, engine from last project, engine from other team in same company.)

    *) Programmers choose rapid prototype because they fully understand D3D or GL and don’t know thing one about whatever engine was offered.

    *) Programmers get stuff on screen in hours or days.

    *) Immediately the rest of the team, specifically the producers think the game is further along than it actually is. There is huge pressure to start production.

    *) The product takes 10x longer to make than it should because no time was given to making a real pipeline. All the hundreds of man hours in tools from those existing engines have effectively been discarded. The prototype has too much momentum to do it right. It has hack upon hack to get data in and man years are spent hastily hacking together new tools in an effort to not completely suck for the artist and designers.

    The solution for me would be to have the engine and prototype using it. I’m sure if you learn Unity or Unreal or some other engine you can prototype games in them very quickly, possibly quicker than you could without them once you know them well. But you have to invest the time up front to learn them.

  • Pingback: Let’s do an iPhone game

  • Pingback: iOS development highlights: August 2010 at Ole Begemann: iOS Development

  • Pingback: Parade of Rain » Blog Archive » Getting Into Prototyping Mode…