One point worth carrying into a design review concerns transports. A transport can move packets, and it does not by itself hand you prediction, snapshot interpolation, authority rules, lag compensation, reconnect restoration, or late-join state reconstruction [9]. That is why the dev.to guide treats "WebSocket or Photon?" as a broken comparison: WebSocket is an application-layer protocol often used as a transport path, while Fusion is a netcode carrying prediction and simulation semantics [8].
Prediction runs deep into the codebase, and that is where the cost stops being reversible. Under client prediction with server reconciliation, the local player applies input immediately, sends that input to the authority, and reconciles when authoritative state arrives, rewinding to the authoritative tick and resimulating to the present [12]. The rule that falls out of resimulation is that tick logic must be safe to run again, so external I/O, analytics, rewards, and one-shot side effects stay out of it [13]. That is a code review rule rather than a package setting, and every feature written after the decision has to pass it.
The other two models put the bill in different places. Snapshot interpolation has the authority send periodic state snapshots for remote clients to interpolate between [10], where raising update frequency buys responsiveness with traffic, which pulls quantization, change detection and interest management forward in the schedule [11]. Deterministic lockstep has peers advance from the same input stream and rollback when delayed input arrives, under simulation constraints stricter than ordinary MonoBehaviour or PhysX gameplay [14]. Real games hybridise: predicted local player, interpolated remotes, local-only cosmetic effects, economic rewards finalised by a backend [15]. So the authority model is answered per object, not once per project.
The Fusion recommendation works the same way. Photon Fusion 2.1 is offered as a strong first proof-of-concept baseline for a GameObject action game that needs client prediction [16], subject to four conditions: prediction is genuinely required for movement, shooting or physics; Photon Cloud dependency and its pricing model are acceptable; host or client-server topology matches the product; and full source redistribution or unrestricted middleware reuse is not a hard requirement [17]. Only one of those four conditions is about the game; the other three are about the business you are agreeing to run [18].
The version notes are where the coupling gets concrete. The guide declines to assume NGO 2.13.2 can be dropped into a Unity 2021 or 2022 project, since older editors have their own package lines [20], and it notes Netcode for Entities 6.5+ is tied to the corresponding Unity 6 editor line as a core package [21]. Pick that netcode and the editor upgrade path is part of the choice. As an aside, the guide says a production stack has at least five layers [3] while its opening sentence names six concerns [2]; the "at least" is doing real work [4].
The article promises the decision in production terms including latency, cheating, reconnection, hosting, bandwidth, operations and total cost [23], and it defines CCU, RTT, SLO, egress and p95/p99 for the purpose [24]. The supplied text carries no prices and no measured latency or bandwidth figures [26]. Treat the cost argument as structural, then, and it holds structurally: the authority model is written into gameplay code and stays, while the vendor, hosting and licensing terms sit behind official documentation checked on August 31, 2026, which the author says to re-check before committing a production project [22].
