Define state authority and session recovery, measure explicit update traffic and record real network-condition tests against named game builds.
Describe how players discover, join, leave and resume a session. Choose the supported player count and topology from the actual design constraints. For each shared state item, record who can request a change, who decides the authoritative value and how clients learn the outcome. Keep identity, authorization and game-state ownership distinct.
Build a minimal join-to-play path with one shared action and a visible authoritative result. Test it with separate client instances, then across the networks relevant to your audience. Record the protocol and library versions, message schema, ownership transfer rules and what happens when an action arrives late or twice.
Record simulation tick frequency, network send frequency and actual bytes per recipient update. Use the traffic calculator for one explicit outbound stream, including only measured overhead in its scope. If an update already contains several entities, count that complete payload once. Compare the calculation with captures under the same recipient count.
Use the network simulator or transport tooling for your installed library to apply documented delay, jitter and packet-loss conditions. Generate named test cases for join, contested actions, timeout, disconnect, reconnect and server/host shutdown. Define the expected state before each test, record logs from the involved instances and confirm the game recovers or gives a useful failure state.
Exercise representative player behavior and scene changes at the intended concurrency using your actual load harness. Capture CPU, memory, bandwidth, errors and end-to-end action timing. Convert the chosen client FPS target only when comparing render frame intervals. Investigate server simulation, transport delay and client rendering separately before changing rates.
Document supported session conditions, measured results, known failure modes and the person responsible for operational follow-up. Include version compatibility, maintenance communication, server recovery and what players see after a failed reconnection. Save the test matrix and the protocol/runbook notes with the release revision, then retest changed conditions on a new build label.
Write and download the state-ownership, protocol and recovery record.
Compare simulation intervals with an explicitly measured outbound update stream.
Record named network lifecycle and degraded-condition tests.
Convert a chosen client rendering target to a frame interval for profiler comparisons.
Loading your checklist…
Unity’s Netcode 2.4.2 concepts describe an authority as the instance making definitive decisions about a networked object. This versioned reference explains the concept; use documentation matching your installed package for implementation.
Set expected behavior before applying a condition.
| Condition | Evidence to retain |
|---|---|
| Delayed or repeated action | Request ID, authoritative outcome and visible client result |
| Loss or jitter | Simulator settings, packet observations and recovery behavior |
| Disconnect and rejoin | Session/build identity, state restored or explicit rejection |
| Load or shutdown | Concurrent behavior, errors, timings and recovery owner |
The linked tools calculate a declared stream and record cases. Protocol correctness, capacity, latency and abuse resistance require testing the implemented system under representative conditions.
Unity Multiplayer Tools 2.2 documents configurable delay, jitter, packet loss and network events. Match the tooling to your installed package and record the actual settings used in each test. Presets are simulation scenarios, not measured characteristics of every real connection.
State whether a number is a simulation interval, render frame time, one-way delay or round-trip observation.
Change one synchronization decision at a time and keep a reproducible session log.