Screenshot from a 2D game with colorful abstract art, played on a blue neon grid.

Last time I announced taking a break from programming. And I have... for about a weekend. During which time I caused a pretty sweet raytraced scene reminiscent of a 1990-something adventure game. Reading a book about Myst the weekend before must have something to do with it.

Then, of course, my mood to program came back. Or maybe it was the vitamin supplement I've been taking. Fact is, less than a week later I can play Buzz Grid on my Nokia E51. And boy, that makes me happy.

It's worth noting that the game was designed for mobiles right from the start, hence the control scheme. But my original attempt to write it in Java failed miserably. This is no language to prototype in. And once I had the Javascript version, there was little motivation to work on a port with all the other shiny projects waiting in line.

Turns out, porting an already written game is much easier. Which is not to say uneventful.

The good

Knowledgeable programmers decry the marketing move that had Javascript filking the syntax of Java, but the upside is that porting code from the former to the latter is often a simple matter of replacing "var" with type declarations. Much of the game logic really was that easy.

I was afraid the graphics would turn out uglier, due to a lack of transparency and arbitrary-sized fonts, but the loss in aesthetics is minimal, and on the plus side the game actually runs smoothly on a 600MHz cellphone CPU, unlike its browser counterpart that stutters on a 900MHz Atom. Java's static typing, otherwise a major annoyance, also helps. Pro tip: always use the smallest data type that can do the job, and be generous with the "final" declaration on variables.

The bad

While porting the game logic was straightforward, the rendering engine had to be largely redone (apart from the general structure), and I found myself making the same mistakes all over again, most notably forgetting to invert the y axis. Having to figure out four sets of coordinates for the ship — due to lack of a rotation transform in the J2ME canvas — was also tricky.

The ugly

Look, Java, is it so hard to understand that I want all these integers converted to floats for the purposes of this calculation and then back? C++ just does it, whereas here I had to turn a very simple formula into a multi-line monstrosity involving temporary variables. It's not the first time I had to do that in Java, either, and it bugs me. At least it doesn't have to be done inside the game loop.

In the end

Buzz Grid ended up being harder to play on a cellphone, which again validates my decision to have selectable play speed. On the plus side, the vector graphics scale to any screen size with no extra effort on my part. Question is, anyone else still using a J2ME device, or is it just me?

Comments

int blah = (int)(1.0 + myIntValue);

should work fine. Java implicitly upcasts between numerics; it’s only downcasting that you have to be explicit about. Even if you have to explicitly cast you should never have to create a temporary.

J2ME is not worth targeting anymore, but porting from J2ME to Android shouldn’t be too difficult. Android uses J2SE which is a superset of J2ME, and there are MIDP stacks for Android to make it even easier to port although I think those cost money (but I think the Android Canvas API is pretty similar to MIDP’s).

fluffy


Believe me, fluffy, it was nowhere near that simple. I’ll mail you the code if you want. Briefly, the problem is that if you have a / b * c, where a and b are integers, and only c is a float, Java will look at each individual subexpression, therefore a / b will undergo integer division!

And I’m targeting J2ME because 1) that’s the kind of phone I have, 2) I’m finding it hard to learn yet another platform and 3) the control scheme pretty much requires a keyboard. You know I’m not a fan of touchscreens.

Also, yes, there is a MIDP emulator for Android. Last time I checked, it was very incomplete, never mind the license.

Felix