30 day battle records

Finally a supporter!

I'll look into what would need to be done to do it later. I assume very little, since most of the system is already in place for it. But for reverse compatibility I will also see about adding an option to the roborumble configuration as well.

If you are going to change the protocol, a nice improvement would be to upload melee battle participants in a single group, so the server can keep track of full melee battles instead of pairings.

I am not sure. I would need a deeper look at the format of the results files, both for the normal rumble and for melee rumble.

The roborumble library is a bit of a mess. It also likes to use File IO. It writes and reads things a lot. I now want to fix that, but I know better then to fiddle with things beyond my (current) understanding.

It seems to upload each result individually. It then checks for an OK being returned and updates battlesnum. After it is done uploading all the results, it then sends this battlesnum to the server to update ratings. This seems like it would be better done all on the server when you upload the results.

So unless we want to get rid of that weird mechanic, I need to get the server to return a string of OK/NOT to the client so I can update this battlesnum.

Otherwise it is a simple matter of slightly restructuring the way it uploads battles.

Isn't the server which sends battlesnum back to the client? Which is deprecated with the improved priority battles list we have now.

How I think a good rumble protocol would work:

- Client requests and downloads the participants list from the wiki server.

- Client uploads participants list to rating server.

- Client uploads number of battles per iteration and downloads priority battles list from rating server. (can be done in the same request which uploads participants)

- Client downloads missing participants.

Run battles. If there is any error downloading priority battles list, fallback to random battle generation.

- Client uploads all battle results at once, keeping data structure as close as possible to how it is returned from the API. Server returns an OK or ERROR after the upload. If an ERROR occurs, keep the results for next iteration.

2 main differences are bulk uploads in the end and priority battles download in the beginning.

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

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.

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

Instead of switching to Distributed Robocode when the rumble stabilizes, which is hard to detect, doing the opposite, running rumble battles after challenge processing finishes is feasible.

For that you would have a graphical client in which you edit the process queue. You can queue as many challenge jobs you want, and can queue a rumble contribution job. Only rumble contribution is a job which consumes all instances, never ends and must be aborted manually.

This central client can group battle results before sending them to the server. It would accomplish 2 things. Uploads are independent from the number of instances, diminishing server load. It would also upload asynchronously (while battles are running), making it "lightning fast" even with the current protocol. But uploading one pairing at a time and downloading priority battles being dependent on uploads is still annoying.

Is it really that hard to detect when the rumble stabilizes? I get what you're saying about full on priority battles, but I'm thinking when all bots have some huge number of battles, like 6,000 or 10,000, you assume it's stable. That's only one API call. It's actually stable long before that as far as most people care. Also, the API call tells you how many pairings each bot has, so you can just check that they are all the same number instead of downloading each individual pairing, if that's the measure you want.

Again, I'm certainly not saying my wish list wouldn't be a ton of work. =) I was intentionally including all my pipe dreams there. But I think they're mostly feasible.

For PL, it's about 16k battles, assuming all pairings are balanced. Otherwise you need to download 600k pairings to analyze.

And relying on Darkcanuck's API will make the client incompatible with other servers.