3 replies to this topic

[Jon Alma]

I'm well advanced on a 3D RTS game where the player's view is pretty up close and personal (the number of units and the game mechanics means that satellite views of the world are not actually needed or a huge advantage and as such the viewpoint can be much closer to the unit currently being controlled).

Now this is all very nice as it allows me to show off the detailed models and other eye candy, but it does present one problem ... many of the units have turrets that track a target (in 3 dimensions as most of the units are aircraft). This works fine when the target is just selected or some distance away as the turret rotates round until the target is in its sights. However, once this point is reached the turrets have a tendency to twitch or judder. Basically even at high check rates the point being targeted changes every update and the turret adjusts to the new target position. If the target is changing position rapidly then the turret starts tracking again but if the target position is relatively small then the twitching starts and can be very noticeable (there is a certain amount of twitching when units are targeting other units but this is most noticeable for turrets probably because they can be orientated out of parallel with the direction of movement meaning that changes in the relative target position are more frequent).

So far I have done two basic things that should help,

• Movement is proportional to the frame rate to avoid uneven movement (and this works fine with normal turret rotation)
• When close to being on target the turret will rotate only what is needed and not the total rotation possible in the time since the last update (there shouldn't be any rotation overshooting and need to adjust back ... although I am currently rechecking the code once again).

However even with this the judder is still there and I have a feeling that I need to 'dampen' the rotation when nearly on target. Here I can see three possible solutions,

• Acceleration and deceleration on the turret movement so as it starts moving again the adjustments are smaller than when in full rotation ... however I have a feeling this will still result in visible twitching
• Using a firing cone - while the target is still in this cone the turret does not move (as it is effectively still on target). It would reduce the small twitches but would this result in less frequent but larger adjustments (slower bigger twitches)?
• Delayed movement after firing so they turret does not move for a certain time and then checks if adjustments are needed. I suspect this is similar to using a firing cone (the target is assumed to still be on target)

Any advice in this area would be most welcome (either in helping me find the cause behind this problem or the solution best placed to add additional smoothing).

Thanks,

Jon.

[Ashaman73]

Here are two ideas:
1. Separate the visualization from the game logic. That is, the game tracks the target all the time, but the visual representation of the turret does it in a smooth way. Often you have a smoothing algorithm which is based on acceleration and a max velocity (GPG .. mentioned such a algorithm, though I don't remember which book it was).
2. Use two cones, an inner and outer cone. Start the movement once the target is out of the outer cone. Stop the targeting once the target is inside the inner cone. This way you have the difference between inner and outer cone as buffer of none movement.

[Jon Alma]

1. Separate the visualization from the game logic. That is, the game tracks the target all the time, but the visual representation of the turret does it in a smooth way. Often you have a smoothing algorithm which is based on acceleration and a max velocity (GPG .. mentioned such a algorithm, though I don't remember which book it was).

They are already separated, but in thinking about this it may be part of the problem. To explain, the unit movement logic is really quite complex (as the units can never stop moving so need to avoid other objects rather than detect their paths are blocked and then halt and correct their movement ... this flocking movement combined with the A.I., weapon firing and projectile collision detection adds up to a lot of checking even when optimised with space partitioning, etc) and as a result it actually runs more slowly than the display update (which is fine for general movement, but may be causing the twitching). I'll adjust this and ensure that the in focus unit is updated every frame ... or better and see what difference this makes ... and then generalise to other in view units if needed.

2. Use two cones, an inner and outer cone. Start the movement once the target is out of the outer cone. Stop the targeting once the target is inside the inner cone. This way you have the difference between inner and outer cone as buffer of none movement.

Again thanks for the advice ... will try as this will clearly help control the on/off movement.

Thanks,

Jon.

[Jon Alma]

To follow up on this,

• Reworking the game logic update made some improvement
• However the introduction of two cones to handle rotation really stabilised the rotation and removed the twitching (after playing about with the size of the cones for a bit to get the right balance).

Many thanks again.

Jon.