(Well, I guess it can be simplified as the X top bots in the general RR@H class...) -- PEZ
Added six bots to the list of wave surfers, and I'm sure it's still missing quite a few: Chomksy 1.5+, Dookious, Phoenix, PowerHouse, Stampede2, and Toad. That list has come in handy for me in trying to learn new things about WaveSurfing, so I figured it would be good to get it up to date. -- Voidious
It seems like there is a significant lack of nicely outlined and detailed info about WaveSurfing on the wiki in comparison to how many masterful WaveSurfers there are in the rumble. (There is a good amount of info, it's just spread out and not always distilled to the precise facts.) Topics like GuessFactorTargeting are very clearly taught by pages like Kawigi's tutorial, and I may try and provide similar details for WaveSurfing in the near future. -- Voidious
Is there a bot that uses a godawlfully simple implimentation of Wavesurfing, asto explain the most basic way of creating a wave surfer, as thats the kind of bot I think would be best for a tutorial, not something with all the dodads that someone new would give up trying to understand and instead just copy and paste. Basically WaveSurfing reduced to something that might kinda surf, if it would stop hitting into walls =P. -- Chase-san
The bottom line is that there's a lot of nitty gritty details to get right in WaveSurfing, and it is quite worth it to get all of those details right. The BasicSurfer bot in the WaveSurfing tutorial is probably the simplest to understand, although it may still seem a bit complex at first. Have you looked at that one yet? I studied CassiusClay quite a bit while I was learning, but there is a lot more to that tank's movement code. -- Voidious
Yeah, the fact is that wavesurfing is pretty complicated even in its most basic form. The idea is simple enough, but in practice there are a lot of details that just have to be right or it won't work. Basically when you set out to make a wavesurfer, you just have to accept that it will involve a lot of time and effort. -wcsv
Yah, I know what you mena no, I have been putting alot into making this surfer work, it uses CustomEvents to wavesurf, but it seems to miss every other bullet when it is far away from the enemy. Any suggestions? (other then try it a different way please) -- Chase-san
Correct EnergyDrop detection is very important. Besides monitoring the enemy's energy, you have to account for
Noo thats not what I meant, I already have that working just fine. Its the CustomEvents, I'll see what I can do to make it work right. -- Chase-san
As seen from Velsheas sour to spot 75, however I acquire as what is a good idea to Segment this movement by, everytime I think it should make it better, it makes it worse instead. Any suggestions (Wavesuffereing indeed)? -- Chase-san
Segment your surfing on acceleration, velocity, and distance. The rest is just details. =) --David Alves
Segment it on nothing until you get over 99% against WSC Bot A, then segment and get 98% against Bot B. BasicGFSurfer doesn't segment on anything and lacks lots of other important details, but it's in the top 50 just because it's bug free... -- Voidious
I would like to think mine are rather low in the bug area, but considering it gets about 40% vs B without segments (about 56 with), it still needs some work. -- Chase-san
I want some input on 'another' idea I have. Now I have many that are just plain FAIL, but this one might work. It has to do with a method such as WaveSerpents? that just records the last n gf's it gets hit at and dodges them, thats about where simularities end, instead of just dodging all of those, which though while the internal surfing mechanism takes decent care of this. Do a core kernel calculation on all the GF's and pick the top n for dodging, which would probably be dynamic, based on how many different patterns present themselves. Basically all this does is reduce the static in the gf dodging to more well defined danger do not enter area's. --Chase-san
It's not clear to me what "core kernel calculation on all the GF's" means, precisely, but it reminds me of how Chalk and Lukious use DynamicClustering / KernelDensity on some n most similar scans to calculate the dangers for each wave. This isn't anything "pattern" based, but using a distance function on various attributes of the scans for those situations. You could surely use movement patterns as the distance function, though. -- Voidious
Kernel Density on a list of GF's to find the most densely populated ones, and then use those as the gf's to dodge then all the bunches of them. --Chase-san
Sounds very much like what Chalk or Lukious does, though I haven't read WaveSerpent's code as much. The key difference is you'd be using pattern based stats to determine the n most similar scans, instead of a distancing function on just the attributes from a scan? Sounds like an interesting idea and probably worth the experience of trying it, but based on experience with PatternMatching in targeting, I wouldn't have high hopes of it outperforming DynamicClustering or VisitCountStats based surfing. -- Voidious
It doesn't use PatternMatching, it uses the standard way of obtaining the GF, and just dumps the number into a buffer. It is exactly like how Chalk and Lukious does it, except it uses it for the surfing, instead of the gun (though thats certainly a possiblity aswell and could be interesting). --Chase-san
Actually, both Chalk and Lukious use that kind of stat system for gun and surfing. -- Voidious
My head hurts, so just to clairify and make sure we're on the same page, it uses the standard method to gain the gf, it also stores the gf in sliced bins, not a log as in DC or PM, it however keeps a list of the n latest GFs such as WaveSerpent does, my idea is to use Kernel Density to reduce the number of GF's to avoid. --Chase-san
Ok - I still don't completely understand how it'd all work, but that's ok. But also just to clarify, Chalk and Lukious definitely use the same methodologies for both their gun and surf stats systems (DynamicClustering). -- Voidious
I know all about dynamic clustering, made a few chalk like systems aswell. --Chase-san
Now that I think about it, its kinda like Dynamic Clsutering without the Clustering, so to speak. --Chase-san
Rambling discussion snipped from Horizon/Questions on 7/20/2007...
Here's a suggestion, you seem fairly active and have a working wavesurfing so I thought I would give the suggestion to you: How about keeping an extra 2 bins that save the amount of times you have been hit by linear or circular targeting? I suggest this because the GF you get hit on is not constant for these targeting methods, instead depending on things like speed, heading, etc. You could weight these bins on top of the normal ones when deciding the safest place to move to. -- Skilgannon
That's an interesting idea, and it really could give you a head start against those methods when writing a WaveSurfing movement. However, considering how well some WaveSurfers do against LinearTargeting and CircularTargeting already (check out MovementChallenge2K6/Results or the WaveSurfing/DevilFISHChallenge), I personally wouldn't want to muddy up my code with a special case for them. Also, consider that just because LT or CT would have hit you in that spot doesn't mean they're using it - if you start thinking you're facing LT and you're really facing GuessFactor / VisitCountStats or PatternMatching, you could really be corrupting your stats.-- Voidious
What I'm thinking is using these bins *on top of* the current bins. You still take into account your normal stats, but if you get hit on the factor that LT or CT gives then you *also* increment that bin. When you are deciding where to move, you could do one of several things: average the values of the LT/CT bins and the bins they 'line up with' for this wave, add the values of the two bins together, or even (temporarily) replace the value of that bin with the LT/CT bin.
I know that some bots are getting amazing results in the MC, but seeing the number of rounds run in RR@H is only 35 an extra 3 or 4 shots avoided while building segmentation data can give you an extra few percent against these bots, which translates into an increase overall. -- Skilgannon
Yeah, I see how it would work - it's definitely an interesting and perfectly valid idea. I hope I don't come off as too much of an [Eeyore] when I say I don't think it's worth it. =)
Consider this, though: Dookious pre-loads one HeadOnTargeting hit into the surf stats before a match starts, so it actually is hard-coded to dodge HoT from the get go, yet it gets the same score (99.6%) in both the WaveSurfing/BarracudaChallenge and WaveSurfing/DevilFISHChallenge. Those are 35 round matches vs HeadOnTargeting and LinearTargeting, respectively. I kind of doubt any part of the statistics could improve those scores; it's more a matter of precise prediction, dive protection, distancing, and having zero bugs in your code.
Still, I say give it a go - you could well find it really is worth all the trouble, or it could lead you to some other great idea. I've tried countless ideas that didn't work out in the end, but I always learned something from them, and some of them are still kicking around my brain, waiting to be revisited and done correctly.
-- Voidious
Well for those of us who AREN'T able to get 100% bug free code ;-) Just kidding, though. I had one other idea, that was for an anti-ws gun. You use precise-prediction to figure out your enemies max escape angle, and then shoot at the lowest bin. What's your take on this? PS. Sorry about the page hijack, Aaron ;-)-- Skilgannon
It might work for few shots, but thats about it. As its not based on the enemies movements but instead on your robots own interal aiming device. If you really wanna make something like that, try only increasing the bins when one of your robots bullets actually hit and then interally having the enemy 'surf' the factor. But the differences in segmentation will quickly be made apparent, as I don't think this would work to well either. --Chase-san
My take on that is: it's a great idea, and one that I have explored myself quite a bit! =) Like Chase said, though, you need to record on real bullet hits, not normal wave hits. I have never had much too much success in making it into a killer AntiSurfer gun, though. Dookious actually does log "negative" hits for bullet hits into the stats of the AntiSurfer gun to try and simulate enemy surf stats a little, but it doesn't make a huge difference.
Using bullet hit stats to augment my AntiSurfer gun in an effective way is probably at the top of my list of good ideas that I want to revisit. The main problem with shooting at the "lowest" bin, in my mind, is that the enemy is going to dodge the other bullets in the air first, and then they will choose the lowest from the remaining bins, not the lowest overall, so I think you need to try and extrapolate their likely movement across all bullets in the air and the one you're about to fire. Also, of course, everyone segments on different attributes, so that's the other glaring issue. Lastly, precise prediction is super CPU intensive, so you will end up with a super SlowBot if you aren't efficient about what you need to calculate. (Sorry for hijacking, too, maybe we can move this discussion elsewhere...)
-- Voidious
I was thinking about trying something like that as a joke: making a gun that applies PrecisePrediction to the enemy, choosing which direction it is most likely to go and firing there. The joke would be that you could copy the segmentation and precise prediction from any surfer, be it BasicSurfer or Dookious, and it would be able to get a perfect score against that bot and only that bot.
Getting back to where the conversation started, I have a few ideas that I think can increase my surfing ability against linear/circular targeting. For example, a circular gun takes two factors into account when it fires: your speed and your turning amount at the time of firing. Therefore, wouldn't it make sense to choose the segment or cluster not based on what your current velocity and rotation is but what it was when the wave you are surfing was fired?
-- AaronR
Aaron, that may just be why things are screwing up in your WS. You do need to choose the segments at time of the firing of the wave. The easiest way to do this is by giving each wave a 1D array at its time of creation, as done in the GFTargetingBot.
About this anti-surfer gun, on second thoughts even if you segment it quite highly it will not update the stats as quickly as they are, so your stats would mis-align, and you would miss. So it's one and only use would be to knock down top bots' PL scores, I guess. <evil chuckle>
My last contribution for now (while I've got everybody's attention), and this one I'm fairly sure on. You guys are calculating the max escape angle using answer 1 on TrigChallenges, when you should be using answer 2. It is shorter to move on the chord than along the arc, so the MEA is bigger for answer 2. IMHO, this is why you are sometimes recording GFs of more than +-1.
-- Skilgannon
It's been brought up now and again, but I'm pretty sure the max escape angle is found by going exactly perpendicular to the absolute bearing to the enemy at fire time. Kawigi (long ago) and Simonton (more recently) have both used their math chops to actually prove this, IIRC. The rought calculation is Math.asin(8/bullet velocity), viewable by imagining a right triangle with the proportions of max bot speed and the bullet's velocity. Dookious and Phoenix even use precise prediction to calculate the resulting escape angle exactly, also taking walls and WallSmoothing into account. -- Voidious
Well, Math.asin(8/bullet velocity) gives a smaller result than 2*Math.asin(8/(2*bullet velocity)), so I think that the perpendicular movement is slightly longer. Another way of looking at it, the average heading in the ChordMovement? is perpendicular to the enemy, and it is perpendicular half-way to the destination - taking the shortest route to the point. I'm guessing that right now you get GFs greater than +-1 against bots that move in straight lines, Walls for example, because they take the ChordMovement? instead of PerpendicularMovement -- Skilgannon
***Perpendicular angle=tan(8/1000) =0.0080001706710 because 8 is the most the enemy can go in 1 tick and the enemy distance is 1000 (think about it as a triangle) ***Chord angle =2*asin(8/2000)=0.0080000213334 because the chord angle formula is 2*asin(chordlength/2(radius))); chordlength (most enemy can travel in 1 tick) is 8, and radius (distance) is 1000 ***Arc (orbit angle) =8/1000 =0.0080000000000 because the arclength angle formula is angle=arclength/radius aka distance; arclength is 8 (most the enemy can travel in 1 tick), radius is enemy distance.Therefore moving perpendicular to the enemy gives you the maximum escape angle. --Starrynte
I had at one time thought the same thing that if it was moving at a 45 degree towards the enemy at a certain speed it would end up outside the range by alot, but after some bits of math, I figure out that its all mathematical, and it takes all that into account. --Chase-san
Starrynte, you calculate MEA with bulletSpeed and enemyMaxVelocity?, not distance. Thus:
For the 'arc movement': theta = 8/11 = 0.7272
For the 'chord movement': theta = 2*asin(8/(2*11)) = 0.7443
For 'perpendicular at time of fire': theta = asin(8/11) = 0.8143
Hmm, I see why the 'perp at fire' is actually the biggest now, I hope this explanation makes people understand and not just accept =). If you move perp. at fire, you end up moving away at a bigger and bigger angle. This makes the bullet take longer to reach the enemy, increasing the time allowed to increase the MEA. Thus, moving away slightly increases the MEA more than moving sideways as fast as possible, because there is more time before the bullet hits. -- Skilgannon
Question for all those wavesurfers out there, if you could perfectly predicted what gf the enemy fired at could you dodge every shot ? if so what movement strategies would you use -- Gorded
Well it seems that even the best of bots cant dodge every bullet from Bot A even though we know where the bullets is . What i was getting at when i say what movement strategies was would A Shrapnel surfer or True Surfer fair better than the other ? -- Gorded
If you know _exactly_ what angle the enemy fires, maybe a normal surfer is not ideal. Normally a surfer will try to get the furthest possible from the predicted gf, making it easier to get trapped in extreme conditions. Maybe a goto surfer without a lot of smoothing would be the best? -- ABC
I would say that those rare cases that Bot A hits is when the surfer starts cornered, and takes a hit when trying to maneuver out. If your bot is at a reasonable distance and takes into account all the surfable waves, I don't think it is really possible to be hit by power 3 (and thus slow) GF 0 bullets unless there are bugs in your algorithm. Which I have learned is always possible, even at 2100+ scores =) -- Skilgannon
Depends on what you call a bug :). If you wallSmooth a lot and have a permissive "angle to enemy" threshold you can get into very tight spots. And then there are those small decisions like if the enemy's GF 0 calculation exactly in the same tick as yours... -- ABC
Well, I know DrussGT and Dookious have unlimited WallSmoothing and don't have an "angle to enemy" threshold. My WSC tests with DrussGT 1.0.5 he got 0 damage, 4 damage, 0 damage against Bot A over 500 rounds. IMO your danger calculation should be able to say whether a spot is a bad position or not, without having to add things like "angle to enemy" thresholds, but I guess that's just personal preference. And I'm not sure I understand your final remark...I thought the definition of GF 0 is where a HOT would shoot? So surely there is only 1 possible tick to base the data off of? -- Skilgannon
Against Bot A yes, but against other (moving) HOT bots there are some differences because some will not take the tick needed for gun turn into account. You're right that a perfect movement should predict bad positions, I know Shadow's movement is far from perfect, but everytime I try to make it "perfect" it ends up (very slightly) better against Bot A and worse against real opponents... ;) -- ABC
So you assume they fired at your position 2 ticks before you detected the energy drop? I don't remeber now what I decided to do in my movement, but I remember testing different tweaks, and noticing different HOT bots acting slightly different. And I usually keep the one that dodges the top guns best. ;) -- ABC
I've just started robocoding so I don't even know if this is the correct place to ask for this, but since this page is supose to be about wave surfing could someone help me to understand why none of wave surfing codes works? I've already read all the tutorials and discussions here, but every time I try to write my own code our improve the BasicSurfer's code I just fail and create a robot that sooner or latter gets disabled. If someone could help me please answer me because I need to share the source (otherwise it would be kind of imposible...) Thank you -- Navajo?
If you put the code up, we could tell you why it's getting disabled. The 2 main reasons are 1) throws an exception or 2) goes into an infinate loop. I actually suggest you try your hand at some of the simpler code before jumping straight into wavesurfing. Getting a GF gun working from scratch, or a PatternMatcher, would be a good start. Just wondering, what is your background in mathematics? Have you done trig? -- Skilgannon
![[Home]](/images/RoboWiki.png)