Nontrivial implementation of noughts and crosses under Android

This article will tell you about Java tic-tac-toe for Android for 30 lines of code, five and a half thousand lines of code, and why it took so much code for such a simple game. A year ago, on December 9, I posted my game on Google Play. Now I want to tell you about what happened this year, how the popularity of the game grew, what worked and what did not. You will see the net statistics of downloads and deletions for the year of existence of the game, numbers. Find out how many users can be collected from Google Play, how the game was created, how it was tested. You will find out whether it is possible to create an indie game with a zero budget, what difficulties a small game can have in a big world. Who cares, welcome.

Introduction

I have long tried to make toys, mostly simple. After learning Java, I decided to try to do something useful in this language. Having learned that you can write Java for Android games, I decided to try to do something simple in order to learn how to make apps for smartphones.

Idea

Now we need an idea that is too simple for time to fail if not successful, and too unique for an application to simply remain the next name in the multi-million list of applications. I chose tic-tac-toe. Too easy? There are many such games? Now it was necessary to come up with something unique. Why now all computer tic-tac-toe work on the principle clicked - set? So I decided that let the figures draw, and the game itself will determine what is drawn. Now, how to make the implementation? Options:

• Each cell is a bitmap image. Disadvantage: you can not draw abroad, otherwise it looks crooked, memory consumption. Pluses: simplicity. An analogue of this is already on the Internet, but not for mobile.
• The whole field is a raster image. Disadvantage: look for figures all over the image, probably printed text is easier to recognize than to find curved figures, the problem of disconnecting glued figures, a large load on the CPU. Dignity: You can draw a cross, running into the next cell.
• Figures - vector. Disadvantages: it is possible to redraw a long (but you can solve it using buffering). Advantages: it is possible to divide the figures which have run at each other, it is easy to change the position of individual figures.

Googling a bit, I did not find anything like it. The idea is good: drawing figures gives the game freedom of choice, the player himself determines the shape of the figure. Therefore, the idea of ​​the game is to provide freedom of drawing, freedom of “cheating” - sketching enemy figures, and freedom of settings and rules of the game (field size, etc.). There are also drawbacks: drawing a cross or a zero is much longer than just clicking on a cell . Therefore, not everyone likes this game.

Name of the game and search for similar games

Before creating a game, I quickly looked for similar games. Under Android, I did not find any such games. I thought the game was called “tic-tac-toe” + drawing. Since there are a lot of noughts and crosses under Android, I decided to postpone this difficult, short stage of creating a game and come up with a final name after a working prototype is ready. After a working prototype, I began to write the name of the game. Then, translating the “tic-tac-toe” into English, and putting the word “Draw” to them, I found, perhaps, the only competitor to the tic-tac-toe with drawing. I needed to include “drawing” in the name of the game. Thinking over the word Draw and the need to include a word about drawing in the name of the game, it was decided to call the game “Tic-Tac-Toe Drawing!”. If you say that the name is very consonant with the others, then how can you call the game of tic-tac-toe, if only paid tic-tac-toe is more than 250 in Google Play, and the free ones are more than 1000?

Implementations

UPD: Features of the game that were required to implement:

• Drawing figures by player, recognition of drawn figures
• Different size of the playing field: from 3x3 to 12x12 (it can be more, but restrictions are imposed by the screen size of many devices)
• Accordingly, the game is not only 3 in a row, but 4, 5, 6 in a row

From here, problems arose: once you can draw anywhere, you can change the opponent’s pieces, gloss over, sketch, erase, even walk outside your turn (yes, you can do it if you draw two crosses at the same time). What to do in such cases? Ban or allow? It was decided to allow, leaving the opportunity to win in any form, but then with a victory to display a complaint of cheating, for example: "Unfair victory."

Choosing a development environment and overall creation plan

While I was looking at what to write for Android, Eclipse was downloaded, the documentation was studied, I decided to start on what I had installed - on NetBeans. I thought that in Java android is the same as simple Java, they should be almost the same, so the logic (engine) can be written separately. According to my plan, the game had to be divided into two packages: Engine and GUI. The engine is a game engine, game logic, this package is almost independent of the implementation of the GUI and OS, it has an interface for interacting with the GUI: receiving incoming events and output. GUI - depends on the OS. For porting to Android, you need to replace only the GUI, without touching the Engine, or almost without touching. That was my plan. The idea was good, but at the time of the translation under Android there was a problem with adaptation (described below).

Game development

Program development cycle

In order to know exactly what to do, I decided to write down by points what my game should do and what needs to be realized. At first I took a piece of paper on which I wrote down the main sections: Engine, AI, Graphics, Bugs, etc., then for each category I wrote down problems that need to be solved. As the decision progressed, I ticked off what was done, replenished the lists with new ideas as I was done, increased the “bugs” section and sometimes other sections as they were debugged. Then I finished the second sheet, but two sheets were quite enough. Since development and support were planned not for a couple of days, but for a long period, for planning and better support, not only sheets with points were used, it was also decided to comment well on the code (see Javadoc ). The development of the game was divided into 2 stages: make a version for PC, transfer to Android. The first version (alpha) was made for PC. It was implemented in stages:

1. simple GUI, drawing lines with mouse, cell. Recognize lines as crosses and zeros. (Coloring the shapes, in accordance with the recognized shape, was done to debug the pattern recognition, then, since it turned out beautifully, it was left in the game)
2. rules of victory, the game man with man.
3. game AI, game mode with a computer.

The life cycle of each of the above stages:

1. drawing up a list of basic requirements
2. programming
3. check result and debug. If errors are detected that are incompatible with the work of the program, go to step 1)

At the next stage, the algorithms were perfected. The cycle of these improvements is similar to the one described above:

1. compiling a list of problems
2. programming
3. check result and debug. Now I was looking for something that could be improved.

Basically, these improvements were related to the recognition of figures and the game of the bot, the writing of which will be written further. At the second stage, the game was ported to Eclipse, and the creation of the GUI for Android began. There are problems with the compatibility of the engine with Android. In the usual Java canvas coordinates (Graphics) - int, in Android - float. Many of the drawing functions and classes (Canvas = Drawable, etc.), and the data structure for drawLine were also distinguished by their names. I had to write a “format converter” (crutch) and replace the data type names. I managed to do all this in an hour and a half, as there were mainly differences in names, not in logic. Then further improvements, drawing pictures. After the integration of the engine and the new GUI was completed, testing and debugging began. The life cycle of these improvements is similar to the above :

1. Checking the game: running on an emulator with different screen sizes, the game.
2. List problems
3. Troubleshooting

This process continued until it was decided that the game had no flaws. The first release, version 1.0, was released.

How the AI ​​was written

The development of the Bot (the term AI was used in the game for abbreviations) for simple noughts and crosses looks like a simple task. But I wanted this AI to be universal: it worked on a field of any size, and not only in game 3 in a row, but also n-in a row. Some implementations of AI worked well on a large field, but easily lost on a small field, or vice versa. Since each implementation of AI required testing not only for some performance, but also for the opportunity to win the game, I first had to test AI manually. just play with him. But, it was too slow, and the assessment of success was subjective, so I found another way to test AI. The AI ​​was fully implemented as a class, so a separate program for testing AI was made: two different classes of AI were launched that played on the virtual playing field, the results were output to the console (who won, for how many moves). Also, if it was necessary, the data for each move were output in text format (game situation, what the AI ​​thinks about the profitability of each cell). For the standard of a well-playing opponent was to take open-source AI from game 5 in a row, which I found on a launchpad. Tests were conducted several times to reduce the effect of randomness. So 2 AIs were made: normal and complex. They were very different in implementation: complex AI worked on the principle of tracing possible paths, and the average on a simple principle: sorting the cells, where to put to win, or not to lose, or at least something was close, otherwise random. Therefore, until I optimized the victory analysis algorithm (version 1.5), the complex AI was many times faster than the average and easy, in games with a field larger than 3x3. After not too much was thrown out of the middle AI, an easy level of difficulty appeared.

Code

Briefly about the code of the game in Java: just pure source takes 275 KB, of which 75% Engine. The code is divided into three packages, about 22 classes are used. A total of 5670 lines of code, but a lot of comments, commented out parts and empty lines, so the clean code is about 4000, an average of 250 lines per class (file). The main engine was written in a couple of weeks, it was possible to speed up to one week. When writing the code, there were dangerous places where an error could occur (for example, the design turned out to be too complicated), I marked it with comments // FIXME and // TODO. Comments concentration: one FIXME for 400 lines of code and about 1 TODO for 60 lines of code. When in the process of testing I discovered shortcomings, I either immediately understood what to fix, or the errors were precisely in these lines. Also, before each release, I tested the game, playing 5-10 times with different settings.The result is a robust application, as evidenced by the report "Crashes and ANR". However, there are more explanations for this: try - catch blocks were used, which is not very good, but in some cases in the event of a failure, the application should automatically disable the “experimental” functions and switch to their older versions; or Google this page does not work; or too few people use the game.

Releases and translations

Translation of applications for Android is very simple: all strings are stored in the strings.xml file, which is located in the values ​​folder. The default language is English. To add the Russian language (and others), you need to create the values-ru folder, and create a copy of the strings.xml file, which will contain translated string substitutes. All lines in the application are obtained through the API. To speed up the translation, you can use electronic translators, for example, I used Google Translator. Before the translation of the game, I was not sure of my knowledge of the English language, after translation the uncertainty in the knowledge of English passed to Google Translator. When translating, at least try to translate the received sentences into the original language. And it is better, additionally translate by words yourself and compare with how the translator translated. There were cases when a computer translator distorted the meaning too much and accepted some words as others by meaning. The application was translated into English, so there was support for two languages. I will tell you more about the impact of translations on downloads. The first release of the game was on the evening of December 9, 2012. The very next day in the statistics, I saw that on the first day there was 1 download. Before the release, I thought what number to give to the first version: 0.99 or 1.0? Since I decided that almost everything worked on the emulator and I could play on it, I have the right to give the number 1.0. I was very wrong then, because many users complained that they could not play this game. Users complained that they had big brakes in the game, others did not display the graphics correctly. And they were right, it was impossible to play 90% of real devices. The problem with the brakes was due to the fact that the graphics were drawn by redrawing the entire Drawable canvas, and a lot of resources were spent on this. I had to quickly find a solution, and it was found. No, not through OpenGL. Redrawing can be done as the entire canvas (repaint (), onPaint ()), and fragments (repaintCliping (), onPaint (rect)). It was necessary to teach the game to determine the necessary areas of redrawing, and to plan in advance the zones of redrawing (to combine intersecting zones, to separate the separated zones of redrawing). All these improvements and advice from some people were collected in the new version, which came out in a week. During each update, I thought that each previous version was bad and it was impossible to play it, and the new one was the best, and there was not a single drawback. . Testing releases were made at first only on the emulator. This device was useful to me only for two purposes: 1) to realize how it is crookedly drawn that the emulator did not show; 2) to test multitouch. While I had been developing and testing the game for so long, I was used to drawing even figures, and did not notice that not all players draw such even figures, so often the figures were not recognized. According to this, when I gave friends to play, I was surprised that the program almost did not understand their drawings. I had to improve the recognition again. As the list of changes is on the page about the game, I will list what main problems the updates solved. Version 1.1: since the surface was implemented as an overloaded View, the entire canvas (Redraw) was redrawn, the graphics slowed down. Implemented support for PaintClipping (), which made it possible to redraw not the entire screen, but only the changing part, which greatly accelerated the drawing. The following updates: fixed problems with motion animation by disabling it; design; multitouch; records First optimizations: I noticed that I accidentally zakopipastil 2 times the drawing, I painted 2 times the same thing; optimization using caches.

Compiler errors? They are?

Somewhere I read an article about the fact that compiler errors are actually programmer errors. But I ran into real errors, of course not the compiler errors themselves, but the SDK and plug-in errors:

• The emulator emulates "ideal" devices. When testing the graphics in the emulator, it looked fine. On some devices, it also looked fine. But on most real devices, when animating the figures of the graphics, it looked awful: the figures split in two and moved together (presumably the reason for using the Matrix transformation matrix, for Java this is AffineTransform).
• Compiler error? I spent quite a few hours debugging the time of the game: the game time was displayed inside the button, as its name, and not in the text field. Solution: it turned out it was necessary to press the “clean project” button before compiling and then everything was fixed (in the official documentation from Google it is recommended to press this button each time before assembling apk, but who reads it?). Perhaps this is due to updating the SDK, but to confuse the names of resources - this can be attributed to compiler errors.
• There were also API errors, some obsolete (deprecated) functions, again, in the emulator, behaved as expected, and on the real device they returned incomprehensible values.

Separately, I want to say about the built-in ProGuard. Contrary to the opinion of the majority, it works, but with the conditions: on the way to the SDK, home folder, folder with the project and its name, there should be neither spaces nor Cyrillic. Then it works (do not forget to uncomment the necessary lines in the project.properties). You can manually obfuscation (I had to do this until I set up ProGuard). To do this, first make a copy of the project. Then we go to the project settings (where to add) and remove unnecessary checkboxes in the “Java Compiler” section in the “Classfile Generation” group. Next, using the “Refractor> Move ...” and “Refractor> Rename ...” tools, we turn the code into something incomprehensible. As this process does not forget to check the residual performance of the code.

Graphics

For drawing the graphics were used: GIMP is a raster editor, and Inkscape is a vector editor. At first glance, GIMP seemed to me much worse than Photoshop, there are no functions in it (or I did not find it). At first it seems very uncomfortable, and it seems that you cannot even draw a line on it. But over time you get used to it, and you understand what it is like opening a photoshop for the first time, when only Paint had seen it before. In GIMP you can draw. Inkscape is also simpler than CorelDraw, but I didn’t need anything more from it. Simple enough, clear editor. Good design was not immediately.

Statistics and marketing

I did not hope to get money through the game, so I didn’t advertise it anywhere. Also, I decided to collect real statistics in the absence of advertising, therefore, sometimes I didn’t even promote it, but there were some attempts at promotion.

Promotion

In the first week I tried to write about the game on w3bsit3-dns.com. He wrote in some branches of the forum (increase to download +15 - +40), without having read their rules, for which he was banned for a couple of days. Then he wrote on the branches of their forum for developers, from where he received valuable advice, a couple of extra installations (+10), and some good reviews on Google Play (+2). They had a project to support game development from the CIS countries, it was that you write a review of the game, and they host it for free, they say now they have closed this project. But for some reason they didn’t accept me to this project, they didn’t like the site with “.com”, they didn’t find my site on the site.

Google Play Reviews

They say that you do not need to worry about single reviews and ratings on Google Play. This is so - people are different, different opinions, someone expects something completely different than you think. They do not read the description of the game, thereby downloading what someone does not need, or they miss an interesting game. However, if several people write that “it’s impossible to play,” or even describe “non-existent” bugs in more detail (“the cross is drawn above cm by 2”), then this is not just that. The emulator can deceive you, your device may also act differently from others. In this case, you should not miss such reviews, but try to find out what is happening on the users' devices and deal with it. I would like to note that in a year, with more than 5000 downloads and 1000 users, only 5 letters came to the e-mail: 4 of them - spam (suggested that I advertise my game and give me a good rating, for this they asked for from $ 100 to $ 60,000). And one letter from Opera Mobile Store (apps.opera.com), where it was reported that you can place applications in their store for free, but I decided to stay only on Google Play for now.

Competition and SEO

The competition for the first positions is high, especially in the genre of games like "tic-tac-toe". There are thousands, thousands of identical daggers with almost identical names. There are so many of them, because they are a little more difficult to write than “Hello world”. It is clear that users will not bother to flip over more than the twentieth second page in search of a better game, but only more than one page (3000/20 = 100 ...). Competition among thousands of tic-tac-toe ... My game is in the top twenty pages ( 20 page), this is not as bad as that of more than 70% of other competitors. It is worth noting that, like in search engines, the position of the game is determined not only by the selected category, but also in the search by various key queries. So, at the request of “tic-tac-toe” my game is on page 20, and at the request of “tic-tac-toe, draw” on the first, among a dozen competitors, but very few people are typing. However, at the request of “tic tac toe for two,” which appears in the tooltip when typing the phrase “tic tac toe,” competition is only among two pages, and this is often typed. 3,636 times (based on the downloads of the English-speaking part of users). It is worth noting that you do not need to spam with all possible keywords, because if you write what players expect to see but not see in the game, then they are not just ud Alat the game, they will add a bad review. As some may have guessed, since specific phrases affect the search so much, tic-tac-toe will be called in different languages ​​differently. The question arises: how many languages ​​do you need to translate the application? The main number of users installed the game with the following languages: Russian (58%), English (US 20% + United Kingdom 11% + other English 2% = 33%), Spanish (3%), the remaining 6%. Therefore, we can conclude that there must be English; a language you speak well; further languages ​​by popularity that your friends know. The graph shows the green Russian-speaking users, the other two lines - English. The point of a sharp rise of Russian-speaking users is adding “for two” to the description of the game. The average statistics on the use of language in the “Puzzles” section (provided in the Google Play Developer Console): How do people get to the page with the game, who downloads it and who leaves the game? This will show the next picture.

Video

Since some minus wrote comments about this kind of content “can be played on paper,” I concluded that many who install the game do not read its description. Pictures (screenshots) poorly explain the feature of this game - drawing. That's why I decided to make a video. Not to attract new players, but to show the gameplay and weed out those who do not like the game (so as not to spoil the rating of the game). As suggested in the documentation for google play, I made a video showing a feature of the game. I tried to make a video without any special effects, as I assumed that there would not be much to watch. But I couldn’t cut 15 minutes of video captured from the screen with ffmpeg in 1.5 minutes.And in vain. The result of the video was ambiguous. Approximately 2 views per day, 1 view lasted 48 seconds (overlook). From this we can conclude that, taking into account the time spent on rewinding video, the best video length is 1 minute. The changes in the number of deletions / installations were insignificant.

Download statistics

General statistics for the year: installations 5113, deletions 4017 (78%), 1096 users left. For the first 10 days (first version): 56 downloads, 22 deletions, 34 left (+3.4 users per day). Such good statistics are due to the fact that in the first weeks the game was discussed at w3bsit3-dns.com. During different periods of loading and deletion, they fluctuated evenly in proportion. The downloads and deletions in the summer are less than 10 a day, from January more than 20 a day. Habraeffekt will be measured and laid out. Presumably there will be a sharp increase in downloads, then the same increase in deletions. UPD: After 2 days, the article collected 13,000 views, then I’ll tell you about the habraeffect. In short: out of all 13,000 views, we became interested in the game and only less than 1% of people downloaded it, but added a lot of good reviews to the game. +180 (1.38% of article views). Basically there were devices with Android 4.1 and 4.2. Deletions also increased, there were 50 of them in the days of publication of the article. On average, these days removed 43% of all installations (40% of deletions of readers of the article, 70% of other users). The number of users of the game for a couple of days increased from 1110 to 1230, an increase of 120 (of which the proportion of people who read the article, It turned out 0.8% of article views). For comparison, the usual growth for a couple of days is 3-4 users. A couple of days after the publication of the article, all the indicators began to approach the usual.I noticed that if some users are attracted to the product by personal communication (branches in forums, articles), then the number of comments and ratings increases. Due to the publication of this article, a lot of reviews appeared on Google Play for the game, and the reviews were positive, in spite of criticism of actually existing shortcomings that need to be corrected.Video views increased by only 7 per day, all views from mobile devices. Strangely enough, I looked through the page on my site about the game more than the video. The first two letters from those who tried to install the game came to the e-mail. Before that, only spam came.

List of programs used to create games and other materials

Development environments:

• Netbeans
• Eclipse (+ Android SKD)

Images and videos:

• GIMP - raster graphics editor
• Inkscape - vector editor
• OpenShot - video editor
• ffmpeg - used to capture video from the screen

Development was conducted in Linux. All these programs are free.

Expenses

0 (zero) for development, graphics, software. More than $ 30 for site support, banking operations, and a GooglePlay developer account. What I received: 0 rubles, experience in developing an Android application, game installation statistics on Google Play, a good article.

Finally

, , 30$ . () () . , , , , , , , -. , , ( , , ..). (, Google Play)