30 day battle records

Also the possibility of only downloading robots as needed when they are needed for a battle. But I am not sure I really want to rewrite all of the client.

I mean I suppose it would be okay if we were also updating the servers at the same time. But the rumble client is time tested, I don't want to change to much at once. :)

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