Jump to content
• Advertisement

# delayed reflexes for AI tank drivers

This topic is 4119 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

## Recommended Posts

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

#### Share this post

##### Share on other sites
Advertisement
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.

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
Thanks, two good ideas. ill implement them and post bask with the results

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
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.

void Update(float frameDelta){  // this works great by approaching the target  // but if the frameDelta is large, then it will skip past desired angle in a step and never line up with the object  if (currentAngle < desiredAngle)   currentAngle += speed * frameDelta;  // clampage - we wont go past with this code  if (currentAngle > desiredAngle)  {   currentAngle = desiredAngle;   Fire();  }}

#### Share this post

##### Share on other sites
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.

#### Share this post

##### Share on other sites
Quote:
 Original post by InnocuousFoxOn 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.

#### Share this post

##### Share on other sites

• Advertisement

### Announcements

• Advertisement
• ### Popular Tags

• Advertisement

• 11
• 20
• 12
• 10
• 38
• ### Forum Statistics

• Total Topics
631401
• Total Posts
2999863
×

## Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!