My game page is back on line!

My free sample game and code page is back on line here.  I had some problems with my earlier web host, so I found a new one.  This means that some of the links to sample jars and code on earlier blog entries may be broken, but all of the code should be available on the new game page (and, as before, you can open the game page in your mobile device’s browser and install the games and apps directly from there).  I’ve rebuilt many of these on the latest version of the WTK, and I’m working on testing them on some new devices.  If any of them aren’t working, feel free to leave a comment.  The “Frog-Parrot User Interface Library” — a set of simple utilities to create a customizable user-interface for a range of MIDP devices — is available as WidgetCanvas, with the source code here.

I’m sorry I haven’t kept up this blog very well lately.  (Wow, the last thing I posted about was Jazoon 2008, and the Jazoon folks are already gearing up for 2009!)  The thing is that I’ve switched gears enigineering-wise — I haven’t been working in Java ME for over a year, so I haven’t had much new stuff to add here.  I’ve mostly been working in software testing automation, but since I’ve been working mostly with proprietary software, I haven’t done much that I can post about.

But I’m planning some new projects this summer that I’ll be writing about! (Not necessarily all in Java ME…)

Jazoon 2008!!!

Jazoon was a blast! Here are some pictures:

My presentation is available for download on the Jazoon site here.

Can’t wait until next year!

FPUIL: Frog-Parrot User Interface Library

I’ve finished my little library of UI utilities, which you can download here: FPUIL.tar.gz or FPUIL.zip.

Just unzip the directory, placing the WidgetCanvas folder in the apps folder of the WTK, and you can open it as a project.

This set of classes is intended to help with a “managing fragmentation” strategy of type “DERIVE-MULTI > SELECTIVE” (see Device Fragmentation of Mobile Applications for the theory).  As explained on TomSoft, this is a good strategy for one-shot projects, and it’s the strategy I’ll be discussing at Jazoon.

Here are some notes on using this little library:

Going to Jazoon 2008!!!

It’s official. I’ll be giving a talk at Jazoon 2008: the European Conference on Java Technology!

My talk will be on customizing applications for a range of (MIDP) handsets. It builds on some of the ideas from the last chapter of my book, but there’ll be plenty of new stuff. (I spent the holiday weekend madly programming some demos and sample code in preparation, which I plan to post here soon.) For details on my talk, look here.

For those of you who are bored of MIDP and want to live on the not-even-released-yet bleeding edge, my colleague at Greenliff Peter Wlodarczak will be giving a talk on Android.

Some basic STAF, with a simple example program

I’ve been playing with the Software Testing Automation Framework lately, and I thought I’d post some of my notes. This isn’t directly related to mobile games except for the fact that every type of software engineering requires testing. The root of STAF is an application that allows machines to control and monitor processes on other machines across a network (as peers instead of client/server). It has a rich set of features (logging, remote file system control, etc.) as well as APIs in multiple languages to allow you to write your own applications using STAF as a tool. To me it looks like this framework could be applied to lots of different distributed computing applications, but automated testing is what it’s designed and optimized for.

If you’re planning to use STAF but you’ve never used it before, here’s what I’d recommend to get started: Bookmark the documentation page and the User’s Guide. The User’s Guide has extensive helpful explanations on how to install STAF, then it contains some high-level discussion of the concepts followed by a detailed list of all of the commands and their options. To get a basic understanding of how STAF works and how to use it, read Getting Started With STAF V3, which includes some good explanation of how to use STAF as well as going over the demo. This blog post is intended as a supplement to the “Getting Started With STAF” tutorial. Here I’ll present an even simpler code example that shows how to interact with a process from the STAF command line.

Game page update

I’ve updated my sample game page to include links directly to the jar files (as some people have requested).

Sorry I haven’t been keeping this blog updated lately — since I’m not currently working on a book, I guess I’m not doing as many independent projects as I used to. However, I do have a new one coming up that I’m planning to post to this blog over the next couple of weeks:

As I’ve said before, the Java ME lcdui classes don’t allow enough customization of the look-and-feel to be appropriate for use in a professional application. So everyone ends up implementing their own UI classes, starting from a blank canvas. Since the basics are always the same, I was thinking of writing a simple library of basic UI navigation classes (starting from the classes I wrote for Chapter 10 of my book) and posting it. Anyone can write such classes, but perhaps it will save someone some time…

My new book just came in the mail…

I just received my box of copies of Creating Mobile Games: Using Java™ ME Platform to Put the Fun into Your Mobile Device and Cell Phone, and it looks great!!!  If I do say so myself…

Radio silence….

I’m sorry I haven’t posted anything new in a while. You might think this means I haven’t undertaken any new programming adventures lately, but you would be wrong. Oh, so very wrong.

What’s up is that I’ve been working on a professional product, so of course I don’t have the same liberty to blog about what I’m doing. And it has kept me so busy that I haven’t had time for any projects on the side or even to write any general articles on technologies we’re using.

However the new product is going to production very soon, and at that point I should be able to post again. We’re working with some exciting new technologies that I’m looing forward to telling you about!

Racecar!

Racecar (a.k.a. Car-voiture) is an amusing little game where you try to see how many laps your little racecar can make around the track — changing lanes and speed — before you inevitably crash into another car or into one of the boulders I’ve conveniently placed on the track.

This game was my first attempt to use the MIDP 2 games API, but since it didn’t illustrate the lcdui.game package in a strong or interesting way, I ended up just back-porting it to MIDP 1 so I could run it on my Nokia 6100:

This game was basically scratch work, so I didn’t end up using it in my book.

I’ve just uploaded the whole thing (source code, resources, etc.) to my site, and you can download it here: racecar.tar.gz or racecar.zip. Just unzip it and place it so that the “Racecar” directory is in the “apps” directory of your WTK, and you can open it as a project. I can’t promise that it illustrates the best possible MIDP game programming techniques, but you might find some interesting strategies for programming a simple game . More likely it’ll serve as a fun exercise to see how many places you can find where the game could be improved. I’m not offering any prizes though…

Converting files to UTF-8

Here’s a common problem you often face as a Java ME programmer:

You’re internationalizing your game or application, so you send all of your files full of texts and labels to the translators, and you get back a bunch of files that are saved in some standard character encoding scheme, but not utf-8. You can’t bundle these files directly into the resource directory of your game’s jar file because some devices won’t be able to read them. Ideally, the solution is to tell the translating service that you need the files in utf-8 format, but often it isn’t the developer who is in charge of this, and sometimes such information gets lost in the shuffle. So your product manager hands you a pile of files and leaves you to figure out how to make them work.

Many standard text editing programs (emacs, for example) are capable of reading in a text file in one encoding and saving it in another. But if you’re a professional software engineer, you don’t want to waste your time opening up fifty files one by one, changing the encoding, and resaving them — especially if you’re likely to get more files and updates later.

What to do?

Some operating systems have built-in commands (such as native2ascii) to change the character encoding of a file. But looking at my options, I’d say the simplest and most portable solution is to just write a trivial little Java SE file converter, like this:

/**
* A utility to convert text files to utf-8.
*/
public class FileEncoder {

/**
* args[0] is the input file name and args[1] is the output file name.
*/
public static void main(String[] args) {
try {
FileInputStream fis = new FileInputStream(args[0]);
byte[] contents = new byte[fis.available()];
fis.read(contents, 0, contents.length);
String asString = new String(contents, “ISO8859_1″);
byte[] newBytes = asString.getBytes(“UTF8″);
FileOutputStream fos = new FileOutputStream(args[1]);
fos.write(newBytes);
fos.close();
} catch(Exception e) {
e.printStackTrace();
}
}

}

Because it’s written in Java, you can call this directly from your Ant build script (see this post for an example of calling an arbitrary Java program from an Ant script). That way you can actually leave the originals as they are and create the corrected files on the fly while building the rest of the resources for each target device.

In the above example, I’ve hard-coded “ISO8859_1″ as the encoding of the source file. That’s ISO Latin-1, a character encoding I see a lot of here in France. For a list of other encodings supported by java (and their names for use in Java) look here. Note that the names of the encodings are a little different in Java SE (formerly J2SE) than they are in Java ME (J2ME). So in the above Java SE program, I write the output file in “UTF8″ but once I’ve read the resource file into a byte array in the Java ME program on the device, I convert it to a String as follows:

String contentsOfMyDataFile = new String(dataFileByteArray, 0, dataFileByteArray.length, “utf-8″);

Now if you want to hard-code a string with non-ascii characters directly into your Java ME application, what you do is completely different from what you do when reading resource files from the jar. In the code, you use escape characters. “\u” is the signal that what follows is a unicode character code. A standard example is printing a price in euros: to put the euro symbol in a String in your code, you would write “\u20ac”

For a list of character code charts, look here.