With my ExEn experience under my belt, I was more than interested when discussions about J2ME started surfacing. Another Java based mobile development system, it sounded like more handset manufacturers were considering taking it up and adding it to their phones. This could mean that downloadable apps were about to enter the mainstream a little more. With iomo having developed a good relationship with Nokia through some WAP work we had done for them, it was doubly, no triply, interesting when they came to us and asked us to create a mobile game to be embedded on their new mobile handset, the 3410. And on top of that, it would be in 3D!!!

No, no - you heard me right. 3D.

That's right. Despite still being in black and white, and still having a 96x65 screen, it came with something akin to OpenGL-ES! Oh my word!

And the game had to fit into 32KB. ... Heyurk!!

What we ended up coming up with was a 3D strategy block-based puzzler with 30+ levels, unlockable levels and tutorial levels. The player controlled this monkey character who wandered around the 3D landscape (rendered in real time) pushing and destroying blocks to try and collect items to finish the levels. And due to the deadline and importance of the project, we had two programmers working on it - Slick and myself. Unfortunately, we really only had a couple of hundred visible polys to play with if we wanted to keep the framerate reasonable, and the renderer didn't support line drawing in the 3D, so several optimisation techniques went out the window.

Slick and I ended up going over to Copenhagen to the Nokia offices there for about a week to work alongside the people making the handset to try and polish off a lot of the development and I think almost every evening on our walk back to our hotel we had the same discussion on how to get the renderer working faster. It was a continuous trade-off of the look we wanted versus poly counts versus frustum poly rejection optimisation.

(For some reason, I also remember getting really bad stomach pains for two of the days I was over there - that wasn't fun at all)

I also dallied around with the concept of writing an obfuscator for the game. It was a real pain, and conceptually not terribly well thought out, although it did work somewhat for this one project. Not something I could extend into a generalised solution however.

Another project that we did with Digital Bridges, DB came to us with the Scooby license and asked us to come up with a game for it. Our thoughts were to create another "sub-game pack" kind of game with an exploratory section (where the player controls Shaggy exploring a haunted house or mine for clues, such "the villain must be short", or "the villain probably has dark hair"), a deduction section (where, demanding how well the player did with Shaggy, Velma ends up trying to guess who the villain might be from a selection of player portraits), and then finally a side-scrolling action section where Scooby (in either the Mystery Machine or a mine cart has to race away from the ghost/zombie, dodgy things in an attempt to lead him towards the final trap).

Now at this point in time, colour mobile phones were just on the way in and this ended up being the first game I did that ended up on quite a few different types of handset - screen sizes from 96x65 up to 176x208; black and white screens to colour screens; small memory to large memory; large possible application size versus small sizes (where we actually had to split the game into multiple downloads with a code that was passed between the two). So what does this mean?

Well, unfortunately, it meant that the code ended up being a complete dog and a mess! I feel sorry for Steve who had to come along later and put it on some other handsets - as a studio, we didn't exactly have a great deal of multi-handset porting experience then, so I was kinda making up ideas as I went along. And a lot of them weren't that great.

Want to see how NOT to write portable code?

#if defined(UI_BW) | defined(MOTOROLA) | defined(SERIES40) | defined(SAMSUNG_S100) | defined(SIEMENS_M50) & !defined(LANG_EN)
#define SCORE_FONT_SIZE 0
#else
#define SCORE_FONT_SIZE 2
#endif

Oh yeah, that'll make porting easy! Yuck!

This game was also my introduction to the world of specification adherence (or lack thereof) that's such a pain in mobile porting. You can't scroll more than a couple of dozen lines in this codebase without finding some "#ifdef something-or-other" hack to get around the fact that all the phones were acting differently. I think, all things considered, this game has the most unreadable codebase of all the games I've ever written. Most the others I could probably go back to now, years on, and find some way of adding a new handset specification to - with this, eurk, I wouldn't wish that on anyone.

Optimisation was a little tighter in the game, with a better standardised way to deal with resource packing, and I started using an off-the-shelf Java obfuscator instead of trying to write one myself (definitely a good idea!), but due to some pesky things about the game (e.g. see above about us having to split it into 2 builds for some handsets), I couldn't optimise the codebase as much as I wanted. However, we did still cram quite a lot in there.

• In the Shaggy game, the layout of the mansion/mine was randomly generated at runtime, including hidden objects, roaming ghosts/zombies, multi level map including locked doors and the need to find keys for them, scooby snacks on the floor to replenish the player's health... I was pretty happy with that.
• In the Velma game, we had a variety of charcaters with different facial features that we could draw tall or short, with glasses and without.
• In the Scooby game, the animations and graphics were pretty cool, and it required good reflexes and timing to avoid all the potholes / fallen trees and such to get to the end of the track.

And all of them ran at a pretty reasonable framerate, even on the terrible phones that were around at the time. and there was an ongoing difficulty curve where if you completed the game once, it would continue your session onto another setting, but the mine/mansion had more floors / the Scooby chase was longer, ...

On its release, the game even got nominated for a Best Mobile Game BAFTA! Jinkies!

I do have to admit that the graphics of the colour version were very much an afterthought, though. The original game was almost completed in black and white when the request for a colour version came in, so they just ended up being colourised versions of the b&w images. Not a bad thing, you might think, but generally the colour phones had larger screens too, and we didn't really make any effort to enlarge the images, so on larger phones the game tended to have a very 'letterboxed' feel to it. However, now that I think about it, I dread to think how much worse that codebase would have looked if I had tried to crowbar in different image sizes into it as well.

(shudder!)

The last game where I had to worry about black and white handsets. Oh sure, when we were doing later projects things like the 3410 and Siemens SL45 were still around, but the people who owned them weren't the people spending money downloading new games, so as revenue earners they were becoming a smaller and smaller part of the games market. However, here, at the end of 2002, the handsets were still a reasonable part of the market and so I had to create another game that supported both black and white and colour. And having learnt a lot from Scooby, I tried to make this a) a neater codebase, and b) less of a hack job getting colour integrated.

But first, the golf game. Back when I was doing Wentworth Golf, the java, course data and images stored on the server came to about 400KB when zipped up. That's quite large. Or at least, that was quite large by 2002 mobile standards. And by "quite large", I mean "HUGE"! For some of the devices we were targetting here I had to get everything into a 50KB JAR file. Okay, so we'd only be requiring one course (the illustrious Pebble Beach), not two like in Wentworth, but that still left a huge amount of changes and optimisation I'd need to look at.

First things first - course storage. As I showed on the Wentworth page, I was storing the data there in a horrific manner. I really needed to crunch that course data down. The end result - storing vectorised outline information for all the course features. (Real world example - if you wanted to store the detail of 50'x20' rectangular swimming pool, you would get a piece of graph paper and write 1000 X's in a 50x20 grid - that's hugely wasteful - you'd store corner-position : corner-position : corner-position : corner-position, job done - much tinier amount of data, can be resolved to the same info by extracting it right)

Fortunately, back when I was working at SCi one of my tasks on one of the projects I was working on was creating a vectorised map for an in game scanner system. Based on what I knew from that it was a piece of cake to write something so that the artist could create a top down map image (using symbolic colours - dark green for rough, light for fairway, lighter still for green, red dot for the tee, etc.) and my utility would scan the thing and create a vectorised estimative outline of all the features. As a result, I got all 18 holes of data stored in less than 10KB. Sweet! We're on our way to crunch stuff down.

Additionally in the game it was required that there be a 2D view and a 3D view. I think some of the really low-end handsets actually ended up without the 3D view because of memory limitations of what I was trying, and on top of that some had to sacrifice the golfer animations as well, but for the higher spec handsets, the end result was quite impressive, I thought, for the time it came out. There was a nicely dithered 3D colour render, some handsets even had reflections in the water, there were even weather effects.

There was the downside that on the higher spec handsets you could clearly see the vectorisation of the map data (see those jagged edges to things in the screenshots above!), and the rendering on some handsets was quite slow, but it was no worse than early PC golf games, in my opinion. All in all, I was quite happy with the end result (and I imagine other people were too, or we wouldn't have been asked to do sequels).