What's the Point of Prototyping?

On the last episode of Game Dev 101 - my series about the indie game production pipeline - I shared a whole bunch of tips for coming up with ideas for games. So, now you know what sort of game you want to make - it's time to start building it, right? You know, make the art, write the code, hire the composer... Wrong! In fact, rushing straight into production is one of the biggest mistakes that new game developers can make.

But check this out: before studio MDHR drew thousands of hand drawn animation frames for Cuphead, it made a version that looked like this... And before Nintendo built the enormous open world of Hyrule for Breath of the Wild, it made a simple top-down 2D version, using sprites borrowed from Zelda 1. These are prototypes - scrappy, sample versions of games, built to test the idea before starting development. It's the game dev equivalent of building a bridge...

by first making it out of wood, string, and zip ties. Now you might be thinking - oh man, I have to make a whole other game, before I get to make the game itself? That seems like a lot of work! What's the point of doing a prototype, anyway? And, well, that's what this video is all about. And to help me out, I chatted to Luke Muscat - the superstar designer behind games like Fruit Ninja, Jetpack Joyride, and Feed the Deep - to offer some expert advice.

LUKE MUSCAT: I have made literally hundreds of prototypes at this point in my career and I would say like at least half of them weren't fun at all. So, this is Game Dev 101, and this is episode two: what's the point of prototyping? Okay, so basically... a prototype lets you answer a question. And perhaps the most important question of all is...

"is this game fun"? Because, as it turns out, our brains are terrible video game simulators. Almost any idea can sound good in our head. But it's only when you actually get to play something that you can see whether or not it works. That's why Nintendo designers have the mantra "make before we talk". Whether its splatting ink in Splatoon or making vehicles in Tears of the Kingdom or coming up with wonder transformations in Mario, they always make something, to test and prove that the game will be fun, before pitching the idea to the higher ups.

LUKE MUSCAT: It's just so hard to conceptualise whether things are going to work or not once it becomes a complete system. We can't know whether something's going to be fun without actually playing it and experiencing it, even when we think we have a pretty good imagination for that. There's just too many nuances, too many things that are unexpected. A relatively recent example for me was: I had this idea for like a one-button shooting game and the idea was was like you would shoot like a Uzi and it would push you back at the same time so shooting became your locomotion and your attack.

And it is just really like not fun to move in a backwards position, like always getting pushed away from something didn't feel assertive in the way that a game about shooting heaps of people felt like it should be. That one's so simple, right? Like there's very little to it, but there is a feeling when playing it that just isn't right. But perhaps "fun" is a little restrictive. Because, in truth, a prototype can be used to test almost any aspect of the game.

So when Jonas Tyroller and co were making Thronefall, they certainly made plenty of different gameplay prototypes to see if it was fun - but they also made prototypes exclusively for testing different art styles and camera angles. You could even a prototype to test out the narrative. At Pixar, the studio will often make the entire film as a scrappy comic book animatic, with stand-in voices from the animators, to they see if the narrative makes sense.

And all before they ever make a single 3D model. Another question a prototype can help answer is...

"is this idea viable?" The act of making a prototype will give you a lot of insight into what it would be like to make the whole game, and give you a preview of how easy or difficult production is going to be. LUKE MUSCAT: I think puzzle games are a really good example. Like if you're prototyping a puzzle game, if it's really easy to make puzzles for the puzzle game, you know you're somewhere fertile. If it's really hard, it's like, well, okay, this is Clearly, going to be an uphill battle the whole way.

And as Jonas explained in the previous episode - you can make a pretty good guess for how long a project will take, based on how long the prototype takes to build. Like, I was working on a prototype for a game about running your own video rental store, where you'd decide how to stock the shelves and answer customer queries. But even that small sample took weeks of work - and showed me that this project would take much more time than I have to spare right now.

And, besides, a few months later, the game Tiny Bookshop launched which is basically the exact same thing but better. So, dodged a bullet there. And then the other important question a prototype can help answer is...

"will other people like it?" A prototype lets you share your vision with other people - but not as a pitch or a concept. But as something actually playable. Like, when Rare was trying to get Microsoft to green-light the pirate party game Sea of Thieves, the studio got Phil Spencer and co to play a scrappy prototype version of the game, and filmed their session - to prove the point that this game would lead to cooperation, conversation, and banter.

And so, ultimately, you can use a prototype to help figure out if this game is going to be a hit, once it comes out. For my roguelike spelling game Word Play I was able to build a simple version of the concept in just two days for a game jam - and then immediately got strong feedback that people liked the game and would play, and buy it, if there was a full version. That enthusiasm basically kept me going through the rest of the development.

And, I should say, it proved true - the game has already sold more than twice the number of copies as my previous game. But, of course, it can also go the other way. LUKE MUSCAT: I was working on a prototype called Luck of the Draw, which was Luke Be a Landlord meets Super Auto Pets, so, kind of like a roulette wheel, deck builder, versus mode. And when I was making that prototype, I'm like, this might be the smartest thing I've ever made.

This is such a, I can't wait for everyone to play this, and this is just gonna blow up. This is it, this is like THE game. And I released it, and no one cared. It was like complete crickets. And that was perfect. That's exactly what you want from a prototype. It gave me so much information and it told me this isn't it. Especially, this isn't it in a way that I thought it was. I would have gone and spent two years on that game based on me playing it.

But that's the thing - this failed prototype meant Luke was able to can that game after a few weeks of work - rather than after two years of development.

And so to complete that definition from before - a prototype lets you answer a question, quickly. Prototypes let you try out ideas, and then throw them away, before spending a lot of time and resources on them. A prototype lets you pivot, tweak, or completely nope out of a project before you've invested any actual resources into its creation. That's what makes prototypes so powerful, and so important. You want to learn whether your bridge design works now - not when you're halfway across the river.

So, if a prototype is about making something quickly... here are four tips for getting to the point, as fast as possible. Tip number one is... don't make it flashy. If you're making a gameplay prototype, avoid the temptation to make it look and sound good. Instead, use ugly programmer art made in Microsoft Paint. Use grey boxes and the default Unreal Engine dummy. Use sprites stolen from other games. Use free assets from the store.

You don't need music. You don't need UI. You don't need hyper extensible, clean, commented code. All of this stuff will slow you down and lead to wasted work. A prototype is designed to be disposable, after all, so don't spend time on stuff that's only going to be thrown away. And, besides, it can distract from the point of the prototype - it's hard to evaluate if a gameplay mechanic is fun if your playtesters are caught up on the story or the art style.

The only caveat here... is when it comes to game feel and juice. LUKE MUSCAT: The juice can be part of the fun, especially if it is a visceral game. And so if you're just like, no, we can't do any particle effects, we can't do any kind of feedback. It's completely possible that you're missing part of what's going to help it be fun. Fruit Ninja. Super good example of that. The prototype for that was really, really simple, but even that just had the splatters.

The prototype had some particles to at least be: yes, this is going to be like a viscerally satisfying experience. On the other hand, it's very easy to be like, well, okay, all I need to do is add these 20 things. And then the game will be fun. And so you spend like a month. Adding these like extra juice, like, and you what you're doing then is you're kind of bandaiding over the problem that the core game isn't fun. So, I think when you're creating a game, you kind of have to be the judge of that, but you have to judge it very honestly.

Tip number two is... use other mediums. You don't have to make your prototype in the same engine that you're planning to make the final game in. Thatgamecompany made a prototype of Journey in Macromedia Flash before ever making something that would run on a PlayStation 3. So use whatever tools let you get to the idea quickly. In fact - you don't need to make it in a game engine at all. Paper prototyping is the art of planning a game out on, well, paper.

When designing the puzzles for the game Storyteller, the developers created cardboard mock-ups of the assets to try out levels outside of the game. And when I was making Word Play and trying to imagine the gameplay loop, I used Scrabble tiles, and wrote the modifiers on a deck of hand-made cards to help inspire ideas for different upgrades. In fact, you can use all sorts of materials. For the upcoming detective game Locator, the developer played a prototype over Discord by sharing sketches of the current viewpoint and then asking his players what they'd choose to do next - kind of like running a D&D campaign to simulate the gameplay.

Meanwhile, Hideo Kojima planned out levels for Metal Gear Solid by making them out of Lego and then looking at them through a tiny camera. And for a complex simulation game with lots of interlocking systems, you could make that in a spreadsheet, or as a tabletop board game, before writing a single line of code. And while a prototype is technically something payable... it doesn't have to be. Ori and the Blind Forest started as simple animations, so the devs could play around with ideas for moves and attacks.

And Arnt Jensen used this cinematic concept video to hire the team and raise the funds to make Limbo.

Tip number three is to keep your prototypes small and specific. A prototype is not just a crap version of the whole game. It's not supposed to contain every system. Instead, it's a tiny sample of a specific feature, mechanic, or idea to prove its viability, before you go on to make it for real. So keep your prototypes small. And also keep them separated, with distinctly different project files for your gameplay, art, technical, and audio prototypes.

Keeping your prototypes small also allows you to make way more prototypes. Developer Dinosaur Polo Club made almost 20 different versions of Mini Motorways before entering production - with each one offering some new insight into the best way to make the game. More prototypes means more questions are answered, more decisions are made, and more risks are removed. And you might find that, through this fast and iterative process - you'll stumble upon new ideas that you couldn't have come up with just by brainstorming.

Sometimes, the process of writing code and fiddling with numbers and noodling in your engine can spark incredible ideas. I actually made a whole video about this phenomenon - so check out "The games that designed themselves" for more inspiration.

And then - tip number four is realising that you don't need to prototype everything. LUKE MUSCAT: I think there's a misconception that once you create the prototype you'll have all the answers. I think really it just gives you confidence that you're heading out into hopefully fertile soil. But that doesn't mean you know what You're gonna plant out there. You know, I would say most of my games, like, the prototypes are pretty thin, and then we just go, like, okay, I feel like we're heading out into a place that has good possibilities and we'll figure out the rest of it out there.

The prototype for Jetpack Joyride was Literally, just getting the machine gun jetpack in Monster Dash and kind of just removing the level, adding a roof, and then adding some obstacles. And we were like, okay, this is pretty fun. There's something here. But we never prototyped like. the challenge system, the mission system, you know, the vehicles all came after the prototype. Realistically, the meat of that game and what made it stand out came well after we were into production.

Because here's the thing. Making prototypes can be really fun. In fact, it's pretty addictive. You're constantly trying new things, starting new projects, and you're free from the constraints of good code and polished assets. Plus, there's always that nagging voice that says... what if the next prototype is even better? But if you never stop making prototypes, you won't make a video game. So an important skill you have to learn is knowing when enough is enough, and when it's time to actually start making the game.

Which means - these initial prototypes should help answer the biggest and most risky questions. Is this fun? Is it viable? Will people like it? But as for the hundreds of thousands of small questions you must answer as a game designer... well they can be figured out as you go along. But, the thing is - you can use prototypes for those questions too. Because prototyping is not some one-and-done process that must be buttoned up before production.

It's not something you leave behind once you start making the game for real. Prototyping is simply a cost-effective way to test an idea or answer a question. And so under that definition... well, it can be used at any point of the process. Want to add a new feature? Prototype it. Want to add a boss fight? Prototype it. Want to add a new level? Prototype it! Can't decide whether the game should have a double jump or a dash? Make quick prototypes for both, put them in front of playtesters, and go with the winner.

Thanks to Luke Muscat for his help on this one. Check him out on YouTube and watch him prototype an overly complicated golf game, a Vampire Survivors-like with cars, and more. Plus thanks to all the other designers who shared footage of their prototypes with me. But okay. We've picked a game idea. We've made a bunch of prototypes to prove that it's fun and viable. Now... we can actually make the game, right? Well, I'm sorry, but not quite yet.

Because we should take a moment to do something really important, often forgotten, and not at all fun or sexy... I'm talking about planning. So click here for a video about how to plan out your game's production.