Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

10 Golden Nuggets on Mobile Phone Game Development

Sign in to follow this  


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.
Sign in to follow this  


Recommended Comments

Happy New Year Meh!

Great journal entry and thanks for the nod of how we weren't baaad to work for. [wink]

Good Luck at the "competition" erm, your new job - keep us informed on how it all goes!. [smile]

Share this comment

Link to comment
Hey there Charles! long time no see on msn. how goes work at real time? hopeit's good. i am continuing the quest for employment. see ya soon take care, rach x

Share this comment

Link to comment
Some nice stuff there.

I wonder if you have seen mDevInf, an OS Java project that acts as a front end to the WURFL database of mobile, wireless device information. All the information is user submitted, so quality isn't exactly assured, but its still probably the best collected resource of information on wireless devices available at the moment.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!