Implementing this successfully can be a nightmare.

Those are some 'gotchas' indeed! Particularly that middle one - it will take some integration between the smoothing and direction code to know to reverse but not turn until the robot velocity changes signs.

Lately, I've really been thinking about minimum-risk type movement. If you generate a bunch of movement options and then simulate them, it is easy to see whether they hit the wall. The trick is generating points which are likely to produce good movement options without having to generate millions of points.

Yeah, Diamond's Melee movement just precise predicts 5 ticks out and discards any movement option that hits a wall. It looks butter smooth and I love watching it.

But I once tried augmenting my existing 1v1 wall smoothing with this trick. In the end, the code was horribly ugly, I never hit a wall, and I didn't gain any points from it. Kind of killed my spirit to find points in improved wall smoothing. (And I removed it.)

And really, sometimes maximizing escape angle means slamming into the wall at full speed. If it means dodging a bullet it's still the right move.

Combat uses precise prediction to avoid walls in melee. It doesn't start turning until the very last tick.

It is iterative, which isn't a problem when combined with anti-gravity movement. Predicts 45 ticks ahead in 4 directions: forward/clockwise, forward/counter-clockwise, backward/clockwise and backward/counter-clockwise.

Predicts all 4 of them if starting to turn the current tick and again if wall avoidance is delayed to the next tick. If simulation shows delaying wall avoidance hits a wall then it starts turning, otherwise, keep with current movement.

It is still not calculating accurately when to stop turning and Combat zig-zags when moving parallel to walls. Looks ugly, but at least confuses opponents which relies heavily on heading in their targeting, like displacement vectors, PIF and segmenting data based on forward distance to walls.