Hal - Team Ball

"Team Ball" consists solely of me, Allen Ball. Hal is my entry into the ICFP 2002 Programming Contest. I named my robot "Hal" because "2001: A Space Odyssey" (specifically, "I can't do that, Dave") was all I could think of as I worked on the exercise. It was also all the wit and whimsey I could muster after staying up all night Sunday to finish. Hal is implemented in Java and my entry may be found here. The javadoc may be found here. I chose Java because it has been the language I have been using lately and because I have no Redhat Linux 7.3 PCs at my disposal so I needed the "write once, debug^H^H^H^H^Hrun everywhere" capabilities of Java.

The Java code is divided into the following packages:

  • world.* - Classes for the components objects within the world. These include the four different kinds of tiles (plain, base, water, and wall), player and opponent robots, and packages. A class for calculating (and remembering) the shortest path between tiles is also contained herein.
  • protocol.* - Classes for communicating with the game server.
  • player.* - These classes include the main entry point of the player client and a Strategy class that was meant to be subclassed for specific strategy implementations.
  • player.strategy.* - The actually strategy implementations.
  • gui.* - Utility classes for the GUI portion of the application.

    • There is only one [slightly more than] nontrivial Strategy implementation: "PlanA." This is a direct result of running out of time to work on "PlanB." The "PlanA" algorithm is very simple. For the player robot turn, it decides an action as follows:

  • Is this tile the destination of any packages we are carrying? If it is, we'll drop the packages. Otherwise,
  • Does this tile have any packages we want to pick up? That is, are there packages here and do we have carrying capacity? If there are, we'll pick them up. Otherwise,
  • If we have at least one package, find the closest destination we have package(s) for and move along that path. Otherwise,
  • If we know where some packages are, go get them. Only go after packages that we know the weight (either we have visited the base or we held them once) to avoid visiting a destination. Otherwise,
  • If we don't know where some packages are, head for a base that we have not previously visited. (If we have already been to a base, the previous rule would have kicked in. Therefore, a base we have been to (and do know the inventory) is *not* a candidate. Go to the closest that is a candidate.) Otherwise,
  • Again, if we know where some packages are, go get them (even if we don't know their weight). Otherwise,
  • If there are no more packages on the board. Go after the opponent with the most packages (hoping we may encounter some "droppings").

    • Hal will double his bid if he wants to drop packages and if an opponent could move into his tile but his baseline bid is always one so this may be of little effect.

    Time ran out before I could implement even the most basic self-preservation rules in Hal's strategy. Therefore, I do not expect Hal to fare well against "belligerent" robotic competition.

    Finally, I was able to implement some protocol tracing and monitoring capabilities. To watch the raw communications between the client and the game server, specify "-Dtrace=true" to the java command line. To see a graphical representation of the game board and the known status of all robots, specify "-DuseGUI=true" on the java command line. (Otherwise, the client (as submitted) will run quietly.) This can be most easily done by uncommenting the assignment of the OPTIONAL_JAVA_ARGS environment variable in the "runme" script. An example command line is:

    java -DuseGUI=true -Dtrace=true -jar lib/player.jar icfp1.cse.ogi.edu 22103