Cover and line of sight makes an obstacle part of the attack rule. The player identifies the source, reads the protected side, enters the occluded region fully, and knows when to leave. It works only when rendering, collision, damage, camera, and multiplayer authority agree about the same blocker.

Open boss builder
Lock the source and reveal the shadowAt 0.42 s Kern's head rune locks a fixed line through Tavi. At 0.78 s the pillar projects a clear safe shadow away from the source, so the required side is visible before movement begins.
Let one pillar visibly break the attack line Kern aims a straight rune beam toward Tavi. A stone pillar between them casts a marked shadow away from Kern; Tavi moves fully into it, the active beam terminates on the pillar, then Tavi leaves after the beam ends and lands one sword strike. Boss Player

At 0.42 s Kern's head rune locks a fixed line through Tavi. At 0.78 s the pillar projects a clear safe shadow away from the source, so the required side is visible before movement begins.

Implementation checklist

Implement source locking, blocker eligibility, line-segment occlusion, readable shadow geometry, full-body clearance, attack termination, edge tolerance, cover persistence, and a reliable post-attack exit as one contract.

Core checks

Three questions for the mechanic

  • What exactly can block this attack?

    Tag eligible cover explicitly and define whether the query uses a point, capsule, several body samples, or a swept volume. Decide how height, thickness, destruction state, moving platforms, gaps, slopes, and one-way geometry affect the result. Use the same authoritative blocker data for warning, damage, AI, replay, and networking instead of trusting whatever happens to be visible on screen.

  • Can the player read the safe side before committing?

    Reveal the source, the attack direction, and the blocker early enough to form one spatial problem. A shadow wedge, rim light, projected ray, or floor mask can show the protected region, but it must match the actual damage test. Include the player's full body and movement stopping distance; touching the pillar is not enough if the head or trailing collision still crosses the attack line.

  • How does the cover state end?

    Separate beam shutdown from the moment the player may safely leave. Signal both, preserve a short tolerance at the edge, and define whether the obstacle survives, moves, breaks, or becomes invalid for the next attack. Provide a useful post-cover choice—reposition, attack, restore resources, or protect another target—so waiting behind geometry leads back into play.

Design mistakes

  • The picture says blocked while the damage query says exposed

    A camera angle can hide the source even when a center-point ray slips past the blocker, or a visible beam can continue through cover while damage is suppressed. These contradictions teach distrust. Draw the actual query in debug builds, sample the player's relevant volume, stop effects at the hit surface, and test every camera and latency condition.

  • Cover becomes passive downtime

    A long attack with one permanent safe spot asks the player to arrive once and then wait. Add a preparation decision, a moving source, vulnerable cover, competing positions, or a meaningful exit timing—but keep the core occlusion rule stable. Pressure should come from reaching or preserving cover, not from secretly invalidating it.

Tuning

Tune the attack

  • Compute occlusion from the threat source

    Capture the source position used by the attack and test segments from that point to defined player samples. If the source moves during the cast, either update the shadow continuously and visibly or lock it at a named beat. Distinguish visual camera occlusion from gameplay line of sight: the camera may see around a pillar while the attack remains physically blocked.

  • Give edges an authored margin

    Exact tangency is noisy across animation, frame rates, and network correction. Expand the blocker or contract the safe region by a small visible margin, then validate with the player's widest supported collision pose. Avoid a hidden rule where feet are safe but weapons, companions, or an upper-body sample remain exposed.

  • Treat destructible cover as a resource

    If attacks can damage the blocker, show durability and ensure at least one reachable alternative before it fails. Decide whether the lethal hit is absorbed, penetrates, or destroys the obstacle first. In multiplayer, prevent one player's unrelated splash damage from removing the only answer after teammates have committed to it without a replacement signal.

  • Test source, cover, and player as a triangle

    Sweep the source around every blocker and sample player positions just inside and outside both shadow edges. Test tall and short avatars, knockback, dashes, crouches, camera cuts, moving cover, simultaneous hazards, late joins, rollback, and low frame rates. Log false-safe and false-hit cases separately; both damage trust even when aggregate difficulty looks acceptable.

Arena

  • The quarry pillar still catches Kern's rune fire

    The old stone was cut from the same warded seam as Kern's shell. When the elemental focuses its head rune, the pillar absorbs the beam and leaves a cool turquoise shadow, making the safety rule feel like a property of the setting rather than a floating interface exception.

Player upgrades

  • Use Tavi's ordinary run and sword

    The pillar is close enough for Tavi's normal acceleration and wide enough for the complete body silhouette. No dodge invulnerability is required. The beam ends before Tavi leaves cover, and the short response route fits one normal sword strike before Kern resets.

Do not confuse this with

  • Occlusion, not distance or generic avoidance

    A straight beam may be escaped by moving outside its lane, and a shield may block through an owned defensive state. Cover and line of sight specifically makes another world object interrupt the segment from source to player; safety depends on their relative geometry.

Bosses that use this mechanic

Learn more

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