From idea to Google Play in 30 hours

Greetings, harazhiteli!

Today I want to share with you a story about how I did a lot of all the right things to bring the project to create a small toy from beginning to end. These things were: analysis, planning, design, TDD development and testing. And all this went along scrum. Yes, yes, in that composition and order. In general, all this should be the rule, the ideal route for the project, but not everyone does not always understand this. Well, at least I often get lazy and throw myself into code, forgetting about the rest. It is not difficult to guess what comes of this. But not this time, I told myself, and putting down the keyboard, I took the sheet and pen.

Disclaimer : This article is purely motivational. Technical details will be provided separately.

Motives

The main reason that spurred me on to this project was the desire to go all the way to developing games, even in the context of such a small project and even in a vacuum. But in the end, I still wanted to penetrate every aspect of the game dev. For myself, I decided that in the past I had already made enough mistakes with home projects, and this time everything should be like in adults.

Idea

The type of upcoming software was already predetermined - a game (there was somehow nothing to think about, subconsciously everything was decided a long time ago). The target platform of the first version assumed Android, but only because it is closer in spirit and does not require additional knowledge. Next, I thought about the genre. Despite the shooters and real-time strategies that pop up in my imagination, I, pessimistic about my strength, decided to follow the quick win principle and aimed at a simple puzzle. Among the abundance of puzzles, the first filler arose in my memory, a field of rhombuses of different colors and the only goal: to capture more than half of all cells. On this and stopped. Of course, as expected, the search yielded similar results, but nevertheless, not so many, and the choice was approved.

Breakdown into tasks and their planning

Before calculating labor costs and distributing tasks according to the calendar, it was necessary to consider the final product from all sides, decompose it to the level of elementary tasks, select tools, libraries, estimate the testing process and production.

First of all, preliminary mockups were created on a piece of paper (or rather a couple of dozen A4). Then it was decided to fully depict them in Photoshop, so there was a chance to prevent visual inaccuracies during design. There is no artist from me, so in the end I had to look for lessons on the Internet (how much success you managed to judge). But it was decided to build the sketches from the final versions of the resources, so I tried to kill two birds with one stone, and already at the end of the project I can say that this decision was successful.

Next, I thought out the business logic from A to Z (it is important to understand that even if small algorithms are not thought out at this stage, they will have to be fired in a hurry at the development stage, so I highly recommend not to neglect this) and made up the functional requirements. Based on this information, I moved on to choosing a framework.

The spirit of the experimenter suggested that something new should be tried out. So I met cocos2d-x. I will not list the benefits. Inquisitive users have already gone Google, and those who are familiar with this platform will understand me in my choice. I’ll just notice from myself - both the functionality and performance, and the license fit my requirements perfectly. Now that the framework was known, it became easier with the assessment of labor costs.

And the code is still too early to write, but based on the available information, you can do UML. I strongly recommend that you cover yourself with all the materials that are currently collected and build-build-build class diagrams. I spent the whole evening on this activity. The first option was, as before, tyap-blunder, and managed. But the class diagram should save the developer from designing the architecture on the go. Therefore, all the boxes went into the trash and the second round began. Somewhere in the middle of it, I again made a mistake of excessive simplification and it was only the third time that I managed to compose a very decent document. Looking ahead, I’ll say that it corresponds to the real code by more than 80%.

To summarize and go over the entire scribble, I determined 10 hours to work with resources (by the way I took the music ready, which I really don’t know how to do), 20 hours of pure programming, and 10 hours for testing and bug fixing.

Let's get started!

So, the list of tasks has been compiled, we proceed to implementation. On the calendar was the beginning of the vacation, and his hands, not weaned from the keyboard at work, were already scratching and rushing into battle. But in order to continue to follow the best practices, I sat down at photoshop. And, lo and behold, I did not need to invent a job for myself. Everything was clearly decomposed and painted for me:
- In total, 5 screens.
- 1st day, menu screen, and game mode selection. They depict ..., ... buttons, ... elements and so on.
- 2nd day, the playing field, which depicts ..., ... and so on.
- 3rd day, pause and end game screen.
Wielding scrum, I set aside tasks for myself, prioritized them, set limits and managed a backlog, in short there was a king and a god. Everything tasted very well systematized my work. For myself, I made a small rule - not to take into development more than 2 interchangeable tasks. Stalled on one, move on to the other, and later return to the first.
Resource preparation took three evenings, for a total of 7 hours. Such advancing graphics warmed the soul.

We pass to development. We have 20 hours. How can I follow the progress and at least indirectly understand if I have time? And here's how: 20 hours is a rounded number, consisting of the sum of the labor required to implement each element of the class diagram. Now, to understand what parts of the program are ready, and what overall progress has been made, the following method has been invented:
- we implement all-all classes / methods, but put dummies inside, we only need a successful compilation;
- for each method, we throw Unit tests (3-5 pieces for each);
- now, when assembling, you can see how many tests passed, and this is% of completion of the project, and how many tests fell, and this is the part that has not yet been implemented.
Thus, we have an indicator of the progress of the project.

A separate paragraph deserves information about monetization. Of course, for the time and effort spent, I want a reward. Therefore, it was decided to fasten some advertising. Google AdMob has different types of promotional messages. But I chose this strategy: during the game - no advertising, but only a full-page banner after exiting the game. Here I also want to talk about a small architectural feint (this is from 20% of the code that does not correspond to the class diagram). Cocos2dx at the end of the game does not go the normal way to finalize the application, it does not call onDestroy, etc., it just kill the current thread with the application. At the same time, cramming ads into a native library is also a non-trivial task.
The solution is this:
1) after the user closes the game (by clicking Exit), the main field of the game is hidden and JNI comes to the rescue, which pulls the display of a new Activity with advertising;
2) when the advertisement is either closed by the user, or is minimized, or is there some other option (Back / Home / Menu buttons, etc.), again JNI, but in the opposite direction it sends a call to finalize the game and that's it closes.

Testing

For testing, I applied two strategies (again, even at this stage I had everything planned and went according to plan):
1) manual testing. Fortunately, the wife is a QA engineer. Special thanks for the help.
2) automated testing. Now the Internet is actively developing services that provide remote access to real phones / tablets in order to test applications under development (I will provide links below). A positive feature of such services is the presence of a trial period of use. For myself, I have identified three such services. The first is in order to be able to run the final application on different devices. The second is for measuring performance and load. And the third - for mass surface testing on a large number of devices.

In total, both strategies yielded about a dozen obvious problems, and again the planned amount of labor was not fully utilized.

Production

Better to see once than to hear seven times.

Total

- Invaluable experience!
- 18 hours of development + 7 hours of preparation of resources + 5 hours of testing = 30 hours of real work, for which it is not a shame.
- Pride for the project that is brought to an end! And a wild desire to share the achievement (which is why, not having enough sleep, I dress up this article).
- The hope that something will come of this (it may be empty, since I had no previous experience in the mini-commercial game dev).
- Motivation / tips for readers.

What remains to be done (if the project begins to show signs of popularity):
1) Launch the game for iOS and Windows Phone 8, and most likely the desktop version for Windows.
2) Fasten google analytics to analyze the behavior of players.
3) Extend the functionality: difficulty levels, field / cell sizes, general top (somewhere in the cloud).

If I did not cover any details of interest, write in the comments, I will definitely answer.

Useful links:
1) play.google.com/store/apps/details?id=com.xlab.ice.HexFiller - actually my "masterpiece"
2) appthwack.com - mass testing service
3) cloud.testdroid.com/web / home - application performance testing service
4) testobject.com - the ability to run the application on many devices with subsequent interaction
5) developers.google.com/mobile-ads-sdk/docs/admob/advanced - interstitial ads

Behind the scenes were the nuances of preparing graphics, working with different displays, assembling, running on an emulator, an AI game strategy algorithm, and all sorts of little things. But this article is more motivational in nature. And yet, if anyone will be interested to hear the unsaid - vote, I will write the second part of the article.

Thanks for reading!
As you can see, a serious approach even to small projects is paying off. Both time saving and the final result, all this points to the negative aspects of the disregard for the pre-coding / post-coding stages, which must have everywhere. Now I have learned it.

PS Thanks reenboog for tips on graphics and resources and coder1cv8 for tips on monetization.