Finite Improbability

For the most part yesterday (and part of this morning) was spent working on the build environment. Up until this point I’ve been compiling my program “by hand” with a command line argument run in the background by Emacs. This worked well enough, but adding three new files to the compile list was enough for me to decide it was time to address building the project in a better way.

So, I got to spend the day playing around with Apache Ant. Scala has a bunch of ant task definitions that took forever for me to figure out how to import. From there getting the whole thing to compile worked well enough, but figuring out how to tell ant how to run the program was a pain. I somehow managed to segue into building distribution jars, where I discovered the brain-dead inability to pack a jar within a jar.

Anyways, at the end of the day I have a build file that compiles the project and can run it directly or package it into it’s own .jar file and dump that into a dist folder. Eventually I’ll have to get around to solving the webstart issue, but for now I’m happy with what I’ve got.

The little bit of actual coding work was some class reorganization. I cleaned up most of the mess in my classes left behind from all of the testing I’ve been doing. I actually have code that is intended to represent the ants, ant hill, and food objects sitting in the source tree.

Well, I have actors working correctly in the game … mostly.

Here’s a screenshot of the test running. That’s 625 actors all maintaining separate locations and an angle. The same class that implements the actors also draws the triangle image oriented correctly, currently they’re following the (not seen) mouse pointer.

The problem I’m running into is that I can get great performance out of this on my dual core macbook. For the most part I can allow all of the actors to run asynchronously without a problem and get about 350 frames/sec. A smaller test (400 actors, also asynchronous) on a creaky old athlon 3000 xp reveals the flaw in that idea: updates don’t have a chance to propogate between render calls, or possibly even between one game loop update and the next. Since this is asynchronous, the only thing I can conclude is that the overhead of managing 400 actors is just too much for that processor. I’m sure I could optimize it a bit, in fact I’m deliberately leaving a lot of the actor code on the “heavy” side so I’ll have some easy targets to optimize it later.

My big concern is that having a second core available is what really makes this whole thing kick ass. Even in scala’s event-based actor mode, which is what I’m using, there are still a few extra threads. Some tests to push the macbook show that my code is using both cores, so the results here just plain don’t translate to a single core system. It would really suck to finish up an awesome game and have it only work with dual core computers.

I’ll probably go through the hassle of trying to package everything for webstart and see if I can get some help testing it, or just run it on every system I can find.

Update:

As was entirely predictible, switching to direct method calls delivered an insane speedup. 7000 ants all adjusting to mouse movement (even if they’re too far away to see any kind of appreciable difference) ran at an acceptable-to-me 33 fps on the macbook. Granted, I’ll have to try it on my “minimum system requirements” box, but I’m happy again.

What I really wanted more than anything out of the actors library was the message passing and pattern matching. Now that I understand it a little better I can fake it pretty well without the overhead of the concurrency. It isn’t even all that hard, I just have to figure out how (or if) I’m going to return values.

Even less progress than day 1. I’m considering switching to weekly updates since my main focus right now is school, but doing them daily forces me to get something done, no matter how small.

Anyways, yesterday’s small bit of advancement was working on communication between an actor network and the game loop handling code. Specifically I want to be able to notify an actor about something (user input, a game tick happened, we need renderables, whatever) and wait for it to finish.

To test this I started modifying the pingpong example. A bit of playing around with it gave me this:

import scala.actors.Actor
import scala.actors.Actor._
import scala.actors.OutputChannel

abstract class PingMessage
case object Start extends PingMessage
case object SendPing extends PingMessage
case object Pong extends PingMessage
case object Done extends PingMessage

abstract class PongMessage
case object Ping extends PongMessage
case object Stop extends PongMessage

object pingpong extends Application {
  val pong = new Pong
  val ping = new Ping(100000, pong)
  ping.start
  pong.start
  val f = ping !! Start
  f()
  println("This happened after the actors")
}

class Ping(count: Int, pong: Actor) extends Actor {
  self.trapExit = true;
  var initiator = null : OutputChannel[Any];
  def act() {
    println("Ping: Initializing with count "+count+": "+pong)
    var pingsLeft = count
    loop {
      react {
        case Start =>
      initiator = sender;
          println("Ping: starting.")
          pong ! Ping
          pingsLeft = pingsLeft - 1
        case SendPing =>
          pong ! Ping
        pingsLeft = pingsLeft - 1
        case Pong =>
          if (pingsLeft % 1000 == 0)
        println("Ping: pong from: "+sender)
        if (pingsLeft > 0)
          self ! SendPing
        else {
          println("Ping: Stop.")
      pong ! Stop
      self ! Done
    }
    case Done =>
      initiator ! Done
      exit('stop)
      }
    }
  }
}

class Pong extends Actor {
  def act() {
    var pongCount = 0
    loop {
      react {
        case Ping =>
          if (pongCount % 1000 == 0)
            println("Pong: ping "+pongCount+" from "+sender)
          sender ! Pong
          pongCount = pongCount + 1
        case Stop =>
          println("Pong: Stop.")
          exit('stop)
      }
    }
  }
}

The original example is largely unmodified, except for the following changes:

• Added an “initiator” variable to the Ping actor, which is set with a reference to the actor that sent the “Start” message.
• Added a “Done” message to the Ping actor, which it sends to itself to call cleanup code and send its reply to the “initiator” saved in Start.

Granted, this would run into some problems if I were to send Start to Ping twice in a row without blocking until it completes, but I don’t plan on doing that.

Not a terribly productive day yesterday. Initiated a darcs repo and copied over a bit of generic stuff from my big game’s codebase. Spent a good deal of time futzing around with trying to get a rectangle (org.newdawn.slick.geom.Rectangle) to rotate the way I wanted it to. After doing a bunch of fire and pray changes I decided to look at the wiki and found that drawing any of the geometry classes isn’t particularly efficient, which throws them right out even for prototyping since I will have lots and lots. Have created a simple yellow triangle that can pretend to be an ant while I do testing.

Spent a while trying to understand Scala actors and see how they would fit in this context. My current idea is to have the ants, food objects, and beacons all represented as actors with non-actor methods to handle game loop interaction. Theoretically game updates and rendering could be handled as actors as well, maybe this is a good way to do this, I’m just worried about the overhead. I guess I could always switch later if needed.

I have a big game in the works. By “big” I mean much larger than any single person should reasonably expect to be able to finish soon. I’d like to see it done before I graduate, which should be in about two years. So I have a big idea that I want to accomplish in two years, working part time. I’m a big believer in constraints helping to focus creativity, but this really seems like it is pushing it. One aspect that helps here is I can look at the idea of doing this game in 3d and easily say “it won’t give me much but eye candy, and will multiply the time spent on art by at least a factor of ten”. That makes the decision to go 2d with this dead simple, which saves me a world of time. Without my two year deadline I’d probably decide to go ahead and do it since it would look better, which would probably push my time-to-completion from two years to never.

Another useful constraint is that the whole thing has to theoretically work on my Macbook. That means relatively light graphics requirements and controls operated with a single-button mouse. Sure I’ll probably get an external mouse later on for testing (I want the gameplay to be fast paced, so a trackpad might not be the best of tools), but limiting myself to a single button leaves me with the possibility of running this in an applet and ensures that the gameplay can’t get too complicated.

Even with all of those advantages, this is still a very complex game. I’m using Java so I don’t have to worry about manual memory management or deployment, so those aren’t elements of the project’s complexity. There’s a lot of well-designed Java libraries I can draw from, and it even has neat features like webstart so people can play the game without installing anything. I’m also using Scala, which has functional programming and actors and all kinds of other tools to manage complexity.

Despite all of this, I think I’m still going to need to be careful about how I go about writing this game. If I try to simply attack it directly I could easily get lost in the complexity of the game. This is compounded by the fact that I don’t know a whole lot about Scala or the programming libraries I want to use other than that they look like they offer useful tools.

So, my current goal is a lot smaller, mini-games that can be easily completed and are based on a subset of the big game. These should ideally be projects that can be finished in a week or two, and will leave me with code that I can easily port to the big game.

One aspect of my larger game is going to involve swarms of units. These swarms will have in-game objectives in the form of an in-game object that they should cluster around and perform some action based on their overal purpose. To get that idea off the ground I’m going to work on a game where you control ants trying to invade a picnic. The idea is to take a swarm of ants coming out of your ant mound and try to gather up as much of the food on the blanket as possible in the time limit before the picnic-goers return. The player can set targets that include a notion of how many ants should head toward that target, and the individual ants take care of moving toward the target, gathering a bit of food, and returning to the nest with it. Larger items of food give you more bits, and things that are further from the mound take longer to gather. The goal here is to have a rather basic game that relies on something fundamentally similar to the behavior I want for the big game.

Since this is a learning experience, here’s what I hope to get out of “Picnic Invasion”:

• A basic understanding of background and sprite loading
• Basic sprite manipulation (rotation and transformation for ants, scaling for food items and obstacles)
• Basic navigation
• An idea of how I want to structure the rendering and game update pipelines
• An understanding of actors (used to implement the individual ants in the swarm)

This is probably going to be a bigger project than most of the other small games, since a good portion of the list above will be reused practically without modification in later games. Still it seems like a great place to start. I’ll be documenting progress as I get things going.