# Simonton/DCResearch

Robo Home | Simonton | Changes | Preferences | AllPages

Challenge Results

• 0001: A VG array (with very poor choice mechanism) of 2 DC guns, one with cluster size 35 using all firing waves, the other with cluster size 1 using the last 20 firing waves. Both use LateralVelocity, RetreatingVelocity?, distance and forward & backward WallDistance. Those values are normalized to 0-1 (or -.5-.5). The distance function simply sums abs(scan1.value - scan2.value), unweighted. The guess factors are oriented toward the bot's accelleration direction, not lateral velocity. GF 0 is where the bot would end up if slamming the breaks, 1 is if he steps on the gas, -1 is if he travels full reverse, all calculated using lateral velocity and lateral accelleration-decelleration of 1-2. The kernel density calculation is "how many other firing angles does this one hit" given a tolerance of atan(20/firing_distance).
• 0006: Several bugfixes. Only the 35-cluster gun is used. Added time-since-orientation-change to the distance function.
• 0007: Only the 1-cluster gun is used, using the last 30 firing waves (and time-since from 0006).
• 0008: tick waves
• 0009: ? probably a buggy one
• 0010: 35 gun, time segment, increment/decrement dynamic weighting
• 0011: 2 gun, time segment, increment/decrement dynamic weighting
• 0012: 35 gun, double/half dynamic weighting
• 0013: 2 gun, full history, increment/decrement dynamic weighting
• 0014: 2 gun, full history, double/half dynamic weighting
• 0015: both guns (35/all & 1/30), non-dynamic (mostly 0001 with DC bug fixes of 0006 & 7). Oops! also squares weights
• 0016: both guns (35/all & 1/30), non-dynamic, virtual gun chooses by straight-up hit percentage. Oops! also squares weights
• 0017: just 35/all from 0016. Oops! also squares weights
• 0018: just 1/30 from 0016. Oops! also squares weights
• 0019: BUG! No lateral velocity segment 35 gun, increment/decrement, straight weights
• 0020; BUG! No lateral velocity segment 35 gun, increment/decrement, square weights
• 0021: BUG! No lateral velocity segment the Chalk version. 50 gun, not dynamic, tick waves, weightings: 5 lateralVelocity, 0 retreatingVelocity, 4 distance, 4 forwardWallDistance, 1 backwardWallDistance, 2 sinceDChange
• 0022: BUG! No lateral velocity segment the better Chalk version. Doesn't consider shooting out-of-bounds.
• 0023: BUG! No lateral velocity segment 0006 that doesn't shoot out-of-bounds
• 0024: BUG! No lateral velocity segment 0007 that doesn't shoot out-of-bounds
• 0025: BUG! No lateral velocity segment VG of 0023 & 0024
• 0026: BUG! No lateral velocity segment 35 gun, remove the distance-to-GF weirdness in the density calculation.
• 0027: BUG! No lateral velocity segment 35 gun, add Skilgannon's 1/distance idea to the density calculation.
• 0028: BUG! No lateral velocity segment 1 gun, trying a new anti-surfer trick.
• 0029: BUG! No lateral velocity segment 1 gun, trying to make the new anti-surfer trick much more subtle.
• 0030: BUG! No lateral velocity segment 35 gun, back to straight weights in density, tick waves
• 0031: BUG! No lateral velocity segment 35 gun, tick waves, increment/decrement dynamic weights (in clustering)
• 0032: 35 gun, tick waves, increment/decrement dynamic weights (in clustering)
• 0033: 35 gun, tick waves
• 0034: 35 gun, tick waves, 1.25/.8 dynamic weights
• 0035: Oops, I discoverd my density calculation has favored closer-range shots for a long time. Fixed, 35 gun, tick waves
• 0036: Oops, I discoverd my density calculation has favored closer-range shots for a long time. Fixed, 35 gun, tick waves, inc/dec
• 0037: Oops, I discoverd my density calculation has favored closer-range shots for a long time. Fixed, 1 gun
• 0038: Oops, I discoverd my density calculation has favored closer-range shots for a long time. Fixed, 1 gun, inc/dec
• 0039: Slow-learing, wave surfer special -- ok, i guess it's not so special! (0038 beats it)
• 0040: Dynamic weighting system 2*: 35/500, +/-
• 0041: Dynamic weighting system 2*: 35/500, 2/.5
• 0042: Dynamic weighting system 2*: 35/500, 1.25/.8
• 0044: 0037 w/ last time-since-orientation-change composed in. bug in the composition
• 0045: 0041 w/ last time-since-orientation-change composed in. bug in the composition
• 0046: 0041 w/ last time-since-orientation-change composed in.
• 0047: 0037 w/ last time-since-orientation-change composed in.
• 0048: 0041 w/ last time-since-orientation-change as another segment.
• 0049: Dynamic weighting system 2*: 35/1000, +/-
• 0050: Dynamic weighting system 2*: 35/500, +/-. Adds a "wall approach angle" segment.
• 0051: Dynamic weighting system 2*: 35/500, +/-. Adds wall approach angle segment that's only "activated" when approaching a wall. (We'll see how well the dynamic weighting controls for this in version 0050).
• 0052: Dynamic weighting system 2*: 35/500, +/-. Forward AND backward wall approach angle, activated only when near a wall.
• 0054: 0051 minus backward wall distance.
• 0055: Dynamic weighting system 2*: 35/500, 2/.5, unlimited iterations. Same segments as 0054.
• 0056: 0055, swapping out "time since orientation change" for "rolling average lateral velocity".
• 0057: Oops, these scores were with unweighted segments 0049 w/ unlimited iterations, run without the "forcing stop" bug.
• 0058: Oops, these scores were with unweighted segments 0051 w/ unlimited iterations, run without the "forcing stop" bug.
• 0059: Oops, these scores were with unweighted segments 0052 w/ unlimited iterations, run without the "forcing stop" bug.
• 0060: Oops, these scores were with unweighted segments 0055, run without the "forcing stop" bug (which wasn't happening much with 0055's runs, since Starrynte ran them for me. Thanks!).
• 0061: Oops, these scores were with unweighted segments Out of curiosity - remove the forward wall distance segment ...
• 0062: 0049 w/ unlimited iterations, run without the "forcing stop" bug.
• 0063: 0051 w/ unlimited iterations, run without the "forcing stop" bug.
• 0064: 0052 w/ unlimited iterations, run without the "forcing stop" bug.
• 0065: 0055, run without the "forcing stop" bug (which wasn't happening much with 0055's runs, since Starrynte ran them for me. Thanks!).
• 0066: no dynamic weighting. segments of 0065. break density ties using distance to center of cluster (David Alves's idea).
• 0067: no dynamic weighting. segments of 0065. density now includes compactness within the 1/2 bot width.
• 0068: with dynamic weighting. segments of 0065. density now includes compactness within the 1/2 bot width.
• 0069: no dynamic weighting. segments of 0065. seems like something broke.
• 0070: re-release of 0069 with a minor bugfix in the gf 1/-1 calculation, and the nicified tree (which is now released @ /MyTree?), which should remember a little more data than 0069's version.
• 0071: bugfix: the wall approach angle was being activated even when wall angle > 1. This also cause an occasional assertion error.
• 0072: filter scans that put the enemy out-of-bounds *before* adding them to the cluster, so that the cluster always reaches the desired size.

* Dynamic weighting system 2: take a large cluster as the first cut of the algorithm. This cluster uses unweighted distances. Then iteratively try pulling shooting-sized clusters out of that first cut using different weightings. Finally fire using the weighting that gave the densest firing angle. 35/500 indicates a shooting cluster size of 35 from a first cut of 500 scans. +/- means each iteration tries adding one to each weighting in turn, for each one that didn't create a denser cluster subtracting one & trying again. 2/.5 means multiply by 2, then .5 instead of incrementing/decrementing. "rand" means just try a bunch of random weightings.

More things to try:

• Give the surfer gun a dis-advantage in the VG choice (like Chalk) & see if it hurts the surfer scores compared to a straight-up VG choice (it should help the non-surfer).
• Add more attributes. Similar attributes could, perhaps, be encoded into one dimension, like `(5*time-since-dir-change + last-time-since-dir-change)/6`. Maybe try giving them more weight than regular attributes, since they have more state information. not a great idea
• Run other challenges. done.
• Have someone with a non-messed-up system test whether I'm skipping turns. Optimize for speed a bit.
• Get my system un-messed-up (any volunteers to offer advice?).
• Try using about a 1-2 turn rolling average in a VG & see if it helps or hurts.
• Try using a more continuous density function for the dynamic weighting choice.
• Try using total density for the dynamic weighting, instead of density-of-best-firing-angle.
• Try a dynamic weighting system like Voidious' in my gun. (At fire time calculate the density of clustering the first cut by each attribute only, assign weights accordingly). This would be a very interesting reference.
• Try piecing together GFs using several weighting schemes to make a cluster (more like layering segmentation, or CrowdTargeting).

How big of a log are you keeping and searching through in that first gun? "All firing waves" sounds like all of them through the whole match, but that wouldn't fly with my algorithm (similar to Chalk and DCBot). Other question - how can you get a TC score of -1 against a bot? =) -- Voidious

• First, notice that this is the fast learning challenge, so it's no problem to search that many. Right? I just got a brand new setup at home - dual core AMD64 6000+, dual channel DDR2 800 4-4-4-12. It's running linux. But when I "recalculate CPU constant" it comes back with like 83, so I don't know what's going on there. It takes 1 hour to run the fast learning challenge. So I'm not sure if it should be skipping or not? Second, the -1 score is what RoboResearch does when it doesn't have any data for a bot ... I had the wrong jar in there so WeeksOnEnd didn't exist. :) -- Simonton
• What distro, and do you have a SMP kernel? Also, you ARE running a 64 bit release, right? Your CPU constant shouldn't be nearly that high. On a 2.4GHz P4 I'm getting a constant of 33. -- Skilgannon
• I'm running Ubuntu 7.something. What's an SMP kernel? But yes, it's the 64 bit one. Come to think of it, though, I'm not sure if I'm running 64 or 32 bit java. I built a 64 bit vista machine for my mom, and 64 bit java ran slightly slower and took twice as much memory. I'm guessing the only difference they made was making all pointers 64 bits, so you could access huge amounts of memory. -- Simonton
I'm getting 6 on Vista 64-bit. =D --David Alves
• Yeah, but Vi\$ta doesn't have nice fancy desktop graphics. Search youtube for 'compiz' or 'beryl', you'll see what Linux is capable of =) -- Skilgannon
• Yeah, but Vi\$\$\$\$\$\$\$\$ta runs way slower than Linux no matter what kind of fancy graphics you have set up. =) And I get 10 on 32-bit XP and Vista. -- AaronR
Jeez calm down folks, I have Linux on my laptop, but I built my desktop for games so it's running Windows. I was showing off the 6 not the OS. =) --David Alves

It's kind of funny, Skilgannon and I are taking opposite sides on the issue by saying Vista sucks in different ways. =) -- AaronR

Hey Simonton, are you weighting all your waves equally? How about weighting ALL the waves by the inverse of how close they are to the current scan? Thus a 'distance' of 0 would have a weight of infinity. -- Skilgannon

• I think infinity for distance = 0 is excessive =), I'd lean towards dist 0 = 1 and a gaussian distribution, but I do think there's merit to the idea. Old Lukious uses distance between scans as a second element in the KernelDensity estimation, but I've ditched it in the new gun - bottom line seems to be that your 50 closest scans out of 20000 are all extremely close in distance to the current scan, so why bother. -- Voidious
• Yes, all waves are weighted equally. I saw that ... was it Chalk or the old Lukious? ... weighted the closest scans by their distance - seems like a good idea. I'll give it a try. (Maybe even sooner than it takes me to give forward/angular velocity pattern matching a try ...) -- Simonton

I see that your "Chalk version" had tick waves, but other than that, are you generally only using firing waves? I see 010 and 023 are your best non-surfer versions - neither of them use tick waves? I know DC is a lot different from VisitCountStats in many ways, but I can say for sure that in VCS there is a LOT to be gained from using tick waves. -- Voidious

• (Oops! I see 008 had good non-surf scores, too, and used tick waves.) -- Voidious
• Yeah, I'm not entirely sure why I've been working mostly with only firing waves. I guess I figured an improvement in one would mean an improvement in the other. And firing waves only runs faster. But now I think I'm getting serious about getting the dynamic weighting working, so I'd better get the tick waves going now, too (so I can tune the system correctly). -- Simonton

This morning I discovered a bug in a LOT of my results up there (as you can now see). But there's still interesting things to learn from them, so I'll leave them here. -- Simonton

I feel now as if I wasted alot of time. There isn't much farther I can push my NN. --Chase-san

I think everyone feels like they are wasting a lot of time with Robocode recently. Since we can be reasonably confident that there can be no further revolutions in the current version of Robocode, everyone is just sitting around and waiting for someone to actually say, "Lets start coding Robocode 2!". -- AaronR

That's not true for me. I have a whole page of things which wait to be implemented, some are common knowlege and others are unique. And the whole robocode community is currently quite active! If you want to do something new, try yourself at melee or team bots. Especially team battles are underdeveloped. You might be right, that there will not be any further revolutions in 1on1. But I think Robocode 2 would not really change much, propably mutations of GF or patternmatching guns and WaveSurfing movements would dominate the rankings again. And i highly disagree with your assumption that there can't be any further revolutions, time will tell. I think it's astonishing that there is no method which dominates all other. I like robocode as it is, because of its simplicity. --Krabb

• Actually I have talked to fnl on this and I think it will be tad harder to do then one would think. --Chase-san

If you are not #1, then you are not wasting time, you definitely can have goals within the current version. Namely, becoming #1. Incidentally, the basic rules and physics of Robocode have not been changed since I started (in 2003... or was it 2002?). During that time I've written maybe 50 bots. I don't consider any of that time wasted. If you really think you're wasting time, maybe you should consider a different hobby? --David Alves

Waste of time or not, I am enjoying myself. The problem, I think, is that this is too much fun, and pulls me away from more important things (currently most notable: reading the Bible, prayer, and spending time with the lonely). -- Simonton

Hey, I look forward to Robocode 2 as much as anyone, but I have to agree with the other responses. There is still plenty to explore in the current Robocode. It's been thought many times that bots could not evolve any further - and most of those times were before I even started, during which time they have continued to get even better. Even in (arguably) the most developed division, 1v1, we've raised the bar in the top 10 by 30-50 points (with rating drift) in the last couple years; NeuralNetwork methods, DynamicClustering, evolutions of VCS/GF, or something else entirely could very well take us even higher.

If the steep hill of 1v1 or Melee are still discouraging, maybe you can try Teams, or get involved with making the TwinDuel, HatTourney, or another fresh new style of play a reality. I think it's only natural to get sick of the traditional modes of play and to want something else - hence the MiniBotChallenge, the ImplementsDroidCompetition, the ExtendsRobotCompetition, the PassiveKillChallenge, the LongThinLeague, RobocodeDeathMatch, the TwinDuel, and probably others I'm unaware of. While Robocode 2 will surely provide a lot of fun new ground to cover, I say there is still plenty left unexplored in Robocode 1 in the meantime.

-- Voidious

SpinBotChallenge too, that one is good fun and good practice. --David Alves

Whoa, I just got back from classes and saw all of the responses. I am sorry that you are misinterpreting what my original post was trying to say. I agree that there can be further evolutions of DynamicClustering, VCS, NeuralNetworks, etc. I also agree that there are many things that can be done in Melee and Teams. (I have several melee bots and a TwinDuel team that I haven't released, in case anyone was wondering.) But, in my opinion, there will be no further major revolutions in the current version of Robocode. Revolution in the sense that PatternMatching was a revolution compared to LinearTargeting, and that GuessFactorTargeting was a revolution compared to PatternMatching, and that WaveSurfing was a revolution compared to random and SandboxFlattener movements. Because every Robocode bullet can be represented in terms of a single Wave and a GuessFactor, I suspect that it is possible to rigorously prove that some version of WaveSurfing is an optimal movement strategy. (Wouldn't that make a fun CS paper?) But, of course, there is still vast room for improvement outside of the basic techniques. I was just trying to point out how, because the base set of strategies (WaveSurfing, GuessFactorTargeting, and PatternMatching) have been worked out, there is no longer as much of a sense that the entirety of Robocode bot-building might change in an instant. If I have offended anyone, I apologize. -- AaronR

I agree that AdaptiveMovement is the best strategy for moving, and maybe we're already close to making the best possible AdaptiveMovement, who knows? But there might still be room for a revolution in the aiming world. But that's only in the 1v1 world, I think teams are almost totally unexplored; there's room for 3 or 4 "revolutions" there. So far most of the good teams don't really cooperate, they're just a bunch of good melee bots put in together with a few tweaks. --David Alves

So anyway, back on the original topic of this page... Those are some really impressive anti-surfer scores. Was there any one change that really made the difference against surfers? My DC gun can't hit them at all, but even my GF antisurfer gun doesn't score nearly as well as this monster. =) --David Alves

It seems to me like someone entering the DC race ought to share a bit about his gun before asking for others' secrets ... -- Simonton

Sure, there isn't much of interest to share though. I store 40000 "states", each of which has speed, acceleration, distance, etc. When I have more than 40000 I drop the oldest ones. I store states for both turns that I fired and turns that I did not fire. When it is time to fire I find the 50 states which most closely match the current state (minimizing sum of squares of error for each number in the state), making sure that if the enemy followed that same movement pattern it would end up on the field. Then I shoot at the densest cluster of destination points. I think it's a pretty standard implementation of a DCGun as described by ABC. I guess the main thing I'm curious about is not so much the exact line of code you used to beat surfers, but rather which area the improvement was in, e.g. weighting of the factors, trying non-traditional factors, or whatever. Or maybe there's a ton of different minor things that all contributed to your AS prowess rather than one "magic bullet"? --David Alves

Ha! Ok, ok, I guess I'll share about equally bland info, then. 0037, my best anti-surfer for 35 round battles (which are the ones that count) is just 0007 with bugfixes. I'm pretty sure you can figure out exactly how it works from the version notes above. I wouldn't mind swapping source with you. The part I'm interested in is the weighting, since I think that's where DC guns' potential really lies. -- Simonton

Well, it seems I got a dynamic weighting system that helps, but I still have a long way to go to be fighting with the best. Well ... actually ... maybe not as much as I think if I can get virtual guns working better. Hmm ... I am hitting non-surfurs on par with CassiousClay?, that's decent. And in this challenge my anti-surfer is the best. So that's not all bad. When I get back after this weekend maybe I should run some of the other challenges to see if I'm actually that close! -- Simonton

• Looks like I'm about 2% down across the board in the non-surfer category. But then, when I throw in a VG, it seems to drop my score by another 2%, so I'm definitely not there yet. -- Simonton

So I wrote a gun last night that gets 83 against the non-surfers in fast learning. But the same gun scores a pitiful *67* against surfers. I just can't seem to get this anti-surfer DC thing down. --David Alves

• And now it's up to 84 I see. Impressive. Care to share any secrets? -- Simonton

Do you account for firing vs non-firing waves at all? I'm not focusing on surfers at all, but I do account for that somewhat and I get decent surfer scores. How do you do vs Cigaret or FloodMini? If you have poor performance there, too, that's gotta be it. I'm way jealous of your non-surfer score, but couldn't care less about your surfer score. =) -- Voidious

I give non-firing waves an extra bit of "error" to make them less likely to match than firing waves (at least once I'm near capacity). I should probably test against Cigaret though, good idea. --David Alves

• Also, remember that you're aiming 2-3 ticks before firing time - do you make sure to count those as the firing waves instead of the waves from the same tick you actually fire? -- Voidious

I'm not exactly sure what you mean. When I'm matching the current state to the states in my huge list, I always count the current state as "firing", even if it is a few turns before I will actually fire.. --David Alves

Just as a point of interest (for myself) - 0043 used dynamic weights but chose the best from a pool of random weightings for each shot (0041-0043 evolve weights for each shot). I added an explanation of the dynamic weighting system I'm using above. It'll be nice when we get these KD-tree like structures going. -- Simonton

Almost done with those trees. --Chase-san

Hey Simonton, would you mind running more fast-learning seasons of 37 and 38? In my experience 15-20 seasons isn't enough seasons to be accurate (it's probably within 1 for the total) and I'm really curious what the average would be for those guns in the long run. I'd be happy to run it for you if you like. --David Alves

• I'll run a bunch of 0044 instead (if it turns out worse, I'll run some more of 37). -- Simonton
• Cool, thanks. =) --David Alves
• Ok ... let's make that 0047. -- Simonton

Added Phoenix DC12 to your "all random movers fast learning" table. =) --David Alves

• Oh ... wow ... thanks. I suddenly feel less discouraged! -- Simonton
• Uhhhh .... 270 seasons?? *gulp* That's ... probably reliable data. -- Simonton
• Indeed. =) I'm running DC6 (the strongest vs. random movers in TC2K7) against the full set of random movers today, we'll see how it does when I get home tonight. --David Alves
• My fingers are un-crossed ;) -- Simonton
• Looks like those fingers did the trick. Looking at the scores, it looks like your gun is about the same vs. most opponents, but much stronger against a few specific ones. Incidentally Cigaret is on that list twice. DC6 would be tied with your strongest version if the duplicate Cigaret was removed from the TC2K6 section. =P --David Alves

I'm pretty surprized at just how close the scores are when using velocity / attack angle (0053) when compared to advancing / lateral velocity (0051). With pattern matching it causes a lot more fluctuations. (At least with single-tick pattern matching) -- Simonton

Wow. If those numbers hold, that's a really strong gun. --David Alves

Indeed. about a 1/2 point away from taking over as the strongest gun in the random movement super-challenge. Too bad nobody has a perfect virtual gun system to lend me :). -- Simonton

Congrats with 0055, 90.03!!!!! --Starrynte

Very, very impressive, Simonton! Major congrats. Time for me to play catch up. =) However, about that "king of hitting random movers" title - seems like my latest Dookious FL results (1.23 and 1.543, which are not all that different) total 90.20, and that's with a performance hit from the VirtualGuns. ;) -- Voidious

Hmm, funny, by my calculations it's (92.02+92.61+83.68)/3=89.44. :P -- Simonton

• And no, there's no need to run a version without the virtual gun. :| -- Simonton
• I stand corrected - 90.03 is just the average of the averages, not the weighted averages (which is how I, personally, would calculate a TC score against 21 bots :P). The "real" TC score (though with Cigaret twice) is 90.83. Sweet. -- Voidious

That's sad. Now that the "forcing stop" bug has been removed from robocode & results are more reliable, I see that the dynamic weighting system does absolutely nothing except make my bot skip turns on a normal CPU constant. :( That's a letdown. I'm about to give up on dynamic weighting. Unless ... hmm ... let's give it one more shot with 0066. -- Simonton

Hmm. It looks like 0069 wasn't the best version, but I've posted comprehensive TC tests for it (here and on the TC pages). A couple notes: 1) DC seems to be a great way to learn surfers in the long haul (using every tick wave of 500 rounds), but the same technique is not so hot in 35 rounds. That's without weighting firing waves any different from the rest. 2) The surfers of the TC2K6 seem to be a bit easier to learn than those of the TC2K7.

In case you didn't look at this already, I was comparing Dookious to Dookiton, and the difference breakdown was pretty much what I expected: almost no difference against the weaker bots, but Dooki's gun is a bit stronger vs mid-top bots. The difference (Dookious minus Dookiton) across each quarter of the RoboRumble is: +62.4 vs the 25% lowest scores (toughest bots), +172.4 vs 25-50%, +57.5 vs 50-75%, +7.8 vs 75-100%. That's a very, very strong gun you have there, as I'm sure you already know! Taking it straight from the TC lab into the rumble, it's already either the #3 or #4 gun, and not too many points from #1. -- Voidious

Robo Home | Simonton | Changes | Preferences | AllPages