I've just posted a new version of War Worlds to the App Store, which fixes a number of bugs that were found in the initial release of War Worlds. You should be getting it in the next day or so.

Firstly, I just want to say a big thank you to everyone who reported a crash in the initial release of War Worlds. Please continue to report all crashes you have and even non-crash bug reports (you can either email me, or post them to our Google+ community).

Being a small developer, I don't have a large QA department or a swath of devices with which to test the game so I rely on users to report bugs using the "Report" feature. This feature is actually pretty amazing: you can type a comment and the report shows up immediately in my developer console along with the comment. I can see the top crashes that people are reporting, it gives me the exception that happened and the stack trace and usually I can pinpoint exactly what the problem is in a couple of minutes.

Being the very first release, there were a couple of nasty bugs which I probably should have picked up myself in the first place. I'd like to take a moment to describe what I learned in the process.

OutOfMemory Errors

The first one was a lot of OutOfMemory errors. This would manifest itself as crashes while you were trying to move fleets, crashes when switching between starfield view and solarsystem view and crashes while just scrolling around the starfield view.

It kind of surprises me, even on relatively new hardware, how little heap space you get to allocate bitmaps and so on. One of the features of the game (which I described in quite a bit of detail in an earlier series) is the ability to generate unique planet and star images for every single planet and star in the game.

In retrospect, I probably should have realised this was going to be a bit of a memory hog: a unique image for each star that gets rendered in the starfield view can quickly add up to lots of images. I had a caching system in place so that only visible stars would be loaded, but that caused a bit of stuttering as stars would be loaded and unloaded as you scroll around.

I had already implemented a feature to disable the unique star and planet image generation and just use a spritesheet of pre-generated ones, it was just that by default, it was generating the unique images. The "solution" here was to switch that option off by default. In reality, it doesn't really affect the look of the game all that much. I'd say the only time you'd notice it is with the "terran" style planets anyway. You certainly don't notice it on the starfield view.

Exceptions while building

I have not quite gotten to the bottom of this one, but I've added code that should mitigate the problem for the most part. This seems to be related to the issue I describe below (saving the best one for last), but essentially there were some issues with the build queue getting out of sync with the server and the client not finding what it was expecting to find there.

Exceptions when resuming activties

I'm probably a little OCD in the way I use my Android. Normally, when I leave an application, I use the "Recent Applications" button to force-close all of the running apps.

 

This view sets off my OCD and I always end up closeing the applications as soon as I've finished with them. And War Worlds was no exception!

But it seems like I might be somewhat alone in this kind of behaviour. I was getting a lot of crashes where things were null which I wasn't expecting them to be null, and the only explanation I could come up with is that Android was unloading my activities (and hence, sometimes, the process) so all my static variables would be null the next time the activity was resumed.

Don't Keep Activties

Testing this is actually kind of hard, because Android will normally unload activties at fairly random times. However, an option in the Developer Settings, "Don't keep activties" (formally "Immediately destroy activities") lets us simulate what happens by having Android not keep Activties around after you're finished with them.

Enabling this setting on my test device, I was pretty quickly able to reproduce the issues and (hopefully) fix them.

A Warning

Just closing off with a quick warning about the "Don't keep activties" setting. Remember: this setting is specifically designed for developers who want to debug situations like the one I described above. It's not for normal use.

I've seen a number of places on the web suggesting that turning "Don't keep activties" (or "Immediately destroy activties") on will result in "better performance". I can't stress enough how utterly horrible this advice is. I can tell you right now that the vast majority of the switching you do between activties is between activties that are already loaded. If you enable that setting then every time you switch activties, it has to reload all the data it had. You might save yourself a couple of MB of memory, but it'll be at the expense of activty-switching speed.