30 day battle records

I know I can't compete with giant clusters like bwbaugh, and it's not that scientific since it depends on what bots are submitted, but in case anyone's curious.. In September, I ran my i7 with 4 clients all month to see what I could max out at for battles contributed. Best I saw in "last 30 days" was 1,269,511.

I know my client spends more time on the upload than running battles, not sure if it's due to the extra latency from South Africa or just Darkcanuck's delays. That slow upload was one of my motivations for writing Literumble.

I built a custom results uploader which uploads battle results in parallel. Up to 15 simultaneous connections (configurable) are made to the server to work around latency issues. It makes a huge difference in melee, and also helps in 1v1.

As a side effect, priority battles are downloaded in parallel, and they are grouped together before writing them in the priority battles file.

If anyone is interested I can put it in the tools page.

I think it would be better to just allow both the server and the client to upload them in bulk, rather then one at a time.

It would be a lot more efficient to have batch uploads, but the work around above at least keeps backward compatibility.

Keep in mind that the delays in uploading to Darkcanuck's server were added intentionally because the server couldn't handle the load otherwise. So it might not be a great idea to circumvent them. But I do agree that they take a lot of time and it would be great to have a system with faster up loads.

On that note, maybe we should finally accept that Darkcanuck's server is "orphaned" and we need to setup a new one where we can update country flags / give people API access and so forth.

I think the biggest problem with Darkcanuck´s server right now is the admin, Darkcanuck, not being around. If the server suddenly goes offline for any reason, no one will be there to look after it.

That might be an idea, and while we are at it we can add support for bulk transfers at least to the server. Perhaps a modified url for bulk download of robot pairings as well. This should cut off considerable time required to run the rumble, as sometimes the uploading can take as long as just running the battles.

My feelings are split on if we should use the normal rumble or the lite rumble codebase. I like the idea behind the lite rumble, but python leaves much to be desired in the area of performance.

I would prefer Java EE, but there are a lot fewer clouds which support it.

I have never really used Java EE. But for web applications I still think that languages like PHP are best.

Java EE has features to ease web development while still allowing you to fallback to plain Java with all its features and libraries when needed.

But there are a lot more clouds supporting PHP than Java EE.

Google App Engine (where I've got LiteRumble) supports a subset of Java EE.

I'm not sure we really need any special casing of bulk uploads. The uploads already fly with LiteRumble with whatever he's doing now.

I'm also torn, as Darkcanuck's server has a pretty robust feature set and is time tested with the huge load of a real rumble server. But I don't think it would be hard for LiteRumble to gain the new stuff we want and I love how lean and flexible it is. It's also a code base someone active is familiar with. And I'm happy to pitch in for resources if we need anything to support "rumble scale".

Bulk uploads would be particularly nice for melee, because it would mean I wouldn't have to do as many database writes. But as far as upload speeds go, Literumble is way, way, way faster than Darkcanuck's server. Looking in his code, he has a 1 second wait hardcoded into each pairing upload, which is kind of ridiculous. That means that for each melee battle it takes a minute to upload once you count processing and connection overheads.

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.

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

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.

I am fully in favor of setting up a new rumble server, though I am fairly new to programming so I doubt I would be able to help much. Perhaps, if we are starting from scratch, we could go ahead with the Roborumble.org project that has been talked about for many years.

Would the entire ~1000 bot participants list move over to the new server, or would we start over fresh with active participants and a stable of "classic" bots that have historical/otherwise significance?

The answer to that question may decide who ends up with the #1 spot on the new rumble server. ;)

If it's just a matter of copying, I see no reason not to move the entire list. But, if we change it so that every bot has to be added individually, I doubt many people would be volunteering to move 1000+ bots. :)

I think it´s better to keep them all. For me, as long as the server can handle, the more participants the better.

If you want a smaller rumble, we can create another division.

About who ends up #1 being affected by others below it, we will end up ressurrecting the king maker discussion started a long time ago.

The "should we make another rumble" or "should we restart the rumble" was something that has been tossed around for years. Generally the answers have been no. Mostly since there was no very good reason to do so.

Perhaps when we get obstacles into the game, we can get a new rumble going with a special arena, or urban combat robots.

About obstacles in the game. There is a mod called Virtual Combat which is exactly that.

Also BerryBots has obstacles in a very robust / configurable fashion, as opposed to tacked onto a game not designed for it. =)

(I think you're both on Windows, though, and it's not on Windows yet. Very soon though. I bought Windows 8 and got BerryBots running on it, but there's some more stuff to be done before releasing.)

Just make sure it is usable on Windows 7. That is, don't use anything that is Windows 8 only.

Pretty confident that won't be a problem. I'm using MinGW, and the graphics libraries are wxWidgets and SFML, both of which are cross-platform and I'm compiling them from source too. But I'm not going out and buying any more friggin' copies of Windows =), so hopefully I can get someone to test it out.

I have Windows 7 and I am very excited about trying BerryBots.

Just out of curiosity, is 8 really as bad as they say?

I haven't really used Windows since XP, and I haven't played with 8 much yet. So far my impression is mainly that the UI has some nice little things, isn't much better or worse than XP, but definitely a lot weirder. I like that they're at least trying something different but I expected it to like it a little more than I do.

I'm turned off by Windows 8, myself. I like Windows 7, but I don't use it. I'm still using XP, primarily because copies of Windows are always about twice as expensive as I am willing to pay. I'm kind of hoping once Windows 8 is going full steam, that copies of Windows 7 might get discounted to a price I am actually willing to play.

You know what -- I make decent pay at my job, but I'm still not willing to pay what Microsoft wants for copies of Windows. I have to think that very very few people actually buy copies of Windows, if I'm not willing to. I would guess most people just use whatever comes on whatever machine they buy. I build my own computers, so that is not really an option for me. If I could get games to run under Linux, I would probably switch. Games are the only thing really holding me to Windows at this point.

Back a little closer to on topic, if there were to be a new Rumble, I would want the full list of robots in it. I probably would not participate in a combat with obstacles, just due to lack of spare time for play. If I had more time, I would get into the existing melee first.

Prompted by some interest from Chase, I posted the current in-development version of BerryBots, compiled for Windows (on Windows 8/MinGW): berrybots_wintest1.zip (~20 MB). You should be able to just unzip and run berrybots.bat. If anyone wants to test it out, I'd love to hear if/how well it works on other Windows's - I haven't tested anywhere beyond my own Windows 8 install.

One thing I'd be curious to hear is if tab navigation in the dialogs works - it's not working for me on Win8, but does on other platforms. Trying to figure out if I need to hand-code that for Windows.

I'm getting an error when I try to run on Win7: "The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem".

Ok, much thanks for testing it out. Chase got something similar, so I guess I have some research to do. Maybe it is depending on having MinGW installed or something.

I'm able to duplicate this by removing MinGW stuff from my path. I just need to straighten out static linking and/or including the .dll's for a couple things. Hope to have another test version posted soon for anyone still willing to help.

Well, the simplest solution is apparently to just include the MinGW DLL's I depend on. I've put them here (just drop them in berrybots/), and the updated zip with them is here.

I'd rather not be distributing all these DLLs so I'm going to look into statically linking against them. But since I'm also dynamically linking to wxWidgets, which links to these, I have to switch to statically linking against that first. I guess there's also debate about how dynamic vs static vs any linking at all relates to the GPL terms, but I'm already using a more permissive license than that, anyway.

If nothing else, this whole "build a cross-platform / native desktop GUI app" has been a pretty educational experience. :-)

Great! Thanks for testing. I will have separate downloads (more than two :-)), this was just a quick export to see if it worked on Windows 7 / other people's computers. Thx for feedback on tab navigation, I need to figure that out - I've otherwise put a lot of care into good keyboard navigation / shortcuts, so that's a must-fix.

That is understandable. In that case it should be fine. As long as you are not using the Windows 8 only apis (which do exist!). But from the soudns of it, you're not. Since I don't think MinGW supports any of that yet.

In december I ran my i7 with one client continuously, it delivered 280k battles in 31 days. It also depends a bit on the priority battles to do, a new micro usually is faster and delivers more battles than f.e. a new XanderCat. I was proud on my 9000 battles a day, I remember the time when only David Alves could deliver more battles per month.