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.

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.

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.