My experience in developing games for Android. Part one
Good afternoon, colleagues! On Habré, quite often there are posts about the development of the first Android applications, and I decided to also share my experience. This is my first writing experience on Habré and my first game, so please do not judge strictly.
The article was very large, so I divided it into two parts. In the first part, I wrote about the prerequisites for writing a game, about ideas and the technical side of implementation, and the second about the financial and psychological aspects of developing a game, publishing in a marketplace, and what came of all this. For those who want to immediately evaluate the game - here .
My acquaintance with the world of Android and mobile development began in the fall of 2010, when one friend asked me to write an application for him for this platform for a fee. Free time in the evenings, plus the desire to try something new (in general, I'm a .NET developer) - I agreed.
')
After the end of the project I decided to write my own application. There were three main reasons:
1) Android is still a young system, and there are many free niches that you can try to occupy.
2) Everything you need to develop is completely free to download and use.
3) Android Market requires a minimum of effort to distribute and sell applications - no need to mess with registrars, license keys, etc. You just have to write a good application, put the money yourself in the pocket :) Now it’s funny, of course, but then I thought that way.
No sooner said than done. I will not describe the whole development process and get into technical subtleties - instead, in this and subsequent articles I will focus on the main points and problems that I encountered.
The idea of the application is the alpha and omega of the future application, it is no less important than the implementation itself. I stopped at the game, because people played games, they play and they will play. Here, too, has its own subtleties: if you are a lonely developer and do not have a huge supply of free time, then you should not take up 3d monsters or platformers with hundreds of levels. Even a simple 3d game takes a lot of time, and it is better to underestimate your strength a bit, than to overestimate the project to see the light at all.
In my case, the choice fell on the section of logic games and puzzles, because they:
1) quite popular (downloads of leaders in this section reach tens of millions);
2) as a rule, not very difficult to implement - character animation is trivial, subject lines are simple, etc.
The main disadvantage of this choice is quite high competition in this section.
As a starting point, I took the game “Heat and Cold” - I liked it and my friends, and I did not find any analogues for it under Android. I reworked the rules, added another game mode and completely changed the design - it seemed to me enough that the game was fresh and interesting.
TK. After you have a good idea of what you are going to do, sit down and first thing ...throw it out of your head write it all down as some specification or TK for a future project - it will be very useful in the future. With the help of TK, you can control the timing of writing the game, do not miss the details and generally give the development process more order.
Prototype. No less important than TK is to write a prototype of the application — you can test the future interface of the game, control it and check a lot of things that were only “on paper” before.
My prototype looked like this:
Do not pay attention to the numbers - screenshots are taken from the assignment to the designer. Despite the simplicity, the prototype really helped me understand what kind of application should end up and give up on some obviously unnecessary things.
Emulator The transition to the Android platform from .NET was fairly painless, but the emulator could be better. I had to say goodbye to him immediately, as soon as I moved from the prototype to writing the main version of the game, the benefit was the opportunity to purchase a tablet and the cost of buying it was initially budgeted. The emulator speed loses to real devices several times, so you can forget about debugging animations or some complicated calculations on the emulator. The choice of the move, which took 1-2 seconds on the tablet, was made by the emulator in 8-10 seconds. In addition, I was terrified when a number of features that worked well on the emulator did not want to work on a real device (for example, playing background music). Therefore, even if during the whole period of development you will use the emulator, you definitely need to think about where to get at least one (and preferably two - a phone and a tablet) device for testing and focus on them.
I bought myself a 10-inch Asus EEE Pad Transformer tablet from an auction in America, and a friend (see below) Samsung Galaxy S. Thus, the problem with the devices for testing was solved.
User interface and management. Here it is, the scourge of mobile applications! Small screen, and how much you need to fit! If your game will be inconvenient to play or it will have a confusing interface - this will bury it at the start. Be sure to work on the prototype several management options (unless of course it is absolutely trivial), find a couple of different devices in format and try to play them, ask advice from those who will be the target audience of your game. And it would not hurt to hire a game designer, if funds allow it (unfortunately, my budget was limited).
I have one of the main problems in the interface was that the field is large, and it is necessary to fit it entirely on the screen - in this game the position on the map should be assessed entirely. In the end, if the game first looked like this:
then the final version was:
In the course of work, we had to first change the display angle of the field, then try to occupy the largest screen area under the field (abandoned a number of buttons on the game screen), and then, for the convenience of playing on mobile phones, make it possible to play the game in full screen mode.
Also in the course of work, the help section has undergone significant changes - from an eight-page section with page switching to a small page with scrolling. By the way, the section was reworked after negative user reviews.
And of course, as a Russian developer, I could not help but add support for the Russian language to the game, since I consider the Russian-speaking market segment to be very significant.
Graphics and design. Your game should have good graphics - that's all. If you yourself do not work in parallel as a designer and do not own a very good level of applications for drawing - do not harbor illusions about your strength, hire a designer and watch how it works, so that it turns out what you need. People most likely will not play a game where the graphics are “just marked”. The budget should definitely take into account the cost of the visual part, and they can take a significant part of the entire budget. A clear drawing, bright characters, good animation - only Tetris and tic-tac-toe survive without it all, and they have long been in Android.
I found a designer who, on the basis of his main work, draws for social games, and she provided me with a good price-performance ratio, but the work on the visual part continues now.
Fragmentation. This is not a myth, this is the real evil of Android. A bunch of devices with different characteristics and different screens, so your game may look at them differently. It remains only to create a lot of virtual devices with different characteristics and check the operation of the game and the interface to them. Actively use device classifiers in the names of folders with resources, separate styles, images and layouts according to different screen sizes and different dpi. Very tedious, but it's better than getting a hundred angry feedback from users and a low rating. In the end, I managed to achieve an acceptable menu display and games on all types of devices on which I was able to check.
I think the number of letters in this article has already reached indecent limits, so I’ll finish the first part with this.
Part Two .
The article was very large, so I divided it into two parts. In the first part, I wrote about the prerequisites for writing a game, about ideas and the technical side of implementation, and the second about the financial and psychological aspects of developing a game, publishing in a marketplace, and what came of all this. For those who want to immediately evaluate the game - here .
Prehistory
My acquaintance with the world of Android and mobile development began in the fall of 2010, when one friend asked me to write an application for him for this platform for a fee. Free time in the evenings, plus the desire to try something new (in general, I'm a .NET developer) - I agreed.
')
After the end of the project I decided to write my own application. There were three main reasons:
1) Android is still a young system, and there are many free niches that you can try to occupy.
2) Everything you need to develop is completely free to download and use.
3) Android Market requires a minimum of effort to distribute and sell applications - no need to mess with registrars, license keys, etc. You just have to write a good application, put the money yourself in the pocket :) Now it’s funny, of course, but then I thought that way.
No sooner said than done. I will not describe the whole development process and get into technical subtleties - instead, in this and subsequent articles I will focus on the main points and problems that I encountered.
Idea
The idea of the application is the alpha and omega of the future application, it is no less important than the implementation itself. I stopped at the game, because people played games, they play and they will play. Here, too, has its own subtleties: if you are a lonely developer and do not have a huge supply of free time, then you should not take up 3d monsters or platformers with hundreds of levels. Even a simple 3d game takes a lot of time, and it is better to underestimate your strength a bit, than to overestimate the project to see the light at all.
In my case, the choice fell on the section of logic games and puzzles, because they:
1) quite popular (downloads of leaders in this section reach tens of millions);
2) as a rule, not very difficult to implement - character animation is trivial, subject lines are simple, etc.
The main disadvantage of this choice is quite high competition in this section.
As a starting point, I took the game “Heat and Cold” - I liked it and my friends, and I did not find any analogues for it under Android. I reworked the rules, added another game mode and completely changed the design - it seemed to me enough that the game was fresh and interesting.
Technical side
TK. After you have a good idea of what you are going to do, sit down and first thing ...
Prototype. No less important than TK is to write a prototype of the application — you can test the future interface of the game, control it and check a lot of things that were only “on paper” before.
My prototype looked like this:
Do not pay attention to the numbers - screenshots are taken from the assignment to the designer. Despite the simplicity, the prototype really helped me understand what kind of application should end up and give up on some obviously unnecessary things.
Emulator The transition to the Android platform from .NET was fairly painless, but the emulator could be better. I had to say goodbye to him immediately, as soon as I moved from the prototype to writing the main version of the game, the benefit was the opportunity to purchase a tablet and the cost of buying it was initially budgeted. The emulator speed loses to real devices several times, so you can forget about debugging animations or some complicated calculations on the emulator. The choice of the move, which took 1-2 seconds on the tablet, was made by the emulator in 8-10 seconds. In addition, I was terrified when a number of features that worked well on the emulator did not want to work on a real device (for example, playing background music). Therefore, even if during the whole period of development you will use the emulator, you definitely need to think about where to get at least one (and preferably two - a phone and a tablet) device for testing and focus on them.
I bought myself a 10-inch Asus EEE Pad Transformer tablet from an auction in America, and a friend (see below) Samsung Galaxy S. Thus, the problem with the devices for testing was solved.
User interface and management. Here it is, the scourge of mobile applications! Small screen, and how much you need to fit! If your game will be inconvenient to play or it will have a confusing interface - this will bury it at the start. Be sure to work on the prototype several management options (unless of course it is absolutely trivial), find a couple of different devices in format and try to play them, ask advice from those who will be the target audience of your game. And it would not hurt to hire a game designer, if funds allow it (unfortunately, my budget was limited).
I have one of the main problems in the interface was that the field is large, and it is necessary to fit it entirely on the screen - in this game the position on the map should be assessed entirely. In the end, if the game first looked like this:
then the final version was:
In the course of work, we had to first change the display angle of the field, then try to occupy the largest screen area under the field (abandoned a number of buttons on the game screen), and then, for the convenience of playing on mobile phones, make it possible to play the game in full screen mode.
Also in the course of work, the help section has undergone significant changes - from an eight-page section with page switching to a small page with scrolling. By the way, the section was reworked after negative user reviews.
And of course, as a Russian developer, I could not help but add support for the Russian language to the game, since I consider the Russian-speaking market segment to be very significant.
Graphics and design. Your game should have good graphics - that's all. If you yourself do not work in parallel as a designer and do not own a very good level of applications for drawing - do not harbor illusions about your strength, hire a designer and watch how it works, so that it turns out what you need. People most likely will not play a game where the graphics are “just marked”. The budget should definitely take into account the cost of the visual part, and they can take a significant part of the entire budget. A clear drawing, bright characters, good animation - only Tetris and tic-tac-toe survive without it all, and they have long been in Android.
I found a designer who, on the basis of his main work, draws for social games, and she provided me with a good price-performance ratio, but the work on the visual part continues now.
Fragmentation. This is not a myth, this is the real evil of Android. A bunch of devices with different characteristics and different screens, so your game may look at them differently. It remains only to create a lot of virtual devices with different characteristics and check the operation of the game and the interface to them. Actively use device classifiers in the names of folders with resources, separate styles, images and layouts according to different screen sizes and different dpi. Very tedious, but it's better than getting a hundred angry feedback from users and a low rating. In the end, I managed to achieve an acceptable menu display and games on all types of devices on which I was able to check.
I think the number of letters in this article has already reached indecent limits, so I’ll finish the first part with this.
Part Two .
Source: https://habr.com/ru/post/126628/
All Articles