Reminds me of what I was working on
The highlighted comment was created in this revision.
As-described this reminds me of what I was working towards back in 2012 or so for a new movement engine that I never quite completed. I'm not quite sure how far BeepBoop is going with it, but what had started on was intended to have extremely comprehensive coverage of all possible non-redundant paths a bot could be maneuvering. Seeing this page here got me looking at my old backup files. I thought I remember talking about it some on the wiki at least in passing but can't find it. The main thing I remember finding tricky was the optimization required to make it not be absurdly slow, while not compromising on the range of movement options available. Maybe I'll pick that back up again some time.
I remember this, you were discussing using a lookup table but running into file size limits.
I still want to go back to my idea of surfing future waves, so you don't just control how you react, but also proactively you control what the enemy sees at fire-time. This way you could dynamically 'discover' motion patterns like stop-n-go, which force even linear guns to shoot HOT. I'm sure many other classes of guns have similar weaknesses which we can't see...
BeepBoop uses something like a lookup table (actually a kd tree) for finding paths, but a pretty small one. Given a current velocity, desired distance to travel, and desired ending velocity it outputs a "path" (sequence of 1s/-1s/0s corresponding to calling setAhead(100/-100/0)) that approximately meets those criteria. When its surfing, BeepBoop sets the desired distance to one that will take it to a low-danger area of the wave (kind of like GoTo surfing) and sets the desired end velocity to 8, -8, or 0 randomly, which means it will try out a variety of ways of getting to that area. It then precisely predicts the looked-up paths along with the standard going forward/backward/stopping paths true surfers use.