Fix: Construct 3 Multiplayer Host Migration Crash

Here is how to fix Construct 3 multiplayer host migration crash. You build a multiplayer game using the built-in Multiplayer plugin. Four players join a room, the host starts the game, everything works beautifully. Then the host closes their browser tab. Instantly, every other player’s game freezes, throws errors, or drops to a broken state where objects stop moving and inputs stop registering. The game is over for everyone because the host left. The Multiplayer plugin handles peer-to-peer connections through a host, and when that host vanishes, the entire session collapses unless you build a recovery system.

The Symptom

When the host player disconnects (closes the browser, loses internet, or their device sleeps), the remaining peers experience one or more of the following: the game freezes entirely as synced objects stop updating, JavaScript errors appear in the browser console referencing null peer IDs, the Multiplayer object reports an error state but event sheets do not handle it, or the game continues locally but desynchronized from other peers who each see a different frozen state.

The crash typically manifests as an unhandled exception in the runtime when the sync system attempts to send data to or receive data from the host that no longer exists. The WebRTC data channels close, but the event sheet continues to reference them on the next tick, causing the error. In some cases, the game does not crash immediately but enters a zombie state where it appears to run but no multiplayer functionality works.

What Causes This

No built-in host migration. Construct 3’s Multiplayer plugin uses a host-peer architecture where one player is the authoritative host and all others are peers. The host owns the room, manages sync state, and relays messages. When the host disconnects, the WebRTC connections between the host and each peer are severed. The peers do not have direct connections to each other (unless you set up a full mesh, which the plugin does not do by default). With the hub gone, the spokes are isolated.

Synced objects referencing the host peer. Every synced object in the Multiplayer system has an owner — either the host or a specific peer. Objects owned by the host (which is often the majority, including all environment objects, NPCs, and game state managers) stop receiving updates when the host disconnects. If your event sheet checks the sync state of these objects or tries to read their synced instance variables, the data is stale or the reference is invalid.

Signaling server connection lost. The initial connection between peers is brokered through a signaling server. Once WebRTC connections are established, the signaling server is no longer actively used. But when the host disconnects and you want to re-establish connections with a new host, you need the signaling server again. If the peers have since disconnected from the signaling server (which can happen after a timeout), they cannot find each other to reconnect.

Object ownership not transferred. Even if you manage to elect a new host and reconnect peers, the synced objects that were owned by the old host have no owner. The Multiplayer plugin does not automatically reassign ownership. These objects become unsynced ghosts — they exist on each peer’s screen but nobody is authoritative over their state, leading to desynchronization.

The Fix

Step 1: Detect host disconnection and pause the game. Use the On peer disconnected trigger to detect when any peer leaves. Check if the disconnected peer was the host, and if so, immediately pause all sync-dependent logic.

// Event Sheet: Host Disconnect Detection

// Trigger: Multiplayer > On peer disconnected
// Condition: Multiplayer.DisconnectedPeerID = HostPeerID
// Actions:
Set global variable isHostAlive to 0
Set global variable migrationInProgress to 1

// Pause all sync-dependent game logic
Set time scale to 0
Browser.Log("Host disconnected, starting migration")

// Determine new host: lowest remaining peer ID
Set local variable newHostID to ""
For each peer in Multiplayer.PeerList
    If newHostID = "" OR peer.ID < newHostID
        Set newHostID to peer.ID

// Check if this peer is the new host
If Multiplayer.MyPeerID = newHostID
    Call function "BecomeNewHost"
Else
    Call function "WaitForNewHost"

Setting the time scale to 0 freezes the game while migration is in progress. This prevents synced objects from updating with stale data and gives you a clean window to re-establish connections. Display a “Reconnecting...” message to players so they know the game has not crashed.

Step 2: Reconnect through the signaling server. The new host creates a new room on the signaling server, and the remaining peers join it. This requires that all peers maintain their connection to the signaling server throughout the game session. If the connection has dropped, reconnect before attempting migration.

// Function: BecomeNewHost
// The elected peer creates a new room
Multiplayer.CreateRoom("migration-" & GameSessionID)

// On room created successfully:
Multiplayer.SendMessage("all",
    "HOST_READY|" & Multiplayer.MyPeerID)

// Function: WaitForNewHost
// Non-host peers wait for the migration room
// On message received where tag = "HOST_READY":
Multiplayer.JoinRoom(
    "migration-" & GameSessionID)

// On joined room successfully:
Multiplayer.SendMessage("host",
    "PEER_RECONNECTED|" & localGameState)

The migration room name includes the game session ID so that peers from the same session find each other. The localGameState sent by each peer can include their position, score, inventory, and other state that needs to survive the migration.

Object Ownership Transfer

Once all peers are connected to the new host, the new host must take ownership of all objects that were previously owned by the old host. This means iterating through every synced object, checking its owner, and reassigning ownership where the owner is the disconnected host’s peer ID.

For objects that each peer owns (like their own player character), ownership is already correct — each peer continues to own their own objects. The problem is shared objects: enemies, pickups, projectiles, and game state objects that the original host controlled. The new host claims these by setting itself as the owner and broadcasting the updated state to all peers.

After all ownership is transferred and all peers confirm they are synchronized, set migrationInProgress to 0 and restore the time scale to 1. The game resumes from the point of interruption. Players may notice a brief pause, but no game state is lost.

Keeping the Signaling Server Connection Alive

A critical prerequisite for host migration is that all peers remain connected to the signaling server throughout the game session. By default, WebSocket connections to the signaling server may time out after a period of inactivity (since active gameplay uses direct WebRTC connections, not the signaling server). Send periodic keepalive messages to the signaling server to prevent this timeout. A simple ping every 30 seconds is sufficient.

If you use a custom signaling server, add a reconnection mechanism that automatically re-establishes the WebSocket connection if it drops. Store the room name and peer credentials so that reconnection is seamless. If you use the default Construct 3 signaling server, be aware of its connection limits and timeout policies.

“Host migration is not a feature you can add later. It requires designing your game state to be serializable, your object ownership to be transferable, and your connection layer to be resilient from the start. Retrofitting it is twice the work.”

Related Issues

If peers experience high latency after reconnection, see Multiplayer High Latency on WebRTC for TURN server configuration and data channel optimization. If synced objects jitter or teleport during normal gameplay (not just during migration), check Multiplayer Object Sync Jitter for interpolation and input prediction settings.

Keep the signaling server connection alive with periodic pings — you cannot migrate if peers cannot find each other.