Memo to a novice computer game developer

This article is aimed at schoolchildren, students, and those who are older, who have never tried, but really want to start writing computer games. Who in childhood did not play computer games, and did not want to write his own game, which will be better than GTA or Crysis? And I wanted, and, oddly enough, I still want to. And for several years of practice teaching the same programmers, I got a few notes on where to go and what to do.



The article does not claim to be completely accurate and accurate, it is written by just one person who has gathered his experience in just a few years. Also, it considers only the practical and romantic side: it does not cover the issues of monetization and getting any benefits from games other than satisfying one's beloved, and possibly others.

1. Where to start?

From practice. You can start with pure C and OpenGL / DirectX, this is the way of the samurai, because to learn it from scratch, without any abstractions, is quite difficult.



You can use frameworks like SDL, or higher-level LibGDX / PyGame / LÖVE2D if C / C ++ seems too confused. Here the level of abstraction is a little higher, so working a little easier, but you have to do the whole organization of the internal structure of the game yourself, realizing what a game cycle is and how to organize an event system in it. This approach provides a good level of knowledge and skills, but, at first, it does not provide an incentive to climb into the depths of iron wilds.



And finally, you can take a game engine like Unity / Unreal / CryEngine / Godot, and make a toy on it.



So, how do we choose from all this diversity? But this is only a small part. The typical trap that a novice yet-non-developer falls into is the choice of a tool. Framework / engine and language. Many articles are read, video tutorials are watched, somewhere great things are said about something, somewhere nasty things are told about the same ... There is no ideal system and does not exist, otherwise the Ideal Game Engine would have been invented long ago (along with Ideal Programming Language), and all corporations would simply be looking for “programmers,” not programmers in any particular ecosystem. We just take the tool that is better suited to our task, or just more like it, and a person who can’t choose can stay in the same place where he was for years, without any progress.

So how to choose? We can just take the first one, and begin to understand. Didn't like it when using it for longer than a week or two? We take the following, and immediately write something simple like a snake, along the way reading the documentation for the selected tool and looking in Google for everything else, and writing out the design document for our Super Game, which will kill Diablo and Doom at the same time. Why start with something simple when we already have the idea of ​​a Super Game? Everything is very simple, the level of skill of a novice developer is always so low that he will rewrite his Super Game twenty times, the results will not live up to expectations, and behind this frustration is a complete cooling off to the idea of ​​writing your game and programming in general. At the start of training, we do simple things that you can immediately feel and play with friends right there, competing in records. This is our incentive, this is our joy from self-education and productive brain activity, this is something that does not allow us to burn out. After the snake, you can first look at this snake and try to rewrite it “in the normal way”, because the first snake, even a perfectly working one, will have a monster-like internal structure, changing the look of the snake will be very difficult, and adding a new bonus to it will be even more difficult . And then rewrite it again, or move on to something else, otherwise this snake is already sitting in the liver. Now we will make, for example, a ball jumping from the walls, which need to get into the ring, it does not matter what, in fact, would be an idea.



There are only a couple of tips for choosing: in my opinion, you should not take something too low-level, because we are kind of writing games here, rather than interrupting bit flags and indulging in pointers. With something very low level, it’s very easy to go to distant jungle, and spend a few months almost wasted. And do not take something too high-level (like engines), because they give too high a level of abstraction. As long as we don’t know how the engines are arranged, we don’t make much sense to use other people's developments, we would have to understand how it is organized, because everyone in the world of engines has many internal limitations that we will have to deal with in the future, and we have hands and feet connected lack of information and understanding of the process, plus as soon as some hole in the engine leaks , we can’t do anything until we fully understand its internal structure. The balance of the complexity of learning and freedom of action.

2. How to study?

Here one extremely useful skill called “googling” is useful to us. The Internet is a huge source of information, which for some reason, in my memory, is usually underestimated, and the second page of the search engine is already something unattainable. Therefore, we learn to ask such questions to the search engine so that it gives the sample we need. In general, at the start, video tutorials will come down. And you can read textbooks. Video lessons have the advantage that they immediately give a tangible result in a short time, which is very useful for motivation, but they have big problems with the completeness of information, so no one canceled the textbooks and documentation. You can search for and look at code examples on the github, this is an extremely useful lesson, from which you can draw no less than from textbooks. We look at everything incomprehensible in someone else's code, and look on the net for what it was just here. Then we use (or not, hehe). Theft of ideas and concepts is only encouraged (if the code was under a free license). If something is straightforward quite complicated, but very necessary - it is not forbidden to contact other people in forums and chat rooms, but it is very easy to start abusing this method, therefore it is not advisable and only if completely baked, and several hours of competent search were unsuccessful. From the areas of mathematics, I strongly advise you to read and understand vector algebra, analytic geometry, probability theory and a lot of smart words, since these are quite universal areas that are useful not only in games. Of the languages ​​- obvious English, most of the documentation is written in English. Using translators is not forbidden. Again, here we most need to learn how to learn and look for information, it will come in handy everywhere and always, not only in this area. However, training should not overshadow practice and vice versa. It is advisable to keep the ratio of time between writing and studying at the level of 20/80, and then, practice can only be added, eternal students are good, but impractical. Balancing time.

3. Wanted something more serious?

After the last stage and several (dozens) prototypes of games, we have already learned to write tolerably well, maybe even with a not very large number of nested if-elseif-elseif. We found and read several dozens of other people's projects, and even if half did not understand, this is still not very scary, because we already seem ready to do something serious, such as the Super Game? Hold the horses. We have several prototypes, and they even play great, but we have not even tried to finish our work. As soon as something became more or less working, we just moved on to something more interesting, but we are still waiting for an extremely harsh stage, at which very many (including me, hehe) break down: creating the Finished Project. How does it differ from our prototypes? And here’s what: The Finished Project is the same prototype, but it’s been spent three times longer than the prototype part, we made all the menus, settings, checked that it works fine at different screen resolutions and with different keyboards, at least a dozen levels or a choice of difficulty level so that it is interesting to play not only to the author and his friends, but also to random people at school or university. The most routine part, what to say, but the most useful, and very well trained will to win. If you do not go through this stage, you can remain a prototype writer for life. Balancing yourself in routine and fun.

4. Where to look for libraries?

If you carefully read the second paragraph, the answer becomes seemingly obvious: online, in repositories and from other people. And as if all is well, we save time and immediately do something cool. But while we study and we have time, and we have the opportunity to build bicycles - it’s a sin not to take this opportunity. If reading textbooks and articles, and viewing lessons is an extension of our knowledge, then writing our own libraries is a deepening, and on several fronts at once: implementing convenient APIs (cutting off superfluous and balancing performance and usability), deepening and exploring the insides of our language-iron ecosystem , and the creation of small finished modules, even if they partially duplicate the functionality of existing ones. But the main thing here is not to go in cycles. We are still writing games, and a toolkit for them, here you can just as well become a library writer, and never do a single Finished Project. But here is also a huge layer of general experience.

5. Conclusion.

There are still many unanswered questions, some of which will be briefly answered here.

What is a design document and why is it needed? This is such a wiki on a game not yet created, the fuller the better. And this thing should be done before the start of the game, roughly estimating the development time with the available number of people and cutting off features.



Why cut off features? Passing through the previous stages, you can approximately estimate the time during which you and your team will get tired of doing this project. If we are in a situation of basement indie development without funding and a work schedule, there is a very high chance of confusion and reeling instead of implementing the project. All the cool stuff is implemented very quickly, and there remains a lot of routine, which nevertheless needs to be done, and our task is to balance the coolness and the routine so as to finish it all the same.



Where to look for artists / musicians / designers? To begin with, you can make an Almost Finished Project, without graphics and sounds, with sprites scribbled in msPaint and the same clumsy animations and fuck-bangs from free resources found on the network. I really do not recommend loading other people with something that is not yet finished and has high chances to remain unfinished.



Actually, I was going to get a job at Valve, EpicGames or anywhere else, and work there, why do I need all this? Most of the programmers in the world are self-taught, often with extensive "basement" experience, moreover, prototypes and small toys are an excellent portfolio for placement in large companies, and not only for the position of game developer.



Bonus: Most of these techniques are suitable for absolutely any field, not only programming games, but also just programming. Moreover, you can get an art education or learn curly carving, using the same instructions after small edits in the right direction.



Thanks for reading, the article is subject to criticism and additions.