Difference between revisions of "Talk:Wave Surfing Tutorial"

From Robowiki
Jump to navigation Jump to search
(→‎Surfing Multiple Waves: # waves in the air)
 
(6 intermediate revisions by 4 users not shown)
Line 64: Line 64:
  
 
Most direct data I have from surfing one to surfing two waves (in a correct way). There was more then a wave surfing change here, but disabling second wave is pretty simple and you could run some tests on version 60 or so. Need to look inside checkWaveRisk and comment out the line where it adds the second wave danger. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 20:46, 7 September 2011 (UTC)
 
Most direct data I have from surfing one to surfing two waves (in a correct way). There was more then a wave surfing change here, but disabling second wave is pretty simple and you could run some tests on version 60 or so. Need to look inside checkWaveRisk and comment out the line where it adds the second wave danger. &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 20:46, 7 September 2011 (UTC)
 +
 +
:One of the problems I have with surfing more than just 1 wave is that my drive doesn't just decide which direction is safer and move in that direction; rather it it decides exactly what factor it wants to move to for the wave and heads there.  To surf more than one wave in that manner, I would have to overlay danger from the second wave onto the danger for the first wave, which is a rather complex transformation.  So instead, I am planning on trying a hybrid approach.  My drive compares the best factor in both surf directions when deciding on where to go; if they are both within a certain margin, it then looks at average danger in each direction as a tie breaker, and if those are close to, it chooses randomly (as currently configured, tie breaking happens about 15% of the time, with averages being used about 10% of the time and random selection 5%).  My hybrid approach will be to change this behavior to take the second wave into account in the tie breaking.  So instead of choosing by best-factor with tie breakers of average then random, it will choose by best-factor-first-wave followed by tie breakers best-factor-second-wave, average-first-wave, average-second-wave, random. -- [[User:Skotty|Skotty]] 03:18, 9 September 2011 (UTC)
 +
 +
: Like you, I'm using Goto-surfing. You basically generate a whole bunch of points, then see which point is the safest and go to it, right? How I surf the second wave is for each point that I'm evaluating I see what my position/angle/whatever is as I reach the point for the first wave, then generate a whole bunch of new points for the second wave and with the starting conditions from that first wave surf the second wave. I then add the danger from the second wave to the first wave, weighted according to how long it will take for them to hit me. Obviously the amount of required computing increases exponentially for each additional wave you surf, which is why I only surf 2 waves max. But using this technique it essentially 'branches' out all the possibilities of where you will be in ''n'' waves time and how you got there. --[[User:Skilgannon|Skilgannon]] 06:53, 9 September 2011 (UTC)
 +
 +
Generally second-wave surfing is implemented by running the full precise prediction again from *each* endpoint evaluated in the first wave. The danger added the each first wave endpoint is the minimum danger that can be reached in the second wave based on that precise precision. I wouldn't consider it very complicated at all, though the cpu impact is certainly non-negligible. --[[User:Rednaxela|Rednaxela]] 04:36, 9 September 2011 (UTC)
 +
 +
: Exactly, because at the end of the day, you are testing just how dangerous it is to move in a certain way. Looking down the road at more then one wave just tells you just how good/bad moving in that direction will position you at a later date (assuming you continued to surf, which most surfers do). &#8212; <span style="font-family: monospace">[[User:Chase-san|Chase]]-[[User_talk:Chase-san|san]]</span> 04:59, 9 September 2011 (UTC)
 +
 +
: I will have to think about this some more.  I think I understand what Rednaxela is saying now, and I think that has more potential than what I was trying to do (which in testing was a wash -- no improvement).  However, with a distancing of about 400 (which is what I use and around what most people are doing I think), there is usually very little time when a second wave is fired to change your mind about where to go for the first wave.  I'm still not convinced it is worth the effort or processing expense, but I will try to experiment with it when I have the time. -- [[User:Skotty|Skotty]] 17:28, 9 September 2011 (UTC)
 +
 +
: Well, bullet power 2 is pretty common, which is a speed 14 bullet every 14 ticks = waves ~200 distance apart. So I'd actually expect 2+ waves in the air at all times if you keep a distance of ~400. --[[User:Voidious|Voidious]] 17:50, 9 September 2011 (UTC)

Latest revision as of 18:50, 9 September 2011

From old wiki

Nice tutorial. I'm feeling inspired to go through Cyanide to make sure all of its small details (and potential bugs) match this. One thing though, I thought that the iterative wall smoothing came from Jam. At least I first saw it in one of the Raikos. Slightly OT and maybe not for this page, but what's your take on keeping track of enemy waves fired every tick, as opposed to just the actual bullets. -- Alcatraz

I'll look into the source of the iterative WallSmoothing, thanks for pointing that out. Dookious does keep track of EnemyWaves from every tick, but non-firing waves are tracked in separate stat buffers and only on visits (like with a gun) and never with onHitByBullets. Those stat arrays are used as a flattener when the enemy's hit % is high enough, and (in rare circumstances) he'll surf those waves if there are no others in the air. Frankly, though, I've found that doing any kind of flattening is really dangerous for the majority of RR opponents - even against really good guns, Dookious sometimes does better to just surf normally. (I do roll all surf stats pretty quickly, though.) -- Voidious

Voidious, thanks, great reading!

As you said, maybe WaveSuffering makes you a wiser man, but with the limited time on my hand this maybe is the help i needed to get my WaveSuffering bot Wolwa above the current 60% score against bot B of the WaveSurfingChallenge (it scores 87% against bot A). I will certainly look at this bot with new energy. --Loki

  • yesterday evening i finished reading this tutorial and came up to the text "This bot, as presented above, will score about 90% vs WaveSurfingChallengeBotA and 60% vs WaveSurfingChallengeBotB". So i was a bit dissapointed as those numbers look very familiar. The possitive side is that my first wavesurfer isn't that bad (i always compared it to al those >95% scoring bots). Another possitive point is that i have found some details to improve and there a quite a number of suggestions in this tutorial to try out. Hopefully this will soon result in my first wavesurfing entry. to be continued. --Loki
    • The lack of any kind of distancing or dive protection is very relevant against BotA, and the lack of any segmentation is very relevent against BotB. Komarious uses a more polished form of this mini-surfing, and you can see her MC2K6 scores are much better than that.
    • Also, the prediction checks the danger of the point you would be at when the EnemyWave intercepts you, but it might help a lot to subtract another bot_half_width, and maybe another bullet_velocity, (from the left side) to be checking the last point you could get to right before even possibly being hit. (Dookious does that.) Maybe I should actually change the tutorial to use that as the calculation, but I wanted to keep it simple... -- Voidious
  • a question: i don't understand the factor "2" in the below code. Can anyone give some additional explanation? thanks --Loki
            // this one is nice ;). if predictedVelocity and moveDir have
            // different signs you want to breack down
            // otherwise you want to accelerate (look at the factor "2")
            predictedVelocity += 
                (predictedVelocity * moveDir < 0 ? 2*moveDir : moveDir);
    • acceleration: speed + 1, deceleration: speed - 2 -- GrubbmGait
    • thanks, i was convinced deceleration was at the same rate as acceleration. I must remember to regularly read the GamePhysics page to refresh my memory. --Loki

@Loki: Glad to hear it, best of luck! =) -- Voidious


All the calculations are done under onScannedRobot method. Is there any diffrence to put it under run().? --sso

It shouldn't make any difference - the order that things are executed is given precisely on the GamePhysics page, and the only thing that happens between onScannedRobot() and run() is that the battle field draws. It's just a matter of preference. -- Voidious

Why do you use the two arraylists, does it add to the front of the array when you add it, if not I don't see how that could work. (i'm gussing since you did it that way that it does, but couldn't you be more exact then just from two rounds ago?) -- Chase-san

The two ArrayList's that start wtih _surf just store the direction and absolute bearings from every tick, because you need those from 2 ticks ago when you detect an EnergyDrop. Yes, it adds to the front of them - the first argument is the position in the ArrayList if you do it like that. What do you mean "two rounds ago"? Do you mean two frames ago? The data from two frames ago is the last data that the enemy saw before firing the shot, so that's why you use it. It's all about figuring where he's aiming based on what he is seeing. -- Voidious

Surfing Multiple Waves

Does anyone have any data on the performance of surfing one wave versus two waves in any of the robots? I still haven't made a serious attempt at surfing more than 1 wave at a time, instead focusing on other areas. I'm wondering how much there is to gain by perfecting surfing multiple waves rather than just the next wave to hit. -- Skotty 18:04, 7 September 2011 (UTC)

I don't have data on hand, but I can attest to it being non-negligible. I have constants in Dookious and Diamond specifying how many waves to surf, if you want to hack on it and run tests. They surf 2 waves, and I've tested 3 in the rumble and (as expected) it had non-measurable impact.

Particularly, imagine when the nearest wave is 1-2 ticks from impact. Your movement choices at that point can only change your position on first-wave intercept by a few pixels*, likely for little to no change in danger. But 1-2 ticks of foresight can greatly impact your options on the second wave. Eg, if you're at full speed and you wait an extra 2 ticks to slam on the brakes and move to full speed in the other direction, that's 32 pixels of escape area you lose access to on the second wave. (*I know, they're not pixels... =P) --Voidious 18:56, 7 September 2011 (UTC)


MC2K6 Fast (35 round)

Version WSCBotA WSCBotB WSCBotC WSC APMC CassiusClay FloodHT Shadow ADAPT Total Seasons Comment
MC43 99.54 73.20 84.00 85.58 29.06 15.90 59.90 12.82 29.54 48.06 20.0
MC44 99.95 90.23 89.03 93.07 30.52 27.64 57.26 21.67 35.52 53.04 20.0

MC2K7 Fast (35 rounds)

Version HOF SPL GRB Sub1 WAY (Sub2) GR3 RKM Sub3 ASC CC CHK Sub4 Total Seasons Comment
MC43 99.72 86.29 85.40 90.47 65.23 75.32 78.50 76.91 30.56 36.94 36.38 34.63 66.81 20.0
MC44 99.78 87.12 90.95 92.62 66.53 71.77 82.01 76.89 34.52 41.12 38.62 38.09 68.53 20.0

Most direct data I have from surfing one to surfing two waves (in a correct way). There was more then a wave surfing change here, but disabling second wave is pretty simple and you could run some tests on version 60 or so. Need to look inside checkWaveRisk and comment out the line where it adds the second wave danger. — Chase-san 20:46, 7 September 2011 (UTC)

One of the problems I have with surfing more than just 1 wave is that my drive doesn't just decide which direction is safer and move in that direction; rather it it decides exactly what factor it wants to move to for the wave and heads there. To surf more than one wave in that manner, I would have to overlay danger from the second wave onto the danger for the first wave, which is a rather complex transformation. So instead, I am planning on trying a hybrid approach. My drive compares the best factor in both surf directions when deciding on where to go; if they are both within a certain margin, it then looks at average danger in each direction as a tie breaker, and if those are close to, it chooses randomly (as currently configured, tie breaking happens about 15% of the time, with averages being used about 10% of the time and random selection 5%). My hybrid approach will be to change this behavior to take the second wave into account in the tie breaking. So instead of choosing by best-factor with tie breakers of average then random, it will choose by best-factor-first-wave followed by tie breakers best-factor-second-wave, average-first-wave, average-second-wave, random. -- Skotty 03:18, 9 September 2011 (UTC)
Like you, I'm using Goto-surfing. You basically generate a whole bunch of points, then see which point is the safest and go to it, right? How I surf the second wave is for each point that I'm evaluating I see what my position/angle/whatever is as I reach the point for the first wave, then generate a whole bunch of new points for the second wave and with the starting conditions from that first wave surf the second wave. I then add the danger from the second wave to the first wave, weighted according to how long it will take for them to hit me. Obviously the amount of required computing increases exponentially for each additional wave you surf, which is why I only surf 2 waves max. But using this technique it essentially 'branches' out all the possibilities of where you will be in n waves time and how you got there. --Skilgannon 06:53, 9 September 2011 (UTC)

Generally second-wave surfing is implemented by running the full precise prediction again from *each* endpoint evaluated in the first wave. The danger added the each first wave endpoint is the minimum danger that can be reached in the second wave based on that precise precision. I wouldn't consider it very complicated at all, though the cpu impact is certainly non-negligible. --Rednaxela 04:36, 9 September 2011 (UTC)

Exactly, because at the end of the day, you are testing just how dangerous it is to move in a certain way. Looking down the road at more then one wave just tells you just how good/bad moving in that direction will position you at a later date (assuming you continued to surf, which most surfers do). — Chase-san 04:59, 9 September 2011 (UTC)
I will have to think about this some more. I think I understand what Rednaxela is saying now, and I think that has more potential than what I was trying to do (which in testing was a wash -- no improvement). However, with a distancing of about 400 (which is what I use and around what most people are doing I think), there is usually very little time when a second wave is fired to change your mind about where to go for the first wave. I'm still not convinced it is worth the effort or processing expense, but I will try to experiment with it when I have the time. -- Skotty 17:28, 9 September 2011 (UTC)
Well, bullet power 2 is pretty common, which is a speed 14 bullet every 14 ticks = waves ~200 distance apart. So I'd actually expect 2+ waves in the air at all times if you keep a distance of ~400. --Voidious 17:50, 9 September 2011 (UTC)