Resource steal changes a hit from simple damage into an ownership transition. A fair implementation names the affected resource, caps the loss, creates each dropped unit once, keeps every pickup visible and attributable, and gives the player a reachable reclaim decision before the boss converts captured units into a declared benefit.

Open boss builder
Signal the affected resource and prove avoidanceKern marks a fixed 96-unit siphon at 0.30 s. Tavi clears the full radius before the 0.98 s resolve, so all six runes remain in the ledger and no pickup is created.
Dodge Kern's first siphon, then watch three runes spill, one return to Tavi, and two empower Kern Six carved rune stones sit above the arena. Kern sends two siphon streams toward Tavi. The first misses after Tavi moves away; the second scatters three stones across the floor. Tavi reclaims the left stone, while the other two fly to Kern and form a rune-marked shield. Boss Player

Kern marks a fixed 96-unit siphon at 0.30 s. Tavi clears the full radius before the 0.98 s resolve, so all six runes remain in the ledger and no pickup is created.

Implementation checklist

Define the eligible resource, loss formula and cap, protected minimum, pickup identities, spawn geometry, ownership transitions, reclaim and capture radii, expiry, boss benefit, pause and checkpoint behavior, co-op authority, and tests that conserve the ledger across simultaneous collection.

Core checks

Three questions for the mechanic

  • What can be lost, and how is the loss bounded?

    Choose one named resource and calculate requested loss separately from applied loss. Clamp against the current amount and any protected minimum, decide whether temporary, premium, quest, or accessibility resources are eligible, and emit one drop event only after authoritative contact.

  • How does every unit move between owners?

    Give each pickup a stable id and one owner state: player, world, boss, or expired. Define spawn clearance, magnetism, collection radius, simultaneous claims, latency reconciliation, and expiry so retries and duplicate collision callbacks cannot clone or erase value.

  • What does capture change without causing runaway loss?

    Declare the boss benefit before the race begins, cap its stacks or duration, and preserve a useful response when recovery is impossible. Test the final conservation equation, checkpoint restoration, phase transitions, death, disconnection, and collection on the same simulation tick.

Design mistakes

  • The HUD decreases but no physical cause remains

    An unexplained deduction reads as a bug or hidden tax. Trace the marked hit into a visible burst, preserve token identities, and show whether the value is reclaimable, destroyed, or already owned by the boss.

  • Boss capture multiplies an already severe penalty

    Losing a scarce resource, missing its reclaim window, and granting uncapped healing or damage can create a one-hit downward spiral. Bound each layer, provide a protected floor, and tune the race against ordinary movement rather than a mandatory mobility upgrade.

Tuning

Tune the attack

  • Keep a conserved ledger

    Record requested loss, applied loss, world pickups, reclaimed units, captured units, expired units, and the boss benefit revision. A simple conservation assertion catches duplicate pickups, late callbacks, save-load errors, and host migration disagreements.

  • Design the spill as arena geometry

    Angles, distance, obstacles, hazards, magnet speed, and lifetime determine whether reclaim is a real choice. Place pickups so one ordinary route can recover something while collecting everything carries visible positional risk.

  • Instrument the ownership race

    Track avoid rate, requested and applied loss, time to first reclaim, reclaim share, boss capture share, expired value, benefit uptime, deaths after loss, protected-floor activation, and repeated same-token claims.

Arena

  • Kern tears loose three runes from Tavi's belt

    The runes land as separate stones instead of vanishing into a number. Tavi grabs the nearest one, while two answer Kern's pull and orbit the elemental as a brief shield, turning ownership into a readable physical event.

Player upgrades

  • Make amount, ownership, and destination redundant

    Combine inventory slots, token shapes, trails, collection sounds, text, and controller feedback. Offer a smaller loss, protected minimum, longer lifetime, stronger player magnet, slower boss capture, automatic partial recovery, or a no-steal mode, and state those assists before combat.

Do not confuse this with

  • Ownership transfer, not ordinary spending or on-hit healing

    Spending begins with the player's chosen action, while a resource drain may simply delete value. Resource steal creates an externally caused ownership event and may place value back into contestable space. If the boss benefits, that capture is a second explicit rule rather than an assumed consequence of damage.

Bosses that use this mechanic

Learn more

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