EDK Eric asked me for some advice on mobile games programming and in replying to him I decided this would make a much better entry in my journal that others can read. My experience of mobile programming is based on five-months working for a company called Caveman Arts creating mobile games and applications in J2ME for the international market.

These are essentially the things I picked up during that time.

1. As an Indie it's very, very hard to get money from above you in the chain, the smaller number of people in that chain the better. Until you start receiving money you will need a lot of investment!

2. Everything you do will be done for multiple handsets, made by multiple developers, with differing interpretations of the standards. In short anything that works on one handset will probably mess up another, even within the same manufacturer and handset family! Device fragmentation is one of the biggest problems facing a Mobile Developer. It isn't insurmountable though.

3. Mobile projects are short-term, the longest is likely to be 6-months and that will be for a big project! As such it is critical to have your tools setup and working before you begin. Including a robust and extensible way to manage a build chain and version control for source and assets. Hacking as you go will work but will leave you with an unwieldy mess that will be hard to take forward. Anyone coming to work on your code afterwards will not have a clue! Trust me, I had to do this daily!

4. The usual rules of development apply things like; design before you implement, profile as best you can before optimisation and don't take shortcuts unless you really, really have to!

5. Java might be an Object Oriented language but you won't be using those features! Every class added to a project adds 1k overhead to the overall JAR size. That's an awful lot of room when you have a 64k ceiling. As usual try and keep non-project specific code together (Math, persistent storage, etc.). Mobile development is most definitely it's own beast, the only way to prepare for it is to do it!

6. The Eclipse IDE is worth its weight in gold, personally I never used any of the MIDP/J2ME plug-ins for it. We stuck with a build chain based in Ant and used the Antenna extensions. Eclipse supports Ant natively and makes a complicated build chain easy to manage. Ant was primarily used to create build tasks for specifics to cope with device fragmentation, localisation and inclusion of specific assets. The other software used included MediaWiki for an internal documentation system and Subversion for asset and source control. Eclipse has some great plug-ins for Subversion.

7. Emulators are complete rubbish for the most part, they are useful for testing non-handset specific code such as game mechanics but there is no substitute for on device testing. On device debugging is even worse, in most cases you are limited to waiting for the device to fall over and hoping you know what went wrong! Error messages are non-existent. The exception to this is Sony Ericsson who support on device debugging, absolutely light-years ahead of anyone else. Back to the emulators and printf debugging for all the others! Bigger headaches include memory management (yes, in Java!) and sound playback. The use of a pre-processor such as the one packaged with Antenna allows device specific work-arounds.

8. Back to device fragmentation, the devil! There is plenty of help out there either in pre-bought solutions such as J2ME Polish or by creating your own build solution. J2ME Polish holds a nice device database and other sites also contain information on device specific issues. The best place to start is the manufacturers Knowledge Base but for the most part these are obtuse and the information you most want is often buried. Other fragmentation issues include localisation (to eastern as well as western languages) and asset management. Mobile phones have an eclectic mix of screen dimensions to cater for and you can often get a better deal with a publisher or distributor by including some adverts. You don't want to be doing this by hand!

9. Sign up on J2ME.org it has a wealth of talented amateurs and professionals.

10. Have fun. I did, working in a small team at a start-up is unlike anything else.