This results in unhappy clients and very bad download counts for small, paid apps like Light Mayhem. To face this fact, I decided to remove the commercial version and merge scoreloop integration into the free app, monetizing with AdMob, again.

The direction, this experiment tends to point to, is not the most pleasing – even Paper Wars which was quite strong through the last months, tends to decrease ad impressions by a great amount. After all, I’m quite happy that I did not decide to go to self-employment for app-development. You will not be able to place a hit with no or low budget, anymore – good for customers because quality improved a lot during the last year, but bad for the lone developer who has no big budget to spend for art and sound.

Anyway, I will continue to support my games as long as it is possible in my spare time. Maybe there will come some content updates as well, but do not expect any major releases any more.

Big thanks go out to everyone who tried my games and was able to give some objective feedback by market comments.

Paper Wars got a huge update today and a lot of the code base was streamlined to the other titles. This means that a lot of code is currently shared which makes maintenance and updates easier and faster. This update is the preparation for some content updates to get into the game, later.

Anyway – I’m happy that the game made it this far!This patch fixed a usability issue where it was possible to place balls while being in “level complete” screen. Additionally, sounds were added to the game – sounds in the sense of “something to start with”.

Finally, the coarse-location-permission was removed as well – it was only needed for admob but did not made any difference. Thus less permissions, more convenience.

After being busy with things other than Android programming, I finally got a new update for Paper Wars published. The game has been surprisingly popular even after being online quite a while. 120983 downloads in 10 months – not too bad for being a hobby project.Install base is about 25000 using android market, which is surprisingly high as well. So

maybe time is right to start working on a content update sooner than later?

Update v1.19 should fix two crash bugs that seemed to happen on multi-touch devices. Additionally, I removed the coarse-location permission since it was only needed for admob and did not make much of a difference from a ad-view and click-count point of view.

And last but not least, the scoreloop integration was easier and looks more promising than originally thought. Besides the online high scores, there are numerous really cool features waiting to be integrated… like challenging other people or social network integrations.

More information about the game can be found here.

For my next project – which is about to go to public beta, soon – I decided to start with high-score integration but move on to support much more functionalities later. Because I am using a OpenGL renderer, I can’t use the CoreUI Package which provides a nice pre-built UI. My architecture is built to support platform-independence. This means:

Platform Application->Game Instance

To make internal communication in the game easier, the Game Instance is a singleton that gets created by the platform dependent application which also creates a update thread and calls a render method of the game. This is quite efficient and flexible – I’m still able to create the whole game mechanics on the Desktop with faster turn-around times and easier debugging and switch to mobile devices once I need.

The problem with scoreloop: it must be called by the main thread of the android application – which is the starting activity. But for my projects, I have three threads running:

1. The Main Activity
2. The Update Thread
3. The OpenGL Thread

Number 2+3 are the actual game instance, which is knowing nothing of thread 1. If things go wrong, funny error messages like this are likely to be thrown to the DDMS:

11-15 10:54:45.493: INFO/dalvikvm(11024): WOW: somebody generated [Landroid/server/data/StackTraceElementData; simultaneously

This happens when an issue is causing my threads 2 and 3 to crash – something like updating and rendering a null pointer. Luckily, the android developers already had a good idea to handle issues like this: the message handler system. This persistent message system if manages state switches by the activities.

The rendering of the scoreloop results happens in the Game interface, but how is it possible to get the data there, if you must access the scoreloop client by the main thread?

1. Create a new message in the update-thread that sends the request to poll data from the scoreloop client
2. Fetch the message in the main thread and trigger a ScoresControllerObserver
3. Display a wait-dialog until a response from the scoreloop server arrives
4. push the retrieved data into the game instance
5. update and render the game user interface

Of cause I can’t easily call a method to push the retrieved data into the game – chances are high that 5th step interferes with the game update and render calles (remember: the push into the game happenes by thread 1 while threads 2 and 3 are still working). But this problem can easily be solved by synchronizing the update, render and push-methods like this:

public synchronized void updateScores(LinkedList scoreResults) {};
public synchronized void update() {};
public synchronized void render(){};

Well – if this solution works for things like challenges might be arguable at the moment. But at least it provides a defined interface to get the scoreloop data into the OpenGL game.

Besides some crashes that got fixed, both applications can now be installed to the SD-Card.

Since this functionality works only on Android 2.2 and higher, a similar trick to the Paper Wars multi-touch support has been used: the Applications are linked against SDK version 8, while min-SDK stays 4 (Android 1.6) which means that the apps still support older devices.

This maintenance patch is finally adding the soundtrack – the data was shipped some weeks, already, but there were issues during playback. Also, the enemy tanks are behaving as expected and several crashes have been fixed.

In current generation of graphics hardware, it is possible to render a lot of fancy post-processing effects – an besides soft shadows and the motion blur, depth of field (DOF) might be on of the most often used effect to enhance visual quality. There is a vast coverage on different techniques in creating pleasing DOF effects – a simple google for “depth of field shader” gave me a about 74.000 hits. For a demo I wanted to write, I decided to use a simple, alpha-channel-based approach because it is simple, fast and looks nice.

The idea is easy: If you already have a shader that does things like per-pixel-lighting, just put the depth information into the resulting color’s alpha channel. All that has to be done in the second pass: render the image again and blur the image with a suitable kernel. As kernel, I chose a Poisson-Disc-Filter with CPU-precomputed data – this is less “jaggy” than using a simple quadratic kernel, giving better visual quality by less samples. To prevent nasty halos around the edges of areas that have high depth-differences, the result is not simply a blurred picture, but the focal-length also controls how much blurred image data get into the final result.

vec4 vColor = texture2D(sceneMap, gl_TexCoord[0].xy);
float fBlurAmount = abs(vColor.a*2.0-1.0);
float fTexel = 16.0/mapSize;
vec4 vResult;
for (int i=0; i<16; ++i) {
    vResult += texture2D(blurMap, gl_TexCoord[0].xy + fBlurAmount*fTexel*poisson[i].xy*poisson[i].z);
}
vResult/=16.0;
gl_FragColor = mix(vColor, vResult, fBlurAmount);

I am aware that this approach is quite limited – as soon as the alpha channel is needed for other effects (like a glow-pass or velocity), it can’t be used like this. But anyway, I’m happy with the results.