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. :)

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).

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