Hi, I have a problem with my algorythm for updating a turret object. This turret class is designed to go underneith a helicopter, or on top of a tank etc. The system i have designed updates the position of the turret every frame, including its rotation and elevation, however to simulate delayed reflexes and save on processing costs, i have decided to run the AI methods only once every n milliseconds. here is my code for this: //ai "thinks" 5 times per second static int first_sample = 1; static float timecount = 0; float reflex_time = 0.1; timecount += 1/fps; if(timecount>=reflex_time){ timecount=0; first_sample = 1; AI(fps); update_actuators(fps); }; update_position(fps); return 1; update_actuators() changes the speed that different parts are moving at, for exampel the rotation of the turret. AI() picks a target and so on the problem is this: when i cap the framerate at less than (1/reflex_time) the inrements of rotation etc. between frames is too large and the turret never gets near to aiming at an object, so it never gets as far as pulling the trigger. this means that if a client is seriously lagging then a turret on top of their tank will not be able to function on auto pilot. time based animation is performed by passing the framerate to each character, which then passes it to each turret on that character. this system is used all over my engine and changing it would require a massive overhaul. How can i modify my algorythm so that the turret does not jump from 1 radian to -1 radians and never line up with the object? thanks

On each itteration, check the system clock to determine how much time has elapsed. Then, apply the rotation rate to that time delta to determine how far it can/has turned.

You can also update the angle as frequently as you want (so the animation is smooth), and simulate slow reflexes by only updating the target position (or desired angle, or whatever) every n milliseconds. I think that would give good results.

Excellent point.

Thanks, two good ideas. ill implement them and post bask with the results

If you would know something about rulesystems you'd know the first factor is a shock.

After that, when surprise wanned, its just a matter of light speed lag. (Which in you case would be minimal.)

Don't forget that turrets have some maximal speed for rotation. (It could look weird if you'd forget it) Majority of current tanks are using assisted targeting, so rotation of turret isn't the problem. (and they could hit at 1.2 km quite reliably.) For crew it's just matter of selecting something on a computer screen, or line it with a targeting optics.

As your problem of don't lining up with a target, it's problem of your engine, or you created the algorithm too primitive. I'd say you would find the solution faster than you can read it on this forum.

If your frame rate is so low and you are rotating the actuators based on some max speed per second * frame rate you can find that the actuators go 'past' the desired location. So you are already setting a minimum speed but it pays to calculate the maximum delta and clamp to that high mark as well. Just to be clear here is a niave implementation.

I think to have the best AI, you need to make your AI think in constant time, so I agree with where you are going with your approach.

My own developments seem to support that premise. My AI and in fact the stepping of the entire game world occurs at a fixed rate of 15 Hz. I essentially have removed framerate from being a factor. The appearance of smoothness is achieved by interpolation between the two most recent positional states for all visible objects.

If someone has a crappy (must be really crappy) system that runs the game below 15 FPS, the AI and the world STILL get updated at their required 15 Hz. That right there gets you the predictable AI behavior you need for aiming.

Anyone with an engineering backgound and knowledge of discrete-time systems can appreciate the benefits and ease of a constant rate for system calculations. My AI aiming is based on the concept of proportional-derivative control and it really makes for some convincing AI with minimal computation. You can easily dial in coefficients for overshoot, to control how sluggish your AI responds, and how accurate it is.

A P-D control style approach for horizontal aiming is basically:

TurnForce = A * AngleToTarget + B * (PreviousAngleToTarget - AngleToTarget)

or possibly:

TurnForce += A * AngleToTarget + B * (PreviousAngleToTarget - AngleToTarget)

A and B can be determined using trial and error.

Quote: Original post by InnocuousFox
On each itteration, check the system clock to determine how much time has elapsed. Then, apply the rotation rate to that time delta to determine how far it can/has turned.

Thats really bad advice, because different entities in the world would be running at different time frames. The entire frame should be running at the same time step each logical frame.