Talk:Diamond/Version History

For old discussions, see Archived talk:Diamond/Version History 20110905.

Hi mate. This version is awesome, the survivability is extraordinary. I know, it's only 3k battles now, but i guess it will hold his score quite well. And that right after i had Wallaby made some sort of a survival king :) (at least in mico) - well done made. This will be thrilling to watch how far you can push it.

I'm just kidding with the 'Stop it!' :)

Tae Care

Thanks dude! I think there's still a lot of room to grow at the top in Melee. Justin (of DemonicRage) and I both kind of just stopped working on it when we got to that virtual tie for #1.

I haven't played with Melee for a while, so right now I'm still kind of just getting my bearings again. But I think between having a better testing tool (RoboRunner vs hacked up RoboResearch) and way more CPU power, it should be a lot easier for me to find real improvements now.

And it might be a good idea to build up a buffer before Numbat and Neuromancer come for my head. ;)

It seems that lower bullet power is a real boost against upper bots... methinks some sort of adaptive bullet power really is the way to go.

I can only speak for melee but it was very rewarding to put a rule within my bots where i only shoot 0.1 bullets if i have more energy than the other bot (endgame 1v1). This worked against every kind of bot. If the bot is weak he will drain his energy anyway (bad hit ratio) and i get the win score. And if the bot is strong there is a good chance that he will also drain his energy and i can't hit him anyway. If i have less energy than the opponent i just shoot with normal bullet power to prevent the stronger bot to score more bullet damage. I guess this is working because in melee you have mostly significant less energy for 1v1 as in normal 1v1 and therefor the stronger bots have not much time to adapt the movement and weapon.

I'm sure this is not working very well in 1v1 but i guess it shows that it is worth to think about because there are a lot of bots with bad energy management.

That would make sense, as most of the time only the strongest bots get to the endgame. I wonder if it would help even more if you only shoot 0.1 against everybody in the endgame...

I have tried to shoot 0.1 only, but it didn't work very well, because if you have less energy than the other bot it is most likely that you lose anyway. But you give the other bot the chance to collect more bullet damage. If you have a weak opponent you have a good chance to hit him and get on some point more energy and a good chance to win, and if it is a strong bot you deny him the additional bullet damage.

I had played with the energy slope to detect when he might be at zero and adjusted my bullet power to this value. The energy slope was quite nice to react on bullet hits and other energy losses and worked very well but it turned out that you have to react on some battle situations where it is better to shoot normal otherwise the opponent get to much bullet score.

Yeah, what a pleasant surprise - I was going for APS. =) This was a .09 improvement over 3000 battles (6 seasons x 500 bots) in tests, so I was sure it would translate to the rumble. But I guess it really did hurt against th really weak bots I excluded from this test bed, which surprises me.

A few weeks ago I tried to find some really scientific bullet power selection. My thinking was that in general, if survival is not a worry, you want to maximize bullet damage - do as much damage as fast as possible, to increase your bulle damage and give him the least amount of time to get his own. But if survival is a concern, you want to maximize energy differential. So I plugged all this in to my normalized hit rates, expected rate of return for both of those, and trying to figure out when to switch between them.

Turns out maximizing bullet damage = 3.0, maximizing energy differential = 0.1, in almost every situation against almost every bot. Like you're literally best off just not firing to maximize energy differential unless your accuracy is super high. It didn't work very well. I think ~2.0 works because it's only slightly below 3.0 in damage rate, while also much better in hedging over more shots for consistent survival, and gun accuracy is better if you stick to a more consistent bullet power in data collection. But I'm not really sure. I'd still like something more intelligent than a hand crafted formula, but for now I'm skeptical about really making that work.

I think the thing to remember is that you don't have to maximize energy difference once you're certain you'll win the battle. From that point onwards it is possible to maximize bullet damage.

I'm interested in what could actually change in a surfing algorithm to increase the MEA. Are you doing a different escape angle or something?

Oh, it's pretty simple actually. Instead of simple orbiting, I'm moving in a straight line towards the point where I'd end up in a precise MEA calculation.

My main worry is it seems like a ton of extra calculations per tick, but in practice it doesn't seem to slow me down that much. I guess some combination of the "don't calculate second wave when you don't need to" optimization, and that I don't recalculate the destination for the direction I'm heading in on the first wave.

Heh, so essentially you're using a sort of Goto surfing now, albeit with a very fancy points generator?

Yeah, it is a little bit of go-to. =) I'm always moving towards a specific destination. But the overall algorithm is still pretty much unchanged from True Surfing, it's just how I choose the movement angles for each direction has changed.

Wow, a loss of 0.1 from some legit bug fixes I found during a small refactoring. My perceptual gun was always reporting HOT to the VG, which should hardly even come into play since barely any firing waves reach the enemy by the time the perceptual gun gets disabled anyway (4 shots). As far as I can tell, that's the only real behavioral change. I'd think the score loss was randomness but I also saw the difference in my benchmark (and I'd dismissed it). So, obviously I refuse to revert to broken code, and now have to figure out how the heck this should really be tuned...

Naturally I want to believe it's some other change I'm missing, but it really was very few changes before the first benchmark that showed the loss. Bummer!

Hey, I just thought you should know that the Literumble pairings are just about complete (which is where all of my CPU cycles have been going).

Diamond KNNPBI

It seems that both of us have very low scores against rtk.Tachikoma. Something to look into.

Or... maybe not: [1]

It seems I have some bad battles...

Cool, thanks for the heads up! I think this will be a great way to find bots to improve against.

Could the Tachikoma thing be a discrepancy in Robocode versions? Are you using 1.7.3.0 or something newer?

It could be. I'm running 1.7.4.2 Alpha2 at the moment as it accepts gzip/deflate encoded data for the rumble and helps cut down on my bandwidth. A lot of the earlier results are from 1.7.3.0 though, so it could be related.

Some quick tests show that DrussGT typically gets 80-85% on my 1.7.3.2 dev Robocode, so it seems the the results on Darkcanuck's server are a bit odd... I see in it's Tachikoma.properties file it is built for 1.7.3.2, but I don't think that could be giving it bad battles on 1.7.3.0.

Here is a more telling result: Tachikoma details sorted by date. Scroll down and keep an eye on the survival. Only the latest battles have any survival at all. The time they started getting survival corresponds with the time I switched my clients from 1.7.3.0 to 1.7.4.2_A2. So it seems it is a client issue.

I recall Wompi discovered some bots acting differently from 1.7.3.0 to 1.7.3.2. I'd forgotten, but Tachikoma was one of them: Talk:RoboRumble#Rumble_Client_1.7.3.2_vs_1.7.3.0_1092.

Ah, that explains it. I'm tempted to remove Tachikoma now.