new Robocode batch battle runner

Jump to navigation Jump to search
Revision as of 22 July 2012 at 16:26.
The highlighted comment was created in this revision.

new Robocode batch battle runner

I'm strongly considering writing up a new Robocode battle runner to replace my RoboResearch usage. I think I could even have something workable over the weekend. Here's my short list of design goals:

  • Easy to setup / configure!
  • Use Robocode control API instead of running a fresh Robocode engine / JVM from the command line for each battle.
  • Support existing .rrc files.
  • Support any battle configuration (battle size, Melee, Twin Duel, etc).

Anyone have any thoughts / requests? I think I would go command line only to start, but maybe if I really get something good I'll consider a GUI.

Now that I can crank out 1,000 battles per hour, the thought of also restarting the JVM 1,000 times per hour kind of makes me cringe. =)

    Voidious15:58, 20 July 2012
    Edited by author.
    Last edit: 04:19, 21 July 2012

    You can take for base Distributed_Robocode

      Jdev04:05, 21 July 2012

      I really should take a look at what you have there, I've never tried it. Though I think I'm looking for something a bit simpler and lightweight. Does the client do multiple threads with multiple Robocode engines? Or do you just have to configure one client per thread, like with RoboRumble clients?

      I just whipped up the core battle runner, which takes paths to multiple Robocode install directories, then runs a collection of battles across the threads using the control API. Though that's pretty much the easy part... =)

        Voidious04:11, 21 July 2012
         

        It uses one thread per server.

        Yes, but in my case, i have more CPU power at my work, so support of remote servers was critical for me:) Latter today, i will publish soures on github.

          Jdev04:18, 21 July 2012
            Jdev20:07, 21 July 2012
             

            Yeah, support for remote clients is a killer feature in that situation!

              Voidious04:20, 21 July 2012
               

              Great feature list. Support of current .rrc files is a good idea. You'd need some sort of config file to parse anyway, and it's a nice, easy to read config format anyway.

              Remote servers would be fun for me too. I've got my main home desktop, and an identical machine running as our living room media center.. so both of them could run battles for me. *evil grin*

              I said it over in my talk page, Voidious, but I'd love to help contribute to this with code and testing. As a teacher my free time will contract somewhat during the school year.

              My recent experience with RR has me interested in helping to make something a bit easier to get off the ground.

                Tkiesel04:27, 21 July 2012
                 

                Hmm. It seems that Robocode itself is not thread safe for running multiple instances? I have multiple RobocodeEngine's going in separate threads, each with its own directory, and I'm still hitting some weird concurrency issues. Bummer! I wonder if I can do something with ClassLoaders to deal with it? I've never really played with them before, and not sure if it would kill performance or not.

                  Voidious22:49, 21 July 2012

                  Oh, yes i also faced with this problem and also think about class loaders but in result came to current architecture

                    Jdev05:53, 22 July 2012
                     

                    Yep, the engine is not thread safe.

                    Creating ClassLoaders should be faster than creating separate JVMs, but don't know by how much.

                    Another approach would be staying with separate JVMs, but not restarting them before each battle. Exchanging messages between JVMs and using the API inside a loop instead, much like how the RoboRumble client works.

                    Creating ClassLoaders once and reusing them on many battles is also another approach. I remember trying this approach in a custom multi-threaded RoboRumble client a long time ago. Didn't remember exactly what went wrong. Maybe the need of a custom JAR loading mechanism.

                      MN17:26, 22 July 2012