• March 2002 Jrobots Challenge: Results

  As we expected, even this month a lot of great long aged robots were eliminated. They are: Marvin3, Schmamageddon and Epa1 (the last was the oldest of the three). Now the oldest robots still around in the arena are KillerBees (the bullet, that is going to eliminate it, is not forged yet) and IlTristoSmorzatore (a robot strong in single matches, but very weak in other play modes).
  The arena IS very competitive and the percentages testify it. Now almost only the top six robots reach the 50% limit in single and double mode and in team mode the percentages are closer than ever. Now the higher percentage doesn't touch the 40%, thanks to an improved IonStorm that now performs well even in team play.
  The Alan Lund's Watch.exe utility (that you can download from the Files section of the mailing list) can be used to foresee the future: As you can see yourself, a lot of other robots are in great danger. But we can't trust those previsions very much, because the next challenge is going to use the new virtual clock generator to beat the thinking time of the robots (read virtualClockGenerator.txt for details).

  The winner of single and double category is still IonStrom and this month it has got a good third place in team mode, very close to the winner GermPlus and the other strong teams Germ and Mouth.

  From the novices' side, Touche, First, Malaysian and UPMKainghe didn't succeed in surviving the hard competition. The last two robots were written using the new Java 2 JDK 1.4 and, at the beginning, the number of their matches was always zero even if all the other robots could play matches and matches. Finally, I discovered that the new JDK uses the 1.2 class format by default instead of 1.1 as the JDK 1.3 did. The majority of the machines that run the tournaments still use the Microsoft JVM that doesn't recognize the 1.2 class format  :( so you'd better to use the compiler option -target 1.1, if you don't want to lose a lot of matches.

  Finally, this challenge accepted robots of 20Kb size, but only a few robots chose to broke the old 10Kb limit. One of these was IonStorm and we can see that the only 1001 bytes added over the limit were of great help: It almost succeeded in winning the three categories, a result we saw when KillerBees was GREAT.

  Now you can upload your robots to win the April 2002 Jrobots Challenge (April 6^th-27^th 2002) aka The Virtual Clock Generator Contest

• Java 2 JDK 1.4 Compiler WARNING

  As I have already pointed out, remember that the class files generated by the compiler of the Java 2 JDK 1.4 is incompatible with the Internet Explorer JVM. This JVM is still the most used Java Virtual Machine around and a lot of matches are executed using it. If you use the new JDK 1.4 and don't want to lose too many victories, be sure to compile your sources with the -target 1.1 option, that forces the use of the 1.1 class format.
  For example, type "javac -g:none -O -target 1.1 __YourRobot_.java" to compile your robot.

• JASTROBOTS

  Thanks to all the people that sent questions about my new programming game. The Overview of JASTROBOTS is not complete yet (the last version was updated on March 23^rd), but you can already grab an idea of the game.

  A lot of question were about the strategical and tactical aspects of the game, in fact the overview is quite indefinite about how to play. Well, the basic implementation is very simple and closer to Jrobots than to an RTS game. For example, you don't have to worry about the management of the resources, but only to develop the AIs of the crews of your starships. I'm planning to include a kind of configurability of the units, but further details are going to be available only during the next week.

  In the meantime I can answer to the people who asked about the "Interpreted JVM" that JASTROBOTS is going to use. If you followed the development of Jrobots, you remember that the use of Java threads to run the AI of the robots brought a lot of machine dependency problems. Recently Alan Lund and Walter Nisticò proposed to drop the real time clock if favour of a virtual clock generator. This choice seems to solve the problem and I hope that the next challenge will confirm this impression.

  Since JASTROBOTS has different requirements compared to Jrobots, I want to test also another approach, that is a Java interpreter. The first choice was BeanShell, an interesting Java source interpreter, but it uses a different object model than standard Java, so I decide to write my own interpreter.

  The JVM I'm writing is a Java bytecode interpreter and now I'm playing with the first alpha version. If you are curious to read its sources and run the demo program, you can download the file jastrobots.zip. The run.bat file shows how to execute the interpreter: When you run it, you can see the output of the demo program JVM_Demo. The interpreter is not complete yet, but the most used opcodes are already implemented. This version needs only to work correctly and is not optimized yet, in fact it runs 1000 times slower that the same program executed using the HotSpot JIT compiler  :(
  I hope to get better results soon or I'll revert to the virtual clock generator of Jrobots.

  Have you any question, comment or suggestion about JASTROBOTS? Send them to me.

• Jrobots

  There is still one day to the end of the March 2002 Jrobots Challenge and tomorrow I'll publish the results.
  The next challenge will use the new Virtual Clock Generator to get uniform results on fast and slow machines. You must consider it as an experimental challenge, because I don't know yet if the clock generator works fine on a wide range of different CPUs, OSes, Browsers and JVMs. I hope that you have already tested your robot using the latest SDK, but remember that there is still a week before the beginning of the next contest.

I have uploaded a page about JASTROBOTS: A new Java programmming game I'm planning. The design is still in progress, but if you read the document, feel free to send any comment or suggestion, I'll really appreciate them.

It seems that the class files generated with the compiler of the Java 2 JDK 1.4 are incompatible with the Internet Explorer JVM. Before uploading your robot be sure to compile it with the -target 1.1 option. For example

javac -g:none -O -target 1.1 __Platoon_.java

• The Jrobots 3.0beta SDK is now available for evaluation.
  A big issue of Jrobots was its machine dependency. This problem was a frustrating one since the players had to do a lot of tuning work in order to make their robots work fine on faster and slower CPUs, different JVMs and underlaying OSes. People was often disappointed seeing unexpected results in the on-line arena.
  Two of the most effective Jrobots players found a solution and worked togheter to make it come true: Maybe it was a small step for two smart developers, but a VERY GIANT LEAP for Jrobots. Now a bunch of new features could be added or even a more complex and realistic simulator could be planned.
  The Virtual Clock Generator solution is now available for download in the Jrobots 3.0beta and after an off-line test period it shall become the official arena for on-line tournaments. So you' d better to test your robot in the new arena before the April 2002 Jrobots Challenge starts, but remember that the current on-line tournament still uses the old simulator.
  Short notes about the new arena follow.

• Jrobots Arena Version 3.0beta by Alan Lund and Walter Nisticò

  This latest version of the game actually brings a little revolution with it: in order to obtain faithful results of robot performance across a vast multitude of environments, OSes, Virtual Machines, CPUs, it was necessary to separate the time as seen by the robots (virtual time) from the time seen by the observer (real time), in order to provide constant CPU power per second to the robot threads.

  With this version, the simulation time (or virtual time) is calibrated around the speed of the machine it's running on by a special "benchmark" function; as a result, the *real* speed of the simulation now varies according to the speed of the CPU, JVM and OS. So, you may notice an increase or decrease of the number of matches per hour of real time that can be played on your machine, but you can be (almost!) guaranteed that the performance of the robots tested and developed on your machine will be consistent across all the possible environments they could be executed on in the real tournament. CPU contention due to other running programs will be gracefully accomodated, causing the simulation to slow down, rather than becoming "jumpy" as with earlier versions.

  A new option has been provided in the user interface: "Display", which can be set to "Smooth" (60 fps of real time), "Fast" (30 fps of *virtual* time) and "None", where the match is not shown but the clock counter is updated and the results are displayed; this setting can be easily changed even within a match. "None" corresponds most closely with the way actual tournament matches are executed, as well as being a bit faster.

  When watching a match, choose between Smooth and Fast, whichever looks best for you. While running extended tests, you might consider opting for "None" in order to get a higher number of matches played per hour. Whatever you choose, unless you have a very fast machine you will notice a considerable slow down in Team play. That is actually one of the biggest benefits of virtual time, as it's now granting a lot more CPU time to the robots, which can now make use of more advanced targeting techniques even in this previously CPU-constrained mode of play.

  As a way to compensate to for the possible slow down / speed up of visualization, two new simulation speed settings have been provided: 8X and 1/8X; however, keep in mind that changing the simulation speed actually changes the CPU time allocated to the robots, so in order to obtain the most faithful picture of your robot's performance, do intensive testings at the official speed of 1X.

  Finally, you should expect to see some changes to win rates, especially in Team mode where robots are now given more CPU time than they were previously.

  Alan Lund (author of IonStrom)
  Walter Nisticò (author of KillerBees)

• The March 2002 Jrobots Challenge starts now.
  Remember that you can send your robots even in the course of the challenge, so you're never too late. The latest robots are stored in the file jjrobots_challengers.zip. You can download it to test off-line the behaviour of your robot against the other challengers. To read the results in real-time simply visit the Battle Applet page.

• Remember also that now you can upload robots up to 20 Kb in size. I'm curious to test the first giant Jrobot uploaded. We are going to see interesting fights between the first Goliath and the 1070bytes David: Which is going to win?

There is still one day to the beginning of the new Jrobots Challenge. As you know the size limit of the class file of your robot was raised to 20Kb and now other new features are available. You can get them downloading the latest Jrobots SDK (2.9)

The new features are:

• Critter wrote a useful JJGraph class that shows the performance of your robot when you test it. The graph utility is available on the on-line applet, but I don't think that it is going to be very useful there. It shows its power when you use it off-line, since you can see how the percentages move when you change something in the algorithms of your robot or when you add new opponents in the arena. Feel free to propose improvements and changes to this utility.

• Zeke proposed a bunch of new useful extensions to the methods available to the robots. A lot of them extends the original methods you know making use of the JJVector class. You can find a description of them reading "extensions.txt".
  All these methods add new features to the basic one already available for programming your Jrobot. The basic methods are documented in the file jjr_info.shtml. You must consider these methods experimental and this is the reason why they are not included in the basic HTML documentation. However, you must consider even that they are already available in the on-line arena (and in the off-line one) and it's very unlikely that someone is going to change something. So use them without too many worries.

• Zeke and WalterNistico proposed (and are working to) new methods to schedule the thread of the robots. As you know, a great problem of Jrobots is its machine dependency. The use of Java threads has this disadvantage and it is very difficult to write some code that can solve the problem.
  In the sources of the simulator of Jrobots you can find (commented out) the Zeke's changes. If you want, you can remove the comments and try to test that (old) version of the thread schedulers, but remember that you make those test at your own RISK. Sometimes the Internet Explorer blocks running those schedulers, while the Sun JVM runs fine. This is the reason why the challenge that starts tomorrow still uses the ORIGINAL simulator.
  However I hope that we are almost near the solution to the machine dependency issue.