GameDev from scratch: From the hackathon to your own game development studio. Part 2
We share the continuation of the story from the life of indie developers from IzHard . Today, the team will tell about the events that happened to them after winning the international competition, as well as about the mistakes that they made in the development process.
1. From the hackathon to our own game development studio: part 1 , part 2 .
2. Unity3D and vector graphics .
3. How to communicate with the player without words .
4. How to get out of chaos and start working .
We continue the series of GameDev from scratch articles through the eyes of the IzHard team. In the first part, we told how we got into the gaming industry and won the Imagine Cup competition . In the second part, we will talk about how our business went on returning home, how our team expanded, what tasks we set for ourselves, what trips to gaming conferences give, why it turned out, what a game we are doing for so long, and as a summary, our mistakes, which we have done being inexperienced, and advice on how not to act.
')
So, after we returned to St. Petersburg and made a month-long break, we had to solve the main task - to complete the game and release it.
Already in the beginning of autumn we had an interested publisher - the company Nekki. They offered us quite good conditions, on which we fully assumed product development, and all the questions of marketing and promotion remained to them. It was a great option - not to be distracted from the development and calmly make the game. We concluded a verbal agreement with Nekki on cooperation and set to work.
We really wanted to make a game with an unusual plot. The whole team of fanatel from the game Journey and dreamed of doing something similar - with a deep philosophical storyline and a “silent” gameplay. We took on the team of a narrative designer, who also dealt with marketing in our team.
We also realized that we would need a programmer with a good knowledge of Unity, since it took a lot of time to research the engine and its capabilities. There were many offers, but we were slow in answering. Many guys had a good experience in the development, but we wanted to find someone who would be as obsessed with the game as we are.
As a result, accidentally stumbling upon an article on Habré , we found a person who alone makes his own game and shares our design vision: minimalism down to color, unusual gameplay and the lack of interface elements familiar to the player. It was surprising that the concept of the game described in the article turned out to be close to the original idea of ​​OVIVO. And, without thinking twice, we contacted the author, and afterwards we offered to move to St. Petersburg and make our games together.
So the team of three turned into five: a programmer, a graphic designer, an artist, a narrative designer and a game designer. With this composition, we decided to make a dream game.
Error # 1. Do not make the first game a dream game if you have no experience. I want to do it perfectly, but without experience it is very difficult to achieve the desired result. Because of this, the development process is greatly delayed and there is a risk that interest in business will be lost.
We decided to start development with writing the concept of the whole game and a detailed description of the design document. For the template documentation took the notorious "Hen Ryaba."
The first outline for the game:
The concept was written immediately, and dizdok filled in the course of development. The game designer and the narrativist were mainly involved in this description, and the whole team participated in the brainstorming. The first problem began with this - everyone wanted to think of something and add it to the game. As a result, the discussions took too much time.
We decided to somehow limit our imagination and came up with, so to speak, the three "whales" on which the game is based and directs the generation of ideas in the right direction. Three rules that we follow now (for us this has become a kind of mantra):
1. The game has only two colors: black and white.
2. The complete absence of any text.
3. Control only three buttons: right / left and the "jump" button.
This greatly helped weed out unnecessary ideas and turn thoughts in the right direction. So we got rid of unnecessary mechanics, problems with localization and clearly defined the visual style of the game.
Error # 2. Designing a document as a text document is an absolutely unnecessary thing for a small team. Nobody wants to read it, and the filling process takes a lot of time. Dizdok is a necessary tool, but it should be convenient for reading and navigation, and it is very important to keep a clear project structure in it. For us, a good alternative was the way of keeping records with the help of a task manager.
When the concept was written and the team was given a general vision of the game, we began to develop. Initially, all the roles were clearly distributed and it seemed that everyone knows what to do. However, it soon became clear that some tasks were being done for too long, the team did not see their priority, and many tasks had to be redone due to inconsistencies. In addition, Unity regularly released patches, and the team needed to be constantly updated on updates.
To coordinate the work, we began to hold daily rallies, so that everyone knows who does what and what tasks are more important for the week and what we expect to see in a month. So we smoothly moved to the principles of a flexible development methodology and began to install sprints. If someone missed the rally, the game designer wrote out the tasks to the task manager and set the priority and deadlines.
In the end, we came to the conclusion that dizdok is a set of tasks in the task manager. And every week together we choose which tasks are of the highest priority and put them on another board in order not to be confused with the whole task pool. On their decision we define deadlines (usually a week), and if we don’t fit in, we transfer the unsolved tasks to the next week. If the task is too complicated or takes a lot of time to solve, then we score on it.
Error # 3. Unfortunately, in our team, not everyone could accustom themselves to deadlines. And for some, corporate methods are simply “uninteresting” to comply with them.
Throughout the development, we often went to various gaming events and conferences. Of course, basically we just wanted to travel and meet people, communicate with professionals from game devs parties. For example, Microsoft sponsored us, as the winners of the Imagine Cup, a trip to PAX EAST in Boston, where we got on twitch and met Rami.
There was another big benefit from the events - we always showcased the game and received valuable feedback from the player. At first, we were skeptical of showcases, they say, time is taken away and there is no special meaning in them. But when the tests showed that the game is full of gaps, we radically changed our opinion.
A very useful skill that we have developed on showcases is to remain silent while testing your game. Without prompts, the player passes the game, as if he received it at home, and thus demonstrates in what moments he has problems. More valuable when the player expresses all his thoughts. So we realized that the game has a high level of complexity, and many elements are incomprehensible and need to be improved. Therefore, we decided to simplify many points, made a smoother complexity curve and added a tutorial (you can write a separate article about how many times we have tweaked the tutorial).
Error # 4 . Do not abuse the frequent visits to the conference, because it is very distracting from the development process and takes a lot of time to prepare. However, you should not develop a game in complete isolation and be afraid to show it in public. Playtests are very important at almost all stages of the game creation - they make it possible to choose the right development course. Ideally, you need to learn how to balance so that the main resources are spent on development, but also not to forget about testing and communicating with colleagues.
Initially, after the Imagine cup, we agreed that the game for us will become a learning project. Therefore, at first we studied the possibilities of Unity and as we advanced our development, we thought up improvements for our game. By the way, this is how the first level of the game looked like during the Imagine Cup.
We rewrote the functional part of the project several times, since the old mechanisms did not meet the new requirements of the gameplay. Similarly, with graphics - using a raster is too “a sinker” project. In our case it was very critical, since the whole game was black and white. In addition, graphics is an interactive element. The character interacts with every corner of the platform, and you need to find a balance in the accuracy of drawing graphics and building physical properties.
In the end, we found a way to use vector graphics in Unity (this will be a separate article). The project began to weigh megabytes instead of gigabytes, and this made it possible to create builds for mobile platforms without any problems.
Now the first level of the game looks like this.
However, the shoveling of the project and frequent conferences led to constant deadlines. We did not have time to complete our tasks in the form in which we wanted, and often had to do “stubs” in the game. To promote the publisher needed videos, promotional materials, working with the site and so on. I had to spend less time on development, but I really didn’t want to sacrifice the quality of the game. In the end, we decided to postpone the issue with the publisher Nekki and focus on development.
Error # 5. Good planning and knowledge of all stages of development (from generating ideas to advancing) in the initial stages will help save time in the future.
Over the past two years, we have learned a lot, and, despite the many mistakes and protracted development, we still get a buzz from our work. We really like what we do, and we advise anyone who looks in the direction of gamedev to try.
Currently, OVIVO is at the final stage of development: we test levels, fix bugs, and prepare materials for the press. The scheduled month of release is May. In parallel, we will continue to share our experiences. In the following parts, we describe the technical component of the game, describe in more detail about the stages of development and the legal issues that confront the indie developer.
We hope that the article was useful to you and will be happy to answer your questions. Thanks to all!
The series of articles "GameDev from scratch"
1. From the hackathon to our own game development studio: part 1 , part 2 .
2. Unity3D and vector graphics .
3. How to communicate with the player without words .
4. How to get out of chaos and start working .
Hello
We continue the series of GameDev from scratch articles through the eyes of the IzHard team. In the first part, we told how we got into the gaming industry and won the Imagine Cup competition . In the second part, we will talk about how our business went on returning home, how our team expanded, what tasks we set for ourselves, what trips to gaming conferences give, why it turned out, what a game we are doing for so long, and as a summary, our mistakes, which we have done being inexperienced, and advice on how not to act.
')
Homecoming and good news
So, after we returned to St. Petersburg and made a month-long break, we had to solve the main task - to complete the game and release it.
Already in the beginning of autumn we had an interested publisher - the company Nekki. They offered us quite good conditions, on which we fully assumed product development, and all the questions of marketing and promotion remained to them. It was a great option - not to be distracted from the development and calmly make the game. We concluded a verbal agreement with Nekki on cooperation and set to work.
Recharge team
We really wanted to make a game with an unusual plot. The whole team of fanatel from the game Journey and dreamed of doing something similar - with a deep philosophical storyline and a “silent” gameplay. We took on the team of a narrative designer, who also dealt with marketing in our team.
We also realized that we would need a programmer with a good knowledge of Unity, since it took a lot of time to research the engine and its capabilities. There were many offers, but we were slow in answering. Many guys had a good experience in the development, but we wanted to find someone who would be as obsessed with the game as we are.
As a result, accidentally stumbling upon an article on Habré , we found a person who alone makes his own game and shares our design vision: minimalism down to color, unusual gameplay and the lack of interface elements familiar to the player. It was surprising that the concept of the game described in the article turned out to be close to the original idea of ​​OVIVO. And, without thinking twice, we contacted the author, and afterwards we offered to move to St. Petersburg and make our games together.
So the team of three turned into five: a programmer, a graphic designer, an artist, a narrative designer and a game designer. With this composition, we decided to make a dream game.
Error # 1. Do not make the first game a dream game if you have no experience. I want to do it perfectly, but without experience it is very difficult to achieve the desired result. Because of this, the development process is greatly delayed and there is a risk that interest in business will be lost.
Start developing and generating ideas
We decided to start development with writing the concept of the whole game and a detailed description of the design document. For the template documentation took the notorious "Hen Ryaba."
The first outline for the game:
The concept was written immediately, and dizdok filled in the course of development. The game designer and the narrativist were mainly involved in this description, and the whole team participated in the brainstorming. The first problem began with this - everyone wanted to think of something and add it to the game. As a result, the discussions took too much time.
Video in which we discuss the idea.
We decided to somehow limit our imagination and came up with, so to speak, the three "whales" on which the game is based and directs the generation of ideas in the right direction. Three rules that we follow now (for us this has become a kind of mantra):
1. The game has only two colors: black and white.
2. The complete absence of any text.
3. Control only three buttons: right / left and the "jump" button.
This greatly helped weed out unnecessary ideas and turn thoughts in the right direction. So we got rid of unnecessary mechanics, problems with localization and clearly defined the visual style of the game.
Error # 2. Designing a document as a text document is an absolutely unnecessary thing for a small team. Nobody wants to read it, and the filling process takes a lot of time. Dizdok is a necessary tool, but it should be convenient for reading and navigation, and it is very important to keep a clear project structure in it. For us, a good alternative was the way of keeping records with the help of a task manager.
Work organization
When the concept was written and the team was given a general vision of the game, we began to develop. Initially, all the roles were clearly distributed and it seemed that everyone knows what to do. However, it soon became clear that some tasks were being done for too long, the team did not see their priority, and many tasks had to be redone due to inconsistencies. In addition, Unity regularly released patches, and the team needed to be constantly updated on updates.
To coordinate the work, we began to hold daily rallies, so that everyone knows who does what and what tasks are more important for the week and what we expect to see in a month. So we smoothly moved to the principles of a flexible development methodology and began to install sprints. If someone missed the rally, the game designer wrote out the tasks to the task manager and set the priority and deadlines.
In the end, we came to the conclusion that dizdok is a set of tasks in the task manager. And every week together we choose which tasks are of the highest priority and put them on another board in order not to be confused with the whole task pool. On their decision we define deadlines (usually a week), and if we don’t fit in, we transfer the unsolved tasks to the next week. If the task is too complicated or takes a lot of time to solve, then we score on it.
Error # 3. Unfortunately, in our team, not everyone could accustom themselves to deadlines. And for some, corporate methods are simply “uninteresting” to comply with them.
Conferences
Throughout the development, we often went to various gaming events and conferences. Of course, basically we just wanted to travel and meet people, communicate with professionals from game devs parties. For example, Microsoft sponsored us, as the winners of the Imagine Cup, a trip to PAX EAST in Boston, where we got on twitch and met Rami.
There was another big benefit from the events - we always showcased the game and received valuable feedback from the player. At first, we were skeptical of showcases, they say, time is taken away and there is no special meaning in them. But when the tests showed that the game is full of gaps, we radically changed our opinion.
A very useful skill that we have developed on showcases is to remain silent while testing your game. Without prompts, the player passes the game, as if he received it at home, and thus demonstrates in what moments he has problems. More valuable when the player expresses all his thoughts. So we realized that the game has a high level of complexity, and many elements are incomprehensible and need to be improved. Therefore, we decided to simplify many points, made a smoother complexity curve and added a tutorial (you can write a separate article about how many times we have tweaked the tutorial).
Error # 4 . Do not abuse the frequent visits to the conference, because it is very distracting from the development process and takes a lot of time to prepare. However, you should not develop a game in complete isolation and be afraid to show it in public. Playtests are very important at almost all stages of the game creation - they make it possible to choose the right development course. Ideally, you need to learn how to balance so that the main resources are spent on development, but also not to forget about testing and communicating with colleagues.
Long development and rejection of publishing
Initially, after the Imagine cup, we agreed that the game for us will become a learning project. Therefore, at first we studied the possibilities of Unity and as we advanced our development, we thought up improvements for our game. By the way, this is how the first level of the game looked like during the Imagine Cup.
We rewrote the functional part of the project several times, since the old mechanisms did not meet the new requirements of the gameplay. Similarly, with graphics - using a raster is too “a sinker” project. In our case it was very critical, since the whole game was black and white. In addition, graphics is an interactive element. The character interacts with every corner of the platform, and you need to find a balance in the accuracy of drawing graphics and building physical properties.
In the end, we found a way to use vector graphics in Unity (this will be a separate article). The project began to weigh megabytes instead of gigabytes, and this made it possible to create builds for mobile platforms without any problems.
Now the first level of the game looks like this.
However, the shoveling of the project and frequent conferences led to constant deadlines. We did not have time to complete our tasks in the form in which we wanted, and often had to do “stubs” in the game. To promote the publisher needed videos, promotional materials, working with the site and so on. I had to spend less time on development, but I really didn’t want to sacrifice the quality of the game. In the end, we decided to postpone the issue with the publisher Nekki and focus on development.
Error # 5. Good planning and knowledge of all stages of development (from generating ideas to advancing) in the initial stages will help save time in the future.
Epilogue
Over the past two years, we have learned a lot, and, despite the many mistakes and protracted development, we still get a buzz from our work. We really like what we do, and we advise anyone who looks in the direction of gamedev to try.
Currently, OVIVO is at the final stage of development: we test levels, fix bugs, and prepare materials for the press. The scheduled month of release is May. In parallel, we will continue to share our experiences. In the following parts, we describe the technical component of the game, describe in more detail about the stages of development and the legal issues that confront the indie developer.
We hope that the article was useful to you and will be happy to answer your questions. Thanks to all!
Source: https://habr.com/ru/post/323676/
All Articles