An exclusive interview with Alan Lund, the most
successful player in Jrobot's history

by Samuel J. Grabski


Jrobot's success is not possible without great people with
brilliant minds and big hearts contributing to the game. I have
privilege to interview Mr. Alan Lund author of IonStorm, by far
the most successful player in JRobot's long history. 


Samuel: Your robot has dominated the arena for many years including
the latest series of consecutive triple victories in all categories. 
Could you tell us about the history of Jrobots from your perspective?

Alan: JRobots started several years before I got involved, and my
knowledge of its early history is mostly what you can get by reading
old messages on the Java Jousters mailing list.
As you would expect, strategies have changed over time and the best
robots have gotten more complicated. Many of the earliest robots, as
far as I can tell, moved in straight lines very fast in order to
"escape" from opponents that used only trivial aiming algorithms
(firing directly at the target).  After aiming techniques improved to
account for this behavior, zig-zag, circular and other irregular
movement patterns were introduced.  KillerBees, I believe, was the
first robot to detect some of these patterns, and IonStorm has used
a variety of predictive techniques over time as well.

KillerBees vs IonStorm (January 2002)

Interestingly, once the "move straight and fast" crowd was gone,
trivial aiming became a fairly effective (and obviously simple)
technique again, and for several months it looked like predictive
techniques were dying out. And then some fast-movers were introduced
again, and they were somewhat successful because the some of the
robots that were left did not do any kind of predictive targeting.
So there is something of a cyclical nature going on, though robots
that last will have to be successful throughout the cycles against a
variety of strategies.

I think I was fairly fortunate in my timing because I started when
there was still a variety of different strategies in use, so IonStorm
has code to detect and respond to that variety.  Some later robots
missed out on that and did poorly against some older and simpler
robots when they were introduced.  The present situation, with two
leagues and with more robots, is putting pressure on authors to handle
diverse strategies better.


Samuel: Your contribution to the simulator is extremely extensive and
crucial - development of the virtual clock and weight-matching
algorithm are the main examples. Please tell us about them and other
milestones...

Alan: It's funny, but I don't remember the specific motivation for the
weighted selection algorithm. [Wait a moment while I rummage through
old emails.] Ah, yes. Before the weighted selection, there was one
tournament that used a "bubble-sorting" selection, where each combat
was between robots that were adjacent in the standings. The idea was
to get a better picture of which robot was the best.  In practice it
did not work out so well, but it did get me thinking about how we
could do better.  I actually simulated a number of different selection
algorithms and measured how quickly they converged to their final
values.  The weighted selection strategy that is used now is the best
of the four or five that I tried.

The virtual clock was collaboration between Walter Nisticò
(co-author of KillerBees) and myself.  My interest in working on it
was due to my observations of how using the real clock was causing
problems in the arena, especially if there was any other kind of CPU
load going on.  It was a bit selfish, really.  IonStorm's results in
the online arena were maybe 10 or 15% lower than in my private
testing.  I wanted a more reliable platform.

The solution that came out at the end was actually more Walter's idea
than mine.  My original solution attempted to do more, but it had
trouble under some JVM's, most notably Internet Explorer's, so I gave
that up.  The virtual clock that we have now is pretty simple, and
reasonably effective.

Other contributions include adding some new methods to JJRobot,
especially to make JJVector easier to use. (IonStorm used JJVector for
a little while, but I ended up taking it out. The most convenient way
to use JJVector ends up creating lots of temporary instances that
seemed to clog up the garbage collector. The less convenient way is,
well, less convenient.) And I guess I published my customized arena
code that has been incorporated into the standard arena.

And then there were some changes to the online arena to record
individual match results, along with the Watch utility that slices and
dices those results, so that you can get a fairly detailed picture of
how things are going in the online arena.


Samuel: What could you tell us about yourself? I guess that you are
professional programmer...

Alan: I live in Eau Claire, Wisconsin. Including other nearby towns and
cities, there are about 100,000 people. For people interested in
computers, the area's greatest claim to fame is that nearby Chippewa
Falls was the original home of Cray Research.

I'm married, and we have two boys, ages 9 and 6. Justin, the
nine-year-old, thinks its pretty cool that my robot wins all the time,
although that's not quite true anymore.

I have a degree in applied physics from Caltech, but I've been a
professional programmer for about thirteen years now.  I spent eight
years working on software for the healthcare industry and the past
three and a half years I have been working for a very small company on
an employee scheduling application.

JRobots is the only Java programming I have done. Professionally I've
used C++ and Delphi, though I'm not particularly happy with either. I
dabble in Python and Ruby, and one of these days I'm going to write
another language, just for fun. (I've written two already.)

For the last four years or so, I've been interested in Extreme
Programming (XP), which I credit with some tremendous improvements in
the way I write software.


Samuel: I would like to ask you about you hobbies, favorite books
and music.

Alan: Most people would probably consider me pretty boring. Obviously,
JRobots was a hobby for a while, and I occasionally play computer
games, but nothing like people who are really into them. I do like to
read, both fiction and non-fiction. For fiction, I like sci-fi and
some fantasy, and my latest "project" has been the "Wheel of Time"
series by Robert Jordan, which is something like 10 books and 6500
hardcover pages and still unfinished. For non-fiction I read books on
software development, of course, my two most recent purchases being
"Lean Development" by Mary and Tom Poppendieck, and "Beyond Software
Architecture: Creating & Sustaining Winning Solutions" by Luke
Hohmann. Also, I've been reading a fair amount about cosmology and
some other somewhat esoteric science topics.

I like to play volleyball.  I used to play three or four times a week,
but since having kids, once a week is all I can manage.  That's about
it for sports, except maybe one game of golf per year.  I do exercise
regularly, at least, though not quite so much as a few years ago.

As for music, I am pretty tolerant, but it's not something I spend
much money or time on. I played trumpet for about eight years starting
in junior high, which I enjoyed very much, but now I play maybe a
couple of times a year. Over the years I've dabbled a bit with the
piano, guitar and harmonica, but not enough to be any good with any of
them.

I drink way too much Coke.


Samuel: Your robot inspired many players trying to emulate your
successful techniques. I personally admire elegant movement pattern,
successful predictive algorithm and unbeatable play at very long
distance range. What advice can you give to young Cadets trying to
develop a successful robot?

Alan: I think it has been very helpful to me to take the time to develop
a set of tools in and around the JRobots code that automate various kinds
of things.  For instance, I've mentioned on the mailing list tools that I used
to analyze IonStorm's behavior against various opponents under various
conditions, as well as modifying JRobots so that I can replicate certain
kinds of starting conditions more easily, rather than just waiting for them
to happen by chance.  Tools like that allow you to focus you attention
more closely on where it is needed.

I would also recommend measuring the effects of your changes.  I've
had a bunch of "great ideas" that turned out not to work that well.
It's easy to watch a few matches and think that the changes you made
helped, but sometimes the overall effect is not what you expect.
Of course, running the measurements takes awhile since a truly good
measurement will take a bunch of combats, so you have to find your
balance.

Having said that, there are a few features in IonStorm that I added
more because I thought they were cool or showed good style than
because I'm sure they really helped. Sometimes I wonder if anybody
else even notices them.

Hmmmm... what else?

Specifically related to things like predictive targeting, one of the
most important principles is to protect your robot's worst case
behavior. Predictive targeting can be very good, but wrong predictions
are often worse than no prediction at all. So, detecting as quickly as
possible situations where your predictions are likely to fail (and
falling back to some safer strategy) is important.

It's okay to look to other robots for ideas, but realize that if all
you do is copy others, you are unlikely to do any better than them.
Innovation is important.

There are two things that I wish I had done better, and perhaps some
people will want to try to do these from the start.

First, I should have developed some kind of unit tests for IonStorm,
so that I could quickly detect at least certain kinds of bugs. I did a
little of this, but I should have started out doing it, and should
have done it much more pervasively.

Secondly there is a thing I would have liked to do differently,
but it's not something that I could just decide to do. I think
IonStorm's code lacks elegance. While winning was certainly a goal,
creating something beautiful and elegant was important to me also, and
I'm not sure I succeeded there. Functional and effective, yes, but
beautiful? Maybe next time.


Samuel: The rules of the game settled down over the years. The simulator
has been greatly improved by you and other contributors. Yet, there are
things, which might be altered or added. What kind of possible direction
would you envision for Jrobots?

Alan: There are, of course, lots of neat things that could be done.  But
it's difficult to make big changes without an active set of players, because
those big changes require not only a lot of work themselves, but then
robots need to be updated to account for the changes.

Ignoring that, here are a few things I think would be great changes:

  - A more sophisticated virtualization of time that would allow
    matches to run at hyper speed without loss of accuracy.  This
    would make it far faster to make small changes and see the
    results, which would then open up a whole new level of play
    where some aspects of robot design could be explored by genetic
    algorithms, genetic programming or neural networks.

  - Allow matches to be recorded and replayed.  It would be especially
    neat if you could automatically detect matches that would be
    entertaining to watch.
  
  - Allow greater freedom in the programming, especially to have
    multiple classes.  I think there has been some recent interest in
    this again.

  - Allowing a variety of weapons, sensors, engines, etc., with varying
    capabilities, costs, weights, etc.  The design space becomes much
    larger, allowing for more creativity, and there is a natural way
    to create divisions or unique monthly competitions.

  - More complex arena geometries that have to be explored.  For
    instance, consider a something like a rectangular race track, with
    both inner and outer walls, or something with pillars space about
    periodically.  Naturally, there would have to be some way to
    detect these additional walls.

(I actually wrote a robot combat program in college that incorporated
each of the last two concepts. Looking back, I'm frankly a bit amazed
at everything it could do, given how little I knew about programming
at the time. Unfortunately, I lost the code somewhere along the way
since then.)


Samuel: Thank you Alan not only for taking time for this interview but also
for all your constant support to Jrobots community.

Alan: You're welcome. I shudder to think sometimes about how much time
I spent on this, but it's been fun.