Instruction novice game developer

In this manual, I tried to highlight the main points of game development. The instruction will be useful for people who are going to start developing games as a leader (the main developer and organizer).

I want to note that the games are different - large and small, complex and easy, and therefore for each game this instruction is correct in some particular degree. It was not possible to cover everything, but I think it turned out to convey the general points.

And so you decided to make your game, what you need to think about ...
')

We think - do you need it

Before you take on something, you need to think about everything. And before you start developing games, you need to think about everything very well. Very often, novice developers, having achieved some success in something (made a mod for the game, a small fan site, etc.), begin to dream of creating their own game. This is due to the fact that they have little understanding of the game development process.

I will list the main mistakes in their presentation:

• No romance. Many novice developers, after playing enough games, come to the conclusion that creating games is also interesting, as well as playing, only a little more difficult. This is a very common mistake. The bigger and harder the game is, the duller and less interesting the process of its development. Romance is absolutely not.
• It is difficult and even impossible. Many after several (or even one) successful project are filled with confidence that they can do a game project. In fact, games are one of the most difficult areas of development. And the "more serious" the game, the more difficult the project. In the process of creating a game, the developer may face unsolvable problems that kill the enthusiasm of even the most obstinate in the bud.
• Aversion to games. Over time, every seasoned game developer develops aversion to games. At first they just become less interesting. Then you begin to notice that they are not at all interesting, but only how they work is interesting. Further we go, worse it becomes.
• Competition and product quality. Many studios and independent developers are involved in games. There is a kind of "level of entry" in this business. Now you can not make a successful game, painted with watercolor (yes, these games met in the early 2000s). She just can not stand the competition. Accordingly, you will not do anything. Here an important psychological moment lurks - the novice developer is forced to make a good product, otherwise he will experience a constant feeling of fear of the failure of his product.
• Time and resources. And the most common mistake is that there will be enough resources (time, money, knowledge) for them. To understand the amount of work, read the following points.

Concept and TK

Once upon a time I wrote a pretty good article about the concept of the project. Over the past couple of years, my views have changed slightly, but the essence remains the same.

• What is the concept? The concept of a game project is a document that describes the goals, objectives, main features of the project, market research and target audience, the conditions for its implementation. Also, since the project is a game, a description of the game mechanics, game concepts, an exemplary scenario and concept art are required. If you still expect to do the project not alone (which is very likely), then you will need more technical task (TK) - a document containing a description of the work required, the terms and conditions.
• Why do you need a concept? Very good question. Why do some kind of “writing” when you need to assemble a team and write code?
  First of all, the concept is needed in order to get a full-fledged understanding of the final result and estimate the amount of work. Without a clear and well-thought-out concept, you will end up with, respectively, a contradictory and ill-conceived game. Without a concept, there is a greater likelihood of errors in the organization of game mechanics or implementation errors.
  Secondarily, the concept is needed so that others understand what you want to do. All team members must work on one common project. Team members will learn about this shared project from the project concept document. This is necessary so that there is no discrepancy in the perception of the final result. If you decide to create a game and assemble a team for this, then the first questions from future members of the team will be: “What do I have to do? What should we get in the end? ” You will need to provide them with a project concept and a ToR. Without the concept and TZ you will not attract any normal specialist.
• Volumes. A very interesting question is the volume of the concept. Here it is necessary to build on the complexity of the game and its development. If you have a simple game, you work alone and you are able to keep the idea of ​​the game in your head, then you can not write a concept at all. If you can not keep all the moments in memory, then you need to transfer them to paper (or other media). If you work in a team or use the help of other people (investors, artists, and others), then you just need a comprehensive concept and TK for each person. Criterion one - clarity. It is necessary that any person, having familiarized himself with the concept and TK, should present the final result, as well as you.
  Pay attention to the fact that if you understand your concept, it does not mean that others will understand it. Writing the concept plays the role of "litmus test". If you cannot write an understandable concept (approximately 5 pages for a small game, a few dozen pages for a large one), then you are unlikely to end up with a project.
• Detail. The concept should have all the answers. After reading the concept, a complete picture of the project should be formed. Experts first look at the concept, if the concept turns out to be incomplete and incomprehensible to them, they will not work with you.
  Separately, it is worth mentioning concept art. It should be, at least in the simplest form. It is proof of a solution to a problem with the content of the game (see the next section).
• Russian language. For many, this is a serious problem. If the concept document contains many grammatical, spelling and syntax errors, then no one expert will take it seriously. Remember: ignorance of the Russian language is very harmful to business.
• Time. It is advisable to specify the terms of execution of the work immediately in the TOR. The problem is how to estimate this time if you have never done anything like this. You will never get the exact answer to this question, everything will come with experience. I will only give one piece of advice: consider not only the development time, but also the time for correcting errors (approximately 50% of the development time).

Content

I specifically singled out this section, since it is crucial in the game development process. Content refers to the entire contents of the game with which the user interacts. These are graphics (raster, vector, 3D), music and sound, video series, script and text. Also here should be added the media materials used to promote the game (advertising, banners, etc.).

In English, there is such a thing as “ artists ” immediately denoting artists, musicians, directors, writers and other creators. Unfortunately, in the Russian language there is no normal analogue of this word, so I will continue to use the concept of " content creator ".

Let us analyze the main points of this section.

• Complexity. This is the main problem in the issue of content. It turns out that in most cases the preparation of content is the most difficult task, harder to write program code, harder to test and debug, and harder to implement the game. Naturally, if the game is small, then it is not so noticeable, and if it is large, then the share of the content creator drops to 80% of the work on the project.
• Volumes. Often due to the fact that developers have never performed the tasks of content creators, it is very difficult for them to estimate the volumes. It seems that there is such a couple of dozens of pictures and 3-4 sounds. But if you count, you get 40 large-size images, 400 small images, two dozen sounds (I gave an example of the average BMMORPG). It is good that all this can be calculated when preparing the concept.
• Quality. First, we must understand that the players work directly with the content. Secondly, we must remember that there is a huge number of competing games with good content. It can be concluded: a game with poor content will not be competitive, i.e. The content in the game must be of high quality.
• Time. It is quite logical that a lot of time is spent on preparing large volumes of high-quality content. It takes more time than all the other directions combined (small games do not count). Keep this in mind when you plan and calculate deadlines.
• The cost of content. Good content is worth “good” money. Very "good" money, which novice game developers usually do not have. Many developers harbor an illusory hope of finding a “free” content creator (or cheap). You can find it, but it will either create low-grade content, or it will create some content for you, and then it will switch to those who will pay it. In short, you will never find the “free” creator of good content. It is for this reason that there are no good “open source” games.
• Theft. Due to the existence of expensive content problems, game developers sometimes appear who steal it. Like, what's wrong? .. I'll take a dozen pictures from this game, and find background images on DA, and put some of my favorite Rammstein songs as background music. The problem is that the copyright of the content is easy enough to confirm. The “victim” of theft has either the source files of the content or a document about the transfer of content from its creator. For content thieves, there is a great chance of running into article 146 of the Criminal Code of the Russian Federation.
• Uniform style. Another important point that is often forgotten. In order for the game to look solid and well thought out, it needs to have a single style. Content creators are not robots, so they do the work in their own individual style. From this we can conclude: it is desirable that the contents of the game create as few people as possible.
• Dilemma. After reading the points described above, you can build the following chain: A competitive game requires the use of high-quality content. Quality content can only be made by a professional content creator. Professional content creator is expensive. There are only three solutions to this problem:
  
  1. Do not make a game, that is, abandon the direction of game development.
  2. Find an investor. But here we are immediately waiting for the problem of concept art. Who will prepare concept art if there is no money for an artist? And without concept art, no one will invest in you.
  3. Solve the problem on their own. That is, one of the team members must be a content creator and get paid, even if everyone else sucks a finger.

Programming

Oddly enough, the creation of software code for games is not the most difficult task, but at the same time it is not an easy one.

• Team. Unlike content creators, programmers for their team are easy to find. This is explained by the fact that, at a certain level of preparation, writing the program code of a game is not such a difficult task. You can find "free" programmers who are ready to work for the sake of interest. And for a fee and a “name” (mention, as a game developer), you can find a programmer who will write good good code. But ... now is not the beginning of the 2000s and programmers have become smarter. First of all, an adequate programmer will ask the developer to demonstrate the concept and TK. Then he will ask about content creation or funding that will be used to create it. Experts are well aware that there is no need to invest in the initially failed project. If you have no concept and the issue with the content is not resolved, you will not find a normal programmer.
• First we do a lot, then a little. Simple advice is enough, but it is not followed most often. The game project in most cases is complicated and has many dependencies. All this is difficult to calculate at the level of conceptualization, often have to change something in the plans. Therefore, in order not to perform double work, you must first make a common working structure (prototype), and then go into the details.
• What is content or code first? After reading the section on content, you probably already realized that modern games are based on content, and not on programming. Hence the dilemma - the code is customized for the content or the content is customized for the code. Both approaches take place in the modern development process. If you adjust the code for the content, then the load falls on the programmer, the development time increases. This is a cheap way. If the content is customized for the code, then the load from the programmer decreases, and taking into account that the content is prepared by employees, the development time is reduced. This is an expensive way, since the load falls on the hired content creators. Assess the situation in advance and follow one of the approaches.
• Unsolved errors. This is not even a problem, but a prejudice. Developing a game is a very complicated process. It happens that the developer is faced with unsolvable problems (or solved extremely hard) and he has to revise almost the entire project. Psychologically it is very difficult. Many, even the most stubborn developers, hitting such a "dead end", lose their enthusiasm and close the project. The prejudice is that everyone believes that this will not happen to them. Tip one: be psychologically prepared to review the entire project and do the work anew.
• Magazines. The advice from me personally. Keep three journals:
  
  1. Project work log to track development progress;
  2. A journal of ideas on the project, in order not to forget them and, if possible, include them in the concept;
  3. Log of found bugs and errors that need to be fixed in the future.
  These three journals will help avoid errors and duplicate work in the development process.
• Time. When determining the time that is planned to write code, they often make one mistake - they do not take into account the time spent on fixing bugs and debugging code.
• Authorship of software code. A certain "insanity" is observed, with some programmers. They believe that they have absolute rights to the code that they have written, that even after the release of the game they can claim the right to “part of the code” of the game. To protect this “sacred” right, they can go to all sorts of meanness (software bombs, backdoors, refusal to transfer source codes, and others). My advice is simple - beware of such inadequate programmers. Program code is not content. Proving his authorship is very difficult. Therefore, a normal programmer first agrees what he gets for the code; then he writes it; then sends it to the developer and gets a reward; after which he no longer claims anything. It should also be organized in a team.

Testing

On testing, novice developers usually do not think, but in vain, since it takes a little less time to spend on it than on writing the software part. There are two important points in this section:

• Testing by third-party people. During the development process, testing is carried out mainly by its own means Over time, the eyes get used to the existing game moments, the ability to work in this system is developed, in short, errors become less noticeable. Therefore, arrange for periodic product tests by outsiders who have never seen your product. Watch their reaction to different game moments, how they perceive the game menu and, in general, question their overall impression. Believe me, one such test will give you a very large amount of useful information. Spend them more often, listen to the feedback, and you will get a good game at the exit.
• Women. I once wrote a nice article about women and games. The point is that women see everything differently. Therefore, it is desirable that at least one woman (girl) participated in the game's test, even if the game is not designed for a female audience. Their feedback will be incredibly helpful.

Organizational issues

• Team. As you might have guessed, creating projects such as games is better for the team. This is justified by the fact that creating content is a completely different type of activity than programming and organizing a project, and it is difficult for one to engage in such various activities. The minimum team is two people, the creator of the content and the developer. To avoid misunderstanding, I will clarify - in my opinion, an employee is also, to some extent, a member of the team.
  Of course, you can be engaged in the development and alone. There are some "crazy" who both write code, draw graphics, and compose music, but these are their problems.
  It is easy to assemble a team when there is funding - programmers and content creators forums, freelancers exchange can help you. In the absence of funding, you can only find a programmer, but you will not find a normal content creator - here you have to rely either on yourself or on luck.
• Legal clearance. Everything is simple here. If you want to have money from a game and protect yourself from a raider seizure (when someone steals your game insolently), then you need legal registration at the level of an individual entrepreneur. , . , , .
• . . , . , , .
• . , , . . , : - , -, (, , ). ¬– , , , .
  , , . . .
• . , , ( -), . . – .
  , .
• . ( , ). . , .

Afterword

The instruction turned out great, a lot of material. I strongly advise you to read it to novice game developers, since perhaps it will help them avoid mistakes in the future.

UPD: The article was successful, even very. But comments can be traced comments about the absence of romance and aversion to the games. Therefore, I will comment on these points.
Many omit the fact that the article for novice game developers applying for the role of leader(first paragraph of the article). I will not deny that over time, when you acquire the experience of developing games and life is going well, romance returns and the disgust subsides. But at the very beginning, when you start from scratch, after you encounter the first serious problems, this romance and love for games disappears to all hell. Game development is not a walk on the carpet in pink glasses, but a walk in the labyrinth of the Minotaur, where there are many dead ends.
I'm not going to instill confidence in novice developers with my article. They need to know that the game developer’s path is complicated, that they can meet unsolvable problems, that their unallocated project will be a symbol of defeat for them.