MIDP-Man: Technical stuff

If you have tested Sun's reference implementation of MIDP, you should be familiar with how to run MIDlets contained in JAR files. Let's say you installed the midp-fcs directory in c:\ on a Windows PC. Then you use the DOS console and, while standing in the same directory where you keep midpman.jar, you type

c:\midp-fcs\bin\midp -classpath c:\midp-fcs\classes;
.\midpman.jar midpman

You may have noticed that the background in MIDP-Man reminds a lot of the classic arcade game Pac-Man. That's because I used the same graphics, scaled down to exactly 50% and cleaned up a bit.

On the left is the original and on the right the maze I use in my game. I had to make the blue quite a bit brighter, or it would have completely blended with the black background. I also made the dots bigger and turned the energizers white instead of pink like regular dots. They blink in the real Pac-Man, to stand out better, but I didn't want to waste computer power on that type of effect.

The scrolling background seemed necessary, because even at 50% the maze is still 112 by 124 pixels, which doesn't fit the 96x101 drawable area of Sun's MIDP phone -- especially when I need some additional space for the score and level numbers. I decided it was better to keep the original layout than to shrink things even further or remove parts. Also, if future devices don't use exactly the same screen size, the game might not look good anyway. Of course, not being able to see the whole maze makes the game more difficult, so I removed one of the four ghosts to compensate.

Why MIDP stinks as a game platform

Three words: no image transparency.

Think about it. All mobile objects need to be rectangular, or they will look awful when drawn against other objects or a background with more than one color. In MIDP-Man, the graphics are so small that you barely notice the problem. In addition, the ghosts are almost rectangular anyway and MIDP-Man clears the background under himself (by eating the dots) as he moves along.

There is no Graphics.copyArea method. This means you can't keep all your graphics data in the same buffer.

There is no way to extract small regions of image data from a larger image, other than creating small images and drawing the bigger image on top of them. Then each little image needs its own Graphics object, which will most likely never be used again. This seems like a big waste of time and memory. In MIDP-Man I ended up saving twenty-eight images into separate files, most of which were only 8x8 pixels or smaller.