Predicting time required for manuvers

Started by
3 comments, last by NotAYakk 17 years, 10 months ago
In programming my AI I want a ship to be able to turn around and apply thrust to come to a stop at a certain point. I want it to act just like a human controlled ship so I can't really cheat and position the ship myself - I'd like it to use the same accelerate and turn functions as the player input uses. How do I predict the amount of time needed for the ship to turn around since the framerate is inconsistent? I have a turn rate per second that is multiplied by timeSinceLastFrame, the same with acceleration. I can predict the number of frames needed to turn around but I need timeSinceLastFrame to keep the animation speed consistent and when I introduce that factor into the equasion, the ship could undershoot or overshoot its target. How do other people solve this?
Advertisement
You already have what you need; the trick is just arranging the parts.

To start simple, take the case of a ship that is sitting in one spot and needs to turn 180 degrees. You already have a turning rate which is (say) degrees/second. You also know the target rotation distance: 180 degrees. You want an answer in seconds. A little dimensional analysis gives us: seconds = degrees / (degrees/second) In other words, take the distance you want to rotate, and divide it by the ship's turning rate to get a turning time in seconds.


You can then do a similar thing to calculate deceleration time. Suppose you're going 100 metres/second and your engine thrust can give you 5 m/s^2 of acceleration. Just divide change_in_speed / acceleration_rate to find out how long it will take to reach the target speed. In our case we want to come to a stop, so the time needed is 100/5 = 20 seconds.

Now, this is all fairly simplistic and assumes constant acceleration and simple free-body physics (no atmospheric drag, etc.). If you want more complicated effects, like engines that take time to reach full power, and so on, you'll need to brush up on your calculus a bit to derive the proper formulae. That's really not necessary though for most cases.


To make your AI a bit more robust and seem more "natural," a common trick is to inflate the time estimates a little bit - say maybe 10%. Then you "waste" the extra time by not doing things optimally (such as taking an extra second between spinning around and beginning to apply thrust for deceleration). The effect is subtle but really helps make your AI seem like an actual person/alien/whatever doing the flying instead of a calculator.


Hope that sheds some light on things for you [smile]

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Original post by TheMoebius
How do I predict the amount of time needed for the ship to turn around since the framerate is inconsistent?


what does framerate have to do with your game physics?
!OH NOES!
you forgot to make your physics Independant of the screen framerate didn't you?

...someone feeling more generous might help you fix this...
Original post by TheMoebius
How do I predict the amount of time needed for the ship to turn around since the framerate is inconsistent?


what does framerate have to do with your game physics?
!OH NOES!
you forgot to make your physics Independant of the screen framerate didn't you?

...someone feeling more generous might help you fix this...
If you don't want to do calculus, one relatively simple way to answer such problems is "do a search of the problem space".

Have the computer simulate the future multiple times, and have it use those simulations to determine what the actions of the computer should be right now.

Depending on the complexity of your AI behaviour model, this can be a low-dimensional problem, or a high-dimensional problem.

Low-dimensional problems (with only a few free parameters) can be searched using relatively simple algorithms. Single-dimensional problems can be binary searched, for example, and you can rapidly get a result that is very close to the ideal one.

Example: Given that your rotation engines take time to warm up (during which time their thrust goes up), and your rotation rate takes time, the amount of time you should "accellerate" your rotatation and "decellerate" your rotation works out to be a pretty nasty bit of calculus. But if you can reduce it down to a single number (how much time before you switch the direction of accelleration) -- you can just test an exponentially growing amount of spin time until you braket the solution with "too much spin" and "too little spin", then do a binary search in the middle until you reach "pretty close to the right amount of spin".

...

High-dimensional problems require fancier searches. (for example: make random plans, evaluate them, pick the best plans, make more random plans based off the previous iteration's best plans, repeat until you run out of time -- at which point, pick one of your best plans and execute it. As the plan is executed, continue picking random plans based off of your new situation and see if you can do better. Sort of like real-time chess. ;) )

This topic is closed to new replies.

Advertisement