# How to implement auto-aiming / auto-targeting

We all know how auto-aiming or auto-targeting works in games.

Now, I need to find how to implement it in my game.

In fact I should implement it in UDK and I would be glad if anyone gave me more specific explanation for UDK. But conceptual explanation is also enjoyable and I'll implement it myself in my way.

• Do you just want perfect auto-targeting? do you have to take into account physics and other effects? Also do you need different levels of skill/accuracy? Oct 30 '12 at 22:07
• What do you mean ? Oct 31 '12 at 18:14
• i was assuming you'd want to shoot after aiming, am i correct? Oct 31 '12 at 19:30
• In fact, I writing a mobile game ( shooting by touching) and I want to correct player shoot fault in some extend. Oct 31 '12 at 19:47
• Check my specific answer to my real problem Oct 31 '12 at 20:17

As far as my knowledge goes, auto aiming is simply looking at a specific coordinates on screen, that are tied to players viewpoint, and bullets travel relatively from the center of the screen (crosshair) anyways.

For multiplayer FPS games, like Quake and CS, the model has bone structure beneath, and all the aimbots are working by specifying which of them to track.

Same for you, in your camera script or player controller or something (don't know how UDK handles all the stuff), in order to autoaim through walls and everything (the most brutal way), you'd simply:

• scan around to find objects you want to be auto-targetable. It could be as simple as foreach loop through all the game objects of particular type or simply, all game objects.
• find the object that is the closest to the player, lock to it. The locking part could be done with a simple Camera lookAt call. And, if it's tied to player, you're done. If it's not, you have to transform the camera pivot coordinates to player.

That's basicly it, you can then add an extra flavor, like: to select only (loop through) only visible objects; to select only objects within certain distance; to apply auto-targeting only when players raw aim is in particular range from the target (on screen, you'd need some math here).

That's the raw concept, unformatted.

I've never actually implemented that so I'll remain quite vague. But what you have to do is test the auto-aim of your favorite game and decompose it in a few steps, then the implementation can be very straightforward.

E.g., in pseudo-code, for reticule magnetism, that's what you could have in an update function:

If the crosshair is close to an enemy
And if the pad's right stick is close to its center position
Then start auto-aim to enemy

If auto-aim is started
If the pad's right stick is still close to its center position
Move view point towards the enemy
Else
Stop auto-aim


Then test it a lot, have other people test it, see if matches your reference game. If it doesn't, tweak your algorithm, rinse, and repeat. After a few iterations you should be satisfied with the results.

• This isn't an answer at all. It also has questionable advice about intentionally trying to have different autoaim behavior for differentiation, which will just be annoying to players who have to relearn the controller for every game because they're not using a standard approach). Aug 30 '12 at 20:31
• Ha, if that's questionable, I'll remove that bit. I'm not sure there's a standard approach for autoaim, it all depends on the game genre, pace... But maybe my phrasing isn't right. Aug 31 '12 at 8:32
• I like how you give a perfectly fine answer and because it applies to the console definition of the word instead of the pc definition you get down voted. Aug 31 '12 at 17:09
• Yeah, I've no idea why the downvotes. Auto-aim is a console feature, maybe there's a confusion with aimbots, which are quite a different thing. Aug 31 '12 at 18:37