Finite Improbability

I’m starting work on a 2d Java game. I’ve been kicking around an idea for a while, and some of the capabilities of the Java platform here make it a really good choice for this task. Webstart, for instance, would allow me to distribute the game to friends by simply having them click a link and let the program run. The JVM and some of the available 2d game engines make writing cross platform code a snap. And I don’t have to futz around with manual memory management, which is always a bonus.

The big problem in this equation is Java. The language isn’t outright bad, but it isn’t terribly good either. Some things that I think would make this game easier to develop simply aren’t available. So, I spent a while poking around on alternative langauges that compile to the JVM. Jython was out immediately for several reasons: speed (not that I worry much about this, but even slower than CPython? ouch), Java interoperability (at least the FAQ makes this look confusing), and lack of static type checking (evidently the borg have gotten to me). I didn’t consider JRuby, mainly by assuming that the same points about Jython would apply. Mozilla Rhino looks interesting, but the whole time I was looking at it I kept thinking I really would like to have static typing.

So, I went with Scala. I’m still getting up to speed on it and the game libraries involved, but so far it looks interesting if nothing else. The language is decently flexible, and seems to play nice with Java as much as possible. Most of my code will be pretty simple Scala->Java calls, so it should be fine. It looks like even building Java->Scala->Java code bases is a mess, but that seems kind of obvious to me.

As a teaser, here’s a simple translation of a “Hello World” program for the slick game library with the original Java code:

import org.newdawn.slick._

// Since we're planning on running this directly out of a .jar we need
// a (singleton) object so the main function is static, hence the
// object with an inner class implementation. An outer class would
// have worked as well, but there you are.
object TestProgram {
  // Take note: Due to scoping rules (i'm assuming) this TestProgram
  // is the one referred to in main below.
  class TestProgram(s : String) extends BasicGame(s : String) {

    override def init(container : GameContainer) {}

    override def update(container : GameContainer, delta : int) {}

    override def render(container : GameContainer, g : Graphics) {
      g.drawString("Hello, Slick (from scala) world!", 0, 100);
    }
  }

  def main(args : Array[String]) {
    try {
      val app = new AppGameContainer(new TestProgram("TestProgram"));
      app.start();
    } catch {
      case e : SlickException => e.printStackTrace();
      case ex : Exception => ex.printStackTrace();
    }
  }
}

And the Java version:

import org.newdawn.slick.BasicGame;
import org.newdawn.slick.GameContainer;
import org.newdawn.slick.Graphics;
import org.newdawn.slick.SlickException;
import org.newdawn.slick.AppGameContainer;
public class SimpleTest extends BasicGame {

    public SimpleTest() {
    super("SimpleTest");
    }

    @Override public void init(GameContainer container) throws SlickException {}

    @Override public void update(GameContainer container, int delta) throws SlickException {}

    @Override public void render(GameContainer container, Graphics g) throws SlickException {
    g.drawString("Hello, Slick world!", 0, 100);
    }

    public static void main(String[] args) {
    try {
        AppGameContainer app = new AppGameContainer(new SimpleTest());
        app.start();
    }
    catch (SlickException e) {
        e.printStackTrace();
    }
    }
}

The scala version is a line longer due to comments, but cheats a little with the unqualified import. Right now the happyplace for me is that I don’t have to write “T foo = new T()” and can let Scala infer from usage that if I’m making a new object of type T, I’m probably holding a reference to it that is of type T as well.