prototype a video game

Prototyping a video game

“As long as it’s in your head, an idea is worthless.”

This is not a quote I’ve read or heard somewhere, but rather a synthesis of what I’ve learned on the subject of video game creation. At first, I found this reflection rather pessimistic, given that I’ve always had a head full of ideas. But as I dug deeper into the subject, I realized: this sentence isn’t trying to put us down, but to save us time.

Indeed, once you’ve acquired enough knowledge to start developing a game, it becomes very tempting to throw yourself wholeheartedly into a project that makes you dream (no matter how far-reaching the concept). The trouble is, if you give in to this temptation, you end up spending a considerable amount of time on details: pretty graphics, a complete inventory, a palette of enemies… Parameters that are certainly motivating, but which, in addition to never ending, completely miss the only question that matters at the moment: does my game have potential? And unfortunately, the only way to answer that question without waiting for our game to be finished… is to prototype it.

What is a prototype

Usually arriving before a game has even gone into production, a prototype is the concrete expression of a concept. If we’re writing a book, for example, our prototype will be a dozen pages and a potential summary. For music, a melody; for film, a dialogue. In the context of a video game (assuming that the heart of the concept is its gameplay), then in its purest form, a prototype is like a minimalist game where you interact with cubes, in an environment made of cubes (commonly known as “gray boxing”). This is, of course, an image illustrating the idea of an experience that goes to the ESSENTIAL, without any extras: no pretty graphics, no lights, no complex systems, no detailed levels (but plenty of bugs!). However, the essence of the gameplay is already there, taking shape in the so-called “3Cs”: Control / Character / Camera, which give a fairly realistic idea of the desired interaction between the player and the protagonist.

Assassin's Creed Mirage prototype

Yes, every great game starts with a cubic prototype (here, Assassin’s Creed Mirage).

It’s rather strange to think that, in order to test whether a game has potential, you first have to go through an ugly, unintuitive game, from which you’ve removed all those details that usually make a game enjoyable to play. And yet, this choice is perfectly conscious, regardless of the studio’s budget. There are several reasons why a prototype should be as simple as possible:

  • To be able to be designed, or even reiterated, quickly,
  • To avoid distracting the player with unimportant details,
  • To enable the development team to remain flexible, without having to dwell on ideas.

All these reasons converge on a common theme: flexibility. The more a concept is slapped together, the easier it will be to modify it as required; whether in terms of coding, for example, or even in terms of the developer’s imagination (which we try to preserve at all costs, thanks to the feeling that everything is still possible).

As you can see, the coating doesn’t make the prototype. It doesn’t have to be a complete experience, or even the most enjoyable to play. It even exists to answer questions such as whether a game has potential. But is it the only one?

Why prototyping

The point at which an idea leaves our imagination and ends up in a prototype is crucial, because it’s only at this stage that we can determine the solidity of a project: if people manage to have fun moving these binary shapes around, then that’s a good sign for the future. And if not, at least the idea will be out of our heads and we can move on.

Determining the viability of the fun is therefore the decisive element… in the first instance. As you can imagine, it’s not all that easy. Knowing whether people are having fun won’t tell us, for example, whether they’re feeling what we want them to (feeling powerful? Afraid? Relaxed?). Likewise, do they play as I expect them to? Have they found a way to cheat? Or is this a type of game that would interest them in a final version? These are all very important questions to answer before production starts, to avoid having to make major changes later on, or even getting stuck.

As you can see, the questions we’ve just addressed mainly concern gameplay. However, as a video game is a whole, you’ll need to think about prototyping other aspects too: visuals, for example, with concept art to imagine the rendering, or music (“main theme“) for sound design; before, potentially, prototyping a rendering mixing these different aspects to see if the whole fits together well.

Alan Wake 2 concept art

Art concepts, key to project visualization.

Depending on studio size, budget and time, the prototyping phase can vary enormously. From a single cubic prototype answering several questions for a single developer… to a plethora of detailed and completely different prototypes for a large studio! This is what happened, for example, with Capcom’s Resident Evil 4, where we were treated to a fixed-camera prototype, another beat’em all (which later gave rise to Devil May Cry), and others before arriving at the form we know today. So, as I heard at a GDC (Game Developers Conference) conference, and because not everyone has Capcom’s budget: “start where you are, use what you have, do what you can”.

How to prototype

1 – Issues

If you’ve read this far, then you already have a good idea of how a prototype is created. As I said, the basis of everything lies in the problem it has to solve. This is the starting point. Can my game be fun? Will people play it the right way? While each of these questions can be found in most prototypes, the key is to think about the questions that are important for OUR prototype.

In my case, for example, I started with the idea of creating a platform game based on the fear of failure. So, for my first prototype, I wanted to know if it was possible to realize this idea in a “top down” view, something rarely seen in a platform game, where side-scrolling is more common. Also, since my ambition was to make a game you’re afraid of falling into, I wanted to see if setting a slow pace, where every jump would require thought and every fall would be punishing, could be fun to play.

plateformer top down prototype

These animations, which can be found online, save an incredible amount of time when prototyping.

2 – Solutions

Once these questions have been answered, the next step is to think about how to answer them. In the present case, it would be interesting, for example, to propose a gameplay of a few levels (around 10 minutes) to see how the controller feels, and to find out whether players take pleasure and feel in control, or, on the contrary, have the sensation of not seeing the edge and falling without having decided to do so. Why not, at a later stage, propose a more complex level to observe their behavior over time, and see whether or not they get bored with the exploration side.

It’s during this stage that it’s also crucial to determine the most important points of a concept, i.e. those that need to be fine-tuned as a priority, and those that can be done a little more “on the fly”. In my case, I felt that offering a pleasant jump that gave a real feeling of control would be far more important than offering moving platforms. Similarly, I preferred to focus on alternating between the top and bottom of the level, rather than concentrating in depth on one of them. This is to see whether the dynamic of change works or not, rather than to create a real parkour challenge.

plateformer top down prototype

Once at the top, nothing is visible at the bottom

3 – Planification

How long will it take to make this prototype? As we all know, in video games, the notion of development time is taboo, so difficult is it to estimate the total duration of a project. Fortunately, since prototyping doesn’t require polishing, this timeframe can be relatively short if you have enough time to devote to it. The aim, once again, is to spend as little time as possible on a particular prototype. In fact, for the same amount of time, it’s better to make several small prototypes than one large one, especially if it’s an original concept.

As for me, it’s hard to estimate how much time I’ve spent on it, given that I started making it while I was still learning to use Unity and to code (which, of course, I still am!) To give you an idea, I’ve been slowly learning to develop for around 7 months now. If I were to restart my prototype today with my current knowledge of the software, coding and my long conversations with Chat GPT, I think that in 2 months (or 2-3 hours a day) it would be feasible.

4 – Action

All that’s left to do. Now that the previous points have given us a global view of our prototype, breaking down everything that’s necessary for it, all that’s left to do is code! We now know what’s most important to achieve, and how much time we have to do it. This time constraint will even enable us to regularly refocus on what really matters – a win-win situation. Here, there’s no time to dwell on clean code or on any parameters that don’t go in the strict direction of the objectives to be achieved. Of course, you don’t have to be psychorigid either: if a detail seems important to add after the fact, we don’t spit on it. So, in the meantime, I’ve added a wobbling state, where the protagonist seems to wobble (so to speak) when he’s too close to the edge, to make us understand to back off.

plateformer top down prototype

Be careful not to stay too close to the edge…

In short, to simplify the task, a commonly used way of determining objectives is to use the SMART method, for Specific, Measurable, Attainable, Relevant, Time-bound. This acronym allows us, for example, to determine an objective as follows:

  • Specific: I want to create a 10-minute prototype with 3 levels…
  • Measurable: I’ll get 5 people to try it out…
  • Achievable: To achieve this, I’ll use basic shapes for the decor…
  • Relevant: I’ll be able to see if these people find my concept fun…
  • Time-bound: I’ll have one month to complete it.

Conclusion

We now have the main keys in hand for designing our first prototype. Of course, these guidelines haven’t taught us how to code, build a level, imagine a game, or even any artistic notions. These other aspects will have to be learned independently, some even before our prototype, if we hope to see it exist one day (like coding, for example). However, as we’re in the discovery phase of our own game, there’s no area that needs to be mastered. On the contrary, we should see it as an exercise that will simplify the rest.

Once the prototype is finalized, what next? Well, since a video game is only interesting when it’s played, it’s time to get people to try it out! This stage, known as “playtesting“, will enable us to evaluate what players think of our game, and thus find out what needs to be changed, added, removed… or even whether or not the project should be stopped. As playtesting is a discipline in its own right and not to be taken lightly, that’s a topic for another time. In the meantime, if you’d like to be kept up to date on this project, feel free to follow me on Twitter, or read my other articles. Thanks for reading, and see you soon.

PS: the development of this prototype would not have been possible without the support of Jean Manzoni, a freelance developer, to whom I’d like to extend a huge thank you.

Translated with www.DeepL.com/Translator (free version)

Sources

Share your thoughts