> For the complete documentation index, see [llms.txt](https://docs.coherence.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coherence.io/2.3/getting-started/beginners-guide-to-networking.md). # Beginner's guide to networking This article is an exploration of how networked games work. It does not cover code examples and doesn't delve into details. Instead, the goal is to prepare someone new to multiplayer programming to think about networking from a high-level perspective; what problems can arise and how they are commonly solved. This knowledge, while useful to understand coherence, is general enough to be applicable to any other similar game networking solution. *** When a game runs on your computer, it contains data that models the game. This includes things like the position of the players, the physical forces applied, and any gameplay-specific variables. We refer to this data as **state**. Updating state efficiently is a hard problem, even for a game that is completely offline. To create the illusion that you're playing together in the same game space, a multiplayer game has to transmit enough of its state to the other players. Since computer networks have limited bandwidth, it is necessary to restrict the amount of data being sent. It's not feasible to send everything, all the time — there's compromises to make. In the world of game networking, we commonly apply two strategies; we can send the state directly, or we can send inputs, and let the game apply them, updating state indirectly. These strategies are not exclusive, a game can use both mechanisms to keep the illusion of a realtime virtual space. #### Sending State In this approach we send enough data to replicate on other clients what we see locally. For every player on the network, game state might evolve in different ways. For example, different players will produce different inputs, experience different latency or their computers might not be able to consistently simulate the game at constant speed. By sending state directly, the forementioned game state divergence is continuosly adjusted, as long as they have a chance to catch up. This concept is usually referred to as [eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency), as it's coherence's model when sending state. Since we're sending state constantly, we don't depend on an initial state, allowing features like late joining, or backing up the state at any given time. When the game clients run the simulation locally and then send state to other players, we say it's **client-authoritative**. This strategy can be costly if there's a lot of state to manage, like a huge number of entities being created, destroyed or updated. While it's possible to compress and reduce the amount of state sent, some games might benefit from a different approach — sending inputs instead of state. #### Sending Inputs From a game design perspective, it is usually possible to enumerate the player's allowed inputs (e.g. jump, run, activate). When an input is processed, we can inform every other player in the session. If we make sure that each player starts the game in exactly the same state, and make sure that everyone applies exactly the same inputs as everyone else, the game state will appear in sync for each player. For games with that hold a lot of state, but offer a contained number of inputs, it can be an efficient networking strategy. A good example are real-time strategy games. RTS games usually handle with hundreds of units. It might be enough to send the coordinates of mouse clicks instead of the location of each unit. This however requires completely **deterministic** game logic, which is a challenge in itself. Another problem is that if there's even the slightest mismatch in inputs, the local game states of the players will begin to diverge. To learn more about this approach (and how to work around some of the problems) see our documentation on rollback networking. {% content-ref url="/pages/-MhE2qWTumGbt2hz9pUk" %} [Determinism, prediction and rollback](/2.3/manual/advanced-topics/competitive-games/determinism-prediction-rollback.md) {% endcontent-ref %} #### Calling methods remotely Aside from pure state, we might want other players to execute specific methods. For example, instead of just setting a `Game Finished` flag to `true` when the game ends, we might want to let everyone know the game has finished by calling an `EndGame()` method that handles this logic directly. In many network solutions this is referred to as RPCs. In coherence, we call these commands. A command or an RPC is a method tagged to be invoked on other game clients in the network. {% content-ref url="/pages/-MYOiEBG8dSTN8aRpkUY" %} [Commands: invoking methods](/2.3/manual/networking-state-changes/commands.md) {% endcontent-ref %} #### Holding State in a Single Source of Truth — The Simulator Sending state and sending input are not exclusive, games can benefit from these two strategies. Some games require state to not be transmitted by players, but by a special game client hosted somewhere online. This is usually the case for games with competitive nature, where preventing cheating is a major concern. In game networking this is often referred to as dedicated servers. In coherence we refer to it as **simulators**. In a game where there's a simulator involved, clients send inputs and receive state. The simulator takes those inputs and applies them, simulating the state for the rest of the players. This is caled **server-authoritative**. This has multiple implications, for example it shifts some of the burden of computation from user devices onto the server. To read more about this approach, see our section on server-authoritate setup. {% content-ref url="/pages/-MYg2ISb335jll59Sw6A" %} [Server-authoritative setup](/2.3/manual/networking-state-changes/authority/server-authoritative-setup.md) {% endcontent-ref %} {% hint style="success" %} With coherence you can combine server-authority and client-authority in interesting and useful ways. For example, it is possible to let players simulate some less-critical parts of the game state locally, while still sending player inputs to a simulator. {% endhint %} ### Optimizations By keeping track of what the other players know about the state of your game, it is often possible to reduce costly state transfer. For example, a player might drop an item on the ground, and send the new location of it to each other participant. Unless that item moves, it is unnecessary to keep sending the same position over and over. This simple idea is used pervasively in **coherence** (and other similar networking solutions) to great effect. It's important to acknowledge that a game sometimes generates many changes in a short timeframe. In such a situation, it is useful to prioritize changes based on how important they are for the particular game in question, while also factoring in how long it has been on hold. This means that an "old" change that doesn't get sent will build up importance and relative priority compared to other changes, eventually getting sent. Finally, a major way of limiting state transfer is to filter out uninteresting information and only send the most important parts based on the needs of each player. There's two mechanisms involved in limiting or filtering game state; what each entity decides to send and what players wants to receive. These two perspectives shape Levels of Detail (LODs) and Queries respectively. {% content-ref url="/pages/LAVhCmK6dnWiEgouwUMn" %} [Level of detail (LOD)](/2.3/manual/optimization/level-of-detail-lod.md) {% endcontent-ref %} {% content-ref url="/pages/EJboKWR9cXenHZ0yGj07" %} [Queries](/2.3/manual/optimization/areas-of-interest.md) {% endcontent-ref %} ### Relay We've covered sending inputs and sending state. But we didn't cover what that really means. Some networking solutions require explicit client-server architectures, where communications are direct and clear; clients send to the server, the server responds back. In coherence, **it doesn't work that way**. Even when using simulators, all the data is routed through a smart relay, at the core of our tech stack — the Replication Server. The role of the Replication Server is to keep track of who is connected and routes inputs and state back and forth between all connected clients and simulators. The Replication Server has knowledge of the game entities that can exist in the world, and applies queries and LODs to filter game state efficiently. Having the concept of a smart relay deattached from who holds state allows for a truly flexible and modular approach to networking that's core to how we solve networking. At the core of this flexibility, there's **authority**, or who dictates state over a network entity. ### Authority In any network transaction, there's always someone sending, and someone receiving. It's a one-to-many relationship. When an entity is sending state, we call it the **authority**. We can also refer to this as *the owner of the entity*, given the authority dictates the simulation. In coherence, authority is not per client but **per entity**, and it breaks down into State Authority and Input Authority — an entity might be the Input Authority (simulates the inputs) but not the State Authority (someone else is in charge of the state). Authority can be both **transferred** and **requested**. This allows for adjust your topology on the go. For example, you might decide that items near your player, or that the player picks up, are simulated by the player. Or you might decide who should be in charge of the global state (on a peer-to-peer) based on latency, and request/transfer authority accordingly. {% content-ref url="/pages/-MYPXxjUQ4ebxbnhK4Cs" %} [Authority transfer](/2.3/manual/networking-state-changes/authority/authority-transfer.md) {% endcontent-ref %} ### Transport Layer and Reliability At the core of networking there's a layer called the Transport Layer. In this layer, there's two protocols used. On one side there's TCP. TCP is reliable, meaning packets are given numbers and read in order. When a packet is lost, it's requested again. There's checksums and other mechanisms to ensure that the information you receive is exactly the information sent. This transport does not work well for fast-paced games, since their simulations run at many frames per second. By the time a lost network message has been resent and finally made it to its final address, the information in it will have a high chance of already being outdated. On the other side there's UDP. UDP is not reliable, meaning packets are sent, but there's no guarantees of their order, or if they are lost. **coherence** however adds a smart reliability layer on top of this protocol. If a packet didn't make it to its recipient, that packet will be sent again, but only after checking if any more recent changes to its data exist. This way, it is more likely that each player gets a consistent and up-to-date view of the shared game state. ### Time and Latency Sending data from one computer to another takes time, and there's no way around that. As a developer, it is important to embrace this fact and recognize that **it changes how you must think about your game logic**. When programming a single-player game (especially if it only runs on a single processor thread) we can assume that any change to the game state is immediate. In a networked game, this is not true. This means that each player of a networked game is playing in their own "parallel universe", which affects each other at a distance. Updates to data that you don't have authority over will appear in an irregular and unpredictable way. Knowing that fact, the challenge becomes how to correct out-of-order updates, unnatural movement and other unexpected circumstances. One way to mask and smooth this reality is interpolation. Interpolation is able to take snapshots of the state and blend them in a more natural and precticable way. coherence has interpolation built-in on its core, and all state you receive can be interpolated at the click of a button. {% content-ref url="/pages/-MYgThhR2VM1MFY3PMQ6" %} [Interpolation](/2.3/manual/networking-state-changes/interpolation.md) {% endcontent-ref %} ### Conclusions We hope that you feel more confident now thinking about the challenges of networked games. While networking surely can be tricky at times, it's also immensely cool and fun when it works. We believe **coherence** will make you reach that point in no time! Now that you grasp what this is all about, we can get hands dirty. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.coherence.io/2.3/getting-started/beginners-guide-to-networking.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.