Introduction
I think most of you were playing chips as a child. Remember, such small circles with pictures? They were on different subjects. Personally, I was not playing very much in them, but I still found them. And then the idea came to make such a game on the phone - on Android. Knowledge was, experience, too, and I started to implement. I will tell you a little about the gameplay, and, of course, I will touch on technical issues - where could they be without them?
The essence of the game
The meaning of the game is quite simple, and does not cause much difficulty. You are given some money and three chips. Your task is to expand your collection of chips. This can be done either by buying them in a game store, or playing with rivals - this is the main way. The global goal of the game is to collect all the chips. There are about five hundred of them, all of them are divided into certain albums by subject. These albums can be viewed, individual chips can be bought / sold. It happens that you win such a chip that you already have - you can sell such duplicates, buy new ones instead. Well, this is how you expand your collection of chips.
Game features
The order of knocking out is determined by a stone-scissors-paper mini-game. This is probably the most stressful part that I wrote in this game.
The game has several game modes. You can play against the computer - such a single player. 3 opponents are playing against you, they are playing in a balanced way - they cannot be defeated in the forehead. You can play on the same phone with your friends - they take turns walking, it turns out like a “hot chair” in Heroes of Might and Magic. And the most interesting mode is network. There is a server with a list of games, you can play there with players from around the world. Now the network game is implemented only for two players, in the future it is planned to expand this number to 4.
')
The game really has a lot of chips - more than a dozen albums, each with a few dozen chips. All this scrolls, all the chips can be viewed in high resolution. Fans will be pleased.
There is also such a thing as bits. A bat is an iron or plastic circle with which chips are knocked out. Our bits were not much honored (I personally have not seen a single one), but they were used abroad. Each bit has its own characteristics, they affect the process of knocking out chips. There are bits of superpowers - allows, under certain conditions, to knock out all caps in a pile.
Bits knocked out by hand. She appears on the screen, grabs a stack of caps or a bat, and hits her on the table - and it still looks quite nice. However, the hand can be disabled in the settings.
Of course there is a certificate, which describes the game nuances. The game is in two languages ​​- Russian and English.
There are beautiful - spinning bits, scattering stars when buying albums \ backgrounds \ bits, stirring inscriptions and the like.
There is a reward system - for example, for all the bits collected, for all open albums, etc.
In general, there are a lot of interesting things in the game - viewing large pictures of caps (with download from the Internet), different backgrounds (with them I suffered too, I will write below why).
Technical details
The game was written in Java, the game engine is libGDX (if anyone knows, it allows you to write for the desktop, android without any problems at all, with a tambourine - and for iOS and html5). More specifically, I built my small framework around libGDX, and already wrote on it. I wrote a few more games on the same framework. Then there were some shortcomings in it, and I began to redo it. Now my new engine is almost complete, a little later I will publish an article about it - there are some sweets :) The development environment is standard - Eclipse.
At the very beginning to create a project I used a program called libGDX UI Project Setup. This thing can create related projects for eclipse, throw the necessary libraries into these projects, make launch classes for different platforms. It can download the latest version of libGDX from the Internet, it also supports third-party libraries. This is the smartest thing, it’s a pity that there’s almost no third-party libraries (. As a result of the program’s work, we’ve got a workspace, Eclipse go in there, import projects — and now, you have a workpiece that you can run on the desktop, on the android, in the browser (with some limitations.) If you have a MacBook, you can try it on the iPhone. I didn’t have an iPhone, I tested it on my computer and phone.
Widely used a utility like GDX TexturePacker. This is a texture packer - you have a lot of small pictures, you set the packer on a folder, and you get one big picture (texture atlas) of the sides, multiples of the power of two (OpenGL requirements for textures) and a text file, where it is described in this large file What picture is located. Then in the game you download this file and texture, get convenient access to the pictures. Whoever uses libGDX and has not heard about this thing - I highly recommend that you save yourself a lot of time. It allows you to save a set of atlases in the project, then add / remove pictures from there - well, the author did a good job and made a really worthy tool.
The development was as follows: the whole game was divided into separate screens. One screen - one Screen (class libGDX). By the same principle, texture atlases were made - for one screen - one atlas. In principle, this would allow to keep in memory only the desired atlas, and unload the rest - but there seemed to be enough memory, so I did not bother with that. The main problem of android - multi-screen. In libGDX there is a class Table - it allows you to deal with this quite well, placing the components not rigidly, but in the cells of the table. Each cell can be set to its own parameters - alignment, size, etc. As a result, it turned out pretty well - on different screens the layout is slightly different, but nothing leaves the borders, everything is decent.
The game had one global class singleton Game type (this is also the class libGDX). He kept links to all resources, allowed to switch screens, catch moments of exit / pause / resume from pause, etc. Also there was a code specific for interaction with Android. This applies to adMob advertising - showing \ ban showing, and tapjoy. To communicate with android interface was written. This interface was implemented in the android-project, using specific things for it. The interface was transferred to the game from the android project. Then the game pulled him, and android executed the necessary commands.
The same singleton was created for settings - I called it the sly name of GameSettings. I saved the player status there, and, in fact, the settings - sound \ music, etc. The player itself was serialized into a json string before saving, and when loading it was deserialized from it. It turned out very convenient - adding a new property to the player did not require to go into his save / download.
Each chip has its own properties - picture, price, album, etc. These properties are also stored in separate json-files. It turned out about 500 json-files. There is a plus in this - they are loaded automatically, for a new chip it is enough for me to create a new file and throw it into this folder. It is clear that manually editing these files would be stressful - a simple chip editor was written - you could choose a picture, specify an album / chip value.
In general, everything that could have been, I rendered in json-files - the same bits, backgrounds. I do not like to climb into the code without the need - I'm lazy. Thus, adding / deleting bits, backgrounds, and chips are operations with files. Automation, however.
To build the apk and the computer version, I wrote an ant-script. He collects the apk, signs it, collects the version for the computer, and throws it all into the dropbox folder. It takes a little time - and my friends start and test the toy. Ant-build script is an invaluable thing, if you often make releases (and since I worked remotely, it was very, very necessary for me).
The main time the game was launched on a computer, and then it was launched on the phone. This is an invaluable advantage of libGDX - you can very quickly debug the game without waiting for it to be uploaded to the emulator \ device. I don’t know how long the development would take, I fill in the game on the phone every time.
Not without monetization. The admob ad banner is displayed at the bottom of the screen. I also figured out and integrated tapjoy - if anyone knows, this is the system where the user gets virtual coins for completing tasks (for example, installing applications from Google Playe). And then you give him the opportunity to spend these virtual coins. For example, I simply convert them to in-game coins.
Problems encountered
Not without problems.
The first problem is the network game.
At first I wanted to do this. Select one player, make it a server. The rest of the players send / send him commands. He controls all the players and at the same time. In this version, the server program only managed the creation of the game and sent commands between the players, announcing the creation / deletion of the game. Everything would be fine, but in practice it turned out that such a realization is very stressful (well, it seemed to me like that). Implementing both the client and the server in the same program did not really work out, then I had to finish the server. For the future, I realized for myself - there are no many tasks on the server. If there is an opportunity to realize something on the server - do it on the server. This is not to mention security.
The second problem is uploading large pictures of chips from the Internet to view them. They were stored in jpg. Initially, each picture was 400 * 400 size - or something like that. In the properties of the engine, I set the use of OpenGL 2.0 - this allowed me to upload images where the sides were not a power of two. It turned out that on some devices the pictures are not loaded, and only the white screen is shown. After dancing with a tambourine, I squeezed all the pictures in 512 * 512 - the problem disappeared.
There was a problem that the game lagged and fell. Inspection showed that a lot (about hundreds) objects of chips are created and deleted. First, the garbage collector tolerates this, and then the game begins to lag and fall. Exit - use pools. The call to new Chip () (yes, I called the so-called chip) is found only in one place - in the chip manager, it’s a pool of chips. After use, the chips are returned to the pool. It is also done with bats, backgrounds - we shove it all into a pool, then return it.
There was also such a problem as the correct display of backgrounds. If you just stretch it to full screen, then on some resolutions it turns out very ugly - for example, round elements become completely not round. Solution - we cut out the necessary elements from the background, the rest of the image is placed on the whole screen. Elements are located in their places with an indication of the relative coordinates. After that, the problem disappeared.
The listener pattern was widely used. He connected everything and everyone. For example, when a player knocked out all the chips, he was shown a reward on the screen. The same reward had to be shown in the statistics screen after the game. The solution - we make a class-writer, which we pull at the achievement of the reward. Individual screens are subscribers. Thus, adding something else (for example, money for awards) is the creation of a new subscriber, and his signature on the necessary events.
In principle, I have successfully overcome the problems described above. There were those that I could not solve - a long (well, too long) loading of the game on some phones. Android fragmentation - yes, it is. But in general, the main rake was bypassed.
Screenshots
What kind of game without screenshots? Here are a few:

"

"

"

"

"
Conclusion
In the process of creating the game, I learned a lot, although this is not my first game. I delved into the details of libGDX - and I will say that I was not disappointed. Not bad pomuchalsya with the optimization of the game, from the creation of the correct architecture. A side effect - I realized which places are the most routine, now I finish my engine, where most of these problems I solved. Gained invaluable experience working with people - communication with the manager, artists and other people. In general, I feel that during the writing of this game the level has increased. Of course, work on it is not completed yet - there will be bugs that will need to be corrected, there will be updates (for example, I want a network game for four people, more caps, etc.). At the moment, the time has come for the programmer - distribution and advertising. The game was quite interesting, I think, it will not get lost and will make itself felt.
PS If technical details are interesting to someone in more detail, at the level of pieces of code - write in the comment \ lichku, I will share, I'm not greedy.