Network latencies can vary depending on the distance between and the performance of the networks along the transmission routes. When you are playing with others, you have to wait for their devices to send information as much as they are waiting for you to do the same.

Since different game types have different requirements for how fast the game progresses, each game has to establish what level of tolerance it has for network latency. Sometimes having synchronization events come in a little slower is okay because you can hide latency with techniques such as prediction and reconciliation.

A lot goes into having single-player games run well and be fun for one person, but how can you know how many players your game can handle at once? Technically, connections are limited by network model, where client-server is able to handle more simultaneous connections easier than peer-to-peer.

The more players you have in a game, the more likely you have to account for more network activity needing to be synchronized. Just like you can lower the level of detail on assets to maintain frame-rate, so too can you change the level of information transmitted across peers to support more players.

In gaming, it’s okay to have certain parts of the simulation not stay in sync across all players when those elements are not essential to the outcome of play. This is an optimization since player-devices and dedicated server machines have finite resources available to them.

Other mitigations that help reduce the synchronized simulation scale include: Reducing the data update frequency of the host, partitioning the world into separately updateable areas, and having players subscribe to updates only on the things they are interested in.

The precision needs of your game affects all systems related to the calculation of the world state and its actors. If you want more precise results, then you’ll need more resources to handle these operations and the higher memory footprint.

In multiplayer, precision also influences the overhead of your network footprint and the speed at which your server can run.

Not everything needs precision, so it’s important to separate what is important to the game’s ruleset and outcome. For the rest, you can use approximations of a lower degree in order to save on overall performance.

There are plenty of considerations to make when you choose the right model for your game and player base.

Solo and indie developers often gravitate towards more affordable server-less solutions, but be cautious as lock-in (below) and the potential for increased cheating can restrict your overall earning potential for the game you have made.

When using services to improve connectivity, server capacity, and latency, understanding that services often perform consumption charges based on peak concurrent users helps when trying to understand which choices are best to take for your title.

Multiplayer development can be daunting due to needing to solve for degrees of complexity when it comes to different network models, total players, range of latency, and design of a good synchronized simulation scale.

Solutions to these issues exist, but not all are easy to use or understand so it’s important that studios properly assess everything first so that networking experts aren’t needed later on.

Solutions that come with great documentation, easy-to-follow samples, and an active support community make your effort to overcome these inherent complexities way easier.

When you bring players together to play together, some will be tempted to tamper with the game or network traffic in order to gain an unfair advantage, cheat the system, or just to create chaos and disorder.

Casual and cooperative-type games don’t have as much incentive for cheating but competitive games are often targeted by disruptive players. Cheat mitigation capabilities are important to counter these actions in order to protect the reputation of your game.

Any information on a client’s local machine will likely be exploited eventually, so game types that are vulnerable to cheating should consider hosting server logic on non-client hardware.

The final factor for consideration is lock-in – or the limitation of any future options once you make your decision. If you choose one networking model, it can be very tricky to convert to others if and when your game needs more advanced capabilities (like cheat management).

Choosing a solution that is easier to upgrade is important for the future success of many games. For example, peer-to-peer models almost always require a complete rewrite to move to some form of client-server model. However, moving between client-server variants is more feasible if you plan ahead in your game design.