Talk:Watermelon/Development

Hooray!

Glad to see you consider your bot worthy of version tracking now! It's fun to watch people's progress. --Simonton 16:11, 25 September 2008 (UTC)

WaveSurfing adaptation

When my wavesurfing was segmented only on velocity, it adapted almost immediately to velocity-based targeting, specifically linear targeting. It only had to get hit perhaps once for each velocity segment before it "got the picture". Now that I've added all these segments, it's adapting *much* more slowly (and getting hit a lot more in the process!). Any thoughts as to what could cause this sort of behavior? Are my segments too narrow? -- Synapse 00:54, 14 June 2009 (UTC)

I have kinda the same problem. GravityWave is segmented on distance currently, since adding even one more segment drops his score by 50%. I just thought it was because my computer is old and my code really basic. I know this didn't help you much, but still :P --Jacob Litewski 01:01, 14 June 2009 (UTC)

It's not just that I increased the segmentation - I have a mechanism for choosing the most useful segmentation based on how "spiky" it is that ensures that I never have to deal with an empty segment. My trouble is that it's not choosing the clearly best segmentation - velocity. It chooses things like time since last reversed or lateral walldistance even though the enemy bot isn't firing based on those variables. Even if I remove the other segmentations so we're down to just velocity and nothing, the velocity segmentation isn't as specific with this framework as it was without the automatic segmentation. -- Synapse 02:16, 14 June 2009 (UTC)

In an effort to get the best of both worlds, Dookious sums dozens of buffers in its surf stats, from unsegmented to extremely segmented. (DrussGT sums even more, and uses randomized buffers each match, iirc.) Dynamic Clustering also inherently adapts to how much data you have to work with. --Voidious 03:31, 14 June 2009 (UTC)

Actually, iirc, DrussGT's "randomized" buffers are the same for every match, and were "randomly" hand chosen and hard coded into the code. --Rednaxela 04:49, 14 June 2009 (UTC)

Correct =) I randomly generated a whole bunch of buffers, and then weeded out duplicates and put in some which I though were missing. --Skilgannon 07:41, 14 June 2009 (UTC)

At the moment I suspect there's a bug in my multi-axis segmentation indexing. Each segment stores its data in an array of arrays, with the first index being a single number representing the particular slice of the segmentation, and the second number being the bins. I think the function to produce an index for the first level of the array is bugged. -- Synapse 07:02, 14 June 2009 (UTC)

What I have found is the best method is to keep several segments 'layered' on top of each other. When the time comes to gather all the stats together for surfing you just add all the current bins together. Thus, if the highest segmented bins don't have hits, the lower segmented ones will still provide information. Also, it provides a good medium between 'deep learning' and a fast rolling set of stats. --Skilgannon 07:41, 14 June 2009 (UTC)

Do you roll your stats? If you do, how fast? I don't think using fancy technique on Wave Surfing stats isn't good ideas. If you are dodging the LT/CT/PM, it may do. If you are dodging GF or AS, since the vast majority of those gun still use simple VCS, that why current top-6 bot are VCS wave surfer. The DC, however, can't dodge the best GF gun well, as seen by #6-#11, which all use DC for wave surfing. » Nat | Talk » 08:17, 14 June 2009 (UTC)

I have a fast rolling average on the surfing side, something like depth of 10, weight of 1, since the surfing gets so little data compared to the gun. -- Synapse 08:06, 15 June 2009 (UTC)

What!?! That's too high! I think 3 is too high for the segmented (quote from DrussGT page =)) » Nat | Talk » 11:43, 15 June 2009 (UTC)

Mirrorbots and a means by which they can be defeated

How does one defeat a mirrorbot? Is there some segmentation I can use that would reveal its parasitic movement strategy? -- Synapse 08:13, 17 June 2009 (UTC)

Anti-Mirror Targeting (not sure if this is migrated). And, no, I don't think there is some segment that can reveal its parasitic movement strategy. But... haven't try yet, but if you use your surfing stats for gun and aim at the least... Perhaps that will work. » Nat | Talk » 11:13, 17 June 2009 (UTC)

I don't really know anything about this, but one way to tell might be to look at your and the other robot's X and Y / heading changes, and if they are very similar it may be a mirrorbot.--CrazyBassoonist 12:36, 17 June 2009 (UTC)

Well there is a segment: "Your own planned movement", of course most bots don't plan their movement in a way that truly guarantees future location. Really, so-called "Anti-Mirror Targeting" (here's the old wiki page) isn't just targeting, it's a coordinated targeting/movement system. To see how effective it is, take a look at this page, and look at the 4 lowest scores there and see how different they are from any others. As you can see, Axe really loves anti-mirror ;P --Rednaxela 12:39, 17 June 2009 (UTC)

I think Duelist series by David Alves all have a truly guarantees future location. If you detect mirror, I think changing to his technique is rather good. He just pick a randomly position (and perpendicular) and set a random number to the timer. Each tick he decrease the timer. When it reach zero it just picks new location. Sound easy, right? I think go-to surfer guarantees it too, just not as accurate as Duelist. I think technique, IIRCm is call DavePantedAntiMirrorTargeting. » Nat | Talk » 12:56, 17 June 2009 (UTC)

A goto surfer doesn't really guarantee it. All goto surfers to my knowledge have provisions to start reacting instantly should extenuing circumstances arise. What the Duelist series alone does isn't sufficent either Nat, because while it guarantees future position for some "x" ticks in the future, "x" may well be less than bullet travel time, thus insufficent to help with anti-mirror. That same issue also affects goto surfing too. What you need to do, is have a way to plan your movement, for however however many ticks bullettraveltime is. You could do this with Dualist-style-movement for instance, if you simply simulate your own movement up to the point you picked, and pick a new point, and buffer these waypoints. You could do this for a simple orbital random movement too, very easily, by simply buffering a series of movement instructions for future ticks. You could even do this with surfing, IF you predict the enemy's future firing (i.e. know when and how powerful the enemy mirror bot will fire in the future), and it's no easier to do it with "go-to" than "true". Either way you have to buffer future movement instructions, and assume you can accurately predict enemy firing timing. Essentially, the trick to an anti-mirror system, is that your bot has to start "living in the future" in it's mind, when it's detected that the enemy is mirroring. --Rednaxela 13:23, 17 June 2009 (UTC)