Netcode explained

November 21, 2016 no comments Posted in Uncategorized


Netcode is a blanket term for anything that somehow relates to networking in online games; netcode is a term most commonly used by gamers when discussing synchronization issues between clients and servers. The actual elements of a game engine that can cause so-called “netcode issues” include, among other things, latency, lag compensation or the lack thereof, simulation errors, and network issues between the client and server that are completely out of the game’s hands. Netcode as a term tends to be used only in the gaming community, as it is not recognized as an actual computer science term.


Netcode is not a term used by the people that make games, but rather the people that play them. It says a lot about public knowledge of networking in video games when the public invents its own term for it,
the technology and techniques that make multiplayer possible might as well be called “black magic”. So, hopefully, I can clear some things up too much without being too cursed by my limitless knowledge 😉


Before I dive into how game engines make multiplayer work(and not work), I’ll introduce describe a small bit about what an engine actually has to do.

The job of a game  engine is to provide game developers with a framework to construct 2D or 3D worlds to their liking, Game engines render animated models and other geometric information into those worlds with realistic-looking physics quickly, filter out heaps of unnecessary work, distribute that work to processor cores, and keep all players in a multiplayer game on the same page, which can be difficult when you have to consider that player latencies can range and spike from 1-1000ms and that hackers are like hawks looking for ways to exploit and break your games.

Balancing processing power and network bandwidth

So, how would you make multiplayer “work”? The ultimate goals is  to have all relevant data up to date for every connected player.

What that data is depends on a few things, such as what type of game it is and how frequently the new data is distributed.
It would usually be exclusive stuff determined on the client side , such as their mouse and keyboard input. Sometimes it would be more efficient on bandwidth to directly send the player’s position, equipped weapon and preference changes rather than the input that led to that information being generated, but the receiver of that information will have to extract the player’s position etc. from that information, which usually means jumping back to a snapshot of how the world was when the last bit of information was received, and simulating what would happen if that information was inputted for that player again, which is taxing on the CPU but better for bandwidth.

A simple solution, might be just to keep all players(henceforth referred to as ‘Clients’) updated of events by sending each other data, using the Peer-to-Peer method:

Blue=key down, yellow=key up. Maybe.
A 3-player game with one player broadcasting the pressing and releasing of movement keys.


In peer to peer, clients simply tell each other what’s up with no intermediate third parties. Each client sends every other client all the new data they would be interested in periodically, or just as they occur.

This method is particularly efficient on processing power compared to more modern methods, but presents some problems over the more common server-centric approach:

  • No authority — Normally,  a server would be entrusted to detect and stop players from doing the obviously impossible (and some specialised cases, not so obviously impossible). But without one, modified clients can pretty much do as they please. Any system put in place to kick dodgy clients could also be abused by dodgy clients to kick legitimate players. Also, without some centralised user authentication service, no player can securely hold an identity and could be easily impersonated, though most peer-to-peer programs would still rely on a server for identification.
  • Extra latency to prevent syncing problems — If one message is missed, it could have a drastic effect on the outcome of the game. For example, if one client misses the memo when a player changes their weapon, it could be the difference between getting shot with a low damaging weapon and getting shot with a high damaging one, which could be the difference between life and death, which could snowball up with the butterfly effect as differences pile up until it can’t really be called multiplayer anymore.





Leave a Comment