Shortly I will be ready to port my mobile phone game which currently runs on a Sony Ericsson Z800, screen 176x220 and uses MIDP2. There seems to have been a lot of talk about the difficulties of porting games between devices but few concrete examples. I am failing to see what the major difficulties are except for screen size and images having to be altered. Note the game is self contained and does not connect to any other devices or networks. Currently sound is not supported however vibration is if the device supports it. Can anyone give me some info on what problems they have had when porting games? I will be only porting to other MIDP2 enabled devices and 128x128 will be the smallest screen size. There seem to be few people here who have successfully released mobile games so hopefully I can get some good information. Thanks, Greig Hamilton PS Also what do most people port their games to? I am think the Nokia 40 and 60 series will be my first ones as they are popular series.
From our experience the absoloute minimum ports needed to get any distro interest would be:- Series 60 Nokia Series 40 Nokia SE K700 / K500 / J300 Series All the Moto V series you can cover And all the Samsung devices you can cover. Main issue in porting is purely speed on the s40 and low end phones and keeping under deliverable file sizes for networks. ie. you may have a 150k build for your SE phone - but still a lot of people want S40 files under 59k and S60 files under 95k..... unless you want 2 sales a month via handango...... and no sound at all ???? c'mon thats like a totaly cop out! if i can help you out with anything let me know
as a side note.... as theres a constant stream of posts regarding mobile gaming for indie's... how about a dedicated board for it ? Then we can keep it all in one place for those interested ?
You are going to leave out a lot of devices then, which means you will probably have difficulties selling your game to aggregators. Besides what mj32 mentioned, file size, cpu speed and memory, another problem is: MIDP2 device A != MIDP2 device B. It's nice to have a standard, but you won't hardly find two devices that behave the same. Before start porting, I recommend to look for known issues about your target device.
I would of recommended that you wrote for midp1 S40 & S60 first and then go from there perhaps as then it would run on loads more devices from the start and also the newer midp2 and open up a lot more devices for you. I started in mipd2 level first back in 2004 and it was to later prove to be a massive and very costly mistake on my part - so I had to bite the bullet and start again sort of!. In the ideal world (which I guess is sorta coming) I'd like everybody to own a midp2 nokia api compatible series60 then life would be much easier heh Anyway I would be up for a mobile board/section or whatever as it would be handy to keep all this sort of thing in once place as a useful resource.
Only just started developing a few mobile games; going with MIDP2 although will definitely support MIDP1 once I have some tried and tested ideas. Since I've never coded Java or MIDP before I found MIDP2 was the easiest option to ease me in. MIDP1 seems to require hacks and digging into the api to find workarounds for the missing game functions. So while learning I'm sticking with midp2. A dedicated forum would be great, and I'm sure it would help morale for some of us learning, and trying to avoid various pitfalls with mobile game development. Would also be cool to try eachothers MIDlets out and offer testing on other devices.
mj32 thanks for the list of what you have found to be the minimum required handsets to port to. Under 59k will be hard, that is going to require a bit of work but hopefully reducing some of the images will help. Any other tips? Okay yes, no sound is a bit of a cop out. I was just trying to keep the game simple to develop. (Now I am going to have to ask what the pitfalls are to doing sound and also where good places to find sounds/music are.) baegsi do you mean that I am going to miss out a lot of handsets because of MIDP2 or because of the handset size? I can understand I will miss out a lot only using MIDP2 but do you also think I should support a smaller screen size? Adrian - Thanks for the advice I am now beginning to see your point, porting back to MIDP1 will take quite a bit of work. Although I am tempted to think long term and the fact that in the future most people will have an MIDP2 phone, so I can just develop a few games now and wait for people to convert. I think this might take a while to happen though, does anyone have any thoughts about how long it will take until MIDP2 is more popular than MIDP1? Finally, yes a separate board for this would be good. Greig Hamilton
If you need good music in a small size fast and at a fair price this guy is very good for it, have used him before for an unreleased game. http://www.mfiles.co.uk/original-music.htm
Because of Midp2. 128x128 screen is fine, but midp2 is a limit. But since you have your game already finished, the question is whether porting it to small midp1 phone is worth it or possible at all.
Just thought I would also 2nd dustinh 's music recommendation. Jim over at mfiles has done the music for every one of our mobile games and I would always give the work to him first! Our 'Chaos Realms' game got an award from a mobile site and 'Super Mixem' won 3rd place in the Samsung game dev compo 2005, and his audio definatley helped in both cases! and, yep under 59k is a pain in the a*s! But is also a huge potential market - and a requirement we have found for China / India and many other markets. We seem to tackle ports by reducing animation frames in sprites / reducing colour depth down to 16cols for everything and looking long and hard at data for levels etc - images with a lot of dithering realy are not good - they dont compress so well so avoid those.. and maybe reducing audio content to only a title tune to save mem but give that immediate 'wow a tune' effect ........and lots of trial and error!
If you have developed for midp2 only then I wouldnt worry about it now I guess just stick with that and do 128x128 128x160 160x160 176x208 and 176x220 graphics (plus extra 208x208 version for Nokia 6230i) and you will cover quite a few Nokia's and Sony Ericsson's plus some other devices to boot for a first game. Dont bite off more than you can chew is the key when starting out but do support as many phones (screen resolutions) that you can by way of different scaled sets of graphics.
Adrian, thanks for the comment. I think you are right. I will just stick to MIDP2 now that the game is mostly complete using it. I will try to support as many MIDP2 phones as possible. Then for my next game do it using MIDP1. If I try to convert the code to MIDP1 I may end up not finishing the game at all. You live and learn I guess. Thanks everyone for your input. This is a really great place with people who actually have finished games and very good advice. Thanks Greig Hamilton
It probably goes without saying - but I'll say it anyway - that there are already quite a few forums for J2ME development at other sites. J2me.org has several very useful and active forums. In the Game Programming forum there, you will find a sticky titled "Give me all your tricks for minimizing jar file size" which has over a hundred posts. Other good forum sites are the J2ME forum at Java Games Forums, Sun's Java Mobility Forums, the Java 2 Micro Edition forum at Java Ranch and the manufacturers' sites, such as Forum Nokia. I don't want to pour cold water on the idea of a mobile forum here at Indiegamer, but there probably should be some thought invested as to its focus, so it won't simply be duplicating forums that are already well-established.
Thanks for pointing out those forums. I was aware of some of them (like the Java games forum) but most forums I came accross were either too quiet or too focused on J2SE game dev. The J2ME.org forum alone is just what I was after.
You may consider using J2ME Polish. It's a set of tools including a game engine/wrapper that makes it possible to use Midp2 API on Midp1 enabled phones. Never tried it before, but heard some good words about it. Adds overhead but could still be useful