Design a player respawn system for a multiplayer Unreal Engine match. When a player dies, after a delay they should come back at an appropriate spawn point with a clean character — no leftover state from the previous life. Persistent data such as score, team, and stats must survive death and carry across to the new life rather than being lost with the dead body. The respawn must be authoritative on the server: the client must not decide on its own when or where it respawns or spawn its own character. The respawn timer should be visible to clients counting down, and the new character must appear correctly for all clients. Describe what is disposable versus persistent across a life, who performs the respawn and spawn-point choice, where persistent state lives, and the trade-offs of your approach.
Handle respawn in the GameMode server-side: on death the old Pawn is destroyed while the PlayerController survives, then after a delay the GameMode picks a PlayerStart and spawns a new Pawn to possess. Persistent state lives on PlayerState.
- ✗Reusing the dead Pawn instead of destroying it and spawning a fresh one
- ✗Letting the client spawn or place its own Pawn instead of the server
GameMode - ✗Storing persistent data on the
Pawn, which is lost when it is destroyed
- →How would you choose a spawn point that avoids enemies and other players?
- →How would you implement a respawn timer that all clients see counting down?
Key classes
AGameMode— server-only: owns respawn logic, spawn-point selection, timers.APlayerController— one per player; survivesPawndeath and holds the session.APlayerState— persistent data across lives: score, team, stats.APlayerStart— spawn points placed in the level, optionally tagged.UHealthComponent— detects death and posts an event to theGameMode.
Data model
The Pawn is disposable: destroyed on death, created fresh on respawn. The Controller and PlayerState are persistent and survive death, so anything that must persist (score, team) lives on PlayerState, not on the Pawn.
Data flow
- Health drops to zero →
UHealthComponentposts an event on the server. GameModeplays the death animation and starts a respawn timer via anFTimerHandle.- On the timer
GameMode::ChoosePlayerStartpicks anAPlayerStart(by team, distance to enemies). GameModespawns a newPawnand callsController->Possess(NewPawn).PlayerStatealready carries score and team — the new Pawn simply continues play.
Replication considerations
Spawning and Possess happen only on the server; the new Pawn replicates to clients automatically. The respawn timer is stored on PlayerState or GameState as Replicated so the client sees the countdown. The death screen is local UI reacting to replicated state.
Designer-facing config
Respawn delay and spawn-point mode (random/by-team/safe) are DataAsset fields or GameMode config. APlayerStart points are placed and tagged in the level by the designer. Life-count rules are data too.
Trade-offs
- A new
Pawnvs. reuse: a new one is clean with no leftover state but costs a spawn; reuse risks leaking old state. - Fixed spawn point vs. dynamic selection: fixed is simple, dynamic (farther from enemies) is fairer but needs world queries.
