How I became an indie gamedev-developer or features of national development on my knee

I am not a professional software developer and programming has almost nothing to do with my main work activity. Everything is much worse - this is my hobby. A change of activity is very useful and allows you to take a break from dull and monotonous work, and if it also allows you to enjoy the process and the result, it is doubly useful.

For me, gamedev (game development) was always interesting. I think that every child (teenager, geek, substitute his own) had such a dream, albeit a distant and practically unattainable one. Most of them grow up and safely forget about it under the weight of current problems, and some keep it even until the moment when their children grow up and begin to craft something like that. I was lucky (or unlucky) to belong to the second group.


You can talk for a long time about how I became a gamedev-developer - it's all boring, tiring and not interesting. I can only say that periodically bumping into what I did earlier, I never get tired of being amazed at how much wild energy and perseverance there was to invent my own “bicycles”, and sometimes they were beautiful and worked on the verge of understanding. Over the years, experience has come, specific knowledge has accumulated, laziness has progressed more and more. There were many different attempts to build your own game engine (I think that more or less progressing HelloWorlds passed through this). Throwing Between GAPI(DX7 / 8/9, later there were attempts under OpenGL 1.1 / 2.1), programming languages ​​(C ++, C #). However, all this usually did not go beyond the implementation of the render and scene graph - self-motivation is a very unreliable ally. As time went on, open source engines were tried, thoughts of writing something of their own with varying success were driven deeper.

Engine selection

And then by chance unity3d turned up . By that time, I was completely lazy and agreed to write something exclusively in C # (it is just nice to write on it, unlike Java). I was struck by the system of the component approach for expanding the functionality of the unified object, and there is nothing to say about the convenient integration of the designer’s environment and the developer’s environment in one bottle. The main thing unity3d is speed and the ability to work on multiple platforms without any effort from the developer. Yes, there is a need for small adaptations, but on other engines in general darkness.


As one is not a warrior in the field, so the programmer will not be able to do much alone, especially if he does not know how to draw with decent quality. There were a lot of attempts to find adequate people for development, but the majority required money (which the indie developer does not have in principle) without consent to share participation, the rest were little like specialists in their fields. And here I was incredibly lucky. Through familiar acquaintances, an artist suddenly appeared who was himself looking for a programmer and just could not find. The result was a tandem about the cooperation process of which and the results will be written below.

Target platform

Android was chosen as a testing ground for mockery of the development: a small price to enter the market (now google play), a low entry threshold, and a mobile market for current glands, which could be more interesting?


Or PROEKT, what it was, and still remains. I must say right away that we did not have any temporary plans for development, the roles were not delimited in principle, everything was done randomly in the rest of our free time in the evenings and not every day. It sounds scary, but it worked and works because of the small number of people in the team, quick coordination of actions via Skype and regular mutual poking. Since we never worked together, it was decided to choose something simpler. The choice fell on the children's fairy tale "Kolobok". It will be ridiculous to someone from our ignorance of the kitchen of children's books on mobile devices, but then it seemed to us that it was simple, interesting, and would allow us to establish a working relationship.
It’s boring to make a simple fairy tale book, so it was decided to immediately make it interactive: the task of the child was to poke a finger on the screen, the task of the book was to give feedback on touching and entertain the child. In fact, it was all the technical requirements for the project.
Each of us had certain knowledge in our field and already imagined how and what it would look like. The artist was able to draw only in 2D (but he did it well), we did not argue, but discussed the data that I would get from him. All art was originally made in CorelDraw and partially animated (where non-linear animation was required) in Flash. At the output, I was given a scattering of sprites in png with alpha and a preview image of how everything should have looked like according to the artist. I had to collect all this, revive and force to interact with the user.
I must say that unity3d is a full-fledged 3d engine without the slightest hint of ordinary 2d. On the component market for unity3d (yes, there is one) there are four main systems for implementing sprites. All of them cost money, but as was said earlier, I’d better do mine than buy, there will be a kind of challenge. All sprite systems are implemented simply: two axes define the plane of the screen, the third axis becomes the depth for the sprite layers. Sprites are planes perpendicular to a texture overlay camera.
It sounds simple, but in fact one feature should be taken into account - the very weak hardware of mobile devices. There is such a thing as the amount of drawcall (hereinafter referred to as dc) (or drawindexedprimitives / drawelements, into which this is all translated internally during the rendering process) - each object is drawn by a separate call to the graphic api. Everything is simple, but the problem is that if on a desktop the number of such renderings can reach 1000 and relatively modern hardware does not choke, then for mobile devices this value should be kept at 20. Only 20 dec! Thank God, in Unity there is an automatic system of batching (batch - performing one operation on a lot of the same type of data, actually preparing data for SIMD) - unity3d independently sorts the geometry by materials (the number of texture block switching is reduced), combines geometry into large accumulative vertex buffers, which are then drawn at a time for each material. As a result, if you have one texture, say, bumps and you propagate this sprite, then unity3d will optimize all these sprites in one dc.
The second way to optimize is to create texture atlases.- the less materials there are, the less texture switching will be and the less dc will be. We had a lot of art and it was constantly changing - a utility was written to generate texture atlases, and this was done inside unity3d as an extension of the shell itself. All art was sorted into scenes, the general day of several scenes was taken out in a separate atlas. Now, when changing the art, I simply set the utility on the folder with the contents of the future atlas (all sprites, including all phases of the animation) and at the output I received one single texture + file describing the placement of sprites inside this texture (frame name, zone coordinates in the picture, animation speed , type of animation - linear / flip-flop, etc.).
The render itself was simple: all geometry was procedural and was regenerated when the animation frame changed (vertex and texture coordinates). As a result of all these tricks, some scenes of the book are drawn in 4-5 dec, do not hit in performance (they work well even on smartphones, not just tablets) and look good.
While all this was being developed, 2 unpleasant features were discovered:
  1. beat the artist's hands if he uses smooth gradients - they look terrible in hardware-supported compression formats like DX1 / 5, etc. In our case, all the textures had to be converted to full-fledged 32-bit texture atlases 1k x 1k - you can imagine how it affected the RAM and the filter.
  2. if you will scale sprites, know that automatic batching does not work on a scale other than This is very important for optimization, we had many objects that differ in size and are mirrored along the axes - for them we had to do additional scale baking in geometry and reset the scale to one. For dynamics, this did not work due to a significant complication of the code - I had to put up with it and use it to a minimum.

Variety of devices

The whole zoo of Android devices didn’t scare me. Initially, the practice of pixel-accurate toys was adopted as vicious and deadly for the developer / artist - we do not have the capacity to prepare several graphics packages for different dpi and aspect ratios. Everything was developed only for one standard size - 1024x600, landscape orientation. Everything that didn’t fit these sizes automatically scaled to the unity3d virtual camera and became 600 virtual units high, the width also kept proportions and was almost always larger than the real screen size, cropped off by the edges (which suited us - simply moved important objects away from the edges ) Practically, because it became possible to test the application on "Experia P" - there was not enough 1024 pixels wide and there were stripes at the edges.


The scoring was immediately ordered from a professional announcer - everything went without discussion at all. I had to spend money (the only cost), but to get a good result on the output, which immediately went to the release with a little dopilivaniyu, the good part of the software was already prepared and tested.

Preparation for publication

All development and testing took place in unity3d + builds were made for webplayer. To build for Android, you need 2 things: android sdk with the necessary platforms installed and unity3d license for Android. Unity3d allows you to build for various versions of Android, 2.2 was chosen as the main one due to the possibility of transferring to an SD-card. A publication license becomes a problem for an indie developer, because he still does not have any income from the project, but thanks to an attraction of unprecedented generosity that took place several months ago, I became the owner of the license for free.


I never thought that there would be such problems with the publication - in all articles they write that everything happens quickly and painlessly. In fact, Google has several servers, the synchronization of data between which is very slow. Those. you can edit the application data, fill in the new apk and see the old text / old distribution on the description page, and going to the application categories page - see something else (if edited several times). All this porridge is reduced to one form in about an hour and a half.


We did not do this in principle - I wrote a mini-review (in fact, an advertising announcement) on a couple of resources and calmed down on this. We were prepared for the fact that children's books, and even on Android, and even in Russian, were not very popular goods, so it’s stupid to wait for any significant profits. It was also noted that people do not like to pay in principle and like to spoil in the comments of free versions of applications, finding fault with trifles, which negatively affects the rating of applications. It was a strong-willed decision - to make only a paid version at an average price. The board has become a kind of entering threshold that protects us from trolls. This gave a magical effect: in 4 days we collected 4 reviews for 5 points and one for 4 points, which raised us to 13th place in our category and 17th place in the general top of new paid applications. And this is with 56 copies sold at the moment and 5 comments! I don’t understand how they consider ratings, but we are in the top and this cannot but rejoice.
Those who didn’t want to pay, raged on resources with PR articles, there were threats that they would break and steal, but they did not ruin our rating.


Should I become a game developer? Everyone decides for himself. There is definitely no way to get big profits on a couple of projects, but with constant work and continuous production you can get out (only these will not be indie teams). Be sure that a team without good theoretical and practical training in different areas will not last long - each participant must give something of his own, becoming part of a successful monolithic solution.

Z.Y. I tried not to write abstruse words, so that it would be clear to the majority, sorry if that.

Also popular now: