**0**

# Targetting Cues

Started by Nov 23 2012 04:09 PM

,
3 replies to this topic

###
#1
Members - Reputation: **334**

Posted 23 November 2012 - 04:09 PM

So my game's a third person space shooter. This causes a wierd problem with targeting as the player ship may not be pointing at the center of the screen at all times, which means crosshairs function kind of strangely and basically make it difficult to determine where exactly you're shooting (see attached screenshot for an earlier incarnation of this game that used a crosshair).

So instead I came up with a new system where there is no crosshair (see second screenshot), but each enemy ship has a targeting pattern that changes colors from red to green if they're in your sights. This targeting is fairly sophisticated in that it's not necessarily green if you're pointing directly at the enemy, but actually factors in the amount that you need to lead your shots to hit the enemy if they maintain their current velocity. However, when I set a few friends in front of this version and they seemed confused as to what the coloring meant. Once I explained it they seemed to get a little better at managing it.

While I could easily explain it away in some kind of tutorial part at the beginning of the game I wanted to get an opinion from the community about third person targetting and whether it's even desirable or if I should just do away with all targeting aids and err to the side of realism.

Since some weapons are fairly inaccurate or have tracking features, this complicates the situation even further.

So instead I came up with a new system where there is no crosshair (see second screenshot), but each enemy ship has a targeting pattern that changes colors from red to green if they're in your sights. This targeting is fairly sophisticated in that it's not necessarily green if you're pointing directly at the enemy, but actually factors in the amount that you need to lead your shots to hit the enemy if they maintain their current velocity. However, when I set a few friends in front of this version and they seemed confused as to what the coloring meant. Once I explained it they seemed to get a little better at managing it.

While I could easily explain it away in some kind of tutorial part at the beginning of the game I wanted to get an opinion from the community about third person targetting and whether it's even desirable or if I should just do away with all targeting aids and err to the side of realism.

Since some weapons are fairly inaccurate or have tracking features, this complicates the situation even further.

###
#2
Members - Reputation: **287**

Posted 23 November 2012 - 10:34 PM

It seems like you've pretty much solved the math for this and you're more or less curious about the design. What I've used in the past is 2 cross hairs along with auto aim. The first cross hair represents where the player is aiming, the second represents where an enemy closest to that crosshair is, and when the player moves the cross hair close enough the first one jumps onto the second to show a lock on, and all rounds fired go towards where the player's cross hair is. This started out as a solution for the z point of where the player was aiming in our 3rd person shooter and eventually became an aim assist that the player could use. It took some of the challenge of shooting out of the game, but it meant that the challenge of the game was getting into cover, and then selectively taking out the targets by the danger priority each target presented. Quite impressive that you've solved the mathematics of this given you have player velocity and direction and enemy velocity and direction to account for. For accuracy we scaled the cross hairs to represent the accuracy of the selected weapon and for some weapons that accuracy decreased as they fired so thee player would end up firing short bursts to keep the shots focused in the reticule. We also used different textures for the cross hairs of different weapons. Another thing to keep in mind with a third person shooter is, that you need to solve that z-axis based on what target you think the player is aiming at for the shots from the player's avatar to hit the target instead of go around it. Which is important when the player needs to fire deflection shots (aiming ahead of the enemy) to score a hit. It's not an issue in first person shooters however. We had a bit in the game where the player fired a turret in first person against fast moving flying enemies, it didn't have a lock on, but it was a bit of a pain to get the deflection shots working intuitively since we needed to use the projected Z position of the target the player was aiming at to solve the z in the equation of what direction the bullet should go.

I say Code! You say Build! Code! Build! Code! Build! Can I get a woop-woop? Woop! Woop!

###
#3
Crossbones+ - Reputation: **1416**

Posted 25 November 2012 - 06:31 AM

About 10% of men are red-green colorblind to some degree, so those colors are pretty much the worst possible ones to indicate correct aim.

Change of color in general is slower and harder to see than a change in sight geometry. I'd suggest you make the sight change shape, add a box around it or something as the indicator.

Change of color in general is slower and harder to see than a change in sight geometry. I'd suggest you make the sight change shape, add a box around it or something as the indicator.

###
#4
Members - Reputation: **334**

Posted 25 November 2012 - 04:33 PM

Stroppy - good call... Yellow/red or blue/red seem to be good choices from that standpoint.

Interesting post Kyall. Please post a screenshot if you have one, kind of curious how you handle the auto-adjustment of the Z-axis. When targeting enemies at different distances would the targeting "pop" around adjusting for different projection lengths?

The mathematics were a little fun. It's just a pretty simple system of vector equations to derive the formula you need, but solving it requires a few tricks. I already use the same formula so that the enemies can lead their shots too (otherwise they're hopelessly inaccurate).

Basically you start with:

finalPosition = initialPosition + velocity * time

What you want is to solve for any point at which a fired bullet will cross into the enemy's radius.

||(bulletInitial + bulletVelocity * time) - (enemyInitial + enemyVelocity * time)|| = enemyRadius

I'll let you figure out the rest of the proof for yourself, but basically you break each vector into it's component parts and solve for time with the quadratic formula. There should either be two real solutions or two complex solutions for time when you solve it. If there are two complex solutions it means the bullet will miss, if the solutions are real the bullet will hit.

The equation of course becomes trickier when you need to account for non-linear bullets like rockets (these have an accelleration component in my game).

Decided to post the code of the "IsTargeted" function so those who don't have the mathematics skills can use it, enjoy!

Interesting post Kyall. Please post a screenshot if you have one, kind of curious how you handle the auto-adjustment of the Z-axis. When targeting enemies at different distances would the targeting "pop" around adjusting for different projection lengths?

The mathematics were a little fun. It's just a pretty simple system of vector equations to derive the formula you need, but solving it requires a few tricks. I already use the same formula so that the enemies can lead their shots too (otherwise they're hopelessly inaccurate).

Basically you start with:

finalPosition = initialPosition + velocity * time

What you want is to solve for any point at which a fired bullet will cross into the enemy's radius.

||(bulletInitial + bulletVelocity * time) - (enemyInitial + enemyVelocity * time)|| = enemyRadius

I'll let you figure out the rest of the proof for yourself, but basically you break each vector into it's component parts and solve for time with the quadratic formula. There should either be two real solutions or two complex solutions for time when you solve it. If there are two complex solutions it means the bullet will miss, if the solutions are real the bullet will hit.

The equation of course becomes trickier when you need to account for non-linear bullets like rockets (these have an accelleration component in my game).

Decided to post the code of the "IsTargeted" function so those who don't have the mathematics skills can use it, enjoy!

private static bool IsTargeted(Weaponry.Weapon weapon, PhysicsObject target, Player p) { var shootPosition = weapon.GetShootPosition(); var shootSpeed = weapon.GetShootVelocity().Length(); // Quadratic formula to calculate time for leading the shot Vector3 shootVelocity = shootSpeed * p.Look; var speedSquared = Square(shootSpeed); var velocityDelta = shootVelocity - target.Velocity; var positionDelta = shootPosition - target.Position; var a = Square(velocityDelta.X) + Square(velocityDelta.Y) + Square(velocityDelta.Z); var b = 2f * (shootPosition.X * shootVelocity.X - shootPosition.X * target.Velocity.X - target.Position.X * shootVelocity.X + target.Position.X * target.Velocity.X + shootPosition.Y * shootVelocity.Y - shootPosition.Y * target.Velocity.Y - target.Position.Y * shootVelocity.Y + target.Position.Y * target.Velocity.Y + shootPosition.Z * shootVelocity.Z - shootPosition.Z * target.Velocity.Z - target.Position.Z * shootVelocity.Z + target.Position.Z * target.Velocity.Z); var c = Square(positionDelta.X) + Square(positionDelta.Y) + Square(positionDelta.Z) - Square(target.Radius) - Square(weapon.BulletRadius); // Evaluate the quadratic formula, with a little modification var inner = Square(b) - 4 * a * c; var latterPart = (float)Math.Sqrt(inner); return inner >= 0 && ((-b + latterPart) / a > 0 || (-b - latterPart) / a > 0); }

**Edited by jsuffolk, 25 November 2012 - 06:37 PM.**