Attack lock is the transition where chosen attack parameters stop updating. Kern tracks Tavi with a guide, captures one aim point, then fires along that unchanged ray after Tavi moves away; the second pass locks a different direction by the same rule. A visible capture flash makes the last useful movement decision understandable.

Open boss builder
Move while aim tracksFrom 0.42–1.18 s Kern's dotted guide follows Tavi. A flash captures (390, 560); the guide becomes a fixed dashed ray while Tavi moves perpendicular to it. No direction updates are accepted after the lock.
Compare tracking before lock with two fixed rays after capture A stone boss aims a dotted guide at a moving sword-bearing player. A crosshair flash captures the first point and turns the guide into a fixed dashed ray. The player moves away before a solid attack fires along the old direction. A second pass tracks from the opposite side, captures another point, and preserves that different ray through release and recovery. Boss Player

From 0.42–1.18 s Kern's dotted guide follows Tavi. A flash captures (390, 560); the guide becomes a fixed dashed ray while Tavi moves perpendicular to it. No direction updates are accepted after the lock.

Implementation checklist

Define what tracks, the lock boundary, captured data, post-lock delay, active geometry, and reset rule.

Core checks

Three questions for the mechanic

  • Which parameters keep updating before lock?

    Whitelist the mutable data: this example updates only an aim point while Kern's origin, lane width, speed, and attack type are already chosen. Sample the player from the authoritative simulation, not rendered interpolation. If lead, destination, facing, or arena anchors also track, expose each dependency and test them independently.

  • What event captures the attack?

    At 1.18 or 3.58 s, copy the aim point into immutable attack state and emit one visible flash. The guide, fixed preview, active lane, boss facing, replay, and network message must read that same snapshot. Define event order for movement and lock on the same frame so local play, rollback, and replays agree.

  • Is there useful time after lock?

    Tavi needs the post-lock interval to act on the commitment: 0.54 s before the first release and 0.60 s before the second. Measure recognition, input, acceleration, and full-body clearance perpendicular to the captured ray. A lock that occurs at impact does not create counterplay even when its marker is visually clear.

Design mistakes

  • The visual ray locks but collision keeps tracking

    Late gameplay steering invalidates the response promised by the frozen guide. Store one snapshot, derive preview and collision from it, and assert that the ray endpoint remains identical throughout delay and release while the player position changes.

  • Everything locks at one undocumented moment

    Aim, destination, attack choice, speed, and damage do not have to share a boundary. Hiding them behind one vague flag makes tuning and bugs opaque. Name each captured field, keep unrelated values live only when intended, and communicate every change that alters the player's answer.

Tuning

Tune the attack

  • Snapshot values, not object references

    Copy coordinates and chosen parameters into the pending attack. Do not retain a live player transform, target component, or mutable path node. Serialization, seeking, rollback, and deterministic tests should reconstruct the same ray from the stored snapshot alone.

  • Use one lock event across disciplines

    Gameplay freezes the aim, animation settles the pose, audio clicks, effects close the crosshair, and UI changes the guide pattern on one event. Offset presentation only deliberately; never let a cosmetic flash imply a later or earlier gameplay boundary.

  • Tune delay separately from tracking

    Tracking duration controls how long movement influences the attack; post-lock delay controls how long the player has to exploit commitment. Adjust them separately, then test the shortest legal delay at close range and the fastest legal tracking against abrupt direction changes.

  • Reset ownership explicitly

    Keep the captured point through the whole active interval and recovery, then clear it once. Check interruption, phase changes, death, target loss, multiplayer retargeting, pause, slow motion, rollback, and a new attack queued before the previous snapshot is released.

Arena

  • A stone sight that crystallizes one direction

    Kern's eye projects a loose dotted ray that follows Tavi. At capture, the crosshair hardens and the ray becomes a rigid rune seam through the floor. Kern releases force through that seam instead of chasing the new position; a second seam proves the stored direction belongs to each attack instance.

Player upgrades

  • Give Tavi a movement decision after commitment

    Tavi can influence the guide before capture, then uses ordinary perpendicular movement after it. Faster movement gains margin but does not change the rule. If a game offers dashes, blocks, cover, or decoys, keep their interaction with the snapshot explicit rather than silently retargeting the ray.

Do not confuse this with

  • A state boundary, not a persistent target marker

    Target lock identifies or follows an entity; source tracking describes an emitter turning toward a target. Attack lock is the moment selected attack data becomes immutable. Predictive aiming may calculate a future point, but it still needs a declared lock boundary before the committed action resolves.

Bosses that use this mechanic

Learn more

Found an inaccuracy or have a suggestion for this page? Propose an edit on GitHub