Trying libGDX android game development: Cross-breed of Pac-man, Nethack and Gauntlet. PART III

 Object pooling misery

In my game there were a couple of types of objects that caused a lot of garbage and resulted in playability killing GC pauses.

Java has supposed to free us from memory management? In mobile games it seems to be mandatory practice. This sucks.

The idea is to have an object factory, where you can ask for objects. You need to return the objects to factory after the use. The factory recycles the objects and this way decreases the need to create new objects.

The code that uses these kind of object factories becomes quite messy very easily, because you need to be sure that the objects are in all cases returned back to factory. And then you are in a big trouble if you happen to return an object that you thought is not used anymore, but in fact was still referenced somewhere. The debugging is hideous. Here you can find info about the object pooling: http://highscalability.com/blog/2015/7/29/a-well-known-but-forgotten-trick-object-pooling.html

First I used libGDX object pooling, but because I had so much trouble with debugging, I created own pool implementation. It has a debug mode, which stores a little more information about the objects and helps uncover object leaks.

Android studio has profiling tools that you can use to check the CPU and memory usage. The profiling may slow game down so it can become almost unplayable. Nevertheless the tools are precious in determining the need for memory optimizations (e.g. pooling), finding memory leaks and sloppy code that takes too much CPU time.

Fine tuning controls

Finding a usable way to control the player via touch screen was challenging. I first started with two buttons for turning the player right and left related to the current movement direction. It was simple but not easy to learn. Then I tried own buttons for up,down,left and right, but during a hectic game it is hard to see where to press. The last option I tried was to use swiping for turning in four directions and it proved to be the most usable one.

Game publishing

At some point I decided that the game is feature complete and decided to polish and publish it. The polishing took quite a long time because now I looked at the game with more critical eyes and decided to overhaul the graphics and add a couple of new features. After this feature creep period I published the game in limited beta in Google play and did some final functional and device testing.

I decided to publish the game free with some not-so-obtrusive advertisements. For advertising revenue I founded a lightweight company "Whim power software". This way I can easily handle the few cents advertising revenue I'm excepting. I'll use the company in my other upcoming home projects as well.

The google play console is pretty good for managing the release cycle: closed test phase, publishing to production, statistics about the installs, ratings and crashes. One positive surprise was the automatic testing Google provides with real phone devices!

A big challenge is to get the people to find and install the game. This is something that requires some more experimenting. One reason for writing this blog post was to get some visibility for the game.

Summary and lessons learned

With LibGDX a lot of coding is required. I found the add-on tools like level and bounding box editors to be quite immature and decided not to use them. The basic LibGDX apis work very nicely and they are documented well enough. Quit a lot of help can be get from stackoverflow.

I was able to run the game as a standalone Java app quite easily but I did to get the HTML version to work. It seems that LibGDX relies in old Google GWT libraries that cause some troubles in Android studio build environment.

The game (and generally software) design, development and testing takes always more time and effort than originally planned. Game design and development is creative art and it means that it requires a lots of experimenting, trying out things and throwing less excellent things to rubbish bin without mercy. One of my favorite saying is (freely translated): great artists have great rubbish bins.

I experienced typical software project sins: feature creeping, hectic crunch time to get the game to a publishable state, a lot of technical debt and so on.


How did I reach my goals?

1. I learned a lot about android development. Memory management sucks. Android studio rocks. 
2. I was able to develop and publish a game and I was quite pleased with the end results.
3. I did not get my son to move from Game Maker to Java. Too steep learning curve.

Next project in the works is surveillance camera app that utilizes Google cloud services for storage and apis. I try to find time to write about it when I get it fully working.


Finally, if you have not yet tried the game, you can find it here: https://play.google.com/store/apps/details?id=com.pajun

To the previous part of this article