Talk:Wave Surfing Tutorial

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)

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)