Nontrivial implementation of tic-tac-toe for Android

This article will talk about tic-tac-toe in Java 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. Exactly a year ago, on December 9, I posted my game on Google Play. Now I want to talk about what happened this year, how the popularity of the game grew, what worked and what didn’t. You will see clean statistics of downloads and deletions for the year the game existed, numbers. Find out how many users you can collect from Google Play, how the game was created, how it was tested. You will learn 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 ones. After learning Java, I decided to try to do something useful in this language. Having learned that you can write Java games for Android games, I decided to try to do something simple in order to learn how to make applications for smartphones.

Idea

Now we need an idea that is too simple so that there is no pity for time in the event of failure, and too unique that the application does not remain just another name in the multi-million list of applications. I chose tic-tac-toe. Too easy? Are there many games like this? Now it was necessary to come up with something unique. Why now all computer tic-tac-toe work on the principle of clicked - set? So I decided that let the figures draw, and the game itself will determine what is drawn. Now, how to make an implementation? Options:

• Each cell is a raster image. Disadvantage: you cannot draw abroad, otherwise it looks crooked, memory consumption. Pluses: simplicity. An analogue of this is already on the Internet, but not for mobile.
• The entire field is a bitmap. Disadvantage: look for figures in the entire image, it is probably easier to recognize printed text than to find curved figures, the problem of disconnecting glued figures, and a large CPU load. Advantage: you can draw a cross by running into a neighboring cell.
• Shapes - vector. Disadvantages: redrawing is possible long (but it is possible to solve by buffering). Advantages: it is possible to separate the figures that have collided upon each other, it is easy to change the position of individual figures.

Googling a little, I did not find this. Why 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” - to draw enemy figures, and freedom of settings and rules of the game (field size, etc.). There are also disadvantages: 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 the game, I quickly looked for similar games. Under Android, I did not find any such games. I thought of calling the game “tic-tac-toe” + drawing. Since there are a lot of tic tac toe for Android, I decided to postpone this difficult, short stage of creating the game and come up with the final name after the working prototype is ready. After the working prototype, I started composing 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 of 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 the word about drawing in the name of the game, it was decided to name the game "Tic-Tac-Toe Drawing!" If you say that the name is very consonant with others, then how to call the game of tic tac toe,

Implementations

UPD: Features of the game that were required to be implemented:

• Player drawing shapes, recognition of drawn shapes
• Different size of the playing field: from 3x3 to 12x12 (it is possible and more, but the screen sizes of many devices impose restrictions)
• Accordingly, the game is not only 3 in a row, but also 4, 5, 6 in a row

This caused problems: since you can draw anywhere, you can change the enemy’s figures, cover up, sketch, wash, even go on the wrong course (yes, this can be done if you draw two crosses at the same time). What to do in such cases? Prohibit or allow? It was decided to resolve, leaving the opportunity to win in any form, but then when winning a complaint about cheating, for example: "Unfair victory."

Choice of development environment and general plan of creation

While I was looking for what to write for Android, Eclipse was downloading, the documentation was being studied, I decided to start on what was installed with me - on NetBeans. I thought that in android Java 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 should be divided into two packages: Engine and GUI. Engine - the 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 - OS dependent. To port 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 transfer under Android, there was a problem with adaptation (described later).

Game development

Program Development Cycle

To know exactly what to do, I decided to write down the points that my game should do, what needs to be implemented. First, I took a leaflet on which I wrote down the main sections: Engine, AI, Graphics, Bugs, etc., then for each category I wrote down the problems that need to be solved. As the decision was made, I ticked off what was done, as I sat idle, I replenished the lists with new ideas, as I debugged, I increased the “bugs” section and sometimes other sections. Then I ended the second sheet, but two sheets were 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 the code well (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 the mouse, cells. Recognition of lines as crosses and zeros. (Colorizing the figures in accordance with the recognized figure was done to debug the recognition of the figures, then, since it turned out beautifully, it was left in the game)
2. rules of victory, a game a man with a man.
3. gaming AI, computer game mode.

The life cycle of each of the above steps:

1. compilation of a list of basic requirements
2. programming
3. checking the result and debugging. If errors are found that are incompatible with the life 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. listing issues
2. programming
3. checking the result and debugging. Now I was looking for what can be improved.

Basically, these improvements were related to figure recognition and the game of the bot, which will be written later. In the second stage, the game was ported to Eclipse and the creation of a GUI for Android began. There were problems with the compatibility of the engine with Android. In ordinary Java, the coordinates of the canvas (Graphics) are int, in Android, float. Also, the names of many drawing functions and classes (Canvas = Drawable, etc.) and the data structure for drawLine differed. I had to write a “format converter” (crutch) and replace the names of data types. I managed to do all this in more than an hour, as there were mainly differences in names, and not in logic. Then there were further improvements, drawing pictures. After the integration of the engine and the new GUI, 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. Listing issues
3. Fix problems

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

How AI was written

Developing Bot (the term AI was used in the game for shortening) for simple tic tac toe 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 AI implementations worked well in a large field, but easily lost in a small field, or vice versa. Since each AI implementation required testing not only for some performance, but also for the ability to win the game, I had to test the AI ​​manually first - just play with him. But, it was too slow, and the assessment of success was subjective, so I found another way to test AI. AI was completely implemented as a class, so a separate program for testing AI was made: two different classes of AI were launched that played on a virtual playing field, data on the results were displayed in the console (who won, how many moves). Also, if necessary, the data for each move was displayed in text format (game situation, what the AI ​​thinks about the profitability of each cell).For the standard of a well-playing opponent, I took the open-source AI from game 5 in a row, which I found on the launchpad. Tests were carried out several times to reduce the influence of randomness. 2 AIs were done: normal and complex. They were very different in implementation: a complex AI worked according to the principle of tracing possible paths, and the middle one according to a simple principle: sorting out cells, where to put in order 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), complex AI was many times faster than medium and lightweight, in games with a field larger than 3x3. After the middle of the AI was thrown out not too much, there was a light level of complexity.

The code

Briefly about the code of the game in Java: in total, the source code occupies 275 kB, of which 75% are Engine. The code is divided into three packages, about 22 classes are used. Only 5670 lines of code, but a lot of comments, commented parts and empty lines, so there are about 4000 pure code, on average 250 lines per class (file). The main engine was written in a couple of weeks, it could be accelerated to one week. When writing code, dangerous places where an error might occur (for example, the construction turned out to be too confusing), I marked with comments // FIXME and // TODO. Concentration of comments: one FIXME per 400 lines of code and about 1 TODO per 60 lines of code. When flaws were identified during the testing process, I either immediately understood what to fix or the errors were in these lines. Also, before each release, I tested the game, playing 5-10 times with different settings.The result was a reliable application, as evidenced by the “Failures and ANR” report. However, there are still explanations for this: try - catch blocks were used, which is not very good, but in some cases when it fails, the application should automatically disable the "experimental" functions and switch to their older versions; or this page does not work for Google; 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 the translated string replacements. All the 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 the translation, the uncertainty in the knowledge of English was transferred to Google Translator. When translating, at a minimum, try translating the sentences you received into the original language. And better, translate the 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 in meaning. The application was translated into English, so there was support for two languages. I'll tell you more about the impact of translations on downloads. The first release of the game was in the evening of December 9, 2012. The very next day, in statistics, I saw that on the first day there was 1 download. Before the release, I thought what number to give 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 that the graphics were not displayed correctly. And they were right, for 90% of real devices it was impossible to play. 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 look for a solution, and it was found. No, not through OpenGL. You can redraw both the entire canvas (repaint (), onPaint ()), and fragments (repaintCliping (), onPaint (rect)). I had to learn the game to determine the necessary redraw areas, and plan the redraw zones in advance (combine intersecting zones, separate separated redraw zones). All these improvements and tips of some people were collected in a new version, which was released a week later. During each update, I thought that each previous version was bad and impossible to play, and the new one was the best, and there wasn’t a single flaw .Testing of releases was carried out at first only on the emulator. This device was useful to me only for two purposes: 1) to realize how crooked it is that the emulator did not show; 2) to test multitouch. As long as I developed and tested the game for so long, I used to draw even figures, and I didn’t notice that not all players draw such even figures, so often the figures were not recognized. Therefore, when I let my friends play, I was surprised that the program hardly understood their drawings. I had to improve recognition again. Since there is a list of changes on the game page, I’ll list what the main problems were solved by the update. Version 1.1: since the surface was implemented as an overloaded View and the entire canvas was redrawn, the graphics slowed down. Support for PaintClipping () was implemented, which made it possible to redraw not the entire screen, but only the changing part, which greatly accelerated drawing. The following updates: fixed problems with the animation of displacement, turning it off; design; multitouch; records. The first optimizations: I noticed that I accidentally saved 2 times the rendering, I drew the same thing 2 times; optimization using caches.

Compiler Errors? They are?

Somewhere I read an article about the fact that compiler errors are actually programmer errors. But I came across real errors, of course not the compiler errors themselves, but the errors of the SDK and plugins:

• The emulator emulates "ideal" devices. When testing the graph in the emulator, it looked normal. On some devices, it also looked normal. But on most real devices, when animating shapes, the chart looked awful: the shapes bifurcated and rolled together (presumably the reason for using the transformation matrices is Matrix, for Java it is AffineTransform).
• Compiler error? I spent a lot of hours debugging the output of the game time: the game time was displayed inside the button, as its name, and not in the text box. Solution: it turns out that before the compilation it was necessary to click the “clear project” button and then everything was fixed (in the official documentation from Google it was recommended to press this button every time before building apk, but who reads it?). This may be related to updating the SDK, but confusing the names of the resources - this can be attributed to compiler errors.
• There were also API errors, some deprecated functions, again, in the emulator they 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 majority opinion, it works, but with the conditions: in the path to the SDK, home folder, project folder and its name, there should be no spaces or Cyrillic. Then it works (don’t forget to uncomment the necessary lines in project.properties). You can perform the obfuscation manually (I had to do this until I adjusted ProGuard). To do this, first make a copy of the project. Then we go to the project settings (where to add it) and remove unnecessary checkmarks in the section “Java Compiler” in the group “Classfile Generation”. Next, using the tool "Refractor> Move ..." and "Refractor> Rename ..." we turn the code into something incomprehensible. As you progress through this process, remember to check the residual performance of the code.

Graphics

For drawing graphics, we used: GIMP - a raster editor, and Inkscape - a vector editor. At first glance, GIMP seemed to me much worse than Photoshop, some functions weren’t in it (or I didn’t find it). At first it seems very uncomfortable, and it seems that you can’t even draw a line on it. But over time you get used to it, and you realize that this is how to open Photoshop for the first time, when before that I saw only Paint. You can draw in GIMP. Inkscape is also simpler than CorelDraw, but I didn't need more from it. Fairly simple, intuitive editor. Successful design did not work right away.

Statistics and Marketing

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

Promotion

In the first week I tried to write about the game on the w3bsit3-dns.com website. I wrote to some forum threads (increase in downloading +15 - +40) without reading their rules, for which I was banned for a couple of days. Then he wrote to 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 devs from the CIS countries, it consisted of writing 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 into this project, either they didn’t like the site with “.com”, or they didn’t find my email on the website.

Reviews on Google Play

They say that you don’t 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. Do not read the description of the game, thereby downloading something that someone does not need, or miss an interesting game.However, if several people write that it is “impossible to play,” or even describe in more detail “nonexistent” bugs (“a cross is drawn 2 cm higher”), then this is not just so. The emulator can deceive you, your device may also act differently from others. In this case, you should not skip such reviews, but try to find out what is happening on users' devices and deal with it. I want to note that in a year, with more than 5,000 downloads and 1,000 users, only 5 emails were sent to e-mail: 4 of them - spam (they suggested that I advertise my game and get a good rating, for that they asked from $ 100 to $ 60,000). And one letter from the Opera Mobile Store (apps.opera.com), which said that it was possible to 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 such a genre of games as "tic-tac-toe." There are thousands, thousands of identical tic-tac-toe with almost the same names. There are so many of them, because they are a little more difficult to write than “Hello world”. It is understood that users will not bother to flip more than twentieththe second page in search of a better game, and the pages in total more than (3000/20 = 100 ...). Competition among thousands of tic tac toe ... My game is in the first twenty pages (on page 20), it is not as bad as in more than 70% of other competitors. It is worth noting that, as in search engines, the position of the game is determined not only by the selected category, but also in the search for 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 few are gaining it. However, for the query “tic-tac-toe for two,” which appears in the tooltip when typing the phrase “tic-tac-toe,” competition is only two pages wide, and this is often typed. The addition of the keyword “for two” in the description of the game resulted in an increase in the load of Russian-speaking users in 3 636 times (based on the downloads basis 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 in what players expect to see, but will not see in the game, then they will not just delete the game, they’ll also add a bad review. As some may have guessed, since specific phrases affect the search, the tic-tac-toe will be called differently in different languages. The question arises: how many languages ​​do you need to translate the application into? The majority of users installed the game with the following languages: Russian (58%), English (USA 20% + Great Britain 11% + other English 2% = 33%), Spanish (3%), the remaining 6%. Therefore, we can conclude that there must be English; The language you speak well further popular languages ​​that your friends know.The graph shows green Russian-speaking users, the other two lines are English-speaking. The point of sharp rise in Russian-speaking users is the addition of “for two” to the description of the game. Average language usage statistics in the “Puzzle” section (provided in the Google Play developer console): How do people get to the game’s page, who downloads it and who leaves the game? This will show the following picture.

Video

Since some minuscules wrote comments about such content “you can play on paper,” I concluded that many who install the game do not read its description. Pictures (screenshots) poorly explain the peculiarity of this game - drawing. Therefore, I decided to make a video. Not in order to attract new players, but to show the gameplay and weed out those who don’t 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 the features of the game. I tried to make a video without special special effects, since I assumed that they would not watch it much. But in 1.5 minutes I couldn’t trim 15 minutes of the video captured from the screen using ffmpeg. But in vain. The result of the video was mixed. About 2 views per day, 1 view lasted 48 seconds (overlooked). From this we can conclude that, taking into account the time spent rewinding the video, the best video duration is 1 minute. Changes in the number of deletions / installations were minor.

Download Statistics

General statistics for the year: 5113 installations, 4017 deletions (78%), 1096 users left. For the first 10 days (first version): 56 downloads, 22 deletions, 34 remained (+3.4 users per day). Such good statistics due to the fact that in the first weeks the game was discussed on w3bsit3-dns.com. In different periods of loading and unloading, they fluctuated evenly proportionally. Weekly downloads and deletions are less than 10 per day, from January more than 20 per day. Habraeffect 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 talk about the “habraeffect.” In short: of all 13,000 views, only less than 1% of people were interested in the game and downloaded, but added a lot of good reviews to the game. More: The number of game downloads in two days increased by +180 (1.38% of article views). Mostly 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 removal of readers of the article, 70% of other users). The number of users of the game in a couple of days increased from 1110 to 1230, an increase of 120 (of which the proportion of people reading the article, turned out to be 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 indicators began to approach normal.I noticed that if some users are involved in the product by personal communication (forum threads, articles), the number of comments and ratings increases. Due to the publication of this article, a lot of reviews appeared on Google Play on the game, and the reviews were positive, despite the criticism of the real flaws that need to be fixed.Video views increased by only 7 per day, all views from mobile devices. Oddly enough, they looked more at the page on my site about the game than the video. On the e-mail came the first two letters from those who tried to install the game. Prior to this, only spam came.

List of programs used to create the game and other materials

Development Environment:

• Netbeans
• Eclipse (+ Android SKD)

Images and video:

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

Development was under Linux, all of which are free.

Expenses

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

Finally

You can, having a computer, $ 30 and time to make a simple and good game. For a good game, you need both gameplay (idea) and a beautiful implementation (graphics) at the same time. To earn a lot of users, you need to do what users need, even if they don’t even suspect the existence of this, and what’s not there yet, do the same in a less competitive field than thousands of tic-tac-toe. Now the game is free, without ads , it does not require any additional permissions (for example, the collection of personal data, sending paid SMS, etc.). (clickable on the game page on Google Play)