Hands-on Android: lessons learned from our first game project

About one year ago we wanted to gain some experience in android app development and the whole associated workflow, consisting of:

  • developing an Android app
  • publishing and maintaining the app in the Play Store
  • performing marketing and earning some money

So we decided to create a trial-balloon-project to get started. Despite the fact that our company normally creates serious business software, we gladly received the ok to do some more “funny stuff” like a game for this special case. We are working for a really cool company, do we?
In this short series of blog posts I want to share with you some of the key-insights we’ve gained (and problems we’ve encountered) since the first version of the app was released one year ago. Today I want to start from a technical perspective which must be a little “game specific”. But the later blog posts will focus on the Google Play Store as well as marketing and selling activities we’ve tried, which should make the whole story more interesting for a wider audience as just game developers. So keep on reading!

Basics about the game

After doing some research to find a genre providing high download rates and not needing too much “artwork” to do, we finally came to the decision to develop a word game with the following, simple setting:

  • it is a round-based two player game with social media connection
  • both players see the same nine letters
  • each player has a maximum of 120 seconds to find up to nine words
  • a word with three letters leads to 10 points, four letters to 20 points and so on
  • if a player find all nine words in less than 120 seconds, he / she will get one additional point per second left
  • the player gaining most points will win

This was the basic idea of the game, later called “Word Duel”: of course, more aspects have been introduced over time, like in-game-statistics, an offline training mode and so on. The following screenshots show some of the main screens of the game and should give you some first impression of the graphical style (it has a western theme) and the basic workflow:

The main game screen
Performing a duel
The result screen

You are also very welcome to download the game at our Play Store site and play some rounds (or visit this site if you want to train your german language skills).

Which framework to use?

After we developed the main idea of the game, the next question we had to answer was about the technical fundamentals. There are a lot of frameworks out there which can be used for game development and help you getting things done. After an evaluation phase we finally decided to use Libgdx, because:

  • it is under Apache 2 license (in contrast to a game development engine like unity, which have some license requirements like less than 100.00 $ revenue per year for your whole company, not only for an actual developed game)
  • it allowed us to program in good-old-java (which made it to a natural choice for us because of our Groovy / Java background)
  • it is fairy well documented and there are a lot of tutorials and books out there
  • it offers full OpenGL ES Speed (in contrast to using WebGL in a HTML5-Game within a container like Cordova: as you can read here the standard WebView-component of Android doesn’t support WebGL, unless you have the current Android 5 Lollipop, so you must do some software rendering which slows down the framerate and is very battery-consuming)
  • it offers a lot of out-of-the-box functionality like an audio and animation api or a font-system and encapsulates the low-level-part of OpenGL ES with a system of nice abstractions (so you don’t have to fiddle around with things like shaders if you don’t want to)

Working with Libgdx also has some drawbacks, especially the version we’ve used when starting the project: because it was still a pre 1.0 version there were some nasty bugs and the whole bootstrapping process was not so straight-forward. The recommended way of developing an app was, to use Eclipse-IDE and the ADT-Eclipse-Plugin and to rely upon the eclipse project settings for compiling and bundling the apk. Thankfully they’ve changed this and are using Gradle nowadays to manage the process.

Some other problems we’ve encountered with Libgdx were related to the coordinate-systems used in certain circumstances (the origin of the current coordinate system is not always where you expect it to be) and the threading-model, which you should really understand before implementing any interaction code between your normal Android UI-thread and the Libgdx OpenGL-thread. Actually it is rather simple: everything done by OpenGL must be executed from within the OpenGL-thread supplied by Libgdx. Do never call an OpenGL routine from the Android UI-thread or you will get strange rendering results like black texture boxes. Instead, you have to call the routine via a callback in conjunction with


Gdx.app.postRunnable()

from the Gdx-singleton. Despite its name, postRunnable has nothing to do with execute something in a new, asynchronous thread. Instead, the task will just be added to the queue of tasks and executed while rendering the next frame of the OpenGL scene. As mentioned, the rule is easy to grasp but we needed some time to really get it.

Embedding the Google Play Games Services and Google+

Because Word Duel is a multiplayer game, we were in need of a server-infrastructure and asynchronous game api. To make things easier, we decided to use the Google Play Games Services (which are part of the Google Play Services): in short, they offer you things like game invitations, achievements, leaderboards and so on. Using this services can save a lot of development time and your customers get some advantages, too:

  • They can use the standard app “Play Games” to manage invitations
  • They don’t have to register to yet-another-game-service and can just use their Google+ account they already have after buying an Android phone

To integrate the services you need to check out the Google BaseGameUtils they’ve published on GitHub. But as you can also see the project is not under really heavy development: they haven’t updated or fixed bugs for 8 months, so prepare yourself for fixing bugs / develop some workarounds on your own.
Be aware that the decision for Google Play Games and Google+ is also a decision against other platforms like Amazon: because they don’t ship their Fire devices with the Google Play Services, their users will not be able to use the multiplayer part of the game at all, making it totally useless for them. Amazon suggests to build an additional apk for their platform, using their “Amazon Game Circle” services instead of the Google counterparts. This sounds simple, but if you really want to do this, you should have it in your mind straight from the beginning, so that you will encapsulate all parts of your multiplayer-logic properly behind an interface.

Instead of using Google Play Games or Amazon Game Circle you can also use some platform independent api like Facebooks Game Service. This should make you platform-neutral but binds you to Facebook and their terms of usage.

Using ads for monetizing

Because we wanted to learn the “standard way” of app development we also decided to use the standard way of monetization: so we created a payed pro version of our app (without ads) and a free version, displaying one ad after each round. To get some feeling if it makes a difference which network you use, we implemented the api of two networks, namely Revmob and Chartboost. The question if one network outperformed the other one and if we earned some money at all with our strategy will be the topic of a later blog post. But you should have the following two things in mind: be flexible about the network you use and also have an eye on the rights the ad-library wants to get from the user. Does the money you receive outweighs them?

Language-specific versions

One of the most important parts of a good word game is the quality of the dictionary. So we spend quite a lot of time into creating a high-quality one, including conjugations. We also decided to create two different dictionaries: a generic english one (targeting the international market) and a german one. Packaging them into separate apps allowed us to use different marketing and selling strategies for each country and the possibility to see if they perform differently. According to the information supplied by the Google Developer Console over 35% of all Word Game installations are located within the USA and only 3,85% goes to Germany, so we did expect the internationalized version to clearly outweight the German one. If this was the case or not will be the subject of a subsequent “marketing” post.

Testing environment

To be frankly, testing an Android application is a real pain. The fragmentation of the Android platform is enormous, not only because of the different Android versions but also because of the different devices offering different screen sizes and pixel densities. Take a look at the offical guide for multiple screen support just to get some idea of what we are talking about.
Of course, there is no possibility to have even a small number of all the different physical devices in your office, just to test them through. So, virtualization should help to make things easier. Actually, the Android SDK is shipped with some kind of virtual machine (called Android Virtual Machine Manager). But using it is not so easy: first of all, the emulator is incredibly slow out of the box. If you don’t want to wait about 10 minutes just to get the emulation of a Nexus 5 started, you better follow this instructions and install the HAXM driver. Be aware that you can only do this if you have an Intel-CPU with VT-technology and the platform you want to emulate is available as an Intel-Atom-image. Afterwards the ramp-up-time is still not that fast (about 20 seconds to boot the nexus 5 on my Intel i5 3.3GHz, 8GB RAM, SSD, Windows 7), but it is at least “ok”.
The next trouble you will run into is, that you can not use your now “fastly” booting image to test your Google Play Services app. Google decided to ship the images without the Google Play Services and without the Play Store, so the only thing you can do is to follow instructions like this and download the appropriate apks from some vague sources: not the thing you want to do within your companys’ network.. Thankfully a user on reddit called my attention to the fact, that Google is now offering some images including the Play Services for their emulator. But unfortunately this only works for emulating devices with Android 4.2.2 or higher, so you can not test older devices with the VM.

To circumvent the performance problems you can also consider using some other emulation solution like Genymotion: Genymotion is based on Virtual Box and boots really fast. But because of legal issues they are also not allowed to ship their emulator together with the Google Play Services.

From my point of view the whole testing-situation is ridiculous: it should be one of Googles’ vital interests to have well-tested and solid apps in their store. To accomplish this they must provide some kind of testing environment. Maybe the Cloud Test Lab will improve the situation a bit in the future.

Conclusion

Developing a game from scratch and following the whole release cycle from planing over implementing and testing up to publishing has helped us enormously to build a solid understanding for Android and its eco-system. So, from our point of view, this is a good and working approach to burrow into a new platform.

In our specific case it was a very good decision to use Libgdx as the base framework for the game. It has speed-up the work enormously and preserved us from digging into too many basics which would have been out of focus for our project (like shader-language and other low level OpenGL stuff). In sense of “getting things done” we also did not regret to use the Google Play Games Services: we integrated them quickly and (despite some problems with the BaseGameUtils) they work like you except them to do. But you should always have in mind that relying on that service will lock you into the world of Google (with their Play Store) and makes it much harder to migrate to other platforms like the Amazon Store or Apples’ App Store, if you want to move on later. If it was a good decision to rely on Google+ as the “backbone social network” for our game will be discussed within one of my next blog posts, so I don’t want to write too much about this now. We also encountered that testing an Android app is no fun at all and in some circumstances nearly impossible: the VM supplied by Google is (without tweaking it) a performance-nightmare and because you can only use the Google Play Services for emulated devices with Android 4.2.2 or higher you can not test your app on those platforms without installing some APKs from “anonymous” dropbox sources.

We are curious to hear about your experiences about developing for the Android platform and the Google Play Store. What do you like / dislike and what were the biggest traps you run into? Of course we would be also glad to hear some feedback about our little multiplayer word game: you can find it at the playstore (it is a free game so just have a try)

Advertisements

One thought on “Hands-on Android: lessons learned from our first game project

  1. hello!,I love your writing so a lot! proportion we keep
    in touch more approximately your article on AOL?

    I require an expert on this space to resolve my problem. Maybe that’s you!
    Taking a look forward to see you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s