What is a game prototype? Certainly, there is a short and elegant definition. But I like how Jesse Schell explains it in his famous book The Art of Game Design. He says that the sole purpose of a game prototype is to answer a question or questions that arise during game development. Questions could be general like: “Is this game mechanic fun?” or very specific: “Does my team have enough experience to produce animations of given quality?”
When I just started my experiments in game development I did not know about prototyping. I had just a blurry vision of how a game development process should look like.
The mistakes I made while prototyping
1. No prototyping at all
Kosmofront was my first game project. A dream game I wanted to build. I ignored and disregarded all the rules of gamedev while working on it. I just did not know them.
But despite the fact of how inexperienced I was, I still knew that there are “game prototypes”. My idea of a game prototype was that it should be a demo version of a game probably in the highest possible quality. Some features implemented, some not. But definitely you can show such a prototype to the general public. I thought of a prototype as a vertical slice of a game.
So I was working on such a “prototype”. The project failed, so did the prototype. I just have not finished it. And it was not even a prototype anyway. I did not know what I was doing.
2. Too broad questions
Later I came up with another idea, not that ambitious now. A top-down shooter where a player can destruct walls. And my definition of a game prototype changed. A prototype, in my opinion, was somewhat a simplified version of a game. You can play it and see how it goes. It should be done quickly and with the lowest quality possible. Free assets appreciated. And the only question which could be asked: “Is it fun to play?”
So I spent a few months building that prototype. And it turned out that it was not fun. The answer to the question was: “No, it is not fun to play”.
I thought something was not right there, so I created a topic on Reddit: Prototyping done right… or not. The whole post could be summarized to a single question: how a game prototype should look like? And there was particularly one interesting reply:
A prototype should exist to answer a specific question and the people playing it should be answering that specific question. If you ask for general feedback you’ll mostly get stuff you already know – “the sound is harsh and boring, there’s no music, it’s visually uninteresting, it’s a very small game.”
…
For your case I think there’s a few questions being asked:
1. Do I have the technical skills to move a character, fire a gun, pick up health, and have basic AI enemies?
2. Is fighting enemies in this setup fun?
3. Does adding the need to slowly push a block through the level make that more fun?
In my personal opinion having not actually touched the prototype: Yes, no, no.
…
The important thing about a prototype is you’ve invested minimal resources so changes and experiments can be done relatively easily.
Anatta336
A person on Reddit helped me to finally understand or at least get much closer to understanding what a game prototype should look like.
3. Not enough prototyping
With such knowledge, I proceeded to my next game project: Amazin Escape. I made a good prototype which answered a few questions:
- Am I able to create an animation in Blender and make it work in UE4? / Yes
- Does it seem fun to play? / Yes
I was happy with the answers and went into full production mode. Little did I know, that there were other questions unanswered. Certainly, in the beginning, everything was clear. But as deeper I was getting into the game production more questions appeared. And each of these questions should have been answered. And, that’s right, to answer all of these questions proper prototypes need to be created.
For instance, one of the important questions I left unanswered was: “Am I able to produce a good visual design or maybe I need to hire an artist?“. I believe if I have answered this question at an early stage, I would have more chances to succeed.
Game prototype done right
Earlier this year, I wanted to take a break from active projects and have some fun. So, I decided to get back to my first project: Kosmofront. The goal was to check how my UE4 skills improved over time. I gave myself a week to build a scene with a Moon landscape. I wanted to have 2 questions answered:
- Am I able to make a decent-looking scene on the Moon?
- Is that scene going to appeal to others?
I spent a week working on the scene and produced this:
I really liked what I’ve done and in my opinion, the answer to the first question was: yes!
Then I shared the video on my twitter and got almost no likes. I was puzzled: I thought I would have got more attention. So, either my skills were not good enough to impress others or a moon landscape was not interesting. Or maybe both. But anyway, I got the answer to the second question: no.
This small scene was not a prototype but it might have been. If I decided to start working on Kosmofront again, I would have known that at the current moment I wasn’t able to produce anything appealing on this topic.
That is how helpful a prototype can be! It eliminated the risk. The risk of investing a lot of time and money into a not appealing game!
Now I am working on a new game project. A “walking simulator” with some puzzles. I have learned a lot already. Now I know that I need to answer important questions first before investing a year or more of my life into this game:
- Is the core game mechanic fun to play? / I am going to create a few prototypes to answer that.
- Am I able to program a shader for my graphics? / I am going to program a smaller and simpler version of the shader and see how difficult it is.
- Is the visual style going to appeal to others? / I hired an artist and soon will show concept arts on the internet.
A very important rule here is to be honest with yourself. If any of these answers are negative then you need to change something. Don’t get attached to ideas that won’t work.
