Level & Flow · Topic Guide

Respawn & Checkpoints

Falling off a course is the most common thing a player will do, so recovery is one component with three composable verbs — and it is built so that a fall volume firing on eight machines at once still moves exactly one character.

One component on the player

PlayerRespawner lives on the player prefab and handles everything about getting back into the round: dying (health reaching its minimum), falling below the kill height, and being sent back by a rule. It schedules a short-delay respawn at the last checkpoint, refills the vitals, and reports one fail to the round.

With no checkpoint set, "the last checkpoint" is the level's spawn points — so a course works before you have placed a single checkpoint, and placing one is an improvement rather than a prerequisite.

Field	Type	Default	What it does
`respawnDelaySeconds`	`float`	`1.5`	Delay between dying or falling and reappearing at the checkpoint. The pause is deliberate — an instant snap reads as a glitch rather than a consequence.
`killBelowY`	`float`	`-15`	Falling below this world height counts as a fall. This is a backstop underneath your composed fall zones, not the primary mechanism — a player who finds a gap in your volumes still recovers.
`restoreStats`	`bool`	`true`	Refill health and stamina on respawn. Turn it off for a game where damage should persist across a fall.

Three verbs, composed onto volumes

None of this is wired by code. Recovery is composed onto trigger volumes with three stock instructions, all under Player in the picker:

Field	Type	What it does
`Out Of Bounds`	`instruction`	Puts the subject through the scene's out-of-bounds rule — respawn, or end the round — instead of hard-wiring one consequence into the volume. This is the one to reach for on a fall zone.
`Respawn Player`	`instruction`	Sends the subject back to their last checkpoint, or to the start if they have none. A complete kill plane is a trigger volume with On Enter → Respawn Player.
`Set Checkpoint`	`instruction`	Makes this the place the subject respawns from next time. Drop it on a volume mid-course and whoever passes through respawns there from then on.

The consequence itself is outOfBoundsConsequence on RoundController: Respawn (the default) or GameOver, which loses the round for everyone. See Rounds & Stock Levels.

Building a checkpointed course

Put a fall zone under the level
A large box collider marked as a trigger, well below the geometry, with a TriggerBehaviour on it.
Give it the out-of-bounds verb
Add Out Of Bounds to the volume's onEnter list. That is the whole kill plane.
Drop checkpoints along the route
A trigger volume at each milestone with Set Checkpoint in onEnter. No ordering, no registration, no manager — a player who passes through one respawns there. On a lap course this step is already done: the Lap Tracker's gates are checkpoints (its Gates Are Checkpoints toggle), and a fallen runner comes back at the last gate they passed, facing the next one.
Leave killBelowY alone
It is the backstop for the case your volumes missed. Lowering it to "disable" it just makes that case fall forever.

From code

The surface is three methods and an event, and each of the methods is the same one the matching instruction calls:

using Curitor.PartyCoreKit.Rounds;
using UnityEngine;

public class CheckpointFlag : MonoBehaviour
{
    [SerializeField] private Transform respawnAt;

    private void Claim(PlayerRespawner respawner)
    {
        // No-ops on a player this machine does not own -- so calling it
        // from something that runs everywhere is safe by construction.
        respawner.SetCheckpoint(respawnAt.position, respawnAt.rotation);
    }

    // HasCheckpoint answers "have they reached one yet?", which is what
    // decides between the checkpoint and the level's spawn points.
    private bool StillAtTheStart(PlayerRespawner respawner)
    {
        return !respawner.HasCheckpoint;
    }

    private void Watch(PlayerRespawner respawner)
    {
        respawner.Respawned += () => Debug.Log("Back in the round.");
    }
}

RequestRespawn() sends the player back; HandleOutOfBounds()routes them through the scene's rule instead. ShowingOutOfBoundsEffect reports whether the out-of-bounds overlay is currently up, which is what the HUD reads.

Multiplayer

Respawn is owner-authoritative, and this is the interesting design decision in the module. Each machine only ever moves its own player. The host never commands another player's transform, so there is nothing to rubber-band, and no correction to smooth over.

That choice is what makes composed recovery safe. A fall volume fires on every machine — trigger volumes are local — so an instruction that moved whoever it was given would move eight characters. Instead, every public entry point no-ops on a player this machine does not own. The volume fires everywhere; exactly one machine acts; the checkpoint is set once.

You get this for free on anything you compose. It is also why the code example above can call SetCheckpoint without checking ownership first.

The one thing that does cross the wire is the fail report— the round's results are host-authoritative, so a fall is reported to the host and counted there.

Respawnable objects are a different thing

Players respawn. So do some objects— a collectible that comes back next round, a crate that resets. That is a separate mechanism with its own memory unit, because an object that is consumed at runtime is neither "still in the scene" nor "spawned at runtime": it is a scene object that has been removed, and a save has to remember the removal rather than the object. See Saving & Loading for the three shapes.

Respawn & Checkpoints

One component on the player

Three verbs, composed onto volumes

Building a checkpointed course

Put a fall zone under the level

Give it the out-of-bounds verb

Drop checkpoints along the route

Leave killBelowY alone

From code

Multiplayer

Respawnable objects are a different thing