INFO   Main   Docs   FAQ   News   Tutorials   Interviews   Forums   Mailing List
ONLINE    BATTLE ARENA   Accounts   Uploads   Downloads   Hall of Fame
|   No-Limits Challenge: JROBOTS FOREVER! (January 6th 2010)   ||   October-December Challenge: The End! (December 26th 2009)   ||   October-December Challenge: JROBOTS 2K9 Q4! (October 3rd 2009)   ||   September-October Challenge: JROBOTS 2K9 Q3! (July 4th 2009)   ||   April-June Challenge: JROBOTS 2K9 Q2! (March 28th 2009)   ||   Old News  |




Hall of Fame





Mailing List
Contact leo

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.
KB vs IS
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.

For more information
send an email to
Project Hosted by SourceForge Copyright © 1999-2009 Leonardo Boselli
All Rights Reserved. Legal Terms.