How to Make Games – An Experimental Guideline (Part 2: Documents)
This content is the second part of a four-part article about game design and development. At present, the next articles are not ready, once they are ready we will put their links here:
Part 1: Idea
Part 3: Development
Part 4: Balance
In the previous part, we discussed how to reach an idea and how to examine it to fit with our team’s skills and requirements. Regardless of how we reached the idea, we have to bring the idea to the practical phase. You may think the next step is sitting behind the computer and beginning coding, But you should remember the sooner you start coding, the later the project will end.
Gradually, the first software engineers and developers realized having a detailed plan or architecture before beginning a project is very vital. They knew that because nobody likes to have no idea about the next step.
Today, I will tell you how to create a detailed useful structure and a documentation that defines it to create an amazing engineered game.
|When DD Alpha Balls project started I had 1 week to create a prototype and documentation. I can not claim that is perfect but it will be very useful to understand the principles in this article.
You can see them here: https://drive.google.com/drive/folders/1cPH7Za_GN4qfspvQQSZ4e97cwJKiq3BV?usp=sharing
Extending the Idea to a Practical Structure
At the very first step, we have to think about everything related to the idea. At this level, there is nothing but a raw idea. If you take a look at successful games in the market, they often have a simple idea like a jumping ball, a shooter that destroys other objects, objects that merge with other similar ones, etc. But all of them are surrounded by a huge number of features, scores, rewards, and options.
The players can not stand your game if they experience nothing but the idea. They need to be satisfied with your idea, they have to be happy when doing a positive action or finishing a job or level. As the first job, you have to add these parts to your idea and convert it to a real game.
In every game you experienced one or more of the following things:
- Points: The easiest oldest way to attract the player. He expects to gain points when he finishes a level, does a good job, or hits a record. I will tell more about balancing points in the next articles.
- Enemies/Obstacles: Absolutely, nobody loves an alone hero. A hero has to pass out obstacles, reach the boss, fight and destroy him. Don’t forget the benefits of the dark side.
- Options: As a game designer, you have to convey a sense of power to the player. Like Points, the player expects to get some options when he does a positive action.
- Rewards: Sometimes, the player does not like to continue the game, either he is disappointed in his abilities or he feels that the game is too boring. Thought-out rewards can make the game tasty for the player. Do not be too generous or stingy in using them.
Building a Prototype
Till here, in both articles, I said about pure mental works and I made you think. But your teammates can not read your mind. In this step, all the thoughts are drawn and written.
A prototype describes the game from the designer’s point of view, it prevents different thoughts about the idea and subsequently about the game. Furthermore, the existence of a model that maps your line of thought helps you to create fewer deviations and distortions in the process of making a game.
In the prototype phase, you should try to draw all the states of the game. Where the player enters? What will happen when he taps a button or swipe the screen or when he finishes a level or scores a certain point? Will he be encouraged or punished after victory or defeat?
After all, you should connect the modes. So, you built a structure that anybody can trace the states and feels the game.
Thanks to technological advances, building a prototype becomes easier to change and more collaborative. But I do not intend to introduce only modern ones. No one thinks this is wrong to draw an idea on a paper. However, the most common tools to build a prototype are:
- Adobe XD
- InVision Studio
- Origami Studio
These give you a collection of powerful options and tools that can make your prototype very professional and descriptive. All of them can work with all the team members together.
As a game designer, you have to study and be informed about the importance of UI/UX. For the most part, an amazing game will be destroyed if it does not benefit from a good UI/UX design.
When building the prototype, consulting with an expert helps you to be sure you are in the right way in designing UI/UX.
As a rule in our team, we first create a prototype because it is a visual document of a game and team members can understand it easier and more accurately. Accordingly, we set a meeting in which the prototype is presented to all team members intended for the project and the game designer wants all to look at the prototype and tell what they feel from it.
When the game designer makes sure the prototype is understood correctly, the latest step before development will begin.
The time for writing! Now all team members understand the idea and the prototype and you as a game designer have to convert all these concepts to text. In this step, you will write documentation that maps your prototype. Be aware of variables, triggers, and actions! In both steps (Prototype and Documentation) they must be called with similar names and specifications.
Describe Game Atmosphere
You talked about the game atmosphere with the colleagues, perhaps. But it does not clarify what the game is about.
Imagine you are designing a shoot’em up game. All you are thinking about is spacecraft because you want to create a game that Space Invaders fans will love, then after a week, your graphic designer shows you her models and what the hell! He has worked all week on a WWII airplane collection!
Experience: In DD Alpha Balls Vida sucked
So, the game story must be described in the documentation. You can express extra details that you do not want to implement in the final version of the game. The most insignificant details can lead to a better perception of the model.
So far, we have talked about expressing details, but how much details is enough? We do not want to create a superficial model that everyone understands in their own way, on the other hand, We do not want to overwhelm our team members with explanations and details.
When you feel your team members can understand the model and also they can imagine the game’s world and atmosphere is the best point to finish the descriptions. As a rule, the purpose of creating a prototype and writing documentation should be to improve the quality and speed up development.
|After completing DD Alpha Balls documents, we sent them to our graphic designer. All the time I and the rest of the team were thinking about a colorful cute design with cool animations. “I will finish the job in 10 days” she said.
After 5 days she sent us the first part of the graphics and what we saw, was a dark formal theme.
Experience has shown that many game designers ignore the documentation after completing the initial steps. We have to admit that we may be wrong. There is no human product that is completely perfect. Everything we have made needs to be repaired and developed. In conclusion, you should be aware of the changes that appear in your design, when one of them happens, the documents should be modified.
Finally, if you try to coordinate the prototype and documentation with the development process and possible changes, you will prevent deviation from the idea.
|When I reached the basic idea of DD Alpha Balls I worried about circles physics in the Construct 3 game engine. The best way to know was a simple prototype that didn’t waste my colleague’s time.
I can’t remember how much time he spent to create a prototype (I swear it didn’t exceed half a day) but when I played, everything I thought could be a problem looked good except for the idea… I changed a big part of my idea tomorrow!
So far, we have understood game making is not only the development phase. In brief, we have learned the initial steps are very necessary and without them, we will not create a good game finally.
Specifically in this article, we have learned the process of building documents for our idea that is going to become a game. Also, this article showed us challenges and points that we have to consider when we are building a prototype and documentation.
Finally, In the last part, the article clarified the importance of updating documents.
What Is the Next Step?
Maybe you follow these contents to learn what about developing a game. From here onwards, we will enter the technical parts of game making. As a game designer, you must encounter new challenges and problems. In this step, the developers and graphic designers have most contact with you.
Are you ready for a challenge with the most logical and the most emotional people in your team?