Multiplayer reliable vs unreliable messages should be split by consequence. Use reliable delivery for durable outcomes players cannot afford to miss, and use unreliable delivery for replaceable updates where the newest packet matters more than the old one.
Reliable sounds like the adult choice. I get why teams reach for it. Nobody wants a missed pickup, a dropped match-start event, or a vanished ability cast. The problem starts when "important" becomes the label for everything the game sends.
Aiming, footsteps, camera-facing, remote player positions, tiny animation hints, combat barks, and cosmetic effects all feel important during a match. They are not all worth remembering. Some messages are groceries. Some are smoke. If smoke arrives late, you do not put it back in the room.
This article uses official docs from Unity Netcode for GameObjects, Photon Fusion, Unreal Engine networking, and Steam Networking Sockets. I am reading them as design material: which game facts deserve guaranteed delivery, which ones should be allowed to disappear, and what the player sees when the wrong lane gets clogged.
Unity Netcode for GameObjects reliability
Unity documents reliable and unreliable RPC delivery and notes that reliable RPCs are delivered in order on the same NetworkObject.
Photon Fusion RPCs
Photon Fusion exposes reliable and unreliable RPC channels, with reliable as the default and unreliable available for messages that can be lost.
Unreal Engine networking
Unreal distinguishes reliable RPCs from unreliable ones and describes unreliable RPCs as faster, more frequent messages that are not guaranteed to arrive.
Steam Networking Sockets
Steamworks documents reliable and unreliable message support for games that need lower-level networking control.
Chatforce
A multi-agent game development workflow that can turn a networked game idea into a browser-playable first version before you commit to a production transport model.
Reliable Means Remembered, Not Fast
The mistake is treating reliable delivery as a quality setting. It is closer to a memory setting. You are telling the transport, "This message still matters later, so keep trying." That is perfect for a purchase, a match result, an inventory grant, or the fact that a door opened.
It is awful for stale position data. If a player sent position 440 and then position 455, I do not want the old position politely arriving after the new one. I want the old one gone. The player has moved on. Literally.
A Better Message Split
| Message | Delivery choice | Reason |
|---|---|---|
| Match start accepted | Reliable | The room needs one shared outcome, and late delivery is better than silent disagreement |
| Player input sample | Usually unreliable or input stream | Newer input replaces older input in fast action games |
| Remote position snapshot | Unreliable | A late old snapshot makes motion worse, not better |
| Inventory item awarded | Reliable | Missing it breaks trust and persistence |
| Muzzle flash or footstep | Unreliable | The next audiovisual cue matters more than a delayed one |
| Chat message | Reliable | Players expect text to arrive or fail clearly |
| Ability result | Reliable state or confirmed event | Damage, cooldowns, and resources need an authoritative record |
Head-of-Line Blocking Is a Design Bug Too
Reliable messages can wait behind earlier reliable messages. That is not a moral failure. It is the deal you made. The weird part is when a harmless old effect blocks a useful new result because both were shoved into the same "safe" lane.
I have seen teams debug this like it is a mystery in the renderer. The remote player stutters. The hit marker arrives late. The door state updates after the explosion. Then someone opens the network log and finds a parade of reliable cosmetic events waiting politely in line. The renderer was innocent.
If a newer message makes the older message useless, the older message probably should not be reliable.
Separate Outcome, Intent, and Feel
Most multiplayer features become easier when you name the kind of message you are sending. Intent says what the player tried. Outcome says what the game accepted. Feel says what the player should sense along the way. Those are different lanes.
A shotgun is a clean example. The trigger input can be part of the client input stream. The server-approved shot result should be reliable enough to resolve ammo, damage, cooldown, and score. The muzzle flash, shell bounce, and camera kick can happen locally or travel unreliably. If the shell bounce gets dropped, nobody files a support ticket.
- Would the message still matter if it arrived 300 ms late?
- Can a newer message replace it without hurting the game state?
- Does a late copy create visual stutter, duplicate feedback, or a false correction?
- Would missing it break score, inventory, matchmaking, chat, progression, or match authority?
- Can the receiver reconstruct the fact from replicated state instead of needing the event?
- Is this message sent from player input, a tick loop, or an animation event that can fire repeatedly?
- Does it share a channel with anything players will notice if delayed?
Reliable Events Should Be Rare Enough to Audit
One useful test: can you read your reliable events list out loud without getting bored? Match accepted. Spawn confirmed. Item granted. Ability resolved. Objective captured. Chat sent. Those sound like records.
Now read the bad list. Position changed. Look angle changed. Animator parameter changed. Dust puff spawned. Footstep played. Crosshair passed over target. Those sound like weather. Weather does not need a receipt.
Reliable event
The message creates a durable fact that must not be skipped.
Inventory grants, lobby ownership changes, match start, objective capture, chat, purchases, and server-approved ability results.Unreliable update
The message is frequent, replaceable, and stale data makes the game feel worse.
Movement snapshots, look direction, aim hints, cosmetic effects, footstep cues, and short-lived animation feedback.Replicated state
Late joiners or recovering clients need the current truth, not every old event.
Health, score, cooldown end times, objective ownership, door state, team assignment, and room readiness.Prototype the Feeling Before You Pick the Transport
This is where quick playable prototypes help. If you are still testing whether a co-op loop is fun, a prompt-to-game workflow like Chatforce can get the room flow, combat beat, and shared objective on screen quickly. That first version will not settle your production transport design, but it can tell you which moments players actually care about.
Once the loop survives a playtest, then wire the real message lanes. Do not spend a week building a careful reliability policy for a mode nobody wants to replay. Get the feeling visible, watch where players argue with the game, then make those facts reliable.
The Rubber-Band Door
A player opens a door, runs through, then gets corrected because the open event waited behind older reliable effects.
Door state should be authoritative and durable. The sparks and handle jiggle should not block it.
The Polite Footsteps
A burst of reliable footstep events arrives late, so the enemy sounds like they are behind their own movement.
Footsteps are feel. Drop stale ones before they lie about position.
The Missing Reward
A pickup animation plays, but the item grant is sent like a disposable effect and disappears under packet loss.
The animation can be unreliable. The grant cannot.
The Player Does Not Care About Your Channel Names
Players feel consequences, not transports. They notice when a reload spends ammo twice. They notice when an opponent jitters through a doorway. They notice when a revive succeeds on one screen and fails on another. They do not care whether the bug came from RPC delivery, a replicated property, a message queue, or your own wrapper.
So pick delivery rules from the player argument you want to avoid. "I earned that." Reliable. "I saw that." State. "I felt that." Usually local or unreliable. It is not perfect, but it keeps the reliable lane for promises instead of confetti.
Reliable vs Unreliable Messages FAQ
Should player movement be reliable in multiplayer games?
Usually no. Movement snapshots are frequent and replaceable, so unreliable delivery is often a better fit. The server can still be authoritative while old client or server snapshots are allowed to drop.
When should I use reliable RPCs?
Use reliable RPCs for durable outcomes that must arrive or fail clearly, such as match start, item grants, chat messages, accepted ability results, and objective changes.
Can unreliable messages still be important?
Yes. Unreliable does not mean unimportant. It means a late old copy is less useful than a newer update, or that the game can tolerate the message being dropped.