new Robocode batch battle runner
The highlighted comment was created in this revision.
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. =)
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... =)
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.
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.
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.
Oh, yes i also faced with this problem and also think about class loaders but in result came to current architecture
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.
