Author Topic: Trajectory prediction and steering control  (Read 7190 times)

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
Trajectory prediction and steering control
« on: January 28, 2008, 11:17:30 AM »
I'm not a maths guy, I always approach problems with a brute trial and error strategy.

I was wondering if anyone knew a simple algorithm to predict the trajectory of a target bot. Also we could discuss here about steering control strategies. The *.refxpos *.refypos angle aiming doesn't consider the lateral speed, that's why when a bot aims a static target it can enter a silly orbit and never reach it.

Currently what I'm doing is add '*.veldx add' into the 360ยบ nine eyes turning. That means that, when the bot is moving laterally, it will oversteer to compensate. It doesn't do much when the target bot is fast and isn't moving away, but it seems to break the orbits.

Probably I'd should add too the *.veldn speed somewhere, to avoid overtaking the target.
Sometimes you win, and sometimes you lose...

Offline googlyeyesultra

  • Bot Destroyer
  • ***
  • Posts: 109
    • View Profile
Trajectory prediction and steering control
« Reply #1 on: January 28, 2008, 07:51:34 PM »
Obviously, the easiest way is to velocity match 'em.

Something like *.refveldx *.veldx sub .dx store tends to alleviate basic aiming problems, but it also prevents you from doing spiffy movement patterns.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Trajectory prediction and steering control
« Reply #2 on: January 29, 2008, 08:56:48 PM »
it would actually be *.refveldx .dx store, refvel always measures relative speed.  It's the method used in Animal Minimalis.

That should also handle issues of trying to shoot a shot to go where the bot will be instead of where it currently is.  The downside is that you have to actually match their vector.  Which means expending energy to alter your course.

If you get in to not wanting to modify your vector, but still fire a shot that will intersect another bot's project path, you get in to a huge mess of crap.  The problem is that you'd really need to know the distance to another bot, and the only way to determine that is to decode the values returned from the eyes.

Offline MacadamiaNuts

  • Bot Destroyer
  • ***
  • Posts: 273
    • View Profile
Trajectory prediction and steering control
« Reply #3 on: January 29, 2008, 09:50:28 PM »
What about the 'dist' command? Like *.refxpos *.refypos dist. But it still would get complex including the body size. Too hardcore for me anyway. Meh, 'bio' sims should be run with thick fluid physics I think. I can't help but feel something wrong about turning DB bots into some sort of intelligent torpedoes or nasty mechanical Battlebots...
Sometimes you win, and sometimes you lose...

Offline googlyeyesultra

  • Bot Destroyer
  • ***
  • Posts: 109
    • View Profile
Trajectory prediction and steering control
« Reply #4 on: January 30, 2008, 10:17:03 PM »
I fiddled around with something like this a while back, and I think Guardian does some of this too. Generally speaking, it only works if you face directly upwards all of the time so that you can just add refvelup times the number of expected cycles to *.refypos, and the same thing with refveldx. That gives you predicted coordinates, and after a few iterations of that, you should have a fairly accurate prediction of where to aim.

Offline rsucoop

  • Bot Destroyer
  • ***
  • Posts: 166
    • View Profile
Trajectory prediction and steering control
« Reply #5 on: January 30, 2008, 11:45:43 PM »
Quote from: Numsgil
it would actually be *.refveldx .dx store, refvel always measures relative speed.  It's the method used in Animal Minimalis.

That should also handle issues of trying to shoot a shot to go where the bot will be instead of where it currently is.  The downside is that you have to actually match their vector.  Which means expending energy to alter your course.

If you get in to not wanting to modify your vector, but still fire a shot that will intersect another bot's project path, you get in to a huge mess of crap.  The problem is that you'd really need to know the distance to another bot, and the only way to determine that is to decode the values returned from the eyes.

I dont think acurately timed shots based on distanced can be derived in this simulation, because decimals are not supported. In order to properly calculate a four dimensional projected path for the bot, you would have to support floating decimal points and imaginary numbers. The easier method is to just use the distance point formula you learn in geometry. sqr((x2 - x1) ^2 + (y2 - y1)^2), but again this will be unsuported in the new version and won't return acurate results in the current version.  One cool thing to do would to simply predict which direction the bot is headed and simply use trigonometry to calculate what angle you must shoot at. I'll work on some proofs for this and let everyone know the simple geometric method which may be better in comparision to the algebraic, since we are mostly dealing with spatial patterns to begin with: I.e. the eye returns being 50 = 2 bots, or pieces of arcs within the bot, its all geometric and have simple relations to any angle associated with them. Simply put,

I believe that a bot only needs to know the spatial distance between the bots, the radius of the bot, the amount of energy that can be expended, the max distance for a shot at that distance (important for stealthy kills), refvel and ones own vel, and the speed of the shots, and refaim. The distances and the speeds would all be relative to the radius of the bot, therefore no true distance need to be calculated, only the number of bots between and the ratio of the bots size to the shots change in distance in one second, something easily calculated by hand and hard coded for ease of use. The amount time necessary would be equal to the number of bots between them divided by the speed of the shot. The amount of energy necessary could come from either the time required, or the number of bots between. The projected future time between would be equal to the following reductions

(#botsbetween / .shotspeed) * (.refxpos .refypos angle ... to be continued I must rest

Offline googlyeyesultra

  • Bot Destroyer
  • ***
  • Posts: 109
    • View Profile
Trajectory prediction and steering control
« Reply #6 on: January 31, 2008, 06:33:08 PM »
I wonder what kind of targeting systems we could write. . .

Obviously, what most bots use now involves simply aiming at the target and firing. Then, there's linear aiming that tries to predict where the target will be when the shot arives assuming a constant speed/direction. Then, there's rotational aiming, which assumes a constant rate of rotation as well (check *.refaim over two cycles). Then, I suppose if we had arrays and trig we could set up pattern matching, which would record a number of previously encountered movement patterns, try to match the target to one of those patterns, and then use the next step in the pattern to decide the shot position.

All conjecture.

Offline rsucoop

  • Bot Destroyer
  • ***
  • Posts: 166
    • View Profile
Trajectory prediction and steering control
« Reply #7 on: January 31, 2008, 07:09:24 PM »
Quote from: googlyeyesultra
I wonder what kind of targeting systems we could write. . .

Obviously, what most bots use now involves simply aiming at the target and firing. Then, there's linear aiming that tries to predict where the target will be when the shot arives assuming a constant speed/direction. Then, there's rotational aiming, which assumes a constant rate of rotation as well (check *.refaim over two cycles). Then, I suppose if we had arrays and trig we could set up pattern matching, which would record a number of previously encountered movement patterns, try to match the target to one of those patterns, and then use the next step in the pattern to decide the shot position.

All conjecture.
I say use a shotgun affect, you would ahve a 1/3 chance of hiting your target with either shot and 100% of hitting the target. Problem is the amount of energy needed for such precision and distance. Three shots, one centered, one left of bot, one right of bot with a small spread about 1 botditance * refvel * refaim * shottime - (vel), assuming you are facing the saim directions, other wise it would be:  refvel * refaim * shottime - (vel * aim), obviously the spread is more like bird shot if the distance is expected to remain the same (I.e you are chasing after the bot), and the shot would b ecome more like buck shot when the incoming bot is expected to be closer, for more effective shots.
« Last Edit: January 31, 2008, 07:11:20 PM by rsucoop »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Trajectory prediction and steering control
« Reply #8 on: January 31, 2008, 10:39:48 PM »
This gets me thinking: currently shots have a very slight random angle added that give them a nozzle spray like effect.  This would be a great thing to open up to DNA control.  Have shots be able to shoot exactly accurate shots or spread out the control and get a vague field of shots.

Offline rsucoop

  • Bot Destroyer
  • ***
  • Posts: 166
    • View Profile
Trajectory prediction and steering control
« Reply #9 on: February 01, 2008, 07:59:31 AM »
Quote from: Numsgil
This gets me thinking: currently shots have a very slight random angle added that give them a nozzle spray like effect.  This would be a great thing to open up to DNA control.  Have shots be able to shoot exactly accurate shots or spread out the control and get a vague field of shots.

That would be awesome. Then the bots would niot be so similair to 007 stylzed hunting.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Trajectory prediction and steering control
« Reply #10 on: February 01, 2008, 11:50:14 AM »
The 20 degree random variation in shot trajectory is there for a reason.  That reason pre-dates my involvement.  It may be there to make it harder to do precisly what you are discussing I.e. super accurate targetting and shooting.  Or, it may be there simply to improve the chances of really dumb shooters actually hitting something.  Personally, I suspect the latter.

I have no fundemental objection to removing shot trajectory randomization or placing it under DNA control via a .shootspread or similar.  If someone wants to champion this, please file a well articulated suggestion in the suggestions forum.

If people have requests for specific operators in this area to improving targetting I.e. trig operators or similar, I would be happy to add them if they are 1) well designed and 2) garner sufficient consensus.  As above, please file such as well articulated suggestions in the suggestions forum.  Separating multipel suggestiosn into separate topics helps keep the discussion focused and lets me work on things independently and incrementally.  Thanks.
Many beers....