Talk:Diamond/Version History

ELO inaccuracy

About "Note: Despite lower ELO, was about .3% APS better than 1.0.", that's not surprising to me at all. Glicko-2 seems to be far more true to a full-pairing APS than ELO was too. Things like this make me glad the new server doesn't just show ELO like the old one :) --Rednaxela 22:02, 17 May 2009 (UTC)

Although I had second thoughts about setting the APS as standard ranking decisor, I must agree that ELO is not as reliable as it was on the old server(s). Mind you that ELO is calculated slightly different on this server than on the old ones. --GrubbmGait 22:11, 17 May 2009 (UTC)

ELO scores have recently taken a nosedive, for several reasons. There has been a lot of new activity recently with lots of bots being updated and a few new ones added in -- that tends to shake things up. Also, several long-running bots were removed within a short time period, notably pederson.Moron which once anchored the bottom end of the scale. It's safer to compare APS instead of ELO, especially right now. --Darkcanuck 15:18, 18 May 2009 (UTC)

I only pulled Moron because it seemed fairly pointless. I don't mind if he is returned to shore up a ratings slide, but that seems like giving a cancer patient a Band-Aid. On a related note, a long time ago I got the notion that the average ELO rating of the old rating system was 1600. I dropped the ratings list in Excel and confirmed that the ratings averaged to about 1600. At the time, most people were wondering what I was smoking, dismissing 1600 as anything of relevance. I recently did another averaging of the ratings and found ELO to average at 1413 and Glicko-2 averages 1608. Dunno if it really means anything, but ELO certainly doesn't compare to the old ratings.--Martin 16:24, 18 May 2009 (UTC)

Avoiding recent enemy locations

Well, I found a bug in my risk calculation for avoiding recent enemy locations (fixed but not tuned in 1.071). I really feel like this must be a good idea (because bullets are likely to be headed to those spots), but I hadn't found any rating boost from it yet. Hopefully I can find some points in a re-tuned, bug-free version of this... --Voidious 17:25, 21 May 2009 (UTC)

1.11* bugs / fixes

Man, this Performance Enhancing Bug really drove me nuts, especially since I have so much trouble testing such a little thing. I think I can live with a .15% APS drop in my "bug-free" 1.115 (versus the "buggy" 1.111). I'm sure I'll continue tuning the randomness of his movement in the future, anyway, and I know there are more performance gains to be had elsewhere. This is long and boring, but I feel compelled to write it out, even if just to have the info "out there" somewhere.

The bug was with my random direction change timer. This timer influences the bot to reverse direction at a random interval (with a risk added for disobeying the timer). If the timer trips while the bot is moving with negative velocity, there would be a risk associated with continuing in that direction, and the bot would soon change direction towards positive velocity. Before the timer trips, there's a risk associated with reversing direction.

With the bug, once the velocity went from negative to zero (or positive), it mixed up its directions and thought that negative velocities were the safer direction. This was caused by two things: it always considered zero velocity to be the same as positive, and it was comparing the possible future heading to the heading from one tick ago (instead of heading from the current tick). So here's the problem scenario:

• Diamond is moving with negative velocity.
• The timer trips, so now there's a risk in continuing in this direction.
• He begins to change direction, eventually hitting zero velocity (or, rarely, as high as +1).
• He notices he's changed direction (because zero is the other direction) and resets the timer, meaning now there is a risk with changing direction.
• But he compares possible movement direction against that of one tick ago, which is a negative velocity, so he thinks that way is the "same" direction.

In short, the direction changing worked fine when moving with positive velocity, but for negative velocity, it was more likely to just stop and then continue in that direction. At this point, I've just removed this timer and tuned the other randomizing factor (risk from recent locations) a bit more.

--Voidious 15:32, 26 May 2009 (UTC)

One thing at a time

The changes in 1.12 and 1.121 are a great example of why you should follow the "one change at a time" dogma. From 1.072 (best version at the time) to 1.08, I removed one thing: risk from recent enemy locations, and added another: risk factor based on damage given to enemy. 1.08 went down 0.1% APS, so I thought, "well that's barely beyond the margin of error, I'll just leave it". From 1.115 to 1.12, I restored the risk to recent enemy locations and saw a .25% APS drop. From 1.115 to 1.121, I removed the damage given risk factor and am seeing a .4% APS gain (pairings almost complete). Yay! --Voidious 18:25, 27 May 2009 (UTC)

Bah, a few more battles and it's not even above 1.115. I guess I should be patient (still only at 1,000 battles). Oh well... =) --Voidious 21:14, 27 May 2009 (UTC)

One-on-one

At least you start working with One-on-one! » Nat | Talk » 14:49, 1 June 2009 (UTC)

Just a little bit to keep myself sane. =) Melee is really hard. Spending a day on 1v1 is therapeutic because I actually know what I'm doing. =) --Voidious 14:56, 1 June 2009 (UTC)

Also, I know I've covered this topic ad nauseum already, but I just have to vent: flatteners are so evil!! They entice you with their 50+ scores against CC in the MC2K6 and then they destroy your RoboRumble rating... =) --Voidious 16:02, 1 June 2009 (UTC)

Evil?!? Not if going for PL ;) --Rednaxela 18:52, 1 June 2009 (UTC)

Yeah, yeah, that's what the devilish flattener always says! =) Just kidding, obviously I'll try to tune it better. But they sure are touchy buggers. --Voidious 19:13, 1 June 2009 (UTC)

Once you get them tuned they can actually give you points. I know on DrussGT the flattener gives a good 5 ELO points at least. The trick is putting your bot against the enemy with the lowest hitrate that you would want the flattener enabled against (Ascendant comes to mind) and then putting the threshold just a tiny bit below that. --Skilgannon 19:56, 1 June 2009 (UTC)

Yeah, I've tested removing the flattener from Dookious and it costs me points (I think it was about 5, too, not to mention killing PL score). The thresholds there are really well tuned and conservative. I'm just feeling greedy now. =) I think I'm going to try to come up with something more clever than just hit percentages (even my carefully normalized ones), like measuring the adaptation rate of the enemy gun, for enabling criteria. Turning the flattener back off when the enemy hit-% drops below the threshold (as I do in Dookious) seems silly from one perspective, because it could just mean the flattener's working, but I've always felt that permanently enabling it carried too much risk. --Voidious 20:05, 1 June 2009 (UTC)

Hmm... Normalized hitrates... I should compare those used in RougeDC's firepower selection with the ones you use for flattener enabling :) --Rednaxela 01:10, 2 June 2009 (UTC)

I tally bullets fired as normal, but bullet hits are weighted by distance and precise escape angle range. So a bullet hit from twice as far away or in a situation with twice as big a max escape angle would count as two hits. (Edit: Oh yeah, I also subtract 1 from bullets fired for onBulletHitBullet.) For my bullet power management experiment in Dookious 1.60, I normalized out the same stuff in a different way, but I didn't use precise max escape angles, because I was feeding the escape angle into a formula for testing 300 bullet powers each tick. =) --Voidious 01:31, 2 June 2009 (UTC)

I've also been thinking about ways to make the flattener smarter, and one was by enabling it when entropy shows that it is predicting where they will shoot better than the regular hit surfing. I haven't tried it yet though. --Skilgannon 20:33, 1 June 2009 (UTC)

Wow, nearly 1% APS improvement with Dooki's gun, meaning more than half the difference between Diamond and Dookious lies in the gun. I guess the movement is already capable of some pretty nice PL performance, too. Exciting! --Voidious 13:59, 13 July 2009 (UTC)

MeleeRumble cruelty

So I feel 99% certain that 1.196 is functionally equivalent to 1.183, but that's a big discrepancy: 1.196 vs 1.183. I recompiled the source I had for 1.183 for a re-release, and it's coming in somewhere between: 1.183b vs 1.183. A binary comparison of the .class files shows that they are all the same besides one which I never update, so I'm confident the source is right. The MeleeRumble is a cruel, frustrating beast... --Voidious 16:02, 10 July 2009 (UTC)

It does make a big difference score to one robot if you fight it under a set of sample robot (which exist in melee) and a battle full of ABC's, rozu's and justin's robots. Although the difference you point isn't as much as I expected. Perhaps we should have a better way to control the melee score. Perhaps we need to weight the score base on the opponent level (which can take from the ranking). But it's a work. » Nat | Talk » 17:29, 10 July 2009 (UTC)

Multiple gun waves experiment

Well, I'm really surprised this worked, and now I'm wondering if anyone else has tried it before. Whenever I fire a gun wave in melee, I now fire an additional gun wave from the last known location of each (still living) enemy (besides the target). The idea is that I can easily collect gun data from the perspectives of all bots on the battle field, and that hopefully, I'll get a better/faster picture of the enemy movements this way.

A couple bug fixes and a bit of polishing later, I had a 0.74% improvement in my test bed from the new gun waves, on top of a 0.14% improvement with the tweak to the "number of bots" weight (also in 1.283). I'm now looking at a ~0.6% APS improvement in the rumble for 1.284 over 1.282, and not too far behind Aleph. Yay!

--Voidious 15:35, 24 August 2009 (UTC)

I've thought about something similar before, but I've yet to build a real melee gun. Really nice stuff! What I wonder, is what the results would be like if you added other points like the corners to that list, since many bots move relative to the corners as well... --Rednaxela 15:43, 24 August 2009 (UTC)

Well, with the way my gun records and reconstructs firing angles, firing waves from the corners for that reason wouldn't have the same effect as if you were using GuessFactors. (The enemy movement isn't recorded relative to the wave source, but relative to the enemy's initial heading.) But indeed, firing waves from additional sources is a good idea to try, and you just gave me the idea to try a "heading relative to nearest corner" attribute... --Voidious 16:03, 24 August 2009 (UTC)

Congrats, that's a huge and clever improvement! --Positive 15:58, 24 August 2009 (UTC)

Thanks! Still a ways to go before I catch Aleph or Portia 1.13, and I don't even want to think about Shadow 3.83, but I'm very happy for now. =) --Voidious 16:03, 24 August 2009 (UTC)

Very clever indeed! That kind of specific melee gun idea is exactly what made Shadow finally break away from Aleph in the rumble. You (and Positive) are not as far from Shadow as you might think, imo. --ABC 16:58, 24 August 2009 (UTC)

Niice! (wall distance.. corner distance) I never thought to try that attribute in the gun.. sounds like a great attribute!, and the gun collecting data from other enemies.. a truley great idea Void.. -Jlm0924 18:55, 10 January 2011 (UTC)

MeleeRumble 2nd place

It seems that no-one noticed, due to the ....Hawk hype, that Diamond passed Aleph and reached second place. Congratulations Voidious! And do I read the results of DiamondHawk correctly if I state that your movement is better than Shadows, but your gun is holding you back?? --GrubbmGait 05:38, 28 August 2009 (UTC)

Thanks for noticing. =) However, Portia 1.13 actually still has 2nd place by a small margin if he were un-retired. I'm still pretty excited about passing Aleph, though! And yes, I'm surprised by how many points I have left in my gun (and working on it now =)). If the *Hawk results translate linearly, this would put Diamond's movement ahead of Shadow 3.84, which is really exciting (even to be close!), but still a little behind 3.83. --Voidious 05:44, 28 August 2009 (UTC)

How about ask ABC to create Shadond? I'm curious if he will get to the throne (or even SHA3.83?) » Nat | Talk » 13:47, 28 August 2009 (UTC)

Now you know what I meant by you and Positive being closer to Shadow than you thought ;). Shadow 3.83 melee movement is just a normal (and very old) Minimum Risk movement, the melee strategy page on this wiki has long contained all the tricks I use. Aleph's movement has probably always been slightly better than Shadow's, but my gun made the difference. At this time I suspect that the strongest combination would be my gun with Portia's movement. --ABC 15:00, 28 August 2009 (UTC)

Well, perhaps the very strongest combination would be... Shadow's gun, Portia's Melee movement, and Diamond's 1v1 movement, but the 1v1 part would only make a small difference I'm sure... :) --Rednaxela 15:04, 28 August 2009 (UTC)

Nah, DrussGT's movement is stronger than Diamond's 1v1. » Nat | Talk » 15:16, 28 August 2009 (UTC)

ShadowHawk and DiamondHawk gave me a pretty good idea where my gun and movement stand, so I don't feel a need to request Shadond. (That is a hilarious name, though.) I'm quite content to wait until I can challenge Shadow myself. =) ABC (or Positive) is free to make a hybrid if he likes - my code is very pluggable, as always. 1.30 is officially at #2 now, so maybe I'll focus on 1v1 for a bit. =) --Voidious 15:21, 28 August 2009 (UTC)

The only obstacle is RWPCL. So unless you officially gave them permissions, they can't =) » Nat | Talk » 15:32, 28 August 2009 (UTC)

Oh bah, the statement "ABC (or Positive) is free to" is good enough for all intents and purposes :) --Rednaxela 15:47, 28 August 2009 (UTC)

(Edit conflict) Diamond 1.30 has definitely passed Portia 1.13 now, so congrats on reaching 2nd place! It's interesting to think about what combination would be best. I think Shadow's movement and gun are quite good for the first few turns of a 1v1 fight, because they don't wait for waves to reach the target (something GF-targeting does have to wait for). In melee, you often only get a few shots while down to 1v1, so it's extra important to have a quick start. --Positive 15:27, 28 August 2009 (UTC)

Thanks! I don't understand, why would GF targeting have to wait for waves to reach the target before firing? Diamond sometimes stays still for a moment when it gets down to 1v1, but I'm not really sure why, actually... I should investigate that. --Voidious 19:51, 28 August 2009 (UTC)

What I mean is that GF-guns can only use a simple targeting method to aim before they have any data, and they only have enough data to make an informed shot after a few waves have hit. A pattern matching can already detect and simulate movement (for example, stop 'n go) before its first waves hit. --Positive 21:45, 28 August 2009 (UTC)

Oh, of course. But in a Melee battle, you can still use the targeting data you collected during Melee when it gets down to 1v1, right? I don't see why a GF gun can't use that Melee data (as I'm sure Shadow does). Shadow is an awesomely quick learner, though, there's no doubt about that. --Voidious 21:56, 28 August 2009 (UTC)

That's true, you could use a combination of the melee data and new data. However, I think most advanced robots behave or will behave differently from melee in 1v1, so it will be or is better to use new data as fast as possible. Also, if you look at Shadow's debugging graphics, it seems like it doesn't use the melee data. :P --Positive 22:06, 28 August 2009 (UTC)

Really? Interesting. Diamond uses "number of bots" as one of its gun dimensions, so 1v1 data is favored, but it uses whatever it has. If I were using GF + VCS, I would probably sum a lower-weighted buffer that doesn't segment on # of bots and a higher weighted one that does, so it would have something to work from before collecting the 1v1 waves. =) --Voidious 22:11, 28 August 2009 (UTC)

Oh, very nice - congrats! Perhaps this will trigger the release of Shadow 3.85? --Darkcanuck 15:56, 28 August 2009 (UTC)

I sure hope not... =) --Voidious 19:51, 28 August 2009 (UTC)

Wow, 1.31 is 0.4 APS from Shadow 3.84, congrats! Now I really have to see if I can squeeze some more points from Shadow's gun/movement. --ABC 12:30, 29 August 2009 (UTC)

Thanks! =) Now that I've got it working, your Melee Gun design is so powerful, it almost feels dirty. Thanks for sharing. I'll probably focus on 1v1 for a bit now, anyway. And seeing as rating points are so much harder to find as you ascend towards #1, I think 3.83 still has a pretty solid lead over Diamond. --Voidious 17:09, 29 August 2009 (UTC)

I just noticed, you are now second in both melee and 1v1 =) Great work you've been doing on Diamond. I'm curious, how much do your melee and 1v1 code interact? For instance, at the end of a melee when there are only 2 bots left (1 being Diamond), does your 1v1 movement kick in with no values? Or does it have some sort of idea where the enemy will be aiming due to it's observations during the melee? --Skilgannon 17:59, 29 August 2009 (UTC)

Thanks! While there's nothing quite like being #1 ;), I'm really satisfied with Diamond's progress. It's also great fun having active competition from Positive, ABC, and Justin... Hopefully, I can give you that "pleasure" on the 1v1 side sometime. =) I know it gets lonely up there. As to your question:

• On the movement side, they are totally separate, much like you said. When it gets to 1v1, the surfing kicks in with preloaded HOT-avoidance, not knowing anything from melee bullet hits. Of course it saves surf stats per-enemy across rounds, too. If I had some Portia-style melee bullet dodging, I'd surely try to integrate it more, but as of now, Diamond's melee movement doesn't even notice energy drop.
• On the gun side, they are more integrated. One of the gun dimensions is number of bots alive, but it doesn't discard melee data for 1v1 scenarios or vice versa. Wall distance is calculated differently (though recorded in the same slot), I use different weights when aiming (including some dimensions being used in only 1v1 or melee), and now the melee gun uses the Shadow/Melee Gun technique.

--Voidious 19:10, 29 August 2009 (UTC)

Hmm. So the gun works pretty optimally between melee/1v1 but the movement doesn't. The movement I've been working on expands seamlessly from 1v1 to melee, with full surfing capabilities, and full learning based not only on hits to yourself, but to all other bots that you can scan. The logic is amazingly complex, with decisions about bullet hits needing to be deferred until more data is collected and checked for bullet bonuses etc, but I see no reason (aside from CPU limits) why it isn't perfectly viable to learn how everybody is shooting all at once =) This is the main reason I haven't progressed that far with it - it's such a massive project that I'm not sure where to begin, and I'm also scared that I'll spend several hundred hours in development and then the whole thing will be a flop =) --Skilgannon 20:35, 29 August 2009 (UTC)

Sounds very cool, and very ambitious. =) I see how a lot can be approximated about enemy targeting during melee, I'm just very skeptical it can be precise enough to be useful for Wave Surfing, which thrives on ultimate precision. But Portia has found a lot of success, ABC is trying likewise, and it sounds like Rednaxela has some good melee dodging now too, so maybe it's worth a shot. Good luck, in any case - it'd be way cool to see you enter the melee arena. --Voidious 21:30, 29 August 2009 (UTC)

I just saw that Diamond 1.31 is PL king at the moment (100% Pairs won), congrats! --Positive 00:14, 1 September 2009 (UTC)

Thanks... Though the top bots are so always so close and I release so many versions, it was bound to happen eventually. =) Likewise, great work with Portia 1.19 - great way to start the semester, eh? Cheers, --Voidious 02:30, 1 September 2009 (UTC)

Performance Enhancing Bug in 1.32

Hm, well it seems that the bug fixed in 1.323 was slightly performance enhancing, and thusly says to me that something isn't ideal about using inverse-distance weighting for scans... Hmm... --Rednaxela 14:58, 31 August 2009 (UTC)

Yeah, I don't know what's up with that. It's not that far beyond the margin of error, but still, I was hoping for a boost. I'm rewriting a lot of my data logging / danger projection into a bigger / badder system, anyway, so I actually don't care all that much. (It was actually while writing up my new system that I noticed this bug.) For what it's worth, in my experience, weighting scans by inverse distance is quite essential against simple targeters, where your most similar scans tell you exactly where the danger is and the rest are just noise. --Voidious 15:30, 31 August 2009 (UTC)

Well, I've found in various experiments over time that weighting scans some function of distance is essential indeed, but that a simple inverse is suboptimal. --Rednaxela 16:07, 31 August 2009 (UTC)

What, according to your experiments would be closer to optimal then? The inverse of some power of the distance perhaps?--Navajo 22:01, 1 September 2009 (UTC)

I'm also curious to hear what Rednaxela thinks... I used to use inverse square root of distance in Lukious, and I think Skilgannon tends to prefer inverse manhattan distance. Diamond is one of the strongest DC movements and is currently using a simple division by distance, for whatever that's worth. (In terms of rumble points, I think it just passed Hydra for the strongest DC movement.)

Semi-off-topic ramblings: I think we end up tuning around a lot of arbitrary things in our very complex bots, so when we change something and lose points, we think the change was universally "bad", when it really was just bad in our specific case. That's just a hunch, partially based on how often I and others tweak values that we've never tweaked and (seem to) find that our first instinct for that value cannot be improved upon.

--Voidious 23:00, 1 September 2009 (UTC)

(OT) I was just thinking the same -- 99% of my tweaks end up with similar or slightly worse performance, it's usually the bigger changes that yield results. --Darkcanuck 03:41, 2 September 2009 (UTC)

Yes, sometimes I make a change that when tested with several seasons yields some APS gain and I never upload a version of YersiniaPestis (after 1.3.7) that is not able to beat all my test bed bots on average, but on the rumble luck plays a huge role. Right now version 3.0 loses to Locke, and I haven't tested against him, but I'm most confident that if they fight some more times that would change, the only reason I haven't really cared about that is because Shadow is currently losing to two bots :). --zyx 04:09, 2 September 2009 (UTC)

Well, I had the most success with things like 1/distance^n or 1/n^distance type things for some magic tweaked value of n. What I found most interesting of all though, was that the best values were highly specific to the dimensions and surfing algorithm in question. When I said that I found simple inverse to be suboptimal, I didn't really have anything very specific in mind that I expected to be better for Diamond, but I had a doubt reinforced by this PerformanceEnhancingBug, that it was quite unlikely that a plain inverse was being truly optimal --Rednaxela 05:59, 2 September 2009 (UTC)

Wavesurfing Views

I'm curious... what do you mean by wavesurfing views? Multiple kd-tree weightings, the results of which are composition into an overall profile perhaps? --Rednaxela 14:40, 3 September 2009 (UTC)

Yeah, basically. I had trouble coming up with a word for it. A "view" consists of a distancing function, attribute weights, cluster size, max size (before cycling out old points), its own tree, and some other stuff like enablement criteria (hit percentage threshold, flattener mode). I already had some of this stuff in my movement, but it was hard-coded. Now it's easy for me to add/remove/change these multiple views. And yes, I now have a bunch more of them weighted and layered at all times. --Voidious 14:55, 3 September 2009 (UTC)

Diamond 1.392

Wow! Diamond 1.392 is doing great so far! Looks like it will take the throne! I really wonder how DiamondHawk would score with those tweaks... and I'm really surprised you never waited till aimed before --Rednaxela 00:56, 21 September 2009 (UTC)

Thanks. =) Still quite a few battles to go, but my fingers are crossed. Before, I'd wait for the gun to be turned only when it got down to 4 bots or less. Maybe ignoring it very early in the round is still a good idea, but I guess that was way too late... Assuming these 700 battles aren't a fluke, I'll post an updated DiamondHawk tomorrow. --Voidious 01:05, 21 September 2009 (UTC)

425 battles to go and Diamond holds the top spot with a narrow 0.2% APS margin... --Darkcanuck 04:36, 21 September 2009 (UTC)

At least it doesn't have to fight mini/microbattles ;-) Congrats man, seems that you have acheived the impossible. --GrubbmGait 06:02, 21 September 2009 (UTC)

Congrats! It's amazing how such a simple change codewise can make such a large difference. I'm definitely going to try to catch up. :) --Positive 10:03, 21 September 2009 (UTC)

Congratulations, you did it! So much time wishing for some melee competition, I finally got what I asked for ;). Now you defend that throne the best you can, there are other very strong contenders coming for it. --ABC 10:45, 21 September 2009 (UTC)

Congrats. Updating Wikipedia page, but still leave best overall megabot to Shadow. » Nat Pavasant » 11:15, 21 September 2009 (UTC)

Thanks guys! I still feel Diamond 1.392 vs Shadow 3.83 is a bit too close to call, but even a draw makes me pretty ecstatic. =) --Voidious 12:51, 21 September 2009 (UTC)

Information on the wikipedia is current meleerumble kings so it is Diamond. » Nat Pavasant » 13:18, 21 September 2009 (UTC)

Thanks, but I still feel free to have my own view of things. =) --Voidious 13:21, 21 September 2009 (UTC)

Great work on Diamond. I just have to hope you don't make a similar push in 1v1 =) --Skilgannon 14:30, 21 September 2009 (UTC)

Congrats on your new shiny crown. --zyx 14:37, 21 September 2009 (UTC)

I didn't thik anyone would beat Shadow this soon, but you did it, congratulations, it is great. --Navajo 20:47, 21 September 2009 (UTC)

Well then, it also seems that you've stolen my recently obtained title of "Strongest Melee Gun" from me with this tweak... I may have to delay the full release of Glacier further than I had initially planned in order to fix this... :) --Rednaxela 00:15, 22 September 2009 (UTC)

I noticed some bugs in my melee bullet power selection code and I've been obsessing over it since. It's there in 1.392 and since 1.382. The most glaring one is setting bulletpower=2.999 if enemiesAlive <= 7, instead of >= 7. Attempts to fix/update bullet power have all lost points, but leaving the silly logic doesn't sit well with me. 1.393 and 1.395 both showed improvement in my test bed over a significant number of seasons, but lost points in the rumble. Argh, maybe I'll just leave it for now... it's not the most exciting thing to work on. --Voidious 13:09, 23 September 2009 (UTC)

I don't think that setting should result badly per se. At the start of the game robots move a lot (go to corners, etc.), so they might be harder hit with slow bullets. Somewhat later they settle in more static positions when bots aren't constantly dying. With Portia I tried to avoid using 3.0 bullets as much as possible, and made it use 2.5 bullets for that reason. By the way, I have a similar 'bug' in Portia's targeting: it prefers using the first few results of the KdTree search, but those results aren't ordered on lowest error. 'Fixing' it causes point loss, and I have no idea why. --Positive 15:39, 23 September 2009 (UTC)

BulletPower

Hmm... 1.40 seems to be performing almost as good as 1.392, though not quite. Hooray for PerformanceEnhancingBugs. I've lately found that even seemingly minor/improving BulletPower tweaks can cause nightmarish (IMO) score drops in melee rumble. By the way, mind if I test out Diamond 1.40's bulletPower choosing in a GlacialHawk 1.11 release? (and as an aside, it seems that GlacialHawk 1.10 has stolen the 'Strongest Melee Gun' back, even if only by a small margin :)) --Rednaxela 17:40, 24 September 2009 (UTC)

I noticed, congrats. =) Feel free to borrow the bullet power - I'm curious too. I'm chalking up 1.392 and 1.40 as equal, as it's pretty close, so I can rest easily again. (1.40's Wave Surfing is also slightly weaker, but not sure it's enough to matter in melee.) --Voidious 17:50, 24 September 2009 (UTC)

Hmm... seems that GlacialHawk's bulletPower calculation is stronger in melee rumble overall, but weaker in battles with the stronger bots. Actually, it's just a very slightly modified HawkOnFire bulletPower calculation, which is far slimmer in code, but seems well-tuned overall for melee. As a side note, I find it somewhat amusing how Hypothermia is stronger in melee, yet is less than 1/4th of DiamondFist's code even when only stripping out the non-melee and anti-surfer modes :) --Rednaxela 15:16, 25 September 2009 (UTC)

[Edit conflict] You do know that size doesn't matter ? ;) Personally I have never found it worth the effort to investigate different bulletpower schemes, so I still fire full-power at close range, 1.9 at medium and peas at large distances. --GrubbmGait 15:32, 25 September 2009 (UTC)

I know size doesn't matter. I'm interested in simplicity, not code size. :) --Rednaxela 15:57, 25 September 2009 (UTC)

I must say, it's nice to see you don't have lots of points in a simple bullet power tweak. :-P DiamondFist definitely has some bloat right now from recent gun experiments, but I don't obsess much over code size, anyway... And I'm not sure I agree with your measurement: it looks like GlacialHawk 1.11 is just over 50% the code size of DiamondHawk 1.02 (12302 vs 23435). --Voidious 15:30, 25 September 2009 (UTC)

Well, I once compared lines of code between the core functionality of each gun, rather than codesize. I suspect the discrepency is due to things like 1) Enemy status/history storage is more seperated from the gun in Glacier, 2) Both including significant amounts of code that are not a core part of gun functionality, and 3) Different code style. I think comparing the gun package only would make GlacialHawk appear much leaner (not that the other parts don't matter equally) --Rednaxela 15:57, 25 September 2009 (UTC)

Rating order

It would be good if you keep your rating order the same. I mean, sometimes you put MeleeRumble first but sometimes you put RoboRumble rating first. --Nat Pavasant 14:57, 1 October 2009 (UTC)

I do mean to put MeleeRumble first always, but I did a bunch of them at once and used the wrong order, apparently... Thanks for the heads up. --Voidious 14:58, 1 October 2009 (UTC)

DV vs GF

I wonder what if you switch Diamond's kNN 1v1 gun to GF, how much will you gain? Because you say that the performance of TripHammer increased a lot when you switched to GF from DV. --Nat Pavasant 15:10, 1 October 2009 (UTC)

I think it would gain some in the TC, but not much in the rumble. Even when TripHammer was at 90.56 in TCRM vs Diamond's Main Gun at 89.85, using TripHammer in the rumble gained me almost nothing. Also, since TripHammer and Diamond share a ton of code, the TripHammer KNN test that got 91.20 in the TCRM could just as well be called Diamond + GF + different cluster size + TripHammer's kernel density. --Voidious 15:18, 1 October 2009 (UTC)

Diamond 1.461

Congrats on passing Dookious! --Nat Pavasant 15:03, 16 October 2009 (UTC)

Thanks, I'm pretty stoked! =) On the other hand, I could try rolling those changes back into Dookious, too... --Voidious 15:06, 16 October 2009 (UTC)

Wow! Interesting that it increased your score so much, in DrussGT I settled on a 'best distance' of 500 but I never really experimented with it beyond the MC2K7. --Skilgannon 16:30, 16 October 2009 (UTC)

I'm surprised, too. The first change I tested was to 450, but the score dropped so much in my test bed that I tried the opposite =), and saw a nice improvement. The attack angle changes came out even in my test bed, but I prefer one mode to two. --Voidious 17:18, 16 October 2009 (UTC)

Congrats, I would have to test something like that, but the best desired distance for YersiniaPestis so far is 400, I set it to 450 and it already drops a lot of score (especially PL wise). But I've always though is because my gun is pretty bad compared to top guns, and the movement is what gives me the edge, so being relatively close allows me to increase my hit rate without being hit that much. If I set it to ~370, it crushes Shadow, about 60% on average, but Dookious and DrustGT feast on him. --zyx 05:53, 17 October 2009 (UTC)

I thought that when you fight more aggressively, you get better PL but worse APS and vice versa. --Nat Pavasant 12:53, 17 October 2009 (UTC)

I figured it was inevitable that you'd eventually top Dookius. Now, do you have enough tweaks left to topple WaveSerpent and DrussGT? =) --Darkcanuck 17:58, 18 October 2009 (UTC)

Precise intersection (1.47*)

This precise intersection stuff is cool, even though it seems like sooo much code for such a tiny detail! Calculating the line segment / circle intersections was the first algebra I've done by hand in years. =) Really surprised by some of these results...

• 1.47 - Totally lame and imprecise implementation, not surprised it did poorly.
• 1.471 - Real precise intersection, simulating the given movement option until the wave totally passes. Uses center of angular range as the firing angle, half the range as the kernel density bandwidth.
• 1.472 - No precise intersection. Use the angle from wave source to bot center on the first tick that the wave could hit the bot, use (18 / predicted distance) for kernel density bandwidth. (This is how I've done it for ever...)
• 1.473 - Precise intersection, but instead of predicting the movement option until the wave passes, predict slamming on the brakes as soon as the wave could hit the bot. My rationale is a little complicated and specific to my exact surfing, but it's basically like this:
  • I want to consider how dangerous it is to choose this movement option. That may not include going full speed through the whole wave passing, which will create a large bot width.
  • Slamming on the brakes once the wave starts passing will minimize bot width, and thus projected dangers (not always, but in most cases, I am guessing).
  • Once the surfing really does reach the first tick the wave intersects the bot, it will predict one tick into the future for each movement option, then (just for precise intersection) slamming on the brakes until the wave passes. So it will eventually consider going full speed through the wave, or when to really slam on the brakes.
  • I'm really shocked how well this worked. Will go hunting for other explanations (read: other bugs =)) later.
• Note that my "slam on the brakes" precise intersect prediction is a separate branch from my main precise prediction. I also want to try predicting a slam on the brakes only after wave has passed center.

--Voidious 17:43, 22 October 2009 (UTC)

I have similar logic in YersniaPestis, but for every tick. On every tick I see what happens if I start stopping, so the actual decision is how many ticks until I have to break is the least dangerous option on each direction and keep the smallest of those two. --zyx 19:24, 22 October 2009 (UTC)

Dia 1.48

Congrats! (never noticed this 'till I saw your tweet =)) By the way, does this mean that kNN is better than k-means? And still you are using GF or DV in one-on-one? --Nat Pavasant 13:50, 24 October 2009 (UTC)

Thanks! I think it does mean kNN is better - 0.1% is almost within margin for error, but I also saw a nice boost in my test bed. I wanted to remove the k-means just because it seemed to be lots of code and complexity for little value. The main gun uses GFs with precise MEA, and the Anti-Surfer gun uses DV. I might experiment with making the Anti-Surfer gun use GFs soon. --Voidious 16:37, 24 October 2009 (UTC)

1.5.0

Nice update for 1.50. Good overall gain thus far! --Miked0801 22:07, 11 February 2010 (UTC)

Thanks. It was a very patient process of: make slight tweak, run 300 battles (2700 pairings) in my test bed. =) Eliminated two attributes and tweaked all the weights in the melee gun. Will probably need to use my brain for the next update, though... --Voidious 22:29, 11 February 2010 (UTC)

1.5.2

Finally putting some real focus on PL prowess now. My test bed is 16 of Diamond's toughest matchups. 1.5.1 was a 1.3% APS improvement over 1.49 and 1.5.2 was another 0.7% APS. While 1.5.2 is sitting at 3 losses in PL, in my testing over 50 battles, it still loses to Shadow, Pris, DrussGT, WaveSerpent, and Dookious, plus basically a draw (50.2%) against YersiniaPestis. Shadow is the only one that's not close, at 42.2%; the rest are ~48% or more. --Voidious 18:30, 24 February 2010 (UTC)

1.5.5

Awesome bulletpower tweaks! I had no idea that there was still room for improvement there. And ofcourse #1 ! (for now) --GrubbmGait 12:48, 11 April 2010 (UTC)

I know, I'm completely amazed...! And happy. =) --Voidious 16:04, 11 April 2010 (UTC)

That's very odd! Do you think it's due to a bug in the robocode engine? --Skilgannon 16:49, 11 April 2010 (UTC)

It hadn't occurred to me, but with such a freakishly large gain, you have to wonder. It could also be that the distance > 700 thing is where the rumble points came from, while the 1.95 thing was just something about my test bed... I should try reverting default to 1.999 and see what happens, but I kind of want to continue testing more bullet power tweaks now. =) --Voidious 17:07, 11 April 2010 (UTC)

I'll release a DrussGT with that change, see if it makes any difference =) Although I feel kind of guilty, since this is the results of your research... If I get time I want to try to make a platform that can use any gun in the sort of rumble-less environment you've set up for Diamond. Unless yours already does that? --Skilgannon 17:16, 11 April 2010 (UTC)

No need to feel guilty, I've sure looked over your version history for inspiration plenty of times. When you say rumble-less environment, do you mean the TripHammer/Research stuff? That just lets me test the classification, ie what angle to aim at, not bullet powers or anything like that. My general testing is still just RoboResearch and test beds created with the help of my BedMaker script. (Currently, 48 bots in the 70-90% score range.) --Voidious 17:31, 11 April 2010 (UTC)

Huh, it still feels strange =) Mostly because I'm still king I guess? I'm not sure. I didn't fully understand your TripHammer/Research stuff. I thought it was something where you saved the sequences of moves the enemy bot would make and then would iterate everything forward using everything except the actual Robocode itself. Anyways, that is the vision of what I want to create. Something that essentially provides an optimized targeting environment without any extra overhead, and which calculates all the stats for you. Thus, it would work for any gun, you just need to implement all the methods for onXXX() and log which gets called when, and the actual gun does the rest. It probably wouldn't be nearly as fast as yours, but could probably still cut benchmarking time in half. --Skilgannon 19:23, 11 April 2010 (UTC)

Not quite - it's another step removed from that, I guess. It basically stores raw wave data: attributes, hitting GuessFactor / bearing offset, bullet power, and id of last wave collected before this one was fired. For most wave-based guns, this is everything you need to train your gun or decide what angle to aim at. So then it iterates through the data, feeding your gun the same data it would have collected in a real battle, seeing what angle it would have aimed at for each firing wave, and checking if it would have hit. Yeah, storing actual positions would cost you some speed, but give you a lot more freedom in what you can test with it. --Voidious 19:39, 11 April 2010 (UTC)

Ok, back on topic =) It seems my survival was boosted about 0.2% but APS wise there was essentially no difference. I wonder if it's a thing with your test bed? Or maybe the way you weight/distribute your attributes? --Skilgannon 05:38, 12 April 2010 (UTC)

And were you also coming from a default of 1.999ish?? I guess I should just try reverting to 1.999 and see what happens in the Rumble... --Voidious 13:42, 12 April 2010 (UTC)

Yep, 1.999. Doing a direct compare, actually, it seems that survival went up 0.4% but APS didn't change at all. --Skilgannon 14:46, 13 April 2010 (UTC)

I just discovered a major bug in DrussGT, causing the majority of waves not to be logged, which was affected by any bullet power which gave a bullet velocity of XX.X5. 1.95 is one of them, with a bullet velocity of 14.15. I wonder if DrussGT happened to sneak into your test bed, throwing off your scores =)? Unless other robots also do matching of detected bullet velocity to the wave velocity by multiplying by 10, then rounding, then testing for equality? Needless to say, I'll release a new DrussGT the moment the current one stabilizes. This one shouldn't get 35% against Diamond =) --Skilgannon 17:14, 13 April 2010 (UTC)

Haha... you know, I noticed the high 60's against DrussGT, but it just seemed kinda weird and I shrugged it off. =) So it was a rounding error, like 14.14999 rounded down and didn't match? What a strange series of events to find that bug. I actually compare bullet powers rounded to 1 decimal place, which should have the same problem. I doubt most bots in my test bed are even detecting energy drop, but now you have me thinking it must be something like this. Bullet power 1.95 was like 0.5 APS better than 1.94 or 1.96 over 30 seasons of a 48-bot test bed, which is just baffling. --Voidious 17:51, 13 April 2010 (UTC)

• Yep, exactly. If you test 1.85 or 2.05 against the values around them you should notice similar phenomenon =) Could you see which bots in your 48 were affected? --Skilgannon 18:03, 13 April 2010 (UTC)
  • Well, 30 seasons for an individual bot isn't terribly precise, but I will take a look... --Voidious 18:34, 13 April 2010 (UTC)

Lol, GresSuffurd made an almost 0.5 APS point jump from 20 to spot 16, just by changing bulletpower from 1.9 to 1.95. I wish there were more of these 'logical' improvements to make :D --GrubbmGait 17:59, 13 April 2010 (UTC)

I wonder how much of that was from going from 30s against DrussGT to high 60s? =) --Skilgannon 18:03, 13 April 2010 (UTC)

Well, a 30% change... divided by about 700 participants... results in 0.04% APS change... therefore only roughly tenth of this is from those DrussGT results :P --Rednaxela 18:21, 13 April 2010 (UTC)

Just tested against Diamond 1.5.5 and BasicSurfer suffers from this bug. A lot of bots are based off BasicSurfer. Doh! I'll fix the code to check if the difference is under some threshold. I tested Diamond and noticed that it too suffered from this, tho it seems quite a bit less frequently. --Voidious 18:34, 13 April 2010 (UTC)

Chase's bots especially, they're (Seraphim and Prototype) both scoring less than 10% against the 1.95 power bots. It looks like 1.95 might be a valid improvement until everyone catches on =) --Skilgannon 18:40, 13 April 2010 (UTC)

1.5.16

Interesting... Seems the gunheat wave helped a bot already this high up more than I expected. I'm glad this trick I started in RougeDC works well :) --Rednaxela 13:23, 12 May 2010 (UTC)

Yeah, very cool and innovative idea! That reminds me I should give you credit. Sometimes I forget that what seems like "common knowledge" to me (that you invented this) is anything but. =) --Voidious 13:56, 12 May 2010 (UTC)

1.5.21

Curious about how many points I lose to my Virtual Guns, I tested with the Anti-Surfer gun off a while back. Avg score went down a whopping 0.5% in my test bed! So I guess my AS gun (whether due to fast adapting or some bots being more susceptible to Displacement Vectors, I'm not sure) helps for more than just surfers. Removing bullet hits showed a noticeable improvement - hopefully it translates in the rumble. --Voidious 15:42, 29 May 2010 (UTC)

Are you sure your test bed doesn't include any surfers? I remember your score also went up a bunch when you discovered the x.x5 bug in BasicSurfer. --Skilgannon 09:32, 30 May 2010 (UTC)

It includes PhoenixOS and BlackHole, which are surfers, and Tron 3 might surf too. My score actually went down against all 3 of them with 1.5.21. But, darn it... most of that drop when I turned off the AS gun was due to PhoenixOS and Tron. So that explains that. Looking back at the 1.95 thing, I still don't understand it. Biggest improvement was 8% vs Jekyl, a very old non-surfer, and 4% vs Earth, apparently a surfer based on CC. I gained 0.6% APS across 30 bots. Maybe it's time to refine this test bed. --Voidious 16:56, 30 May 2010 (UTC)

1.6.0

Congrats on being the first to implement bullet shadows in normal surfing! I'm really curious about how it'll work out :) --Rednaxela 03:48, 21 August 2011 (UTC)

I'm curious too - it was killing it in my tests (knock on wood). The only down side is this is pretty straightforward for anyone else to do too if it proves to be valuable. (Well, I guess there's only one person that I really care about... =)) But it's still a really cool addition to the state of the art, and beyond this basic technical implementation, there's probably room for strategic enhancements. --Voidious 04:05, 21 August 2011 (UTC)

Wow, that's a nice score increase! I predict that more bots will be implementing this soon... --Darkcanuck 01:30, 22 August 2011 (UTC)

Thanks! I never would've guessed it might be worth 0.8 APS, but I started getting optimistic once it was destroying my 100-bot test beds. I'll enjoy my time sharing the thin air up here with DrussGT while it lasts, which I suspect won't be long. =) Now to turn my attention to that PL (/Condorcet/batch ELO) crown...--Voidious 02:43, 22 August 2011 (UTC)

Hah! Sneaking up with a potential death blow, huh? This has always been one of those things that I thought wouldn't give much of an advantage for a whole lot of extra work... I didn't realise how easy this would be to implement until I tried it! I've been running MC2K7 on various tweaks all night. Just one more variation to test, then I'll be ready for release I think. Using DC and precise intersection should be easier with this technique... just zero the region of the intersection and it's done. For me the tweaks that can be done to try to take the discritization of the bins into account makes things a little more hairy =) Anyway, state of the art indeed. Nice thinking on this - if I ever get around to coding my Targeting Conditions Manipulation surfing, well, I expect some competition! --Skilgannon 05:56, 22 August 2011 (UTC)

Very nice score increase indeed. As a heads up, Chase-san has made "cs.Nene MC58k7" the second robot in the rumble to do passive bullet shadow surfing, haha. Also... hmm... it seems bullet shadows will now go on the looooong list of things for me to include on my next surfer. --Rednaxela 06:23, 22 August 2011 (UTC)

Oh, a question about implementations: are you calculating where bullet shadows will be before the bullets pass through the waves, or are you only updating shadows once the bullet actually hits the wave? Currently I'm doing the latter, but I suspect the former may improve scores a bit. Also, precalculating hits may be nasty once actual bullet hits start happening - keeping track of which bullets (which may now be gone) improved which waves (which may now be gone) and in what order is a bit of a nasty. (this question goes for you too, Chase) --Skilgannon 07:33, 22 August 2011 (UTC)

At the moment I only add the bullets once they actually pass the wave, as this was much simpler to add. — Chase-san 10:21, 22 August 2011 (UTC)

Why would order matter? The shadows exist for every pair of bullet/enemy wave until/unless there is a BulletHitBullet, then you can recalculate them all. I still say it's not nasty, despite the fact that I moronically forgot to remove the destroyed bullet before recalculating in 1.6.1. --Voidious 16:03, 22 August 2011 (UTC)

Lol @ "death blow". =) Yes, I calculate as soon as a bullet or wave is added. And as of 1.6.1 (which sadly seems to be exploding somehow on Darkcanuck's client) I recalculate all bullet shadows from onBulletHitBullet. It's not really that nasty. I have my lists of active bullets and active enemy waves - when I add one, I loop through the other, and onBulletHitBullet I loop through both, clearing the old shadows first. --Voidious 09:26, 22 August 2011 (UTC)

Congrats. Looking at your debug graphics are the dangers of the dots the actual dangers you use to calculate movement or do you just use those for painting and not use bins for you surfing? I don't use bins in Gilgalad to make the botwidth more precise, but this makes it difficult to mark an area on a wave as safe.--AW 13:37, 22 August 2011 (UTC)

I don't use bins - indeed I do just calculate the danger at 51 specific points for the debug graphics. --Voidious 13:44, 22 August 2011 (UTC)

Well for marking areas as safe without bins, I believe there are two ways:

1. The simple way: Just scale the risk depending on the proportion of the botwidth that is covered by the shadow. (Potential trap of getting caught by bullets near but outside shadows, but Nene MC58 shows this simple method is better than no bullet shadows)
2. The accurate way: Ensure you have a risk function that works with the guessfactors ranges rather than just the center. Then ensure your risk function satisfies the criteria "risk(A to B) + risk(B to C) = risk(A to C)". If your risk function is defined that way, you can subtract the risk of the overlap with the shadow (be sure to not double-count multiple overlapping shadows on the same wave)

--Rednaxela 14:16, 22 August 2011 (UTC)

Rednaxela's #2 is clearly the most accurate way, but seemed really hard. My two approaches were his #1, and since you're dealing with raw firing angles already when you don't use bins, just ignore any angles that fall within a bullet shadow when doing kernel density to calculate danger. Both of those options performed about the same, but somewhat shockingly, doing both was almost twice as good in my test beds. --Voidious 14:26, 22 August 2011 (UTC)

Exactly what I was thinking (re: accurate but difficult), but I have an idea on how to approximate it. The reason it is hard is that we want the danger to push us as far as possible from the firing angles, and to do this, you can use bins (less accurate) or as we do, some smoothed kernel density estimation. So basically we want to approximate the integral of the kernel density estimation across the bot width and use that for our danger. To mark an area as safe, we need to find the danger on the intersection of the interval we will mark as safe and the interval the bot will cover and subtract that from the danger of this movement option as calculated without bullet shadows. So the question is now: "how do you approximate the integral?" Because the danger function is smoothed relative to our bot width, we previously used the center of the bot to approximate danger, but we can do it differently without using much more CPU time. We can approximate the danger by taking the Riemann sum (average the upper and lower for more accuracy) of the kernel density estimation on the interval the bot will cover (for more accurate calculations use more points.) Approximate the danger on the intersection using the same method, subtract this from the movement option's danger, and use this new value. I hope that was clear enough.--AW 15:13, 22 August 2011 (UTC)

Also, if anyone can understand / clarify the algorithm above, should it be added to Bullet Shadow--AW 15:17, 22 August 2011 (UTC)

I think that is very similar to using bins =) The difference being using bins only for the bullet shadow, not the danger function... --Skilgannon 15:37, 22 August 2011 (UTC)

My view is... why bother with the mess of doing a approximations of integrals? Using the exact formula is not hard. Just design a risk function for "probability they fire at a given angle", do a proper integral of that, and just start using it. No need for the extra coding complexity of iterative approximations. It's really not difficult at all, so long as you have a well defined risk function in the first place. If your kernel density function for "probability of where they fire" is the sum of gaussian curves, the integral over a botwidth is made up sums of the "error function". It seems to me, that doing it in an accurate way is only difficult if your risk function is not well-founded in the first place. --Rednaxela 15:56, 22 August 2011 (UTC)

Actually Rednaxela's full method is more or less precisely what Nene did originally, however it required changing my risk function, the new risk function did not perform as well as the older one did, meaning it gained an overall drop in score. I have attached a little doodle I drew detailing about how it works.— Chase-san 15:23, 22 August 2011 (UTC)

http://img189.imageshack.us/img189/4650/bulletshadowintegrals.th.png

Even with bins it's a complicated story. Because of the finite number of bins, there are obviously cases where bins are only partially covered. So what do you do? Round it at 0.5, take the risk and act like they're empty? Act conservatively by using floor and ceil and not take advantage of that extra half bin that could have been safe? Obviously, the larger the number of bins the better, but isn't it always like that... right now I'm weighting the bin by the portion that was covered, but I don't really like it. According to MC2K7 it worked just a smidgeon better when rounding, but not against the weak bots - I lost 0.3 on average compared to partial bins. The possibility for tweaking is endless...--Skilgannon 14:58, 22 August 2011 (UTC) s

Nice idea and improvement :) This is similar to enemy waves passing other bots which is effective in melee. This may help in melee too. (Make sure your accomodating for missed scans/interpolation). Will the new Diamond be released in Melee? -Jlm0924 16:26, 22 August 2011 (UTC)

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.

RoboRumble ‒ APS: 89.82% (1st), PL: 913-1 (2nd), Survival: 97.19%

It's one small step for bot, one giant leap for community! I know, that it's too small margin, but congrats, Voidious, you're the best again!:)

Skilgannon, nothing personal, but i'm opponent of absolute monarchy:)

Hmm, I'd say my best version was 2.5.5 though.

http://darkcanuck.net/rumble/RatingsCompare?game=roborumble&name=voidious.Diamond%201.7.54&vs=jk.mega.DrussGT%202.5.5

This shows DrussGT a *little* bit ahead... exciting times!

I foresee fierce battle for crown in next few week with unpredictable result. And as i say earlier i'm fan of Diamond this time:) Actually, i think that completly new King, Jdev for example, is better case:) But in fact now only you, Voidious and Skilgannon, worthy of crown:) So good luck for both and i will go to market for popcorn:)

P.S. Let's break a 90 APS barrier!:)

Thanks for the encouragement Jdev. =) It's exciting (and a little weird) to even be in the ballpark of DrussGT, he's been so dominant for so long.

DrussGT is indeed still the king - I think the best of each is Diamond 1.7.53 vs DrussGT 2.5.6. Diamond shows slightly ahead there, but that doesn't include the head to head battle, which DrussGT wins by a margin and would put him in the lead. But really this is all well within margin of error, anyway, which means DrussGT is still King.

Lets see what happen in next few weeks:)

Besides, I've been making a nice run in the real competition since I got my Robocode computer. ;)

• Diamond 1.7.47: Math.exp(-0.5 * ux * ux)
• Diamond 1.7.50: Math.pow(2, -0.5 * ux * ux) (.47 vs .50)
• Diamond 1.7.51: Math.pow(2, -Math.abs(ux)) (.50 vs .51)

I know 1.7.51 is far from stable, but it blew away my test bed enough that I'm pretty sure it's a nice jump (knock on wood).

Fun to experiment with!

I just need to figure out where my major performance problems lie, because if I try directly using Math.exp() or Math.pow(), I get hundreds or thousands of skipped turns in a round. I'm pretty heavily reliant on using a fast approximation for Math.exp() right now.. but I don't think I should have to be...

Using the approximator seems reasonable to me. I actually saw that in your version history and played with one a bit in my gun. =) In my main gun, where I do over 10k kernel density calculations per tick, I long ago abandoned gaussian because it was too slow. But I thought with an approximation, which I already had laying around from some experiments with an integral surf danger formula, it might work. It was fast enough, but it didn't perform better anyway...

I've found that a formula that smooths across the whole angle range is really important in movement. And in my movement, it's a max of 200 data points * 12 firing angles tested = 2400 kernel density calculations (across both waves). So until now, I stuck with gaussian because it's the only common kernel density formula I'd seen with that property. But I finally started playing with modifications of that and it was quite an improvement.

Bingo!

A big big problem was that I was calculating all dangers on my waves up-front. My reasoning was to take a one-time calculation hit and then surf using lookups.

Problem was, at the angular resolution I was wanting, this involved tens (maybe even hundreds) of thousands of kernel density calculations when creating my wave danger Object. Seems like a few thousand kernel density calcs each tick works a lot better for surfing. My skipped turns were probably happening when I detected enemy waves fired on the same turn as trying to make a targeting decision.

Targeting is still annoying in this sense.. the entire angular range needs to be evaluated on this tick. I like the exponential/Gaussian approach.. but want to investigate if there are less processor intensive kernel functions that work as well (or better?).

Regarding targeting being annoying in terms of evaluating the entire angular range, how are you doing that currently? Are you just calling a kernel density function on a large number of fixed points?

Here are three examples of ways to perhaps calculate kernel density faster in the context of targeting where you only care about the maximum:

1. If you take the derivative of your kernel density function, you should be able to find the zero-crossings of the slope, and only calculate the kernel density at those points.
2. One could also try approaches like skipping the kernel density calculation for angles which are too far from any data points.
3. Or maybe even use the data points themselves as the angles to run the kernel density calculation for.
4. With certain exceptionally simple kernel density functions (i.e. rectangle like I use in RougeDC/Scarlet's targeting), you can find the peak extremely fast with specialized algorithms also.

re #1: That seems to break for me, because (taking the Gaussian example) if I have two data points, centers -0.25 and 0.25 .. the maximum of the total area after calculating both kernels will be at x=0, which wasn't a zero-crossing of either Gaussian point in isolation.

re #2: I like this idea!

I've just now switched (experimentally) to using the Tricube kernel because I like it's shape: flattish in the center and trailing off to either side. I have it adjusted to slightly overhang the precise intersection width of each data point. Since it only exists from (-1,1), I've got some of your suggestion #2 built in, and turn skipping has pretty much ceased! We'll see how well this kernel compares, of course....

For #1 I did not mean the zero-crossing of any one point, I meant the zero-crossings of the sum of all the derivatives of the kernel density function. Of course, whether it's efficient to calculate those zeros or not all depends on what the kernel density function is (probably not practical for gaussian, trivial for triangular, as two extereme cases)

Hmm... tricube sounds like an interesting one, though that's quite a bit of multiplication it uses. I wonder if this is the sort of thing that would be worth doing a rough approximation of really. I mean... it probably wouldn't affect the results too much to do the kernel density as a piecewise "sum of rectangles" approximation, and it would be much faster.

My solution to your problem was 2-fold:

1: Use a faster smoothing function. I've ended up at 1/(1+sqr(x))

2: A bit of dynamic programming: pre-calculate a single 'function profile' (and put it into a set of bins), centred at GF0, which runs from GF-2 to GF+2. Then whatever your GF is, you just need to scale your GF to figure out where on the function to draw your value from. So rather than doing an entire smoothing function for each hit, log all your hits (without smoothing) into a set of bins, then do the smoothing afterwards into a different set of bins by checking each bin if it is non-zero and overlaying a 'function profile' with that weight. If you're really sneaky you can even keep what the bin index of the hit is, instead of the actual GF ;-)

Until a couple versions ago, in my main gun, I was using Gaussian until a certain number of data points, then switching to if (abs(ux) < 1) { density += square(1 - square(ux)) }. After some testing with WaveSim, I'm now using (1 - cube(abs(ux))) and never using Gaussian. YMMV, but I think with the amount of data you have in a gun, you don't really need the heavy smoothing offered by formulas that cover the whole range.

One less intensive approach that covers the whole range would be something like: density += 1.0 / (1 + square(ux)), which is akin to what a lot of VCS guns do for Bin Smoothing.

Wow, nice work. I haven't really stopped robocoding (does anyone ever really stop?) but I took a break for a while and now I'm working on an R-Tree, and some rewriting for Gilgalad. I had an idea that might push Diamond to the top. As far as I can tell, you only surf three options on the second wave for each of your three options on the first wave. I suspect that the bullet shadows make the dangers much less continuous so that using more points on the second wave would help your score a bit. (For Gilgalad, I thought I had more or less fixed the skipped turns problem by using every 5th point and making sure I got the extreme points in either direction for the second wave, but I got a new computer that has an intel processor rather than an AMD. It's more than twice as fast as my old one from four years ago, but it seems to have way more skipped turns.

Hmm, interesting thought. My original surf algorithm was to check every point along the second wave (in the days of bins and no precise intersection), but just checking forward/stop/reverse somehow always outperformed it. It's true that a lot has changed since then, including bullet shadows, so maybe you're right. But my most recent experiments with changing my surf algorithm were even more significant and came out with almost no change in score, so now I'm a little skeptical about tweaking my surf algorithm. =)

Wow, congrats on these tweaks, although it brings Diamond a bit too close for my liking there! I think that we tend to weight the second wave so low anyways that minor inaccuracies aren't as big of a deal. Wintermute does that though, for each tick on the second wave try stopping and see where the intersection is. It mostly just made it slow.

You mean you only use three movement options on the second wave for each movement option on the first wave? And I've spent all these hundreds of hours optimizing for nothing!

Hey, you can never be too optimized! =)

Man, I'm so relieved to finally have a nicely tuned gun in 1.7.47. I hit several weird hurdles along the way that had me really confused / annoyed. The whole time, I knew it wouldn't even gain me many points, but all I wanted was to find some small gains and get warm fuzzies about my gun being nicely polished. =)

Now that I have that figured out, I'll just re-tune the perceptual gun against the same bots, hope I don't lose much or maybe even gain a little, and move on with my life. =)

The hurdles, if anyone's curious:

• Made a new version of TripHammer updated to Diamond's current code base, which has changed a lot of nitty gritty data processing stuff.
• My genetic algorithm code for the "fading KNN" was setting the parameters related to "size of k" on the wrong Classifier, so they were producing jibberish (had no impact on fitness) for several versions of Diamond.
• My KNN classifier (basically the WaveSim version of Diamond's gun) was multiplying the scan weight to the value I pass to Math.exp, instead of the result of Math.exp. No idea how/when that happened, but it sure made me feel stupid.

It's so strange, I found, once I add an attribute it doesn't really matter how much it is weighted (within an order of magnitude or so), I still get around the same results for gun accuracy. The biggest gains I had from genetic tuning was adjusting the speed that the 'time' attribute increased, and even then once it was in the right ballpark there was very little to choose between them. Still, it does help to squeeze that extra 0.1% out =)

Hmm, is it that strange though? You have enough good attributes already that the new attribute likely correlates to a significant degree (but not entirely) with one or more of them, which I'd expect to make it so it wouldn't change which points are closest when it's weighting is only changed a small amount.

True. I really need to PCA the data that gets generated by a typical battle. There must be an input transformation which can eliminate a bunch of the dimensions.

Attribute weighting is probably one of the things in Robocode that has received the most attention vs what it deserves. =) Sort of like dynamic segmentation, which used to get tons of focus, but is IMO much more elegantly implemented with KNN. I think it's worth having them tuned, but for example, Gilgalad is a super strong bot and recently got the exact same score when he removed his gun weights.

My 5 cents mainly for newbies and future readers. Tomcat (a little more, than super strong bot:)) also does not use weights in knn-gun and, by definition, in RS-movement

My thoughts with PCA would be that we could eliminate a large number of the dimensions stored in the tree by only taking the X main components, and make a transform which combines a large number of measurements from all sorts of things which aren't even very useful and turn them into a much more information-dense, lower dimension location. This would save on memory as well as search time while still keeping pretty much exactly the same results.

I agree that far too much effort has been put into refining weights, but it does have its place for ekking out that extra little bit of performance against a known population.

Obviously I agree it's worth some effort, if you check my recent version history. =) It's a very obvious and easy knob to fiddle with. And I can see pretty clearly with WaveSim that there are accuracy gains that can come out of it.

The PCA stuff sounds pretty interesting. I think it went a bit over my head in my Machine Learning class (though I understand the basic idea).

I think another big factor is that there's so much variance in hit rate, and so much score coming from movement and survival, that increasing accuracy beyond a certain point just doesn't translate into very many rumble points. The best of guns can miss 10 shots in a row and force you to rely on good movement and energy management. It's still fun though. =)

My current view is that movement and targeting inextricably linked with each other and it's impossible to say which part of points come from movement and gun. I think, that both statemets are correct:

• good gun gives less chances to enemy to hit you (so less score for enemy and more bullets for you, so more score to you), because steal his energy
• good movement gives less chances to enemy to hit you (so less score for enemy and more bullets for you, so more score to you), because steal his energy.

It's system of equal partners, imho for last few weeks:)

And a little offtop: also, imho for last few weeks, that statistical targeting is impasse (deadlock?) and next breakthrough may be in single tick playing forward. Especially in the light of the fact that totally annihilate of weak bots is more important, that destroy strong bots.

I disagree for a different reason... I think that's a bit of a false dichotomy, because I'd still classify the "single tick playing forward" methods as statistical targeting so long as the mechanism used each tick is still statistical. It adds another assumption to make each data point used more generally, but so do GuessFactors.

Really, what the technique provides, is denser data by making the assumption that on a given tick the opponant behaves in mostly-deterministic manner according to the attributes you're targeting based on. If your attributes are sufficiently complete, it should have a quicker effective learning rate.

I do think there is value in the "single tick playing forward" idea, but as-is it uses too much CPU, espescially if your targetting attributes are complex. I think one has to consider what it brings to the table and take advantage of it without making things so slow. My current view on the best approach, is that it would be doing larger number of ticks than one at a time (i.e. 10-tick-at-a-time iterative prediction).

I did not say, that behind ST-PIF must be kNN etc.:) Neural Networks may be used, for example. But actually yes - when i implement this, it was knn based. And you completly right: although this gun gets hit rate >95% against walls and >60% against crazy, it was unacceptable slow.

And I never said ST-PIF was always statistical, just that it doesn't have anything more to do with it being statistical or not than GuessFactors do (aka, nothing) :)

<random> Come to think of it, "Single-Tick" techniques and "GuessFactor" techniques have a lot in common... both "fold" data across lines of assumed symmetry. GuessFactors "fold" across the "front-versus-back" symmetry, whereas Single-Tick folds across a temporal symmetry of sorts.

GuessFactors have proven themselves highly beneficial, and Single-Tick techniques may also in the future, howver both techniques would perform sub-optimally when encountering something which violates the symmetry they assume. Unless the targeting attributes include something that differentiates front/back, GuessFactors will perform sub-optimally when faced with an opponent which treats them differently. Of course, it's difficult to take advantage of this in a major way I think.

Similarly the weakness of Single-Tick techniques is when an opponent treats different ticks differently due to something that cannot be detected in the targeting attributes. For most robots, even surfers, the assumption is probably good enough... but... in contrast to guessfactors... <evil>A cleverly designed semi-random multi-mode movement could be designed so that the movement path generated by a "single-tick" technique is never where it actually ends up ;) </evil></random>

Anti-Pattern matching comes to mind.

Have you tried using k=1? How does it compare then with something like regular kNN-PIF in terms of speed and hitrate?

Sorry, but i forgot details, everything that i remember i already wrote. Tomorrow i can publish that code, but i have no time in nearest future to liven up it

I guess K=1 would make ST-PIF have the same weaknesses as neural network based Pattern matching (non-statistical).

If a bot dodges 30% of the time going straight then turning to the right and 70% of the time going straight all the way, Neural Targeting averages both patterns and shoots slightly to the right, missing both patterns. In other words, it is awful against Walls.

Increasing K is what makes the gun choose the "straight all the way" pattern alone and achieve 70% hit rate.

Yeah, but you have other factors which would affect which scan is closest, like forward distance to wall, time since decel, distance last 10 etc. which all affect what the enemy motion will be. That is the advantage of this over plain single-tick pattern matching (which works better than regular pattern matching, but is slow/memory hungry). Even having k=3 would be quite fast for each kNN compared to what works well in guns now, where I can easily use k=150 and not skip any turns.

Also, once it gets onto one of the branches which suggest it will follow the '70%' you mention, the act of following that branch will make it more likely to further follow similar branches in the future, so it won't end up in between, but rather will end up at a different path completely.

I also thought on this problem and find out a possible solution: keep similar amount of data with different classes.

I tend to disagree - I think gaining rumble score via targeting has to come by improving against mid-range bots that are scoring significant amounts of bullet damage and survival against you. Whether or not I beat SpinBot 4000-0 or 5000-0 isn't going to make much difference. =) But going from 70% to 75% against a few dozen bots will make a difference.

Roughly, on eye, Diamond has >=90% APS against ~50% bots, so it's better to go from 90% to 95% against ~450 bots:) More accurate, Diamond has 5 bots with 70% APS and 28 bots with 90%, so, again, it's better to go from 90% to 95%:)

More accurate data: Diamond has 70-80 APS against 134 bots and 85-95 against 277 bots 90-95 APS against 168 bots

Sure, I'd love to go from 90% to 95% =), but that's incredibly difficult. It means cutting the enemy's score in half. And these are bots that you are already annihilating, and which are winning about zero rounds against you, so all the score increase has to come from relative bullet damage.

On the other hand, going from 70% to 75% means cutting the enemy's score by ~16%. And these bots are winning some rounds against you, which gives you more score to take from them as you improve.

I did not say that it's easy to more totally annihilate (completly totatlly annihilate:)) a weak bots. I say, that it's place where more points are hidden:)

Well, I weight the hidden points by how easy they are to obtain. =) For instance, you won't see me talking about the 55 points still "hidden" vs DrussGT...

But they are there!:) Ok, i offer stop this little offtop:)

(Maybe I should see how this fares before babbling about it, but anyway...)

How this works is: for each attribute, I have an initial weight, a final weight, and a final time (say, 20,000 ticks). The weight shifts linearly from initial to final value until final time, when it stays at final value. Tuning against my 500-bot, 4 season general rumble test bed, I increased my hit percentage from 23.21% to 23.90%. Not sure how much I could've gotten just re-tuning without the shifting, but testing just the initial weights or just the final weights came in around 23.1%. And the previous weights were genetically tuned in a similar fashion, so I think they were close to optimal.

How this came about is I was looking into a custom gun just for the first round of a battle, the way I've been using RetroGirl/Gun for the first few shots. I tried just tuning a KNN gun on 1-round battle data, and the result quickly outperformed my current settings, and the weights looked a lot different. After starting to implement it in Diamond and seeing promising (if incomplete) results, I thought of the more general solution of gradually shifting the weights. This too outperformed my current settings after very few generations. One thing that stands out is that my gun heat dimension starts at a very low weight and ends with a pretty high weight late in the match. This seems to make intuitive sense: as I have more data, it's better to favor firing waves more.

Now to cross my fingers that it produces in the rumble. =)

Neat concept! Now this has got me thinking about trying to associate KNN weightings with all sorts of things besides time... distance maybe?

What do you use for your test bed? RoboResearch?

I've been wanting to systematize my testing more so I can shake things out more thoroughly in an automated way before I throw it up on the Rumble server. I've got RoboResearch ready to go.. I just need to assemble a set of bots to test against.

Since he's using genetic algorithms to optimize it, I assume he's using his WaveSim rather than RoboResearch for speed reasons. Trying to use RoboResearch with genetic algorithms would more or less be insanity I think ;)

Yeah, I use RoboResearch for real testing. For some gun-only testing (like this) I use WaveSim, which is a tool I wrote to test just classification against raw battle data - so it doesn't work for testing bullet power or some other nitty gritty things, but for the things it does work for, it's pretty sweet (and fast).

For test beds, I use User:Voidious/BedMaker, which is a little script I wrote to select random bots from the rumble within certain parameters. But you'd need to get a rumble server API key from Darkcanuck first. I've been thinking maybe I should make a web-based version of that for others to use freely, but I wasn't sure if anyone was interested...

Currently hunting down which of a bunch of changes between 1.7.29 and 1.7.35 caused a decrease in performance. I swear I tested rolling back each one individually yesterday and none of them fixed my score. So now the other way: start with 1.7.29 and add each change individually. Once that's done I can see if this fading KNN stuff actually helps.

I've been pretty fearless with continuous refactoring and bug fixes throughout 1.7.x, and this is the price I pay for it. =) But overall I think it's been worth it, both in terms of code quality and performance.

Orrrrr I've been chasing ghosts... In my 2,000 battle benchmark (250 bots x 8 seasons), 1.7.29 came in 0.18 above 1.7.37 and a dev version of 1.7.35 got the exact same score as 1.7.37. Rolling back individual changes gave me anywhere from 0.14 to 0.22 below 1.7.29's score. Then I recompiled 1.7.29, checked the class files came out the same (ie, I had the right source), and reran 10 seasons... and came in 0.14 below 1.7.29.

Another good reason to focus on big improvements: anything else is too small / painful to reliably benchmark. =)

I'm really curious to see how "cast shadows over firing angles that already would have hit" works out. This is actually a feature I had implemented in RougeDC a long time ago, but I can't remember if I saw much benefit in the rumble or not.

Yeah, it seems like a cool feature, and it doesn't seem possible it would cost you points unless there is some other bug or quirk at play. Looks like I lost 0.1 APS, which could be margin of error, but I didn't really reproduce a score increase in tests either, so I think it's accurate. Another nice thing this would let me do is surf a wave until it completely passes without sacrificing anything. If I'm modeling the danger accurately, I'll pretty much be surfing the second wave as soon as I am now anyway, and even a tick or two sooner in a lot of cases where waves break along my front edge.

The one aspect that probably needs improving is how I apply shadows to the danger calculation. I ignore any firing angles that fall within a shadow, and I multiply the final danger by (1 - the percentage of firing angles that are shadowed). Of course this yielded like 0.8 APS with bullet shadows, so it must be a decent approach, but the right way to do it is obviously with integrals and all that. I think I need to change my kernel density formula to do it right, which is something I still need to figure out.

It's funny, I've thought about this idea before, but it always seemed like a hugely complex thing to try to deal with. This time I already had all the pieces in place to do it without much additional work: precise intersection, bullet shadows, plus a lot of newly refactored wave code that makes my life a lot easier. =)

Ahh, a pity it didn't seem to really help, though maybe it would more with the integral-style danger.

Makes sense. It was pretty natural for me to implement in RougeDC because it had both precise intersection and integral-style danger right from the start.

I'm also surprised this didn't work. With Goto surfing I could understand, as it doesn't make any accel/decel decisions once the wave starts breaking, but with True Surfing the decision to speed up/slow down is made as the wave is breaking over you. Are you creating the wave shadows in your simulations as well, or just using the ones which are actually created by the bot hitting the waves?

And you're making me nervous with your recent gains =)

I'm just creating shadows up to the present point in time, including the firing angles that will hit me next tick (before I can move again). I did consider that as an extension, I could shadow any angles that are totally unavoidable, starting several ticks earlier and simulating until the wave is gone, but I'm taking it one step at a time.

My best guess is that the crudeness of how I apply bullet shadows to my danger calculation is what's holding me back. My kernel density danger calculation just ignores any angles that fall within a shadow. But an angle near the edge of a shadow would otherwise cause me to go the other way, and that's probably worth doing since those angles are just guesses. With these shadows, I'm totally ignoring that firing angle. I'm going to try some integral style dangers and see where that takes me.

It's also worth noting that while it's true those angles really should be viewed as having zero danger, many of them are in common across the movement options, so they may frequently cancel each other out anyway. (Ie, what's the difference if I add zero or some other number to all the movement option dangers?)

I know you can't really say anything from 1 battle, but I don't ever recall seeing a score vs Shadow like this one. =) Yay!

My Anti-Surfer gun tries to predict the enemy's surfing on the nearest wave, then restrict its min/max firing angles to those still reachable assuming the enemy surfed the nearest wave as expected. For figuring out what's reachable, I hacked up my precise MEA calculation with a different starting state. But basically I screwed that all up and it hardly worked at all. (About time I started writing unit tests...)

Despite being broken, I had tested this gun against all my worst matchups and it helped against Shadow. So hopefully it will work better now.

Ok, looks like 1.7.9 finally fixes "the" major bug(s) I introduced with the movement refactoring in 1.7.5. I guess I won't know for sure if it was one of the 1.7.8 changes unless I let it fill out its battles, but it started off tanking pretty hard and the wrong GFs in the flattener (fixed in 1.7.9) is exactly the type of thing I thought would be the problem. (I switched to precise intersection in the flattener, since it was free with the new wave processing, but copied a couple lines from the gun that also used precise MEA GFs.) I'm really happy to have the wave interpolation and bullet shadow fixes too, though, and wonder if they're the reason 1.7.9 is undefeated (that or luck).

Regardless, I'm happy I can move on to the rest of the movement refactor. There's still quite a lot to do. :-) It's amazing I can refactor or rewrite every 1-2 years, and every time, the previous code seems so terrible...

While the RoboRumble results don't bear much evidence, I'm quite happy with the progress I've made against top bots recently (while maintaining or increasing APS!). I mainly focus on Shadow and DrussGT, but also against a test bed that includes 6 other strong bots. I swapped out Scarlet for Tomcat because at least twice I saw a score of 85-90 (adaptive bullet power gone haywire?).

    abc.Shadow 3.83c
    darkcanuck.Pris 0.92
    davidalves.Phoenix 1.02
    jk.mega.DrussGT 2.2.0
    kc.serpent.WaveSerpent 2.11
    lxx.Tomcat 3.17.169
    mue.Ascendant 1.2.27
    voidious.Dookious 1.573cNDS (non-data saving)

Results over 100 seasons (plus an extra 200 of 1.6.12 vs Shadow / DrussGT):

Diamond	Shadow	Pris	Phoenix	DrussGT	WaveSerpent	Tomcat	Ascendant	Dookious	Avg	Seasons
v1.6.4	50.20	51.43	56.41	45.74	52.06	58.94	56.05	51.58	52.80	100
v1.6.12	52.46	60.74	61.13	49.30	57.45	58.66	62.81	58.60	57.64	150

There are very strange results for Tomcat's last version, but his aps against Druss and Diamond is about 50% now

Congrats! Did you test it or just looking at the Rumble? 2-3 battles isn't very accurate... But I should update DrussGT and Tomcat to latest versions in any case.

FYI:

• 100 battles vs Tomcat 3.27: 54.15
• 300 battles vs DrussGT 2.2.2: 49.00

Edit: Oops, Tomcat's at 3.29? Doh!

I lost 7-8 places with the latest version, so congratulations are not appropriate in this situation:) No i did not test, but now there're 9 battles and APS is still about 50%:) And yes, i did my previous post to encourage you to get last version of Tomcat:) Good luck with PM crown hunting:)

FYI, take 2 - 100 battles vs Tomcat 3.29: 52.89. Very nice work!

Thank you, but for me is better -5 APS vs Diamond, but + 1 APS overall:)

So far, this hurts vs Phoenix and Dookious and helps vs Shadow, but that's a trade-off I'm willing to make at the moment. It brings me from ~49 to ~51 vs Shadow. As usual, nothing helps vs DrussGT... There's plenty more I can do to tune this, and I could even end up with multiple Anti-Surfer guns in my VG, but I've made enough changes that I just want a sanity release before going much further.