Rules for Prototyping Original Games

Recently I've tried to help some experienced game developers prototype their new game ideas. I wanted to be open to new ways of working, so didn't push hard for them to use the methods that have worked for me. But after months of watching them struggle, I've come to believe even more strongly in a few basic rules when prototyping new original games.

Two people
It's critical that your team is tiny. I've found that 2 is best, but I think 3 could work. Usually this is a programmer and a designer (or designer-programmer). Beyond that and you're playing with fire. Just resist the urge and don't do it. When you're moving and pivoting quickly, the communication overhead with more than 3 people is just deadly. Don't even allow occasional part-time contributors - folks that are prettying things up (more below).

Two weeks
If it sounds like you couldn't prototype anything fun in two weeks, you're probably right. But your goal isn't fun - more below. By keeping the duration short, you're absolutely forcing yourselves to move fast and stay low-fidelity. You're making a "sketch" of a game, not a game.

With this time period, you probably don't even have a full day to plan anything: you just have to start building. There's no time for engine choice either - just use what you're fastest with. Any time a meeting or discussion threatens your progress, you're forced to just make a quick decision instead. There's no time! And that's a feature, not a bug. A helpful reframe here is that it doesn't matter how crappy it is, because you only had two weeks. You can build another prototype after.

This is probably the hardest pill to swallow, but I think it's critical. Absolutely everything will be placeholder and stapled together. You'll have very few systems, everything will be hard-coded. Forget about anything procedural - build a single level by hand.

Exciting, not fun
I never understood why so many people talk about using a prototype to answer a question. To me, the only question I really wanted to answer is "Is this prototype exciting enough to keep going?". The goal of the prototype isn't to make something fun: it's to generate excitement. If players immediately have ideas like "this would be so much better if we added X" or "...and then we could add Y!" or "...this sucks but just imagine when there's art!" then you're on the right track.

It's not going to be fun when you're done. That's OK. But if you have palpable excitement, you're on the right track. Sometimes this excitement is only my own or the among the two-person team, but it's so strong that it eventually gets a life of its own (this happened with Subnautica and Project M).

No polish
Don't put any time into visuals, smoothness, frame-rate, beauty or aesthetics of any kind. Even well-intentioned artists who want to replace your placeholder art with nicer art can ultimately hurt your efforts. Why?

When you have something polished, or more polished then the rest of your piece of crap, inertia sets in. Polish creates an insidious, invisible force: you suddenly don't want to change theme, change that art or make big experiments because it's the nicest part of the prototype. This is deadly. The time to make big theme or genre changes is in subsequent prototypes. When your whole experience is white cubes and red capsules, that's a heck of a lot easier.

Make it crappy
So set out to make something crappy. Yes, crappy! This is the one time in a game developer's career where you can, and must, make something crappy. You are, after all, creating a sketch of an entire game in two weeks with two people. You may want to make big changes to it immediately after - it must be crappy. Anything else is wasteful and counter-productive.

Crappiness is empowering. You can move fast, running circles around other lethargic teams who are obsessed with quality. You might be creating a new genre here! It will give you momentum like you would never believe.

Strive for crappiness. It will be anyway. But it could be incredibly exciting.

"Ship" it
Set a firm deadline, and "ship" your prototype. Make sure the deadline is visible, and commit to playing your prototype with a few people. You can do this in the same place or through screen-sharing, but it's important to do it together. Seeing people play, struggle with and get excited about your prototype is extremely energizing. You don't really even have to ask them what they think - you'll know if there's any excitement there without much effort.

Whether there is or isn't, you can congratulate yourself on accomplishing something incredible: building the bones of a game in two weeks. Just think about how much you've learned and how much easier this will be the next time around? Speaking of which...

Make another prototype
You've played your prototype with your team mate and a few other people. You've watched their faces and you all know what horrible bugs are in there. It's SO CRAPPY. Is there a "glimmer of fun" in there somewhere? Not real fun, but the possibility of fun? Even in such a sorry state, can you feel excitement?

If you think so, go ahead and make another prototype. You can spend another 2 weeks on this one, or throw it away (which is easy because it's a stinking pile) and use what you've learned to do a zoom-in pivot on the most promising aspect. Or decide that it's not working and try something totally different - which also doesn't sting much because you only "wasted" two weeks (is it waste if it led you somewhere amazing?)

Throw it away
If and when you've decided that you're onto something and want to build this game for real, throw it away. Your prototypes were made under duress and designed to be crappy. As tempting as it can be, don't continue building on top. We did this for Subnautica (because we didn't have the time to spare) and it resulted in pop-in and years of extra work. We never took a step back to evaluate technology before building and it really bit us.

Unless you want technical problems and extended development time, throw away your prototypes, and keep the learning. You'll build it so much faster and better if you do this.

Conclusion
Subnautica started as this:

...and ended up as this:

I hope this helps quell your rising fears that making something rough and fast can create something wonderful in the end. I really believe that the rules outlined here are the only constants in making something original and great.

Note  that I'm calling these rules instead of guidelines, because I believe in them so strongly. If you're struggling (as we all are, always), I hope this gives you some firm ground to stand on.

And please send a link to this article when someone tells you you just need a month and a modeler...