DiveProtection

When WallSmoothing it can be important to make sure you don't dive into simple fire at close ranges. This is dive-protection. I have it in all my WallSmoothing bots some of which are Aristocles, Tityus, Pugilist and CassiusClay. Though CC is the only one trying to do this with some finess. -- PEZ

Rumour has it that some of the WaveSurfer's don't need dive-protection. Pulsar and Jim comes to mind. Gives us some details dudes! -- PEZ

What I do in CassiusClay is to always evaluate surfing_danger for three options (forward/stop/reverse). I also give the options for forward and reverse a dive_danger which, when it kicks in, is always much higher than the surfing_danger values. This has the effect that when forward or reverse are dagerous from a diving point of view then the bot is left with the two other movement options. To avoid getting stuck in a corner with an enemy close I also have a case for when both forward and reverse diving_danger is flagged for. Then the bot chooses the option wit the lowest diving danger. (That, is, it doesn't even consider the stop option.) Sounds complicated? Then it's just me not succeeding in explaining it. It really is quite simple... Ask me and I'll try to explain it again. -- PEZ

---

Chat

Well, I've improved my surfing. But I still have a nasty problem with diving into the bot. Cost me 5 rounds against bot A. Ick. -- Alcatraz

Do you have any mechanism to avoid very short distances? If no, i recomend trying one... In SS i had no choice but implementing a if (dist < 150) then Run-Like-Hell-Away-From-Enemy. WaveSurfing becomes pretty useless in very short distances, actually i think that 200 distance is the least that you should try to stay... -- Axe

There is code to tell it not to turn forward into a bot, but it still tries to surf and that can screw it up. Guess I should tell it just to ignore the wave surfing until at a safe distance. -- Alcatraz

Thats what i do... -- Axe

Anyone following along the windles of my above explanation should understand that that's not what I do. Also. If i understand how SilverSurfer does it, that's not what it does either. But clearly Axe should know this better than I do. =) -- PEZ

Cyanide is supposed to do it your way, PEZ, but apparently doesn't. Though thinking about that, I realize that I only increase the dive danger if it is very near the walls, because that's when it's usually a problem. But it sometimes dives into the stationary bot when it is not right on the wall, but is instead coming out of a corner. -- Alcatraz

I think we might speak about two different things here. One is dive-protection and the other is close-battle-evasion. I think maybe Axe is suggesting that when you're very close then skip surfing and just run! I still don't do that. As long as there are waves to surf, CC will surf. On the matter of dive-protection; If the WallSmoothing will bring CC closer than 260 then CC will only allow very little smoothing before raising that danger-flag. And the diving_danger is set to amount_of_smoothing_asked_for * high_number. That way, if cornered, CC wikk still try to slip out using the widest escape door. -- PEZ

I've mentioned this to others, and possibly elsewhere on the wiki, but it can't hurt to mention it here. My form of dive protection in both Dookious and Komarious is very, very simple. My WaveSurfing algorithm in both is based on the one that PEZ uses in CassiusClay, evaluating forward and reverse (and in Dookious, stop) positions and taking the lowest danger one. Well, in that prediction, I make note of the distance I will be from the wave source when that wave hits, given my WallSmoothing. I then multiply the danger for that movement option by (currentDistance / predictedDistance) ^ somePower. In Dookious, I vary that power based on various things; in Komarious, it's 4. I kind of like it, it seems elegant and well rounded, it's also part of my general distancing, and I have certainly found it to be (or forcefully tweaked it to be? =)) quite effective. -- Voidious

What I do in Druss is check what the maximum danger bin my BotWidth? covers at that distance is. Thus, if the predicted position is too close, it will (hopefully) cover a more dangerous bin (among the many it covers), and avoid that position. I also set the 'default offset' to vary depending on distance. It's quite funny to watch it doing almost straight towards-away (against a wall) surfing against DoctorBob, with DoctorBob still getting a 0 hitrate. Against HawkOnFire it just does big orbits, until it gets pinned, and then it backs up. -- Skilgannon

• That does sound fun to watch :). You might try some other methods, though. I've always had more success with methods like "never approach the enemy at greater than 45 degrees" than distance-based methods. This is because 1) you generally want to keep your distance high, and the method you described may find it safer to dive in toward the enemy, but doesn't take into account that you're then closer for the NEXT shots the enemy will take, and 2) when in a corner, distance-based methods will tend to keep turning you back into that corner, since that's how to keep the furthest distance. -- Simonton

• The reason I like this method is because it doesn't special case. It is actually a more precise method, because it takes into account the entire BotWidth? at the predicted position. Another thing I was thinking of trying (but never did) was using the sum of the covered dangers at the predicted position, instead of the maximum. This would drive you backwards, because the closer you are the more bins you cover. Theoretically, using either of these methods, BinSmoothing isn't necessary. In fact, BinSmoothing is more of a bandaid used to cover a lack of these methods. -- Skilgannon

• I agree. I was never able to get that method to work as well as BinSmoothing, though. Best of luck! --Simonton

• Edit conflict...anyways, The way i implement it in Evader probably uses more code than needed...but: in the while loop in PEZ's iterative method for wallsmoothing, i just add && Math.abs(Math.abs(goalDirection)-Math.abs(absBearing))>=0.6 to the while condition... --Starrynte

• A couple things. First, you should look at the danger acros the entire BotWidth? in your surfing no matter what! It's all about that kind of precision. Second, my DiveProtection in Dookious doesn't special case, but it is based on distance. In predicting the forward / stop / reverse positions, it multiplies something like (currentDistance / predictedDistance) into the danger for that spot. This works as both distancing (getting closer is bad) and DiveProtection. -- Voidious
  • Wouldn't that give Dookious undue preference for the stop position in corners? -- Simonton
    • Yes, it would give him preference, but I don't think it's enough to get him into trouble getting cornered. If the enemy is along one wall, then stop-position and moving away from that wall should be the options you consider; if the enemy is exactly equidistant from each wall, the multiplier wouldn't be that intense for either of the directions. The original danger is still a large factor in that formula. My experiments with adding an anti-cornering factor in my surfing have all decreased performance, for what it's worth... -- Voidious
  • How accurate are you calculating the BotWidth?, Voidious? I'm just using a simple 50/distance/binWidth, but on the TrigChallenges page there is a very complicated method that actually does the exact calculation, using the 4 corner points. I know that pixel-perfect is important, but how pixel-perfect? =) Basically, how much could I expect using that method to help in the rumble? -- Skilgannon
    • Yes I know i'm not Voidious, but pixel perfect would be quite a bit less accurate then what most do. BotWidth?, really depends on the angle the enemy is at, and the distance. Your take it your using the bot width to generally reduce the number of bins you use the closer a bot is to you (like some bots do, such as CassiusClay IIRC). Generally speaking BotWidth? if its an angle is normally done as atan(40/distance). However if you wanna get an exact width, its something like 40 / max(abs(sin(AbsoluteRobotHeading?)),abs(cos(AbsoluteRobotHeading?))), then just divide that by the distance and atan it to get the angle. I wouldn't trust my memory, but thats just how I do it if I wanna be picky. --Chase-san
    • Like Chase said, there are some trig based ways to get more exact BotWidth? calculations, but I think the great majority of people just use 36 or 40. A couple pixels probably don't matter much (if at all), but not using BotWidth? at all does matter, I think. In my gun, I just use 36 as BotWidth? when waiting for my gun to be aimed before shooting and don't use BotWidth? in any of the stats. I used to use one of the trig-based, more exact methods in my surfing, but re-reading Dooki's source code now (since the full rewrite), I'm just using 36 there, too. PEZ always told me it probably didn't matter to get that exact - he's often right about such things =) -- Voidious