Portable Game Code - Applet / Android / IPhone - Part 1

I had a few days off, went to the zoo with Meg, shopping with Cath, castles and general time out and about in Sun. Nice! Every spare minute and late into the night I was of course coding away. I've been looking at simple rendering API to abstract between Applets and Android, this was mostly because I find the Android tooling a bit heavy to work with. Being able to test and debug against an applet version and then rebuild and run simple tests on the Android emulator/handset would be really good for productivity.

Since Android and Applets both run Java it wasn't that difficult. Built an extremely simple game API which lets me just get input and splat images to the screen (ok and a bit of geometry and state management). Implemented this in terms of Java2D (for applets) and the Canvas API (for Android). Excellent, I can now code the game once and build as an applet or an Android acitivty. There are of course caveats:

  • Android only allows a 16mb heap per application. Gotta be careful how big those structures you build are
  • Android performance isn't desktop, so again be careful. For my turn based stuff that doesn't hurt too much
  • Android GC is much slower than normal Java, of course it's just good practice not to create to much garbage

So it's the same set of Java code runs in both Android and Applet. With the applet you need to specify a game class in the parameters like this:

<applet archive="soccer-8.jar" 
           code="org.newdawn.game.applet.GameApplet" 
           width="320" height="480">
	<param name="gameClass" value="org.newdawn.soccer.SoccerGame"/>
</applet>

In Android there's a tiny bootstrap Activity class that looks like this:

public class SoccerActivity extends Activity {
	private GameView gameView;
	
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        
        requestWindowFeature(Window.FEATURE_NO_TITLE); 
        
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
                             WindowManager.LayoutParams.FLAG_FULLSCREEN);          
        setContentView(R.layout.main);

        gameView = (GameView) findViewById(R.id.gameview);
        gameView.setAssets(getAssets());
        gameView.setGame(new SoccerGame());
        gameView.start();
    }
}

There's still a bit of work left to optimise the game sufficiently for Android, the AI takes a while to run. However, I started thinking about marketing this game. The IPhone is the hottest market for mobile games at the moment. I believe the Android market will take over, but right now it'd be ideal if I could publish to IPhone as well. However, key to me again is:

  • I like Java, I find it very productive. I don't particularly want to alot of work in Obj-C
  • One code base is better for me, one set of bugs to fix
  • Being able to test the same code an applet, before having to go to my Mac and IPhone is better

Enter XMLVM, it's a tool that converts from Java byte code into an XML document, and then translates this into other languages - one of these being Obj-C. Ok, it's not really as simple as that but I'll describe the details in the next post. Suffice it to say what you get from XMLVM SVN while brilliant doesn't contain enough to write even simple games like Funky Football.

XMLVM relies on a compatibility library written in both Java and Obj-C to provide access to the IPhone platform APIs. The Java one is to build against (and to debug against). The Obj-C version is whats built against once the rest of the code has been converted automatically. So, first I extended the Java side to support the features I needed, this let me use the XMLVM Java version of the IPhone emulator:

Brilliant! At least I thought it was until I realised I had to then implement the features I'd added to the Java library in Obj-C. Scary when you don't know anything about the language really. So I boot my Mac, start trying to use XCode. That really is a poor development tool, especially when you've used Eclipse and Netbeans. It took me a day or two to realise that the nice people at XMLVM had made the output compilable from the command line. This also gave me access to stdout for debugging (more on that in the next post). So I've now spent two days (spare time coding of course) hacking up the bits and pieces of the API I need to make available to Java. This includes SDK things that arn't implemented like ArrayList.indexOf(). This isn't actually as bad as it sounds once you get going. The documentation for the IPhone platform is pretty reasonable and there is a pattern to it. I can now honestly say I know more about Obj-C than I ever wanted to.

It's mostly working now, theres a bit of garbage collection issue with objects that you never assign to a variable (they get collected too early) but otherwise it's all looking pretty good. The shot shown in the rather gratuitous overview below is actually taken from the OSX IPhone emulator running the produced code. You can actually play the game too :)

The IPhone bootstrap class is light, just creates a UIApplicationDelegate for the game:

public class IPhoneSoccer extends IPhoneMain {
	public void applicationDidFinishLaunching(UIApplication application) {   
		setGame(new SoccerGame());
		
		super.applicationDidFinishLaunching(application);
	}
	
	public static void main(String[] argv) {
		try {
			UIApplication.main(argv, IPhoneSoccer.class);
		} catch (Throwable e) {
			System.out.println(e.toString());
			System.out.println(e.getMessage());
		}
	}
}

So what have I achieved? Well, i've taken a reasonably simple game and API and successfully made it possible for one Java project to compile to all 3 platforms (Applet/Android/IPhone). They all work (to some extent) and there's nothing license infringing or jailbreak requiring about any of it.

What next? I've some bugs to sort out (the font issue above is already resolved for insetance), some more SDK to implement and a lot of code to contribute back to XMLVM (should I ever be able to get hold of the developers!). Then I need to try out my bigger more complicated game (Runes of Yore, an RPG) through the system. There are bound to be extra things to find. I'm also going to do another post covering more about how XMLVM works in this use case, and what needed to be extended.

Hopefully someone will be interested in the post and give some time to do this whole thing properly! It all looks so good, but there's about 3 months full time work here to make a working version that supports the majority of the SDK.

Reply

*
*
The content of this field is kept private and will not be shown publicly.

*

  • Lines and paragraphs break automatically.