Ability or healing lock

Three questions for the mechanic

• Which exact verb is locked, and what event owns the status?

  Use an allowlist or capability tag rather than disabling a whole input layer. Resolve contact once, create one status instance with a stable source and end tick, and specify whether an action already in progress completes, cancels, refunds, or becomes immune to late application.

• What happens when the player presses the locked action?

  Return a named rejection reason without spending charges, starting cooldown, consuming stamina, or swallowing the input silently unless that cost is an intentional rule. Decide whether the input buffers until expiry, and make the icon, avatar feedback, sound, and text identify the same blocked verb.

• How does the lock end and remain deterministic?

  Choose fixed duration, cleanse, phase completion, source defeat, or another explicit release. Define refresh, stacking, resistance, save and checkpoint behavior, co-op ownership, host migration, and same-tick ordering when expiry, input, damage, and cleansing arrive together.

Design mistakes

• A generic silence icon hides which control stopped working

  If every ability appears suspect, players test controls instead of reading the fight. Mark the exact verb, leave unaffected controls visually normal, and demonstrate at least one still-available response during the lock.

• Rejected input still spends the resource or begins cooldown

  That converts a readable temporary restriction into an invisible double penalty. Validate availability before payment and activation, emit one rejection result, and test repeated inputs, held inputs, buffered inputs, and expiry on the same simulation tick.

Tune the attack

• Lock the smallest useful capability

  Prefer healing, lifesteal, one spell family, or one movement tool over a total control shutdown. A narrow lock changes planning while preserving agency and gives the player meaningful choices during its duration.

• Tune duration against encounter opportunities

  Measure how many safe healing windows, casts, or mobility checks occur while locked, not duration in isolation. A short seal that covers the only recovery window can be stronger than a long seal during downtime.

• Keep status and input systems in agreement

  Expose one capability query to UI, AI assistance, input handling, animation, resource payment, and networking. Duplicate checks create frames where the icon says locked but the action fires, or the action fails after cost is paid.

• Instrument applications and rejected attempts

  Track source, affected verb, avoid rate, lock uptime, rejected inputs, accidental costs, cleanses, deaths during lock, and first successful use after expiry. This distinguishes a learned planning constraint from an unexplained control failure.

Arena

• Kern seals the healing rune, not Tavi's whole kit

  A hexagonal brand crosses out only the green healing glyph. Tavi can still run and swing the sword while six runes extinguish one by one. When the last rune fades, the glyph opens and the same healing spark reaches the health track.

Player upgrades

• Make the affected verb and remaining time redundant

  Combine the verb icon, slash shape, countdown segments, text, distinct audio, and controller feedback. Offer longer warnings, shorter locks, automatic cleanse, no resource loss, simplified status lists, spoken rejection reasons, or a substitute action, and declare those assists before combat.

Do not confuse this with

• Unavailable action, not depleted resource or global stun

  Resource depletion still permits an attempt that fails for insufficient cost, while cooldown schedules the ability's own next use. A stun removes broad control. An ability lock adds an external rule that rejects one named verb even when its resource and cooldown would otherwise allow it.