Spawn points checkpoints and respawn flow

The recipe

1. Player spawns: place Spawn Point entities, the spawn_point preset (a TransformComponent for the location and facing plus a SpawnPointComponent). Set the component's teamKey for a per-team spawn and its priority and spread radius so simultaneous spawns do not overlap. The game's character policy spawns a body for every seat that joins, its spawn selector chooses among the eligible points, and its respawn rule brings an eliminated player back. You do not script the initial player spawn (see player-characters-and-spawns and teams-and-team-play).
2. Seed the checkpoint position as durable state: writeTypedStateValue { "storeKey":"progress", "recordKey":"player", "field":"checkpoint", "valueType":"vector3", "value": <start position> }.
3. Place checkpoint entities with a trigger ColliderComponent (collision:"trigger"). On cross, react with addTriggerHandler { "handlerKey":"onCheckpoint" } and inside it writeTypedStateValue the new checkpoint position (read the checkpoint entity's transform in a GessaScript body via ctx.entity.readComponent if you need exact coordinates).
4. Return on death: from the death handler (see combat-damage-and-respawn), readTypedStateValue the checkpoint into a binding, then teleport the player from a GessaScript body with ctx.world.teleportPlayer. To place a fresh non-player entity instead, spawnEntityFromTemplate { "scope":{...}, "prefabKey": <prefab key>, "config": { ...inline overrides } }.

Pitfalls

• A player's spawn point is a SpawnPointComponent entity, not a tagged capsule you spawn from in a script; the character policy reads it. Keep the player spawn (component plus policy) and the checkpoint save (durable state plus a handler) as two separate concerns.
• spawnEntityFromTemplate requires EITHER templateKey OR prefabKey, and its config values must be validated inline literals, not arbitrary JSON.
• Spawn and teleport ops carry requiresAuthority; they run on the server authority, not the client.
• Storing the checkpoint as vector3 state (not on a component) is what makes it survive death and reload; a position written only on the entity is lost when the entity despawns.
• ctx.world.teleportPlayer is gated by worlds.teleport_authority; use it for the player, spawnEntityFromTemplate for fresh entities.

Verify

• simulation_run to prove crossing a checkpoint updates the stored position and death returns the player there.
• project_get_graph_snapshot to confirm the Spawn Point entities and the checkpoint triggers exist.