Host your own Roborumble server

There are several reasons why you might want to run your own Roborumble server. Maybe you would like to run small local contest at your school or workplace. Or maybe you are testing your new shiny robot. Or may you want to collect some battle data, like myself.

The current Roborumble server is created and maintained by Darkcanuck. Luckily he shares the RumbleServer sources via subversion. It is implemented in PHP and MySQL.

Because I'm not PHP+MySQL expert, easiest solution for me was to download ready-made LAMP virtual machine and configure it.
I know you are busy ;-), so I published my virtual appliance, you could just start using it. You can download it and run it in VMWare Player. Password is robocode, you should change it as soon. Or you could follow the guide below.

Configure server

Once you have LAMP stack up and running you need few things:
Install subversion client
Get PHP sources
Configure RumbleServer
Turn on URL rewriting mod in Apache
Configure MySQL database and grant permissions

The appliance has could be configured from web admin. You can access it on https://192.168.1.12/ where 192.168.1.12 is the IP address assigned to the virtual machine by your DHCP server. I will use 192.168.1.12 which was assigned to me in rest of the article.


Webmin->Global configuration
  ->Configure Apache Modules->rewrite: switch ON

MyPhpAdmin
  Create database->roborumble   Import script schema/schema.sql
  Priviledges->add new user->
    name->rumbleuser
    pass->rumblepass
    Database for user->None
    Global privileges->Select+Update+Insert+Delete

On root shell do something like this

apt-get install subversion
cd /var/www/
mkdir rumble
cd rumble
svn co http://darkcanuck.net/svn/rumbleserver/trunk/ .
chmod g+w templates_c/
chown :www-data templates_c/
cat > participants.txt
[paste participants.txt file and press Ctrl-D]
cd config
cp config.php-sample config.php

Participants

Are defined as list of robots and their .jar files. Big competition is driven by this file. We could simplify our own list like this. We host the file on the appliance in folder /var/www/. So create you own shortlist and update it there. Note there are starting and ending tags.

----
<pre>
jk.mega.DrussGT 2.0.4,http://www.minifly.rchomepage.com/robocode/jk.mega.DrussGT_2.0.4.jar
voidious.Diamond 1.5.34b,http://www.dijitari.com/void/robocode/voidious.Diamond_1.5.34b.jar
</pre>
----

Configure client

Download and install Robocode 1.7.3
Edit c:\robocode\roborumble\roborumble.txt

  PARTICIPANTSURL=http://192.168.1.12/participants.txt
  UPDATEBOTSURL=http://192.168.1.12/rumble/RemoveOldParticipant
  RESULTSURL=http://192.168.1.12/rumble/UploadedResults
  RATINGS.URL=http://192.168.1.12/rumble/RatingsFile
  ITERATE=YES

start c:\robocode\roborumble.bat

Purge data

If you need to purge the data from the roborumble database and start from scratch just delete rows using MyPhpAdmin.

delete from battle_results;
delete from game_pairings;
delete from bot_data;
delete from participants;
delete from upload_stats;
delete from upload_users;

Oh, and once you are done with your local competition, don't forget to redirect back to official RoboRumble server and contribute your CPU power!

Download turnkey-roborumble.2011-07-18.zip.torrent

CLR 4.0 for Robocode

I finally got motivated by Justin and Jason to do something for Robocode .NET again. I upgraded it to jni4net 0.8. This means Robocode will prefer CLR 4.0 if installed and then will run robots written in C# 4.0 or F#. I also implemented Robocode Control API for .NET. I piggyback to Flemming's working branch, hope he will not kill me once he returns from holidays :-D

Download preview is there, Alpha quality.
robocode-1.7.2.2-Alpha-setup.jar
robocode.dotnet-1.7.2.2-Alpha-setup.jar

MyFirstRobot.F#

I really like the syntax.

namespace SampleFs
open Robocode
type MyFirstRobot() = 
    inherit Robot()
    override robot.Run() = 
            while true do
                robot.TurnLeft(40.0)
                robot.Ahead(20.0)
    override robot.OnScannedRobot(evnt : ScannedRobotEvent) = 
            robot.Fire(1.0)
    override robot.OnHitByBullet(evnt : HitByBulletEvent) = 
            robot.TurnLeft(90.0 - evnt.Bearing)

Robocode with C++/CLI

Recently I spotted question if it's possible to create robot in C++. Here is the answer. Ok, I know, it's not like real C++ with pointers etc, this is managed version of C++, which is safe enough to be runnable in Robocode.

• Download VS 2008 Express C++
• Create new CLR-> Class Library (DLL) project
• Go to project properties, Common Properties, Add New Reference, and add robocode.dll from lib folder of your robocode installation.
• Go to project properties, Configuration properties, General, Common Language Runtime support and set it to Safe MSIL (/clrsafe)
• Go to AssemblyInfo.cpp and delete line with [assembly:SecurityPermission(SecurityAction::RequestMinimum, UnmanagedCode = true)];
• Go to [myCppRobot].h and insert code below
• Compile it, drop the DLL into Robocode and enjoy!

#pragma once
using namespace System;
using namespace Robocode;
namespace myCppR {
    public ref class MyCplusplusRobot : Robot {
    public:
        virtual void Run() override {
            while(true) {
                Ahead(100);
                TurnLeft(100);
            }
        }
    };
}

Robocode .NET - 1.7.2 public beta

This release of Robocode is big achievement for me.

Robocode .NET - alpha bits

I'm proud to present working version of .NET Robocode for community testing. It took me almost exactly 2 years.

Prerequisites

• make sure you have .NET framework >= 2.0 installed on your windows box
• backup your robocode home

Install and start

• Download robocode-1.7.3.0-setup.jar and robocode.dotnet-1.7.3.0-setup.jar
• run robocode-1.7.3.0-setup.jar
• run robocode.dotnet-1.7.3.0-setup.jar
• start robocode.bat
• start new battle with samplecs.MyCsTeam and samplecs.PaintingRobot
• open samplecs.PaintingRobot dialog and enable painting

Optional

• start your Visual Studio
• open robots/samplescs/samplescs.csproj
• or create project new and reference robocode.dll from libs\ (Robot API for .NET)
• and code your own .NET robot :-D

Please try it and say what you think !

Known gaps

• Robot API xml documentation is not yet ready
• IGraphics/onPaint have just simple operations implemented
• Robot could create unlimited threads, (but could not cause any harm to your computer)
• jni4net 0.6 was not released public yet
• Few unit tests still fail

These binaries above are 1.7.3, but that was just working number. We will merge it to trunk and release as 1.7.2 probably. Sources are in trunk already.

Enjoy!

Robocode modules as in version 1.7

In version 1.7 we managed to split Robocode into several modules, introduce dependency injection using PicoContainer. We as well started using Maven 2 for builds. Now I will try to explain it a bit.

Modules Description

• robocode.api - This is really robocode.jar as you know it.
  • But now it contains only Robot API, everything what's visible to the robot in package robocode.
  • It also contains Control API, which you can use to automate the game, for example RoboRumble does exactly that.
  • Main entry point of the application. It finds robocode.core and calls it very soon after start.
  • There are few interfaces and base classes to allow robocode.core and other modules implement them.
  • It is very important to not add any compile time dependency of robocode.api on any other .jar, because that would cause all robot authors would need to have that dependency as well.
• robocode.core - The Hub.
  • It loads all robocode modules. Module is any .jar file in libs directory with name starting with "robocode". It finds class Module from package of the same name as the .jar file. For example net.sf.robocode.repository.Module. The class should initialize itself in static constructor. That's module entry-point. Good way how to do it is to register components (classes and instances) into PicoContainer. Or as a singleton or as a factory (transient). There is only single container in whole application. Components could be also registered under name, which is interesting for extensions, example is JavaHost.
  • Because core is referenced by every other module, it serves as place where all interfaces are defined. But most of the implementations are outside of core. This helps us to prevent spaghetti of dependencies.
  • In the future, we may have more extension points, they will be defined by interface which any extension should implement. The interface will be added into core if they are not specific to one of existing modules.
  • Currently we do NOT consider any interfaces public API, so if you want to create extension to Robocode, you should talk to us on our discussion email group first.
• robocode.battle - The rules and main battle loop.
  • It runs the battle thread, which is driving battle life-cycle. Battle has rounds, turns, and each turn have several steps. See Battle.runTurn()
  • The battle thread also creates robots, by using robocode.host, pauses them between turns, reads their commands and produces events for robots, like ScannedRobotEvent or HitByBulletEvent. It transfers the event from GUI to interactive robots.
  • It also produces all events for IBattleListener, they are produces each turn and we call them snapshots, about position of robots, bullets, etc. They are (99%) immutable structures. They also could contain serialized form of drawing commands from robots and text written by robots.
  • This module would expose extension points when we will implement custom extensible battle rules and battle fields. Watch this space!
• robocode.host - The security sandbox for robot.
  • Loads robot into separate ClassLoader, so he can't access anything but robocode.api. There is bit of magic to load from nested .jar files for team robots.
  • Java SecurityManager is enabled, so we prevent it from all cheating or attacks to user computer.
  • Disk operation are limited to certain directory and volume of data. Files are extracted from robot's .jar file on demand.
  • There are *RobotProxy classes, which transform robot's commands like setFire() into message, which is send each turn, on execute() call. It also validates them.
• robocode.repository - Is the dabase of robots installed on the system.
  • Robot classes are loaded and registered when the game spots them in robots directory. Robot property file is also extracted. The metadata are then stored in database, which is serialized into one file. The trick there is that the database is faster to read than to load all the classes and examine them. We do reload the classes or properties, when we found that file timestamp is later than last timestamp stored in database.
  • There is quite lot of logic to figure out the naming and versioning conflicts of robots.
• robocode.tests - Our unit tests and integration tests.
  • There are different kinds of robots made just for the purpose of testing some feature of Robocode. Some of them try to break rules, attack the security system. Others behave interesting way on battlefield and we measure them, to learn if the game physics is OK.
  • The tests are build with junit, there is base class RobotTestBed which prepares and runs the battle. It implements IBattleListener and we could read all the events produced by game and watch the game by code. During the game we make notes and in tear down phase we evaluate them with asserts.
  • There are some regular unit tests as well, but just few of them.
• robocode.ui - Windows and BattleView.
  • Windows are mostly boring stuff, but there are several problems. One of them is UI thread, which keeps window responsible during the game. But we need to make sure that the UI thread is not used to call battle components or even robot's code (as in pre 1.6). To do that BattleManager is really queue of commands for battle thread. They are executed on battle thread in each turn. Well it's not that simple, and we still have some troubles when the game is paused.
  • Another problem is how to paint all the events produced by battle. They are regullary dispatched on battle thread to anyone registered in BattleManager.addListener(), but for UI it;s different. Imagine that we could run the battle at 9K TPS (turn per second), you could easily see that it doesn't make any sense to render it with same frame rate (FPS). So we introduced AwtBattleAdaptor, which receives them all and dispatches only selected ones to UI thread. It's a bit complicated, because we could skip lots of onTurnEnded, but we need to preserve the text output from robots. So here it comes, we cache the texts per robot and inject it into those snapshots which are really dispatched. (That's only place where we broke immutability of snapshots, and we do that transparently to the recipients). Also bear in mind that we need to deliver all the events of other types, and to do that in correct order in relation to onTurnEnded. We do not dispatch onTurnStarted as current optimization. Anyone on GUI thread could register in AwtBattleAdaptor.addListener() and should properly unregister during disposal.
• robocode.ui.editor - Robot editor for real beginners. Personally I think we need to rather create Robocode as plugin to Eclipse, any volunteer ? There is also problem with Jikes, it's ages old and have bugs. But not all people have JDK installed.
• robocode.roborumble - Download robots, run the battles, upload results. Robocode@Home distributed computing, to get scores. We had issues several releases now, so we were unable to contribute to the grid with recent versions. Hopefully it's over now.
• robocode.sound - Just sound. Easy stuff.
• robocode.installer - Our hand-made installer.
• robocode.content - All other files to be deployed.
• robocode.samples - Our sample robots.

How to create new module

• Read the Developers Guide
• Unzip robocode.dummy.zip and rename all dummy files and all dummy things inside files.
• Implement Module class as described above.
• Add your module to main pom.xml
• Try if you are smart and brave enough to make at least small progress alone. And then definitely TALK to us about your idea.
• Then we decide where your extension belongs. If it's to be installed with main installer, keep it in root directory. If it should have separate installer, move it to plugins directory and create installer for it. There are several unfinished examples already. Next time about that.

Over and out.

URL access to nested .jar files

Tonight I implemented loading of classes from nested jar files. It seems to me that people might be interested in such trick, so here you are.

I created new protocol handler jarjar: which just redirects inner part of URL to .jar handler again. Please note that I use '^/' as jar-in-jar separator to avoid conflict with regular jar handler.

Let's have Outer.jar which contains Inner.jar which contains tested/robots/Ahead.class
Now you can do this

// initialize, just once per JVM please
JarJarURLConnection.register();

new URL(
"jar:jarjar:file:/C:/mylibs/Outer.jar^/Inner.jar!/tested/robots/Ahead.class"
).openStream();

Or create and configure ClassLoader this way

// initialize, just once per JVM please
JarJarURLConnection.register();

new URLClassLoader(
  new URL[]{new URL("jar:jarjar:file:/C:/mylibs/Outer.jar^/Inner.jar!/")}
).loadClass("tested.robots.Ahead");

If you need something more sophisticated or user friendly One-JAR is the solution I think.

Plan for Robocode 1.6.2

We just released Robocode 1.6.1 Beta for community testing. While we are waiting for at least one email with feedback (we really miss it), I will present detailed list of tasks for next version 1.6.2.

RobotPeer redesign - messages instead of shared state

Each robot has it's peer which takes care about the real truth about that robot. Things like energy, velocity, direction and also intentions (settings or commands) are stored there. Battle is reading them each turn and modifying according to rules. Robot is accessing that location using RobotAPI. This location is represented with class RobotPeer.
There are two problems currently. First is that both threads battle and robot's are accessing RobotPeer, so data there need to be synchronized. Current implementation does that per call. So subsequent calls could return different values. And as it is, we couldn't do any better, because bigger granularity could lead to deadlocks or at least to slowdown.
Second problem is that there is fixed cost per call for such synchronization from both sides, robot's and battle's.

What we plan is that we split RobotPeer class to two separate parts. First will serve to robot and second will serve to battle. They will be synchronized once per turn. Let's call first part RobotProxy and RobotPeer the second part from now on.
Great moment for such synchronization is when robot calls execute() method. As everyone knows, robot is blocked till next turn there. We could gather all settings and commands set by robot from last turn and make message from them. Then we could send such message to battle's part.
During processing of turn facts about robot are changed, also new events are produced. Such data need to be sent back to robot during resuming after call to execute(). That data will be merged to information set hold by RobotProxy. RobotProxy will serve as local cache for such info.

We may also wish to decompose hosting of the robot from actual battle logic.

Battle recording and replay - listener and producer

• New version of independent class inside of BattleManager class, next to Battle class. May be called Recorder ?
• Still controlled thru BattleManager and sending BattleEvents like Battle does
• Recording should be implemented as IBattleListener
• Replay will just feed dispatcher of BattleManager
• Think about IBattleControl interface and where to put method for saving and loading recorded battles
• Should be possible to go to any turn, and also rewind the battle etc.
• Should be able to records robot renderings as well as print outs
• Possibility of saving/loading the Replay to a file, e.g. XML

Introduction of interfaces of future modules

As preparation for modularization in 1.6.3, we could do some of the steps earlier. The difference is that in 1.6.2 we will not move implementations in namespaces and we will not break compatibility. My guess is that full modularization will need such non-compatible changes. I'm not talking about RobotAPI, but ControlAPI. So we might even need to release it under 1.7 version instead of 1.6.3.
It will be big change. So some of the work ahead could help us manage it better.

Low priority tasks - nice to have

• OptionManager - components subscribe for changes in setup/options/configuration
• Reduce complexity of TeamPeer, ContestantPeer, ContestantStatistics, TeamStatistics
• Decouple battle save/load from BattleManager
• Adding the music from Hans HiScore
• ATW battle events dispatcher, single point dispatcher on AWT thread
• Robocode log to window - not only to console but as well to GUI window

Module management and Dependecy injection

I'm trying to choose some framework which will help us to manage modules and dependencies after modularization of Robocode.
There are several criteria

• small
• fast
• easy to use
• low impact on code
• easy to configure when user adds new module at runtime

I would like to hear your opinion about weight of criteria above.
I have hard time to choose right one, because lot of Java specific names are new to me. Half of articles on the Internet is kind of holy war again, so it is thought to find informed and balanced article.
I will  try to summarize what I've learned about possibilities.

We have three problems

• 1) how to friendly add .jar plugin to classpath
• 2) how to manage dependencies
• 3) how to manage different versions of plugins or their dependencies on same classpath
• 4) we also need to consider licensing. I'm not an licensing expert, though.
  

Solution for 3) and also 1)

It is quite difficult problem.
There are some standard solutions to the problem
OSGI
http://felix.apache.org/site/index.html
http://www.eclipse.org/equinox/
http://www.knopflerfish.org/

JPF
http://jpf.sourceforge.net/

I propose to ignore the problem, because solution is too heavy for our needs. Ignoring c) may lead to necessity of recompilation of cascade of plugins when some of them will change heavily. I believe that we could live with that.

Update: I have found concierge, which looks pretty small = 80 KB. I should try to use it.

Solution for 2)

This problem is nicely solved by various Dependecy injection frameworks.

Spring, Spring JavaConfig
+ de facto standard
- too heavy

Guice
+ fast
+ quite nice
+ type safe
* no that big, but still ....
- no external configuration (XML)
- code will become dependent on it because annotations

PicoContainer
+ small
* all wiring is done in code
- no external configuration (XML)

NanoContainer (buid on top of PicoContainer)
+basic xml configuration
+ still very small (176KB)
+ able to solve problem 1)
- lack of documentation

Conclusion

For our use case I like most PicoContainer+NanoContainer.
It solves problem 1) and 2), with small size, with possibility of XML configuration, and our components could be independent on it's namespaces. I tested it on small test project with one core and one plugged jar, and with XML config. I was also able to pass parameter to constructor from XML.

I'm interested to hear other opinions. Thanks!

Robocode Modules - draft

I quickly put together proposal of modularization. I didn't yet checked it against current code, so I probably missed something. The names do not match current names of classes. Interfaces are not yet designed at all. It's just first draft.

Robocode 1.6 explained

Why ?

During last Christmas I was seeking for some new toy and remembered Robocode, game or competition for Java programmers. I got an idea that I would rework Robocode for .NET. I sat down and wrote an email to Flemming N. Larsen, owner of Robocode. Soon we realized that we had common opinion about the need for support of other languages in Robocode. We were discussing various technical solutions how we could do it, including IPC messages and complete rewrite. Then I came with idea of IKVM as possible solution. During few days we hacked the prototype. Yep, Robocode for .NET exists, it is able to run both Java and .NET robots, paint the battlefield and it is pretty incomplete and unstable.

Update: 17.02.2010 Finally, Robocode .NET version works. It looks different than described here :-D

During prototyping I realized that I couldn't run AWT on top of IKVM, so we splitted Robocode UI from core and drafted new UI in WinForms.
This was first obstacle, need of split of UI from core "rules". I also hacked robot loader to be able to load .NET robots together with Java robots in same battle.

I started with reimplementation of robot base classes for .NET, because it support properties and naming convetions are different. I would like to make the robot classes look natively to .NET beginner programmers.
There I hit second obstacle, because pre 1.6 versions of Robocode could recognize only robot inherited from Robot class. So when you just inherit .NET robot from Java robot, there will be lot of methods from Java object or just named by Java convention. And this looks ugly in .NET.

Later when Flemming implemented drawing of the battle field (he learned some of GDI+ on it ;-), we hit third obstacle. WinForms are running in single thread only, but Robocode is running lot of threads and doesn't care about synchronization of UI much.

So the prototype showed us, that it is possible to share core of Robocode, but the code should be decomposed and refactored.

Version 1.6 is first step, introduction of robot interfaces, to get rid of necessity to inherit from standard Robocode base robots. I believe that the changes we do are not only for possibility of .NET version, but also for beauty of pure Java Robocode.

How Robocode works

Because lot of people don't have so much knowledge how Robocode internals works, let me first introduce you to the problem area. This is described from viewpoint of robot and oversimplified.
During start of battle round, for each "robot specification" RobotPeer instance is created. This class instance is containing "all the truth" about robot. It is then creating robot instance of "user" robot and start the "robot thread". This thread is that thing which is powering user code of robot, usually calling bunch of get() calls on base class and then it calls execution of some blocking command (for example move or fire). Blocking means that robot thread is blocked in the engine until engine cames to next tick. During tick all robots are examined (by battle thread) for commands issued, position, speed and energy and rules are applied. Then robot threads are resumed again, and redirected into EventManager to evaluate conditions of events. Events are called (still by same robot thread) back to user-land code of robot event handler. Usually there is another blocking command issued from that event handler, which is just nested (recursive call) on the stack.

Event interfaces

On the picture above you already can see one of new interfaces. The interface of event handler. Before 1.6 there were always the methods with same signature as on new event interfaces, they were empty handlers on robot base class and you could override them. This is still true. But now you can also decompose such event listener to some other class. You can see the example of it on AlienComposition robot from new sampleex package. I'm using such decomposition to hide the methods/handlers with Java-like naming convention for .NET base robots. Each robot kind (junior, standard, advanced, team) has some specific events, so there are multiple event interfaces. You can examine it on the picture below.

Robot interfaces

Till version 1.6, every robot should be inherited from Robot or JuniorRobot class to be recognized by Robocode engine. This is another degree of freedom which needs to be unlocked to implement nice base robots in .NET. So now you are not forced to inherit from Robot, instead you just need to implement IBasicRobot, IJuniorRobot, IInteractiveRobot, IAdvancedRobot or ITeamRobot. Each of them will allow you to provide different event handlers and you will be also given by IRobot*Peer which will support appropriate commands. There is also another improvement, so that IAdvancedRobot is not forced to be IInteractiveRobot. In other words, such advanced robots will run faster as they will not need to handle UI events.

I hope that one nice day someone will also use this interfaces to implement nice base robot for Jython or other languages on top of Java.

Peer interfaces

Till version 1.6, security of commands and queries executed by "user" robot code were guarded by robot base class. More advanced base class you inherited more possibilities you got. But more duties as well. Base classes were calling RobotPeer, which has full set of methods,which are not guarded any way. Now when we would like to allow you to just implement the interface, instead of inheriting from base class, we need to give you opportunity to issue commands and queries other way. But we still need to assure that you will not use more power than belongs to your robot kind. So we put protecting shield between base robot and RobotPeer. It is implemented by *RobotProxy classes, which implement I*RobotPeer interfaces. Now when you would like to implement issuing of command in your robot of base robot, you should call thru I*RobotPeer interfaces. This way we created secure layer and allowed robots to inherit from custom classes.

For most of users, inheritance from base classes is still right way how to do it. We are not trying to replace it, as it serve well. This is rather opportunity for very advanced coders to create new base classes with different architecture for others, or for other languages.

All together

All the new functionality described above should work transparently for all existing robots. The new features could be now used only when Robocode is started with -DEXPERIMENTAL=true command-line option, but this limitation will probably disappear in future versions.
I must admire Flemming for hard work on Javadoc for new interfaces. Also documentation of other classes was improved by him.

I believe that decomposition we did is good thing, even for pure Java version, because separation of concerns.

In the pipeline

As you might guess, not all problems found during the work on the prototype were solved in Robocode 1.6. We are working on next steps.

First of them will be rework of RobotPeer, which will address synchronization issues caused by display thread. Most of this work in progress has been already done in this branch. RobotPeer was split into several parts by usage. By robot thread, by battle thread and by display thread. Data about robot state are also decomposed into separate classes, so they could be now fully synchronized. We also moved handling of interactive events from UI thread to robot thread by posting it thru EventManager queue, so you could change priority of such events. If you look at RobotPeer class now in 1.6 you will see big spaghetti implementation, this work should help it a lot. I didn't yet back-merged the changes to .NET branch, so I don't know yet whether it solved UI deadlocks. I will write another article when we get there.

After then we will need to split carefully UI from core, so that core could be reused in .NET. This was already drafted in .NET branch. I'm also thinking about more advanced modularization, plug-in infrastructure. Ideas are welcome.

When we will have that, we can build .NET version on top of it. We could implement UI visually compatible with Java version, or different, if someone will invent something better. The battlefield will be the same of course. We should also think about version control options. For now we are just merging the branches.
After then I dream about IronPyton and IronRuby robots built on top of it ;-)

Feedback

We need lot of feedback and we need it now when 1.6 is Beta. I guess that we will have few weeks of time, before we reach release and will merge interfaces branch to the trunk.

We need lot of testers. Please try to run your historic robots, they should run just OK. Please try to play with new interfaces, so that we could get your feedback. The interfaces will become new API between robot and engine. That means that they will live with us long time, so please review them and shout now, if you don't like them (and have better ideas). Please try also to broke security of the solution, in both legacy and experimental mode.
Questions are also welcome.

Thanks a lot!

Update: 02.04.2008
Just to make it clear: 1) Robocode will stay 100% Java, my IKVM extension will be just build on top of it, so you will be able to run on any Java enabled HW or OS as usually.
2) We still don't have plan how Java only users could run .NET robots, for example in Roborummble. Rednaxela is proposing JaCIL. Ideas and prototypes are welcome.
3) We are looking for someone who will help us design and prototype plugin, which will allow to load robots in other languages running on JVM.

Smooth transition from C# to Java SE

Robocode

In free time I'm playing with Robocode. At the start my idea was to migrate it somehow to .NET and run away from Java as soon as possible. I use IKVM to wrap Robocode. I learned that Java GUI, which is AWT in this case, could not be translated to WinForms by current version of IKVM. Current Robocode is monolithic application, where UI is in same jar module as the core. I was looking for some IDE which will help me with Java and to introduce/refactor UI interfaces and split of UI from core. Currently I'm buried much deeper in Java part of Robocode, but that will be another story.

Update 17.2.2010: Robocode for .NET took different direction, but it's here.

IntelliJ IDEA

Because I'm mostly C# guy, I wanted to use some IDE which will behave similarly like VS. IntelliJ IDEA won the race, because I heavily use their ReSharper for C# in Visual Studio, luckily in the original IDEA key-binding mode. JetBrains were also so kind that donated open-source license to Robocode project. I needed to do only two things to feel at home in IDEA:
1) Install TabSwitch plug-in
2) In File/settings/keymap choose VS, make copy, in tree seek for TabSwitch plugin and set Ctrl-Tab key for SwitchBetweenTwoTabs.

IKVM

is compiler, which translates Java bytecode to .NET IL. In other words you take .jar and compile it with IKVMc to get .NET assembly. Java SDK is also compiled this way so your .jar is running on top of Java framework, but natively on .NET runtime. There is small IKVM runtime for Java framework, similar as runtimes for different platforms. You could event turn on debug flag and you will be able to debug Java code inside VS, pretty cool.