Persistent encounter progress preserves selected boss objectives after player defeat. Each completed milestone is committed before transient combat state resets, then the next attempt restores that ledger and derives the remaining fight from it, reducing repetition without pretending the failed attempt never happened.

Open boss builder
Complete a milestone and commit it before failureAttempt one starts with two intact anchors. Tavi breaks the left anchor at 0.78 s; revision one is committed at 0.98 s before a clearly marked rune lane defeats the player at 1.24 s. The boss's temporary health, attacks, and Tavi's position are allowed to reset, but the left anchor is no longer part of the next attempt.
Break Kern's two rune anchors across retries, then open the core Kern stands behind two tall crystal pylons connected to the boss. Tavi breaks the left pylon, then the right across two defeats and respawns; their stone rubble stays in place while boss health refills. Three carved wall tablets gain permanent marks one by one. On the third attempt Kern’s chest core opens, Tavi strikes it, and a single key appears as the reward. Boss Player

Attempt one starts with two intact anchors. Tavi breaks the left anchor at 0.78 s; revision one is committed at 0.98 s before a clearly marked rune lane defeats the player at 1.24 s. The boss's temporary health, attacks, and Tavi's position are allowed to reset, but the left anchor is no longer part of the next attempt.

Implementation checklist

Define the persistent unit, commit moment, retry boundary, transient fields that reset, restored geometry and attacks, resource policy, difficulty scaling, co-op ownership, save durability, sequence migration, reward authority, and signals that let the player predict exactly what the next attempt will retain.

Core checks

Three questions for the mechanic

  • Which progress unit is meaningful enough to survive failure?

    Persist authored accomplishments such as a destroyed organ, completed ritual, rescued ally, cleared phase, or solved arena route. Avoid silently saving every damage point unless incremental health attrition is the intended encounter. Give each unit a stable id, completion condition, visible world change, and dependency list so restoration cannot produce an impossible phase.

  • When is a milestone durable, and what still resets?

    Commit after the objective is authoritative, not when its animation merely begins. Write the revision before exposing lethal follow-up danger, then reset transient health, player position, spawned attacks, timers, and temporary buffs according to one documented retry package. Confirm the commit before showing a save cue; never promise persistence that is still pending.

  • How does the next attempt reconstruct a coherent fight?

    Load and validate the ledger, rebuild destroyed geometry, choose the correct remaining targets and attack package, place both actors safely, and reconcile resources before control returns. Reserve one terminal result and one reward claim. Test older saves, interrupted writes, co-op disconnects, difficulty changes, and retries after the final milestone.

Design mistakes

  • The save icon appears before the milestone is durable

    If the player dies after a celebratory pulse but before the write finishes, the next attempt contradicts the interface. Commit atomically first, then acknowledge it. On failure, keep the old valid revision and surface recovery instead of loading a half-complete arena.

  • Restoration revives geometry or attacks from an earlier state

    A destroyed anchor that visually returns, a projectile owned by a removed phase, or a sealed route with no remaining key breaks trust and can soft-lock the fight. Derive arena objects, attack eligibility, navigation, and objective UI from the same validated ledger.

Tuning

Tune the attack

  • Separate persistent and transient state

    Persistent fields may include objective ids, phase tokens, route changes, narrative flags, checkpoint revision, difficulty policy, and result claims. Transient fields include current health, animation time, active hitboxes, projectiles, local timers, target locks, and temporary effects. Make the boundary explicit in code and telemetry.

  • Tune the size and cost of each retained chunk

    A milestone should remove meaningful repetition without collapsing the remaining challenge. Measure time-to-milestone, failure rate immediately after it, replay time saved, resource replenishment, and how restored attacks ramp back in. Large checkpoints need stronger transition cues and more careful resource normalization.

  • Version, validate, and migrate the ledger

    Store a schema version and stable objective ids rather than array positions. Reject unknown future data, migrate renamed or split objectives, clamp impossible combinations, and keep the last valid revision until the new one is durable. Loading must be idempotent and safe after a crash during commit.

  • Test shared authority and final rewards

    In co-op, decide whose death triggers a retry, who may commit a shared objective, and how late joins receive the ledger. Simulate simultaneous objective completion and defeat, host migration, rollback, repeated final hits, and reconnect. Exactly one encounter result and one reward grant may survive.

Arena

  • The quarry remembers every broken seal

    Tavi cuts one anchor before Kern's rune lane throws the scout back to the gate. On returning, the fractured stone is still dark and the wall inscription has gained a permanent mark. The second attempt leaves another scar. By the third, only the exposed core remains, making the arena itself the clearest record of progress.

Player upgrades

  • Make every restored state understandable and recoverable

    Offer clear checkpoint captions, distinct shapes for saved and temporary progress, readable retry summaries, adjustable resource restoration, and a safe pause before restored attacks resume. Provide a restart-from-beginning option when practical, and never require the player to remember an earlier attempt without persistent visual evidence.

Do not confuse this with

  • Saved encounter state, not short runback or metaprogression

    A nearby checkpoint shortens travel but may reset the whole boss. Metaprogression strengthens later runs without preserving a completed part of this encounter. Persistent encounter progress instead restores authored boss milestones inside the same encounter definition, changing which objectives, geometry, and phases remain.

Bosses that use this mechanic

Learn more

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