Jump to content
  • Advertisement
Sign in to follow this  
dgeuss

Considering starting a J2ME game

This topic is 4507 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Myself and a few friends have been making PC games in our spare time for many years. Its fun, but we can't find many people interested in playing our PC games because there are so many high budget well developed games out there that people would rather play. You just can't compete when you only have 3 people working on the game project part time for fun. Even I wouldn't want to play my own games when I can play World of Warcraft or Civ IV. Then it struck me while playing Doom RPG on my mobile phone. These mobile games are so old school, like back when there were only a few people working on the entire game project. So I have a few questions about J2ME... I've done a lot of Java2D programming before. How similar is the J2ME 2D library? How bad are the performace constraints on a mobile phone? Back in the DOS programming days you would need to do all kinds of tricks just to get some performance. Is it like that with J2ME? If so, how convoluted are the performance tricks? I am trying to get an idea about how hard it would be to break the ice in J2ME game programming.

Share this post


Link to post
Share on other sites
Advertisement
In my opinion, if you are a good computer game programmer, it will be easy to program for cellphones.

With J2ME you can have some nice results in a short time. The biggest problem you will face in the code will be memory limitations. You have to optimize every image, every sprite, and so on.

But the real boring thing is to port the game for various devices. The game will simply don't work fine on another devices, you will have to make several versions.

But, if you code game for computers, I don't think you'll have huge problems with... I didn't. It's like the 'old school' that you said, without assembly. =)

Regards,

John.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
JohnLamock summed it up pretty well...but he did not emphisize enough the point of porting for the various phones. This is a tedious task and one which alot of us don't like to do. J2ME (Just like java) is slow and fast. You just need to learn what its good at (this varys from phone to phone) and what it isn't. Of course as always..the only way to find out is to do it.

Share this post


Link to post
Share on other sites
There are all sorts of things supported by vendors.

Besides MIDP1 and MIDP2 (which are the basic APIs), there are things called JSRs, which are extra bits of "almost standard" API which some devices support.

My phone supports hardware 3d through JSR-184 :)

I've not done anything 3d on it though; I've only used MIDP1 and MMAPI (which is part of MIDP2 and available on a few MIDP1 phones).

Also some devices support different sound / music formats from others.

The memory limitations are small but it's not that bad. You can have quite a few objects in memory without any real problem. Having one Java object per thing on the screen is totally feasible.

Mark

Share this post


Link to post
Share on other sites
Quote:
Original post by dgeuss
I've done a lot of Java2D programming before. How similar is the J2ME 2D library?


It bears only a passing resemblance. It's generally a lot easier because it's a lot simpler hence you can't get stuff as wrong.

There is a javax.microedition.lcdui.Graphics which is somewhat similar to the Java2d one, but does a lot less.

Quote:

How bad are the performace constraints on a mobile phone?


Varies enormously from one model to another. The main problem is the libraries. A library call might be very efficient on one phone and very bad on another. Java code will probably run as fast as you need it to.

Another problem is that most emulators don't accurately emulate the phone's libraries, so they're only useful for very basic testing (screen size, res, number of buttons etc). If it doesn't work on the emulator, it won't on the phone, but the reverse is not necessarily true.

Quote:

Back in the DOS programming days you would need to do all kinds of tricks just to get some performance. Is it like that with J2ME?


Yes and no. Most of the problems are with memory not runtime performance. Everyone tries to make their .JAR as small as possible as it is very critical to some users (most people get charged by the kb for OTA downloads).

Quote:

If so, how convoluted are the performance tricks?


They're not that bad. Some people advise object pooling tricks, which may help in extreme cases. I wouldn't recommend a particle system with a Java object for every particle. Arrays of primitive types are good.

Quote:

I am trying to get an idea about how hard it would be to break the ice in J2ME game programming.


Dead easy really :)

If you want to demo your MIDlet on the web, look at the free "Microemulator", which is a J2ME emulator Java applet.

Mark

Share this post


Link to post
Share on other sites
Some 'good' news for all you J2SE guys: no floating point numbers under MIDP1.0.
Another important thing for J2ME is to keep the code small.
Do not use classes if you do not REALLY need them, if you really do, recycle them.
(allmost) all devices are unique, each has it's own unique features.
Optimisation on some devices is very important.
Some devices (Nokia7650) support different memory areas. f.i. Images are loaded into native memory. You can clear it all you like, it is still there and takes up the memory until the OS decides to throw it away.
Worst of all are the bugs that are not obvious. Some devices do not like certain method calls (Nokia7650.setGain()->crashes app) or other wierd stuff.

Share this post


Link to post
Share on other sites
Quote:
Original post by Frank Henry
Some devices (Nokia7650) support different memory areas. f.i. Images are loaded into native memory. You can clear it all you like, it is still there and takes up the memory until the OS decides to throw it away.

That one's actually a bug and not a feature. The early Series 60 phones leak memory in when opening resources from the jar. The memory those files are loaded into is never reclaimed. The good news is that early Series 60 phones have plenty of memory (relatively), so the workaround involves loading all big resources from the jar only once and keeping them loaded until you're sure you won't need them any more. But old Series 60 phones (7650 and 3650) are quite irrelevant in today's market.

Symbian phones do have a big difference when it comes to memory though: the heap is dynamically allocated at runtime. You start out with a few hundred K's and if you need more memory the OS will allocate it for you. This means that the freeMemory() method is useless, since it only reports on the memory currently allocated and not all of the memory available.

shmoove

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!