Monday, 1 October 2007

What's so bad about J2ME anyway? I forget - ho, ho.

This is something of a continuation of my earlier rant.. you have been warned :)

Not many people buy mobile games, in comparison to the number of people who own them. So the carriers want games that work on as many handsets as possible to maximise the number of potential customers. This is one of the things that makes J2ME game development more like PC dev than console, in the sense that we don't have a fixed platform. This I think was the original selling point of Java on mobile devices - that it standardised the way games would be developed and distributed; the much-touted "Write Once Run Anywhere" promise. But that only makes sense if you completely blind yourself to all other technical questions: while games developed for similar-spec'd PCs were created using all manner of low-level assembly tricks to squeeze every precious cycle out of the processor, Java actively prevents the programmer from finding out any information about the hardware on which the program is running. John Carmack made some mention of this during his experience creating Doom RPG. There are even more fundamental questions like "how do you make a sprite-based game that simultaneously works on a 120x120 screen and a 240x320 screen?".

The reality is even devices that are very similar behave completely differently, due to the manufacturer's JVM implementation. Since I make 3D games I'm somewhat blessed in that I only have to deal with fairly few devices, all of which are fairly high-end. On my first couple of 3D titles the worst device by far was the Nokia 6680 - it has a severe issue whereby the garbage collector either doesn't reclaim unused memory or never compacts memory, allowing it to fragment. The end result is, as you release the resources from one level to load the resources for the next, a big chunk of memory disappears, and very soon the phone runs out - at which point Crazy Things happen. The accepted "solution" to this problem is to work around it i.e. to load all the resources for all the levels at startup and never release anything ever. Thankfully the 6680 was eventually superseded by the n70, which doesn't seem to suffer from the same problem.

On my most recent project we deliberately "pushed the envelope" in terms of graphical quality, meaning we had a hell of a lot of resources. So many in fact that they couldn't all be loaded at once on the 6680. It was fine on the n70, so the client didn't seem to mind too much. I created reference builds for various other devices, leaving the new one until last: the n95. This is the phone Nokia are very heavily pushing at the moment with their "what the PC has become" ad campaign. When I first looked at it I was very impressed - it has a great screen, and hardware acceleration allowing it to spew polygons onto the screen faster than any other device I've seen. When I finally came to do a full build of the game I was soon disappointed - after a couple of levels I noticed the loading times became incredibly slow. I discovered a call interrupt was enough to kill the game after this had happened. It took me some time to conclude that the 6680 memory issue was never resolved. Nokia's "fix" for its n-series devices was to put vastly more memory in them, so you'd need to play a game for several days non-stop before the phone crashed. Unfortunately the n95 has about as much available memory as the 6680 - so the issue has returned. The annoying part is Nokia are perfectly capable of producing a phone without stupid memory issues - the 6280 is such a good phone I even own one, yet its an arguably low-end s40 device. Actually no, that's not the annoying part - the annoying part is Nokia's refusal to admit that there is even a problem.

Now if only SonyEricsson could get their M3G implementations right, I would convert!

3 comments:

Pete said...

I still believe the solution involves cats.

chrismcr said...

Cats with telescopic legs, I'll be bound..

Ceana said...
This comment has been removed by a blog administrator.