Netcode Traps: Messages That Silently Disappear

Multiplayer bugs are a genus of their own: nothing crashes, nothing logs an error — simply nothing happens. Two of our favorite traps from our own networking code, as a warning and for entertainment.

Trap 1: the unregistered message. Our network protocol knows message classes — "block changed", "player moved", "chat". Every new message type has to be registered with the codec so it gets an ID and can be serialized. Forget that, and the worst possible thing happens: the send call fails, but in a place where the error is silently swallowed. No crash, no log — the feature "just doesn't work". We debugged that more than once until the reflex stuck: new message class? First question: is it registered?

Trap 2: the ghost block. When the server changes a block — say, because a script is reshaping terrain — it has to actively tell all connected players. Forget the broadcast and you get a ghost block: the server knows there's a block there, the client shows air. The player runs into an invisible wall — or worse, builds in a spot that no longer exists on the server side. Only reloading the chunk brings both worlds back into alignment.

The common denominator: in multiplayer there are always two truths — the server's and the client's — and every place that has to keep both in sync is a potential trap. Our response was tests that check exactly this synchronization, and checklists for new messages. Unspectacular, but the ghosts have become rare since then.