Lesson 28: Multiplayer Reliability Add-On - Rejoin and Host-Migration Smoke Protocol (2026)

If your game has any online session surface (co-op, async ghost data, or light PvP), the fastest way to lose reviews and players in 2026 is not a missing feature. It is session continuity: players who crash, suspend, or switch networks and then cannot rejoin cleanly, or lobbies that die when the original host leaves.

This lesson is an add-on to the launch-ops arc from Lessons 21-27. You will not build netcode here. You will build a smoke protocol and evidence habit that fits small teams.

Why this matters now

Live-service literacy is higher. Players expect mobile-grade resume behavior even in indie titles. Store and platform reviews increasingly touch multiplayer claims in metadata and patch notes. A rejoin regression that ships during a cert window is expensive because it looks like false advertising and stability at the same time.

What you will build

By the end of this lesson, you will have:

1. A Rejoin and host-migration smoke script your QA (or you) can run in under an hour
2. A session evidence row template aligned with your candidate tuple discipline from earlier lessons
3. A go / conditional / defer rule for multiplayer risk before launch week

Prerequisites

• Lessons 21-24 completed enough that you already name owners and record decisions
• A test build with multiplayer enabled (even if only a vertical slice)
• Two test accounts and two devices (or one device + emulator) for basic continuity checks

Step 1 - Decide if this add-on applies

Use this lesson if any of the following is true:

• matchmaking, invites, or join-in-progress exists
• host migration, listen-server, or relay fallbacks are claimed
• cloud saves or profiles bind to session ids that can change across rounds

If you are strictly offline single-player, archive this lesson as not applicable and keep your binder focused on Lessons 21-27.

Success check: you wrote a one-sentence scope line listing which modes are in scope for multiplayer smoke (for example: “2P co-op campaign sessions only”).

Step 2 - Lock the same candidate tuple discipline

Reuse the candidate identity pattern from Lesson 27:

• candidate_build_id
• git_tag_or_commit
• network_profile (production, staging, or cert lane)
• smoke_owner

Do not run host-migration tests while multiple mystery builds float in Discord attachments.

Common pitfall: “works on my branch” without a shared candidate_build_id everyone launches.

Step 3 - Write the five-minute rejoin matrix

Create a table with rows as scenarios and columns as pass/fail, time, and notes.

Minimum scenarios:

1. Cold join into a live session
2. Background the app for 30-60 seconds, return, confirm state
3. Force-close the client, relaunch, rejoin the same session id (or equivalent flow)
4. Airplane mode toggle for 5-10 seconds mid-session, recover
5. Host leaves (or host migration event) while the second client remains

For each row, record:

• expected session id / match id behavior
• expected player-owned state (inventory, quest flags, progression chunk)
• acceptable visual desync window (none, sub-second, requires manual resync)

Success check: a new teammate can execute the matrix without asking you what “rejoin” is supposed to mean.

Step 4 - Host-migration smoke (even if you swear you do not migrate)

Many teams “do not migrate hosts” on paper but still have:

• lobby recreation
• dedicated server spin-up
• relay fallback that changes authority

Treat those as migration-class events. Your smoke should prove:

• clients reconnect to the correct authority
• late joiners see consistent session metadata
• no duplicate ghost hosts accepting inputs

Pro tip: If you cannot migrate safely, narrow the store claim instead of hoping reviewers skip multiplayer footnotes.

Step 5 - Evidence row you can attach to the control panel

Add one block to your Lesson 21-style dashboard packet:

• smoke_protocol_revision
• rejoin_matrix_pass_count / total
• host_migration_class_events_tested
• blocker_ids linked to your issue tracker
• rollback_or_feature_flag_note

If you run a conditional go, say what you disabled (cross-play, invite-only, region) and how long that configuration is allowed to live.

Step 6 - Tie to support and comms

Prepare three player-facing lines:

• what players should do if a rejoin fails (restart client, re-invite, check version)
• what you will not promise (for example: mid-match migration across platforms)
• how you will acknowledge a widespread outage without over-claiming root cause

This reduces review risk and refund noise when something still breaks.

Troubleshooting quick guide

• Rejoin works in dev, fails in staging -> certificate, backend environment, or CDN config drift; align network_profile and rebuild.
• Host leave kills everyone -> migration path missing; either implement or remove “continue without host” marketing.
• State snaps back after rejoin -> authority and serialization order bug; treat as ship blocker for progression modes.
• Only Wi-Fi fails -> MTU, IPv6, or carrier NAT issues; log network class in evidence rows.

Mini challenge

Run the matrix once on a minimum-spec device you actually sell on. If you only test on flagship hardware, you are collecting marketing evidence, not launch evidence.

FAQ

Do we need automated load tests first

No. Smoke first. Load tests matter after rejoin and migration basics pass.

What if we only have async multiplayer

Still test session bind and resume paths that touch your backend identity. Narrow the matrix accordingly.

Should this block a single-player launch

If multiplayer is off in the shipping build, keep documentation that Lessons 21-27 gates still apply and archive this add-on as N/A.

Lesson recap

Multiplayer reliability is a continuity problem. Rejoin and host-migration smokes are how small teams prove, with boring evidence, that they are not accidentally shipping a one-way session story.

Next steps

• If you ship online features, pair this habit with Ship a Multiplayer Vertical Slice in Unity (2026) for engine-level networking literacy.
• For Godot-style replication pitfalls, bookmark Godot 4 MultiplayerSynchronizer Desync After Scene Reload as a troubleshooting anchor.
• Roll smoke results into Lesson 21 dashboards before any go call in release week.

Bookmark this protocol if your next milestone adds invite-only co-op or cross-play—that is exactly when rejoin regressions spike.