Finite Improbability

After seeing this game, which seems close to a lot of the ideas I’ve been working on, I’m trying to get back into writing mine. Here’s what I think needs to change from my previous work:

Graphics

I got seriously hung up over graphics. I kept flip-flopping between trying to do it in 2d and doing it in 3d. Could I make graphics that wouldn’t suck in either? I’m a programmer, not an artist. 3d models are a lot of work, and the game idea I have is inherently not three dimensional. This should have been a simple point, huh? Anyways, unless I can coerce my wife into doing something better, expect programmer-quality crap artwork.

No “Starter Games”

One idea I was pursuing was to try and do small games that encapsulated one portion of the functionality I was working on for Starbound. Since I wanted to have a bunch of ships semi-autonomously flying around the screen I came up with the idea of Picnic Invasion!, where a bunch of ants semi-autnomously crawl around a board.

In the right scenario, this could work out well. Unfortunately I couldn’t really stir up much enthusiasm for the smaller game, so pretty much nothing got done. I’m going to focus on Starbound and just that. Picnic Invasion! is pretty much dead, although I’ll hang on to the idea if I want to start doing simple applet games.

The Clojure/Java bridge

When I started working with Clojure, I pretty much assumed it would be easier to do my computation in Clojure and use Java for storage. This let me completely pass up learning all of the stuff in Clojure for handling mutable data by hiding all of my mutations in Java.

The end result was that I had a bunch of Java classes that constantly needed maintenance. The runtime modification that was the whole point of me using a Lisp dialect for this was pretty well lost. It also meant a lot of cumbersome stuff with objects that were little more than data holders, and code like this:

(defn update-game-obj 
  "Update the information provided to Java about the game object."
  [#^GameObject obj]
   (let [p (get-pos obj)
     v (get-vel obj)]
     (set! (. obj x) (. p (getX)))
     (set! (. obj y) (. p (getY)))
     (set! (. obj ang) (+ 90 (. v (getTheta))))))

Where a game object has to be told twice something it already knows just so the Java-based rendering function can know how to render the object. Except it’s not that simple, as the render loop is actually built from Clojure code, so there’s a lot of unnecessary indirection and duplication going on here.

The point is that I really should be wholly embracing one or the other. Clojure has a lot of beautiful parts that I’m missing out on because of this organization. The persistant data structures are pretty much useless in this approach as any of my Java-based objects directly violate their core assumptions, so any of the cool things I could do with them (like easily rewinding time) simply aren’t possible.

Slick?

Kevin Glass’ Slick library is really great. He’s spent a lot of time on it and it handles a lot of stuff I’d rather not deal with. Slick tries really hard to just do what you need and stay out of your way the rest of the time.

That said, I still am considering doing the whole thing “from scratch” using lwjgl. It would be nice to learn a bit more about OpenGL and some of the other technologies, and I would essentially be able to do all of the game in Clojure, which is a real plus. That said, I’d be taking on a lot more responsibility, and re-doing a bunch of things that Slick handles pretty admirably. The jury is still out on this one.

What Went Right?

With all of this complaining, there were a few things that went really well. When I didn’t have to shut everything down to monkey with one of my Java classes, using a Lisp for runtime development was awesome. It’s easy to get lost in tweaking something until it is perfect, which can be a bit of a time sink, but simply having that ability means that when it is time to start perfecting things the work will go a lot faster.