30 day battle records

I can rewrite the client and make it open source, so anyone can revise the code and propose fixes/enhancements.

The hardest part is dealing with network and server failures. There is always a situation you didn't think of that makes the client crash. Although the current client still have some of these issues.

I can say this all because I already built custom clients in the past.

If you feel up to the task. I just ask you make it compatible with the current rumble servers. Since we don't have anything else yet.

If you think about it, it's surprising we haven't yet rewritten the client. We've rewritten everything else plenty of times. =) I think my ultimate client wish list would be:

• Rewritten protocol for lightning fast uploads (and better/more robust maybe priority battles options).
• Simple, direct control over what battles run. E.g., you could have a rule like "always give voidious.* bots priority if they don't have enough battles."
• Multi-threading support so we don't have to setup/run multiple clients. (Could fork RoboRunner pretty easily I think.)
• At whatever limit of RoboRumble stability, start running battles for Distributed Robocode instead.
• Recovers from Java OutOfMemory Error's.

Only, making it compatible with current server and rewrite the protocol for lightning fast uploads at the same time implies 2 protocols.

The second protocol only becoming useful after a new server with the new protocol appears. This protocol rewrite will probably only work if a new server is written at the same time.

Compatibility with Distributed Robocode will imply in a third protocol, but can be done. Only I never used Distributed Robocode.

Multi-threading is nice. This was the reason I tried to build a custom client myself in the past. Only I never managed to isolate classpaths between engine instances. One problem with multi-threading is OutOfMemoryErrors tend to crash all threads, making it harder to recover (i.e. one thread is saving results while another throws OOME, crashing everything and corrupting files).

Yeah, I certainly wasn't saying it was a reasonable list. =)

RoboRunner runs each engine in its own process, communicating with STDIN/STDOUT. I think that means it would be able to recover from OOME, but I haven't tested it.

I've never used Distributed Robocode either, but I've always wanted a client that would switch to RoboRumble after finishing running challenges, and vice versa. My main issue with DR and similar CPU pooling (besides for RoboRumble) has been that I never thought it would reach a happy medium - I thought you'd either be stuck contributing all your power when you'd be better off just using it yourself, or you'd be trying to use it and nobody else would be contributing. But we have a surplus of CPU power these days (12k min battles in General 1v1), so if pooling it were simple, I think it could work.

You imagined a process controller which would queue RoboRunner and RoboRumble jobs automatically. More than that, balance the load between them. O.o'

It is a bit hard to keep track of RoboRumble state from the clients. My custom battle generator which prioritizes my bots downloads HTML pages to track how many battles each pairing has. Since I have few bots, only few pages are downloaded. But keeping track of the whole rumble means hundreds of downloads. That's why we have the priority battles list instead.

Well been mulling over an implementation details.

These are on a gist so they are fully editable and just an idea so far.

https://gist.github.com/Chase-san/4742843