Tips for working on a prototype game from Social Quantum

The report was read as part of White Nights St. Petersburg 2018 this summer. We give a brief version of the speech.

Kirill ShabordinWhen there is a need for a prototype

The main task of the game is to make it fun and fun. Emotions and mood are hard–to-define things, multicomponent. It is not always clear which mechanisms should be used for this.

The situation is complicated by the fact that under joy or even a specific thesis, some people have one thing, and people of another specialty have a completely different one. If I say “Let’s make an RPG”, then many people will think about the same thing. But as soon as there are fundamental clarifications, it turns out that in detail we were thinking about completely different things.

And at this moment, when your idea begins to split into many other ideas that are not obvious to the people you work with, there is a need for a prototype.

Please note that at this stage there is a need not for a detailed design document, but for creating a prototype.

Why?

The fact is that an exhaustive design document is a myth. The final document with a full description of the game design appears exactly at the time of publication of the game, not earlier. At the same time, I am not saying that this is something insignificant, it is necessary, but it plays the role of constantly being clarified as documentation is developed.

In general, the procedure for the production of a software product usually looks like this: idea, pitch, design document (being specified), prototypes, transition to the production cycle.

And a prototype is needed, since the verbalization of various aspects of gaming software is quite complex, these aspects cannot be simply explained.

And as soon as we have a linguistic hunger, as soon as we have no way to determine it through the text, we start writing prototypes.

What is a prototype

Let’s first talk about what prototypes are not. These do not include: internal developments, ideas stored in a pile, bad pipeline, non-working technologies and everything about which phrases in the spirit of “Yes, I did badly, but this is a prototype, then I will do better” are possible. MVP (minimally viable product), by the way, also does not apply to the prototype.

There is also no rapid prototyping. This is a tautology. There is no slow prototyping. Any prototype is a thing that we do quickly.

What is “fast”? If the implementation of full-fledged functionality takes a month, then its prototyping should take no more than two days. A day is better. If this is not the case, then you are not prototyping, you are poorly implementing the feature.

Prototyping is not doing it badly, prototyping is doing it differently.

So what is a prototype, what is it?

First, any prototype demonstrates some one essential aspect of the product that you are making. Prototypes are not a complex thing, but one that demonstrates one important aspect.

Secondly, the result of the prototype life cycle is always a trash can. The prototype should always be thrown away.

Third, the prototype must have an addressee, a person who makes decisions. Maybe a group of people. The thing is that the purpose of writing a prototype is to receive a binary answer from the receiving party: either “yes” or “no”. That is, either we do such functionality, or we don’t.

Fourth, the prototype must use the language that is as clear as possible to this point of decision-making.

For example, if you demonstrate the work of the graphical interface to the user, then you just need to draw a screencast. He answers only one question: is this the set of user interactions that he needs?

Last, if you are doing prototypes, you should have a special kind of tools that allow you to do it quickly.

A prototype can be if you write some kind of story related to balance, even a table in Excel or in Goolge with two scripts that consider, for example, what will happen if a player goes one way, how much damage will he receive if he goes the other way. You can already play it.

The prototype of the game level can be a scene made on Unreal with standard assets, from which it is clear whether points of interest will work on the map, whether enemies are located successfully, whether the first aid kit is visible to all players, and so on.

At the same time, it is important to understand that the quality that your prototyping team gives out is always the same, but the time may be different. And in order to minimize the time, you should use what you have, ready-made solutions. It’s not worth reinventing the wheel.

Evolutionary prototyping

Don’t fall into the trap called “evolutionary prototyping”. The latter means the gradual refinement of the prototype, its transformation into a working product.

The fact is that a prototype by its very nature cannot be turned into a working product. I do not know a single person who has succeeded.

Those people who call what they specified a prototype did not make a prototype from the point of view of theory, but simply developed from bad to good. Iteratively we did one feature, the second, the third. Up to a certain point, it was called a prototype. Then, without changing the code, they called the result a product.

Proof-of-concept

Before developing, it is very important to know how technologically you meet the tasks that exist. There should be a reconnaissance before the battle.

I know three or four stories when people put the game into production, made it for a long time, and then found out that they couldn’t implement the basic things.

Example. You are going to make a multiplayer game. Before that, it is important for you to ask yourself a number of questions.

• Can we afford to make a multiplayer game at all?
• How many people will be able to play the game at the same time at our current capacities?
• What is lag compensation?

Of course, there are more questions. And everyone will require not only a specific answer, but also proof.

However, there are a huge number of technologies in which nothing needs to be proved. You use ready-made engines, you use ready-made, understandable concepts. Therefore, very often there are solutions that you don’t have to prove to someone and you can just skip this point.

Prototyping Tips

As a conclusion, I will list the tips that can help you in creating a prototype:

1) Be sure to use something that is great for prototypes. For example, you work in Unity. There is some kind of 2D task. It will be faster to take Defold or Game Maker to test it than to get into the 2D functionality of Unity.

2) Don’t do anything in prototypes that doesn’t demonstrate the idea.

3) Don’t call a bad implementation a prototype.

4) Any prototype is better than words.

5) Try to use one mechanic, one aspect of what you are doing in the prototype.

6) Do not think that you need to hire children to create prototypes. Hire normal programmers, because normal programmers work faster.

7) When working on a prototype, reusing content is always faster and more correct than inventing a new one.

9) It is more correct to switch to another tool than to invent a solution yourself. If someone has come up with something, and the goal of the team is only to demonstrate the idea to a person who will say “yes” or “no”, then taking another tool is simply absolutely more rational than inventing code from scratch.