Game lock-on and targeting systems explained

Target acquisition: who is “in front of me”?

Before lock-on, the engine must answer: which entities are valid targets? Typical filters:

• Team / hostility: only enemies, or allies for heals and buffs.
• Line of sight: ray or capsule cast from camera or weapon socket; optional “soft LOS” that forgives thin cover.
• Range band: min/max distance per weapon class; melee ignores flyers beyond leap range unless tagged.
• State: dead, invulnerable, stealthed, or phased targets excluded.

Candidates inside a forward acquisition cone (often 60–90° horizontally, narrower vertically) are scored each frame or on input press. A practical score function:

score = wd · (1 / distance) + wa · dot(cameraForward, toTarget) + wt · threatWeight + wh · recentDamage

Distance bias keeps nearest threats win; angular bias keeps targets you are actually facing; threat and recent-damage terms stop the system from locking a far archer while a melee is punching you — tying naturally into threat and aggro tables. Weighted random tie-break among top-two scores within epsilon prevents robotic always-nearest behavior in crowds.

Soft lock vs hard lock

Soft lock (Z-targeting lite): camera and attacks gently bias toward the highest-scored target without freezing player rotation. Player retains full strafe and can break bias by overriding stick input past a threshold. Used in Zelda-style action adventures and many ARPGs on mouse.

Hard lock: camera enters orbit mode; character strafes around the target; attacks auto-face within a yaw limit. Break on dodge roll, heavy hitstun, target death, excessive range, or manual cancel. Souls-likes and third-person action games on gamepad rely on this for readable 1v1 duels.

Hybrid stacks are common: soft lock by default, hard lock on shoulder-button hold, free aim when aiming down sights in shooters that support both modes.

Camera orbit, strafe assist, and attack facing

Hard lock fails when the camera fights the player. A stable orbit:

1. Place pivot at midpoint between player root and target chest socket (not feet — avoids ground clipping).
2. Maintain desired radius r and height offset h; lerp violations over 2–4 frames when target jumps or teleports.
3. Player stick input adjusts orbit angle around target, not world yaw directly.
4. Camera collision: pull in along view ray when geometry occludes; never pop through walls in one frame.

Strafe assist rotates the character's forward vector toward the target at a capped deg/s while locked, but allows full manual facing when unlocked or during i-frames from dodge rolls. Melee attacks should read attack direction from animation root or weapon sweep, not from lock vector alone — otherwise sidestep attacks feel glued to the enemy center mass and melee spacing collapses.

Target switching and stickiness

Flick-right-stick (or mouse wheel / tab key) cycles candidates sorted by horizontal angle from current aim. Apply hysteresis: a new target must beat the current target's score by margin δ for 150–250 ms before swap, stopping oscillation when two enemies overlap. On switch, briefly ease camera bearing (100–200 ms) rather than snapping — snaps feel competitive; eases feel action-adventure.

Optional priority tiers: bosses > elites > adds, unless an add is actively channeling a lethal cast (override via scripted threat flag). UI: under-target reticle, corner arrow for off-screen locked enemies, color pulse on switch confirm.

Projectiles, weak points, and multi-target edge cases

Lock-on for hitscan differs from projectile weapons. Homing missiles can use hard lock continuously; arcing grenades should lock ground point near target feet, not chest — reuse throwable preview arcs from grenade systems. Weak-point targeting (headshots, breakable limbs) adds a secondary socket list: when the player aims up or uses precision input, acquisition cone narrows and socket priority overrides body center.

Multi-enemy AOEs need cleave rules: does lock pick one victim for damage application while VFX hit many, or does the swing hit all in arc? Document this in design specs — players infer from first hour and feel cheated if rules change per weapon.

Harbor Ruins ARPG refactor

Problem: bridge encounter with two shield grunts and one spear captain; free-camera melee caused 62% of gamepad players to lose lock on the captain when grunts crossed the cone. Changes shipped:

• Acquisition cone tightened from 110° to 75° for melee, widened to 40° only during charged heavy windup.
• Threat weight wt pulled from captain's aggro table entry; grunts capped at 0.3× captain score unless within 2 m.
• Hard lock on L3/R3 toggle; soft bias when unlocked but attack button held.
• Orbit radius 4.2 m, collision pull-in over 3 frames; break lock if target behind wall > 0.6 s.
• Switch stick with δ = 0.15 score margin; reticle + audio tick on confirm.

Playtest metric: time-to-first-hit on captain dropped 1.8 s → 0.9 s on gamepad; parry tutorial completion (needs stable facing) rose 55% → 81%. Mouse players disabled hard lock in settings; 70% kept soft bias only.

Technique decision table

Multiplayer authority and fairness

In networked action games, server or host should validate target ID on each damage event — never trust client-reported lock alone. Serialize: lockTargetId, lockBreakReason, switchSeq for replays. PvP: hard lock is often disabled or narrowed to prevent tracking through smoke; aim assist and lock-on tiers must match across input devices or disclose asymmetry in settings.

Spectator clarity: broadcast UI should show locked target outline even when stream viewers cannot see player reticle.

Common pitfalls

• Locking through walls indefinitely — break after timeout or when LOS fails.
• Camera pop on target death — ease to free camera over 200 ms; auto-acquire next threat only if player holds lock.
• Nearest-only scoring — ignores archers and healers; always blend threat.
• Same tuning for mouse and gamepad — offer separate defaults; mice rarely need hard lock.
• Orbiting into environmental hazards — clamp orbit when back is to a cliff edge.
• Switching during super armor — freeze target change during boss charge phases unless designed.
• No feedback on failed acquisition — play empty click sound when cone has zero valid targets.

Production checklist

• Define valid target masks per game mode (PvE, PvP, friendly fire).
• Implement scored acquisition with tunable weights; expose in debug HUD.
• Ship soft and hard lock modes; map to platform-appropriate buttons.
• Tune orbit radius, height, collision pull-in, and break conditions.
• Add switch input with hysteresis and off-screen indicators.
• Align melee arcs and projectile spawn with lock socket vs body center.
• Playtest 1v1, 1v3, and boss+adds scenarios on gamepad and mouse.
• Validate target ID server-side in multiplayer damage pipeline.
• Settings: toggle hard lock, adjust assist strength, accessibility large reticle.
• Log acquisition failures and switch counts in playtest telemetery.

Key takeaways

• Targeting is a scored pipeline (filter, cone, rank) before lock-on is a camera mode.
• Soft lock biases; hard lock orbits — pick defaults per platform and genre.
• Threat-weighted scoring prevents wrong-target frustration in crowds.
• Switch hysteresis and eased camera moves stop lock bounce and nausea.
• Multiplayer must validate target IDs; PvP needs stricter break and assist rules.

Related reading

• Game aim assist explained — magnetism and friction when lock-on is off or hybrid
• Game threat and aggro systems explained — threat weights for acquisition scoring
• Game melee combat systems explained — spacing and attack arcs under lock
• Game camera shake explained — keep orbit readable under impact feedback