Libgdx Livewallpapers are here

Some nice guy called Patrick Nagelschmidt contributed a wallpaper backend. After much refucktoring, i was able to make it work seamlessly with the rest of libgdx. Here are the instructions. Note that input is still a bit of a WIP, and i didn’t test on a multitude of devices yet. Maybe you guys can help 🙂 The nightlies should be ready in half an hour, they contain the new classes in the Android backend. Also, i extended gdx-tests-android to also install a livewallpaper that displays the WaterRipples test, see, which is just dummy for a settings Activity, livewallpaper.xml which declares metadata for the wallpaper, and finally the modified AndroidManifest.xml.

The starter class for a livewallpaper is called AndroidLiveWallpaperService, here’s an example:

The methods createListener() and createConfig() will be called when your livewallpaper is shown in the picker or when it is created to be displayed on the home screen.

The offsetChange() method is scaled when the user swipes through screens on the home screen and tells you by how much the screen is offset from the center screen. This method will be called on the rendering thread, so you don’t have to synchronize anything.

In addition to a starter class, you also have to create an XML file describing your wallpaper. Let’s call that livewallpaper.xml. Create a folder called xml/ in your Android project’s res/ folder and put the file in there (res/xml/livewallpaper.xml). Here’s what to put into that file:

This defines the thumbnail to be displayed for your LWP in the picker, the description and an Activity that will be displayed when the user hits “Settings” in the LWP picker. This should be just a standard Activity that has a few widgets to change settings such as the background color and similar things. You can store those settings in SharedPreferences and load them later in your LWPs ApplicationListener via

Finally, you’ll need to add things to your AndroidManifest.xml file. Here’s an example for an LWP with a simple settings Activity:

The manifest defines:

  • it uses the live wallpaper feature, see .
  • a permission to be allowed to bind the wallpaper, see android:permission
  • the settings activity
  • the livewallpaper service, pointing at the livewallpaper.xml file, see meta-data

Note that livewallpapers are only supported starting from Android 2.1 (SDK level 7).

LWPs have some limitations concerning touch input. In general only tap/drop will be reported. If you want full touch you can see the AndroidApplicationConfiguration#getTouchEventsForLiveWallpaper flag to true to receive full multi-touch events.

Please test this thing and report any issues you have. Chances are that OpenGL context and surfaceview handling might be broken on some devices, which seems to be a problem of all OpenGL based LWP implementations. I couldn’t find an issue yet.

Tiny Dungeons – Steering and Pathfinding

I’ve spent a few hours today and yesterday adding behaviour to the hero and monsters. The biggest challenge is keeping monsters apart, having them follow the hero and not tunnel through walls.

For path finding i use a rather simple and unoptimized implementation of A* on a tile grid (though it’s generic enough to work on any graph really). Path finding is only used to guide the hero to the point on the map the user tapped on.

For keeping monsters separated i give them a simple separation steering behaviours. To avoid walls, i implemented simplified obstacle avoidance which exploits the fact that the entities are moving on a tile grid. The monsters follow the hero by simple seeking. Those three steering behaviours (separate, wall avoidance, seeking) actually make for a passable overall experience. Each steering behaviour has a weight, so i can control the contribution of individual steering behaviours to the overall direction a monster takes. E.g. wall avoidance is weighted higher than seeking or separation. This (kinda) guarantees that monsters will prefer overlapping with each other more than tunneling through a wall.

I tried doing A* for every individual monster, but wasn’t happy with the result. Steering behaviours can’t resolve deadlocks resulting from paths that overlap in space and time, which creates stalemates among monsters. There might still be a way to make this work, however, for the simple dungeon maps the seek behaviour should suffice.

There’s a nice paper by Vavle on how they solved similar problems in Left 4 Dead. It’s a bit overkill, but some principles i could apply to my scenario as well. Haven’t had time to look into it yet, reactive path following looks pretty much what i had before i killed A* path finding for monsters. Thanks to Dave (@redskyforge) for pointing me at the presentation.

Here’s the obligatory screenshot, green lines show the velocity/direction, red lines show the steering force/acceleration. Blue tiles are the path nodes the hero follows.

You can try the desktop version here. Press ‘d’ to toggle the debug renderer.

You can try the Android version here. Alternatively you can use this QR code: