Reminds me of what I was working on

Jump to navigation Jump to search

Reminds me of what I was working on

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.

Rednaxela (talk)05:40, 14 June 2021

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...

Skilgannon (talk)12:27, 14 June 2021

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.

--Kev (talk)01:44, 15 June 2021

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:Path Surfing/Reminds me of what I was working on/reply (3).

Sounds awesome!

I was always tuning bots against DoctorBob to get 100%, and a few ramming bots to get 80%+, however I always find it challenging and tricky. If random path & RHEA based approach can get better than that, I will regard it as the next innovation since 2005 ;)

Xor (talk)16:46, 5 August 2021

I would say it is interesting, not necessarily awesome given my bots can't break the top 50 (yet). The main disadvantages right now are the fact that making random but limited population of movement paths means that you don't necessarily ever move using the maximum escape angle, which means it might perform worse vs some statistical targeting just because statistically the movement range is smaller. It does get good results against known targeting methods like circular, hot etc which is comparable to the top traditional surfers.

(As an an aside, the main problem with my bots is predicting the enemy shots, rather than moving around them. This is the same for most surfers I assume, but surfers at least consider lower probabilities. In my method I predict multiple potential bullet positions but don't consider wave danger at other points. I might try changing this as one way to improve it as long as I can find a fast way to evaluate that without breaking the current idea which is to move around the bullets. You can't dodge a full wave so it might just push the bot backwards due to the non-limited move direction)

Wolfman (talk)20:42, 5 August 2021