Greatest Failures So Far…

So I made a small list of failures during my game development journey. I probably couldn’t solve any of these problems on my own, I’ve found solution to almost every problem by reading android developer website, stackoverflow, wikipedia or blogs written by android developers. Part of this reason this blog is a bit like collection of great links that have helped me to fix my failures. Right now I have fever so I apologize if my post gets too delirious.

1. Not Planning Enough

Okay I didn’t went just to write code, and noticed that I had written useless dead end code,  when I started my project. I took pen and paper which is probably the best way to start planning any programming project. I drew umlish mind map which described how the turn-based engine worked, but I left Android activities out from it. I didn’t revise my plans when making radical change either. So after I while I was wasting time pondering what to do next and do I have to change something from current code if I do it.

Since software architecture planning is quite vast subject (and since I am such a lazy person) I think just explain my point with links. Here is somewhat simple introduction to UML: UML is a great way to visualize classes and their methods just as longs one doesn’t overdo it.

Here is a Android app concept design that I found great example for android app with lots of activities: . It looks a bit complicated first but it’s so comprehensive it’s way easier to start writing code.  Plans are perfect if the time after planning is spent in programming and other practical stuff like making graphics, not wondering what to do next. Of course perfect plans are really rare in software architecture so better be prepared for errors in planning, but the errors are not reason leave proper planning out (okay I admit that was a bit vague way to put it).

2. Using Android emulator

After my Android phone broke, I thought my only option was Android emulator that came with the SDK. And boy do I hate that emulator. I mean I really really hate it! In Finland we have this idiom that fits here perfectly, “Android emulaattorin käyttö on yhtä tervan juontia”, wich means, “Using Android Emulator is like drinking tar”. I was actually interested in android development before I had my Android cellphone but the emulator in Eclipse scared me away.

In Android development blog there was a post how the emulator is now faster ( Well I don’t see any difference, it’s still like a pint of tar. Okay part of it might be because I have a really old computer and I’m not emulating Android 4.0. But there is another faster way to test Android programs without Android phone. Android-x86 is an Android OS made for personal computers and VirtualBox is software for virtualizing operating systems. Virtualization with these is way faster than emulator.  But there is no reason for me to explain how to set them up since there is well detailed blog on how to set up VirtualBox and Android-x86 for testing Android apps on Eclipse (

3. Not Using Revision Control

Well I didn’t have any catastrophic, “I replaced big part of the working code with useless code”-moment, but I had many, “It would be so much easier to go back”-moments when the Ctrl+Z just isn’t enough. I did very brief research on revision control softwares and solutions. I chose Git on emotional grounds (if manual says it’s, “the stupid content tracker”, it’s have to be good). So I’m using it in eclipse with EGit ( which I’m still learning. There is also entire online book about Git for free ( Here article about revision control that I found through Wikipedia:


I think I broke my laptop (no sound, mouse doesn’t work and keyboard has difficulties understanding finnish) but it isn’t slowing my game development yet. Anyway I had to do some research a while ago about serialization and deserialization (i.e. how to save my game information and how to load for example character or item objects from files). In small casual games there probably isn’t need for larger serialization but in strategy games I don’t think it wouldn’t be smart to pass a huge Java object array or list around between activities.


First option that came into my mind was XML. I’m not much of an XML expert but do know it is a markup language and I had heard that it isn’t exactly a winner in the database or serialization circles. I had some programming experience of it though. Of course through the Android layouts but I had also made parser that made OpenGL vertices from SVG paths. I also knew that Android has also XML parsers in the Android API (

So for example short array for characters in my game would look something like this:

<?xml version="1.0" encoding="UTF-8"?>
	<name>Markku Markkanen</name>
<name>Sam Diego</name>

Size of this file would be about 600 bytes (indentations affect on the size of the file a little bit). XML is easy for human to read but start tags and end tags makes this file difficult to edit by hand in text editor without any autocomplete tricks. It probably would be easier to make GameCharacter into an empty element and current elements inside GameCharacter into attributes. Which would look something like this:

	name = "Markku Markkanen"
	characterId= "1"

So this is a little bit more easier to read and it takes less space: about 400 bytes.


JSON (JavaScript Object Notation) is an alternative for XML in serialization. First I just passed JSON because I haven’t used much JavaScript and I thought JSON is something made specially for JavaScript and if I use it in Android with Java  my laptop will explode and I get laptop shrapnels in my hands and it will hurt my hands. I got over my JSON fobia after I looked closer to the syntax of JSON and found out that JSONObject and JSONArray is included in Android API (

My stumpy GameCharacterArray would look like this in JSON:

"name":"Markku Markkanen",
"name":"Sam Diego",

JSON is pretty easy to read. The square brackets define a JSON object array and curly brackets define JSON object. Handling JSON files is pretty easy with the help of JSONTokenizer, JSONObjects and JSONArray. Size of this file would be 331 bytes.


Both XML and JSON are easy to read for humans. XML is ubiquitous but JSON is more specialized. I found conference article by Audie Sumaray and S. Kama Makki where XML and JSON are compared in data serialization with binary serialization formats: Apache Thrift and Google’s Protocol Buffer (Such a boring name). Well the conclusion in Sumaray’s and Makki’s article was that JSON is exceptionally better in data serialization than XML, both in speed and size. Protocol Buffer and Apache Thrift were faster and more compact but they are not human readable so they do not work for me. So my choice in the end was JSON and I haven’t regretted it yet. Of course there would have YAML which is also pretty popular data serialization format but I was too lazy to look into it.


Audie Sumaray and S. Kami Makki. 2012. A comparison of data serialization formats for optimal efficiency on a mobile platform. In Proceedings of the 6th International Conference on Ubiquitous Information Management and Communication (ICUIMC ’12). ACM, New York, NY, USA, , Article 48 , 6 pages. DOI=10.1145/2184751.2184810



This post is not going to be about programming. It’s more about my problems trying to create game characters into my game with Blender and Makehuman. If these programs are totally unfamiliar to you, Blender is an open-source software for creating 3D graphics with plenty of different features ( and Makehuman is this really handy also open-source software for creating realistic 3d human model (and the models are butt naked!

Since I decided, that my game’s main perspective is going to be top-down, I tried to draw my characters first with Gimp and Inkscape and then by hand but none of them gave me satisfying result (those darn character hands were always so unnatural). So my current game testing character is two ellipses and a stick. Well it’s green like the German polizei.

After my experiments with 2d graphics editor I tried Blender and Makehuman. I knew that Makehuman was pretty simple so I chose them for creating a character of which I would render into top down perspective. First I made human character with Makehuman. It took me practically few minutes because of the top-down perspective I wouldn’t need much to fiddle with expression or genitalia settings. Following that I just exported it into a Blender exchange file. Makehuman can make two different mhx files one for Blender 2.4 and one for 2.5 versions or both.

I’ve been using Blender quite much since 2007 but I hadn’t touch it after I installed new version of Linux Mint about a half a year ago. So I launched my Blender 2.63 and tried to recall my rusted modeling skills when suddenly it crashed an shut down. When I ran the blender from terminal it just gave me: ‘Segmentation fault’. I tried it few times but almost immediately I did something with 3d view it crashed. And when I’ managed to attempt to import .mhx file for the terminal informed that:
‘Error when loading MHX file:
Wrong MHX version
Expected MHX 1.12 but the loaded file has version MHX 1.4’
Same error emerged when I tried file that was made for Blender 2.4 versions except the loaded file had version MHX 1.0.

So apparently mhx files were made strictly only for 2.4 and 2.5 but not for 2.6 version. My solution for this was to download older 2.5 blender version, uncompress it into a folder, not to install it, and run it from terminal. Then the importing 2.5 files worked and I had my human character in my blender. I was so relieved until the 2.5 version crashed informing about the segmentation fault.

I can’t find the forum post but in blender forums they talked about problems with older ATI Radeon graphic cards (Hey my laptop has one!), OpenGL and Ubuntu (Hey my Linux Mint is based on Ubuntu!). So it’s probably problem with drivers and there is no way I’m fiddling with those driver thingies after that ‘I really wanna play Enemy Territory!’ episode (I don’t want to talk about it but I think it was the reason why I formatted my hard drive and installed newer version of Linux Mint). But there

is a solution. I just launched the blender by writing blender-softwaregl on terminal and after that it worked like a charm! It basically turns the hardware acceleration off. But for me it’s way better than suddenly crashing accelerated blender. Finally I had my top down character. At least sort of…

I used the low-poly import because I didn’t see reasons for high-poly for sprites on mobile platform. Just a little clothing and a weapon and it will be ok.


Usually turn-based tactics and strategy game’s game objects are inside squares or hexes. I’ve decided that in my game it would be fun to make turn-based game without those board game like cells. Biggest differences compared to hex and square thingies, I could think of when I planned this, were: objects positions are not hex No. X but x and y float coordinates in game space, distances are not X amount of hexes but  float numbers and the area where game characters can move are now circles. So I’ve came up with MoveCircle which shows where player character can move, how many action points moving will take and path which character will use. I can’t remember, have I seen this kind of way to control character in any other game but it’s so simple I think I am just reinventing the CIRCLE here (but that joke was really original).

Moving path (the blue line in the picture) now shows how far within the green circle the character will go but I’m also going to make it show a path around objects which are blocking the way.

Since OpenGL doesn’t have circle shapes by default  I had to make my circles by myself from triangles. Easiest way for this is to make for-loop which counts vertices from distance from the center of the circle and angle with the help of my arch-nemeses from senior high school: sine and cosine.

//Green circle's vertices
circleArray[0] = 0;
circleArray[1] = 0;
// Angle
float theta = 0;

for (int i = 2; i &lt; circleArray.length; i+=2) {
    // x-coordinate
    circleArray[i] = FloatMath.cos(theta);
    // y-coordinate
    circleArray[i+1] = FloatMath.sin(theta);
    //Black line circle's vertices
    lineCircleArray[i-2] = circleArray[i];
    lineCircleArray[i-1] = circleArray[i+1];
    // The angle is in radians
    theta += 2*(Math.PI) /((circleArray.length/2)-1) ;

The circleArray is an array which consists the green transparent circle’s vertices. It also has the center vertices because it will be drawn from triangles. This loop also includes the black hollow circle’s vertices. It doesn’t have center vertex  because it’s made from lines. When for-loop fills the arrays the line circles and green circle are same size but when OpenGL draws them I just scale them smaller.

The more circle has vertices  the more smoother it is. This also means bigger arrays for vertices and possibly less frames per second. My circleArray’s length is 38 so it has 19 vertices (18 on the edges and 1 in the center). Of course one can distinguish the edge lines in my circles but it’s perfectly adequate for testing.

More about OpenGL ES circles: