How I became an indie gamedev-developer or features of the national development on the knee
I am not a professional software developer and programming is almost completely unrelated to my main activity. Everything is much worse - this is my hobby. Change of activity is very useful and allows you to relax from the dull and monotonous work, and if it also allows you to extract pleasure from the process and the result, it is doubly useful.
Gamedev (game development) was always interesting for me. I think every child (teenager, geek, to substitute his own) had such a distant and practically unattainable, but a dream. Most 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 make something like that. I was lucky (or unlucky) to belong to the second group.
You can talk for a long time about how the formation of me as a gamedev-developer took place - it's all boring, tedious and not interesting. I can only say that, periodically, I stumble upon what I was doing earlier and do not get overwhelmed by how much wild energy and diligence there was of inventing my own “bicycles”, and sometimes they were beautiful and worked on the verge of understanding. Over the years, experience came, specific knowledge accumulated, and laziness progressed more and more. There were a lot of different attempts to build my game engine (I think, more and more less advanced HelloWorlds went 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 did not usually go beyond the implementation of the render and the scene graph - self-motivation is a very unreliable ally. As time went on, opensource-engines were tried, thoughts about writing something of their own, with varying success, were driven deeper.
And then unity3d accidentally turned up . By that time, I was already completely lazy and agreed to write something exclusively in C # (it’s just nice to write on it, unlike in Java). I was impressed by the system of the component approach for expanding the functionality of the unified object, and there’s nothing to say about the convenient integration of the designer’s environment and the developer’s environment in one bottle. The main ridge of unity3d is the speed and ability to work on multiple platforms without any effort on the part of the developer. Yes, there is a need for small adaptations, but on other engines in general is dark.
')
As one is not a warrior in the field, a programmer cannot 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 most demanded money (which the indie developer doesn’t have in principle) without consent to share participation, the rest were few of them as specialists in their fields. And then I was incredibly lucky. Through acquaintances of friends, an artist suddenly showed up, who himself was looking for a programmer and just could not find it. The result is a tandem about the process of cooperation and the results will be written further.
Android was chosen as a testing ground forbullying : a small price to enter the market (now google play), a low entry threshold, and a mobile market for current hardware, what could be more interesting?
Or the project that it was, and still remains. I’ll say right away that we didn’t have any time plans for development, the roles were not demarcated in principle, everything was done at random in spare time in the evenings and not every day. It sounds scary, but it worked and works due to the small number of people in the team, the rapid coordination of actions via Skype and regular mutual podinivaniya. Since we have never worked together, it was decided to choose something simpler. The choice fell on the children's fairy tale "Kolobok". Someone will be funny from our lack of information about 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 improve working relations.
It’s boring to make a simple fairy-tale booklet, so it was decided to immediately make it interactive: the child’s task was to poke a finger at the screen, the book’s task was to give a touchback and entertain the child. In fact, it was all the project terms of reference.
Each of us had certain knowledge in our field and already had an idea of ​​what it would look like. The artist knew how to draw only in 2D (but did it well), we did not argue, but discussed the data that I would receive from him. All art was originally made in CorelDraw and partially animated (where non-linear animation was required) in Flash. At the exit, I was given a scattering of sprites in png with alpha and a picture preview, as everything should look like according to the artist. I had to collect all this, animate and force interaction with the user.
I must say that unity3d is a full-fledged 3d engine without the slightest hint of the usual 2d. On the components market for unity3d (yes, there is one), there are four basic systems for the implementation of sprites. They all cost money, and as was said earlier, I would rather do my own than buy, there will be a challenge. All sprite systems are implemented simply: the two axes define the screen plane, the third axis becomes the depth for the sprite layers. Sprites are planes perpendicular to the camera with a superimposed texture.
It sounds simple, but in fact one thing to be considered is the very weak hardware of mobile devices. There is such a thing as the number of drawcall (hereinafter - dk) (or drawindexedprimitives / drawelements, into which all this is broadcast inside the render process) - each object is drawn by a separate call to the graphical API. Everything is simple, but the problem is that if the number of such drawings on the desktop can go up to 1000 and relatively modern hardware does not choke, then for mobile devices this value should be kept within 20. Only 20 dk! Thank God, in the unit there is an automatic batting system (batch - performing one operation on multiple data of the same type, actually preparing data for SIMD ) - the unity3d sorts the geometry by material (decreases the number of texture unit switching), integrates the geometry into large accumulative vertex buffers, which only then are drawn at once for each material. As a result, if you have one texture, say, bumps and you propagate this sprite, then unity3d optimizes all these sprites into one dk.
The second way to optimize is to create texture atlases - the less materials there are, the fewer texture switchings and the less dk. We had a lot of art and it was constantly changing - a utility for generating atlases of textures was written, and this was done inside the unity3d editor as an extension of the shell itself. All art was sorted by scenes, the total of several scenes of the day was moved to 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 animation phases) and at the output I got one single texture + file-description of the placement of sprites inside this texture (frame name, coordinates of the zone in the picture, animation speed type of animation - linear / flip-flop, etc.).
The render itself was simple: all geometry was procedural and regenerated when the animation frame was changed (vertex and texture coordinates). As a result of all these tricks, some scenes of the book are drawn for 4-5 dk, they do not beat performance (they work well even on smartphones, and not just on tablets) and they look good.
While all this was being developed, 2 unpleasant features were discovered:
I was not very scared by the whole zoo of devices on the Android platform. Initially, the practice of pixel-precise toys was accepted as vicious and murderous for a developer / artist - we do not have such capacities to prepare several graphics packages for different dpi and aspect ratios. Everything was developed only for one size - 1024x600, landscape orientation. Everything that did not fall under these dimensions automatically scaled under the unity3d virtual camera and became 600 virtual units high, the width also kept proportions and almost always was larger than the actual screen size, clipped to the edges (which we were satisfied with - just moved important objects 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 around the edges. As an option, arranged all, it was decided to slightly stretch the background width (coefficient 1.05) - it is imperceptible to the eye and eliminates the stripes on too long screens.
Voicing was immediately ordered from a professional announcer - everything went away without discussion. It was necessary to spend money (the only cost), but to get a good result at the output, which with a little dopilivaniyami immediately went into release, the benefit of the entire software part was already prepared and tested.
All development and testing took place in the unity3d + environment. The assemblies for webplayer were made. To build for Android, you need 2 things: android sdk with the necessary platforms installed and the unity3d license for Android. Unity3d allows you to collect under different versions of Android, the main one was chosen 2.2 because of the possibility of transferring to SD-card. The license for publication becomes a problem for the indie-developer, because he still has no income from the project, but thanks to the attraction of unprecedented generosity, which took place a few months ago, I became the owner of the license completely free of charge for myself.
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 them is very slow. Those. You can edit the application data, upload the new apk and see the old text / old distribution on the description page, and when you go to the application categories page, you can see something else there (if you have ruled several times). All this porridge is reduced to one type in about an hour and a half.
We didn’t do this in principle - I wrote a mini-review (in fact, an advertising announcement) for a couple of resources and calmed down on that. We were ready for the fact that children's books, and even on Android, and even in Russian - this is not a very popular product, so it’s foolish to expect any significant profits. It was also noticed that people do not like to pay in principle and like to be fooled by comments from free versions of applications, finding fault on trifles, which negatively affects the rating of applications. It was a volitional decision - to make only the paid version at an average price. The fee has become a kind of incoming 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 do not understand how they consider the ratings, but we are in the top and it can not but rejoice.
Those who did not want to pay, raged on resources with PR articles, there were threats that they would break and steal, but they did not spoil the rating.
Is it worth becoming a game developer? Everyone decides for himself. There are no big profits for a couple of projects here, 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 their own, becoming part of a successful monolithic solution.
ZY I tried not to write abstruse words so that it was clear to the majority, excuse me, if that.
Gamedev (game development) was always interesting for me. I think every child (teenager, geek, to substitute his own) had such a distant and practically unattainable, but a dream. Most 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 make something like that. I was lucky (or unlucky) to belong to the second group.
Prehistory
You can talk for a long time about how the formation of me as a gamedev-developer took place - it's all boring, tedious and not interesting. I can only say that, periodically, I stumble upon what I was doing earlier and do not get overwhelmed by how much wild energy and diligence there was of inventing my own “bicycles”, and sometimes they were beautiful and worked on the verge of understanding. Over the years, experience came, specific knowledge accumulated, and laziness progressed more and more. There were a lot of different attempts to build my game engine (I think, more and more less advanced HelloWorlds went 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 did not usually go beyond the implementation of the render and the scene graph - self-motivation is a very unreliable ally. As time went on, opensource-engines were tried, thoughts about writing something of their own, with varying success, were driven deeper.
Engine selection
And then unity3d accidentally turned up . By that time, I was already completely lazy and agreed to write something exclusively in C # (it’s just nice to write on it, unlike in Java). I was impressed by the system of the component approach for expanding the functionality of the unified object, and there’s nothing to say about the convenient integration of the designer’s environment and the developer’s environment in one bottle. The main ridge of unity3d is the speed and ability to work on multiple platforms without any effort on the part of the developer. Yes, there is a need for small adaptations, but on other engines in general is dark.
')
Team
As one is not a warrior in the field, a programmer cannot 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 most demanded money (which the indie developer doesn’t have in principle) without consent to share participation, the rest were few of them as specialists in their fields. And then I was incredibly lucky. Through acquaintances of friends, an artist suddenly showed up, who himself was looking for a programmer and just could not find it. The result is a tandem about the process of cooperation and the results will be written further.
Target platform
Android was chosen as a testing ground for
Project
Or the project that it was, and still remains. I’ll say right away that we didn’t have any time plans for development, the roles were not demarcated in principle, everything was done at random in spare time in the evenings and not every day. It sounds scary, but it worked and works due to the small number of people in the team, the rapid coordination of actions via Skype and regular mutual podinivaniya. Since we have never worked together, it was decided to choose something simpler. The choice fell on the children's fairy tale "Kolobok". Someone will be funny from our lack of information about 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 improve working relations.
It’s boring to make a simple fairy-tale booklet, so it was decided to immediately make it interactive: the child’s task was to poke a finger at the screen, the book’s task was to give a touchback and entertain the child. In fact, it was all the project terms of reference.
Each of us had certain knowledge in our field and already had an idea of ​​what it would look like. The artist knew how to draw only in 2D (but did it well), we did not argue, but discussed the data that I would receive from him. All art was originally made in CorelDraw and partially animated (where non-linear animation was required) in Flash. At the exit, I was given a scattering of sprites in png with alpha and a picture preview, as everything should look like according to the artist. I had to collect all this, animate and force interaction with the user.
I must say that unity3d is a full-fledged 3d engine without the slightest hint of the usual 2d. On the components market for unity3d (yes, there is one), there are four basic systems for the implementation of sprites. They all cost money, and as was said earlier, I would rather do my own than buy, there will be a challenge. All sprite systems are implemented simply: the two axes define the screen plane, the third axis becomes the depth for the sprite layers. Sprites are planes perpendicular to the camera with a superimposed texture.
It sounds simple, but in fact one thing to be considered is the very weak hardware of mobile devices. There is such a thing as the number of drawcall (hereinafter - dk) (or drawindexedprimitives / drawelements, into which all this is broadcast inside the render process) - each object is drawn by a separate call to the graphical API. Everything is simple, but the problem is that if the number of such drawings on the desktop can go up to 1000 and relatively modern hardware does not choke, then for mobile devices this value should be kept within 20. Only 20 dk! Thank God, in the unit there is an automatic batting system (batch - performing one operation on multiple data of the same type, actually preparing data for SIMD ) - the unity3d sorts the geometry by material (decreases the number of texture unit switching), integrates the geometry into large accumulative vertex buffers, which only then are drawn at once for each material. As a result, if you have one texture, say, bumps and you propagate this sprite, then unity3d optimizes all these sprites into one dk.
The second way to optimize is to create texture atlases - the less materials there are, the fewer texture switchings and the less dk. We had a lot of art and it was constantly changing - a utility for generating atlases of textures was written, and this was done inside the unity3d editor as an extension of the shell itself. All art was sorted by scenes, the total of several scenes of the day was moved to 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 animation phases) and at the output I got one single texture + file-description of the placement of sprites inside this texture (frame name, coordinates of the zone in the picture, animation speed type of animation - linear / flip-flop, etc.).
The render itself was simple: all geometry was procedural and regenerated when the animation frame was changed (vertex and texture coordinates). As a result of all these tricks, some scenes of the book are drawn for 4-5 dk, they do not beat performance (they work well even on smartphones, and not just on tablets) and they look good.
While all this was being developed, 2 unpleasant features were discovered:
- 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 translated into full-fledged 32-bit texture-atlases 1k x 1k - you can imagine how it affected the RAM and filet.
- if you scale the sprites, know that automatic batching does not work on a scale other than Vector3.one. This is very important for optimization, we had a lot of objects that differed from each other in size and mirrored along the axes - for them we had to do additional baking of the scale into geometry and resetting the scale to one. This was not suitable for dynamics due to the significant complication of the code - I had to accept and use it to the minimum.
Variety of devices
I was not very scared by the whole zoo of devices on the Android platform. Initially, the practice of pixel-precise toys was accepted as vicious and murderous for a developer / artist - we do not have such capacities to prepare several graphics packages for different dpi and aspect ratios. Everything was developed only for one size - 1024x600, landscape orientation. Everything that did not fall under these dimensions automatically scaled under the unity3d virtual camera and became 600 virtual units high, the width also kept proportions and almost always was larger than the actual screen size, clipped to the edges (which we were satisfied with - just moved important objects 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 around the edges. As an option, arranged all, it was decided to slightly stretch the background width (coefficient 1.05) - it is imperceptible to the eye and eliminates the stripes on too long screens.
Sound performance
Voicing was immediately ordered from a professional announcer - everything went away without discussion. It was necessary to spend money (the only cost), but to get a good result at the output, which with a little dopilivaniyami immediately went into release, the benefit of the entire software part was already prepared and tested.
Preparation for publication
All development and testing took place in the unity3d + environment. The assemblies for webplayer were made. To build for Android, you need 2 things: android sdk with the necessary platforms installed and the unity3d license for Android. Unity3d allows you to collect under different versions of Android, the main one was chosen 2.2 because of the possibility of transferring to SD-card. The license for publication becomes a problem for the indie-developer, because he still has no income from the project, but thanks to the attraction of unprecedented generosity, which took place a few months ago, I became the owner of the license completely free of charge for myself.
Publication
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 them is very slow. Those. You can edit the application data, upload the new apk and see the old text / old distribution on the description page, and when you go to the application categories page, you can see something else there (if you have ruled several times). All this porridge is reduced to one type in about an hour and a half.
Advertising
We didn’t do this in principle - I wrote a mini-review (in fact, an advertising announcement) for a couple of resources and calmed down on that. We were ready for the fact that children's books, and even on Android, and even in Russian - this is not a very popular product, so it’s foolish to expect any significant profits. It was also noticed that people do not like to pay in principle and like to be fooled by comments from free versions of applications, finding fault on trifles, which negatively affects the rating of applications. It was a volitional decision - to make only the paid version at an average price. The fee has become a kind of incoming 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 do not understand how they consider the ratings, but we are in the top and it can not but rejoice.
Those who did not want to pay, raged on resources with PR articles, there were threats that they would break and steal, but they did not spoil the rating.
Total
Is it worth becoming a game developer? Everyone decides for himself. There are no big profits for a couple of projects here, 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 their own, becoming part of a successful monolithic solution.
ZY I tried not to write abstruse words so that it was clear to the majority, excuse me, if that.
Source: https://habr.com/ru/post/146038/
All Articles