- Network
- A
Hitchhiking through Multiplayer. Part 4: Authoritarianism and Topologies
This is the fourth article in the guide to developing multiplayer games, where I try to consistently and in one place gather the knowledge that will be required for conscious development of a multiplayer project.
Authoritativeness
In the context of multiplayer development, everything revolves around the term authoritativeness, which determines who is responsible for a particular aspect of the game.
Usually in multiplayer, the concept of authoritativeness is applied:
For management (Input Authority): determines which of the clients is the reliable source of input for a specific game object.
For data (State Authority): determines which node has the right to change certain game data and can be a reliable source of this data.
For creating and deleting objects: determines which node has the right to create or destroy certain network objects. For generality, we will further consider this a special case of State Authority.
These types of authority are closely related to each other. The client who has Input Authority over their character must send a command to the node that has State Authority over the data of this character to update its data after input: change position, shoot, etc.
The client itself can have State Authority over its own data, can have State Authority over another client's data, can have State Authority over part of the game world data or over all its data. The client can have both Input Authority and State Authority at the same time. It may also not have any Authority at all.
At the same time, the boundaries of a specific client's Authority can change dynamically. For example, some mechanics (such as the "Control" ability or handling a temporary disconnect) can temporarily take away the client's Input Authority and transfer it to another client or game server. Similarly with State Authority.
As a rule, all game clients have Input Authority most of the time, otherwise the game would not make sense for users. Having State Authority on the client, on the one hand, allows it to quickly change controlled data and respond promptly to these changes, but on the other hand, it opens up the possibility of changing them unauthorized, not "by the rules", gaining an advantage over other players. Therefore, if it is necessary to protect the gameplay from cheating, one of the following solutions has to be used:
Mutual data validation: clients must confirm the correctness of data operations with other clients. The more clients can confirm the correctness, the more reliable it is. Because a cheater's actions can be confirmed by another cheater. And if all players in the game are cheaters, they are on equal terms - let them have fun. But such checks greatly complicate the overall system and introduce additional costs in the synchronization process.
Transfer of State Authority to a trusted node: clients do not do anything with the data themselves, but only send commands to a dedicated trusted unbiased node (this is usually the game server), which performs correct operations on the data based on the received commands, and then sends the updated values back to the clients. This can apply to all data or only the most sensitive ones.
Topologies
The way Authority is distributed among participants in the project determines the type of topology on which multiplayer interaction is built. Usually, two groups are distinguished:
Clients with a dedicated game server.
Clients without a dedicated game server (P2P / Peer-to-Peer).
It is now difficult to find a true P2P. The solutions I have encountered use various intermediaries in their scheme to simplify communication, which does not fully satisfy the P2P concept. Therefore, we will understand P2P as simply an implementation without a dedicated game server.
Clients + Game Server
This is the most preferred and universal topology for multiplayer games. In this model, all clients participating in the session connect to a single game server. This allows centralizing game management, ensuring high reliability and control over the process. But the cost, in the literal sense, of such a solution is high.
By default, clients have Input Authority, and the server has global State Authority. For various optimizations, part of the State Authority can be transferred to clients. Usually, this is the Authority over the data of the controlled character. But the Authority for spawning and despawning objects usually belongs to the server.
🔗 Connection process:
We will discuss this in more detail later, but for now, for generality, we will hide these details behind the concept of Infrastructure.The client sends a request to get a game session. The request leaves its data (rating, level, etc.) and session settings (game mode, location, difficulty, etc.).
The infrastructure part receives the request and waits for requests from other players for some time.
The received requests from players are distributed among sessions depending on the players' data, their number, and settings.
The availability of running waiting game servers that meet the parameters is checked.
If some of the available servers are missing, new ones are launched (here clients will have to wait longer while the new server is being prepared).
Clients are sent an address for further connection to the target game server (or a message that there is nowhere to connect).
What happens between the server and the client was discussed in the previous part, so I will briefly remind you here.
💡 Server Features:
Does not render the game;
Manages logic;
Controls the game world;
Processes data from clients;
Synchronizes data between clients;
Stores game process data;
Ensures fair play.
💡 Client Features:
Renders the game process;
Receives input from the user;
Sends player action data to the server;
Receives current data changes from the server.
💡 Topology Features:
Versatility: this topology can be successfully used for any multiplayer games (but this is not always justified).
Centralization of logic and data: all (usually) data is stored and managed on the game server. All clients have a single (usually) and reliable source for synchronization.
Support for a large number of players in a session: full-fledged MMOs and Battle Royales cannot be implemented on other topologies.
The only option for fast PvP games: provides equal conditions, fair gameplay, and minimal delays.
Interaction with other nodes: since the server is isolated and unbiased, it can contact other servers (for example, a profile server) with elevated access rights that a regular client cannot have (for example, a client cannot have the rights to update another user's data, but the server can have such rights).
🟢 Advantages of the topology:
Scalability: the number of servers can be dynamically changed depending on the need for the number of sessions.
Adaptability: the power of the servers can be adjusted depending on the load.
Minimization of delays:
The server is usually located in a data center with high bandwidth;
A wide network of servers can allow players to connect to the closest servers;
This topology allows the use of various delay compensation technologies.
Protection against fraud:
Data is stored, processed, verified, and managed mainly by the server, which clients do not have direct access to, reducing the risk of cheating and increasing security;
This type of topology provides a wide range of fraud protection techniques.
Reliability: the server does not depend on clients and is isolated from them, so the server will be equally available to all players, regardless of the connection status of individual clients.
Equal conditions for clients: all clients connect with the same set of rights and powers to the same closest high-performance node.
Less computation on the client: since the logic is processed on the server, clients can refuse to calculate this logic locally, which reduces the load on the client device.
Cross-platform support for clients: client applications can run on different platforms, as interaction occurs through a common interface with the server.
Operational updates and fixes: to update the logic that works only on the server, it is enough to update the server itself without affecting the clients.
🔴 Disadvantages of topology:
Infrastructure issues:
Expertise: to build infrastructure or even to configure ready-made, especially efficient and scalable, expertise in backend and devops is required.
Financial costs:
Renting equipment or buying it with maintenance and subsequent updates;
Software, electricity, administration, etc.;
Alternative: using services that provide ready-made configured infrastructure.
Support: infrastructure is also code that needs to be maintained, improved, and fixed.
Risk of failure: the game server runs on hardware that works for a long time and at the limit of capabilities, gradually degrades over time and risks "burning out at work". You need to be always ready for this, have configured monitoring tools and backup nodes for quick user redirection.
Multiple complications with increasing complexity and scale of the project: no comments.
P2P
This is a network interaction model in which each client connects with other participants, bypassing the central server. This is a good option for developers looking to minimize infrastructure costs and simplify the implementation of their projects. However, this topology option is more suitable for games with a small number of players, limited security and scalability requirements.
This model can be centralized or decentralized, depending on the distribution of State Authority among clients. Each type has its own distinctive features, advantages, and disadvantages.
🔗 Connection process:
Everything is similar to the algorithm discussed above, except that the session is searched not among game servers, but among clients who are also looking for a session or have already started it and have a temporary window for connecting new players.
💡 Topology features:
Limitations: this type of topology is not suitable for all projects.
Support for a small number of players in a session: it is generally recommended to limit one session to ~10 players.
🟢 Topology advantages:
Infrastructure issues:
Cost savings: no need to rent and maintain game servers.
Simplification: the absence of game servers significantly reduces the complexity of developing and maintaining the infrastructure.
🔴 Topology disadvantages:
NAT issues: in modern conditions, it is difficult to connect to a simple private device, as it is hidden behind a variety of routers and gateways.
More computations on clients: in the absence of a server, the server logic must be performed by clients.
Instability: clients objectively lose in stability and power to a dedicated server.
Risk of fraud: without a dedicated trusted node, it is difficult to trust data from clients.
Cross-platform limitations: when directly connecting players to each other from different platforms, problems may arise.
P2P: Shared Mode / Distributed Authority
⚠️ Disclaimer ⚠️
My experience with this topology is quite limited. Mostly only at the level of pet projects.
This is a decentralized variation of P2P. In such a network, there is no leading node responsible for coordinating the entire system; instead, clients interact with each other "directly" (remember, this is not entirely true).
Here, State Authority is fully distributed among clients. Each client is responsible for the data of their character and the objects under their control. But the data of the game world (mobs, time of day, random global events, etc.) is either managed by a specific master client or the responsibility is also distributed among clients (some mobs to one client, some to another, etc.).
Master client is a kind of passing "label", giving State Authority over the game world data and/or the right to coordinate players in the session. It is given to one of the clients, usually the session owner, and then passed to another if the session owner can no longer fulfill their duties (for example, disconnected).
💡 Topology features:
Limitations: well suited for games with low latency requirements:
PvE;
Mobile gaming.
Deterministic implementations can be used to a limited extent in PvP (for example, in fighting games);
Without determinism, it is difficult to compensate for latency and protect against cheating;
Client positioning: the closer the clients are to each other, the better (with "pure" P2P).
Node equality: each node has the same status and can send and receive data from any other node.
Load distribution: the execution of logic and the corresponding load are distributed among all clients.
Fraud protection:
Players can confirm each other's actions.
A quorum of honest players can detect and suppress a cheater.
🟢 Topology advantages:
Simpler development:
Compared to other topologies and without determinism.
It may be easier to start developing your first multiplayer game with this option.
Clients on equal terms: no one has any advantage.
Resilience: disconnecting one of the clients is not fatal, the game will not end because of it.
🔴 Disadvantages of topology:
NAT issues: relevant for all clients.
Data loss: when a player disconnects, some of the data under their control may not have time to synchronize with others to the current state.
Non-portability: changing this type of topology to another in the future is very difficult.
Lack of determinism: without determinism, the approach experiences limitations in delay compensation and cheat protection.
Increased load:
Server logic in the absence of a server must be performed by clients;
As the number of clients increases, the load on each client increases.
Instability:
All clients depend on each other;
Clients have unstable connection quality (especially in Mobile).
Risk of fraud:
Clients have access to game data and have the authority to change it.
Cheat protection techniques for this topology are less effective.
P2P: Clients + Host
This is a centralized variation of the P2P topology, where one of the clients acts simultaneously as a client and as a game server, and the other clients interact with it as a game server.
Such a client is called a Host. Usually, it is the one who first created the game session, or the one who has the best conditions for performing the role of the host (for example, high bandwidth).
State Authority in this scenario, by analogy with the game server, predominantly belongs to the Host.
💡 Topology features:
Limitations: not suitable for PvP, as the host has an advantage.
Client positioning: the closer the clients are to the host, the better (with "pure" P2P).
Centralization of logic and data: all (usually) data is stored and managed on the host. All clients have a single (usually) and reliable source for synchronization.
🟢 Advantages of the topology:
Portability: it is relatively easy to switch to a dedicated game server model.
Stability: the host serves as the central point for synchronizing game states, which reduces the likelihood of desynchronization and improves overall game stability.
Game server techniques: the same techniques for lag compensation and cheat prevention can be used.
🔴 Disadvantages of the topology:
NAT issues: relevant for the host.
Data insecurity: the host has access to all data and can modify it without authorization (if it has Authority over it).
Host advantage: since the host is the server, it has "zero ping" (i.e., no delay in communicating with server logic).
Increased load on the host:
The host has to calculate not only client logic but also server logic, which can be heavy.
As the number of players increases, the load on the host increases.
Dependence only on the host: the quality of gameplay and connection solely depends on the host, which is an ordinary client and may have poor bandwidth or a weak device.
Instability:
Host disconnection ends the game for everyone.
The problem is solved by host migration (Host Migration), but not all frameworks provide this capability.
Even out-of-the-box host migration requires significant effort to implement.
When the main host is disconnected, some unsynchronized data may be lost.
Mixed
This is a combination of a P2P approach and a game server. The main game takes place in P2P mode, and the game server controls only certain aspects of the game related to fraud detection and synchronization correctness in the most sensitive areas. For example, it validates the fact of hitting a player or receiving a valuable item.
This approach allows maintaining the fairness and stability of the gameplay and reduces the load on the game server, making it more lightweight. This, in turn, will allow renting/purchasing weaker computing power in smaller volumes. This can have significant financial benefits on a large scale.
Roughly speaking, the advantages and disadvantages of both approaches are combined. And new ones appear. For example, such a system is much more difficult to develop and maintain.
NAT Issues
NAT (Network Address Translation) is a technology for translating network addresses that allows multiple devices within a private network to use a single public IP address to access the Internet. The main goal of NAT is to save IP addresses and ensure the security of the internal network.
🔎 How NAT Works:
Outgoing packet translation: When a device inside the network sends a request, NAT replaces the internal source IP address with a public one and keeps a record of this translation in the NAT table.
Receiving a response: When the response comes back, NAT uses the table to determine which device the packet belongs to and restores the original internal IP address.
Filtering incoming requests: NAT blocks all incoming requests that do not match previously established communication sessions. This prevents unauthorized access from outside.
The main problem with NAT in a P2P topology is that devices behind NAT cannot directly establish connections with each other. NAT hides the internal IP addresses of devices behind a common public IP address, making it difficult for them to exchange data.
📝 Ways to solve the NAT problem:
Local network:
A very effective and simple solution, but it is only suitable for computer clubs. For a large-scale global multiplayer game, it is not an option.
VPN:
Organization of a local network, but virtually. Programs like Hamachi work on this principle. It already allows you not to be tied to a specific place, but requires additional third-party settings or the installation of additional software from the user. Not user-friendly.
NAT Punch-through:
Two devices try to establish a direct connection by sending special packets through an intermediary server (STUN server). If it is possible to create a tunnel through NAT, the devices start exchanging information directly. But this may not work - no guarantees.
UPnP (Universal Plug and Play):
The UPnP protocol allows devices to automatically open ports on the router, making it easier to establish a direct connection. It does not work with all types of NAT and is not always supported by equipment.
Relay server:
Data is transmitted through an intermediary server (also known as relay), which acts as a bridge between devices. An additional server is needed, but it is reliable, universal, and hidden from the user.
Relay server
When implementing a P2P topology in game development, a relay server is usually used, without trying to complicate the project architecture and solve the NAT problem in other ways.
Relay server is a server through which all data between clients passes if they cannot establish a direct connection.
That is, a dedicated server still appears in the P2P scheme. But it is not a game server, and therefore very lightweight and easy to maintain. And services that provide relay services are much cheaper than services that provide game servers.
🟢 Advantages:
Reliability: even if a direct connection is not possible, clients can still communicate with each other through Relay.
Versatility: suitable for all types of NAT and firewalls.
Simplicity of implementation: you can avoid complex NAT traversal algorithms by focusing on the development of the game itself.
Invisible to the user: does not require any participation or additional actions.
🔴 Disadvantages:
Financial costs: expenses for renting and maintaining a server or service for Relay.
Increased latency: data transmission through an intermediary adds additional delay.
Topology selection
Topology is something that needs to be decided at the very beginning of development. The further the project moves away from the starting point, the more difficult it will be to change anything in this matter. And the implementation of the ability to work in any mode will turn development into a cognitively complex process, which will affect the maintainability of the project and the overall speed of its development.
On the Photon website, you can find a topology quadrant, where the most popular genres of multiplayer games are distributed according to the most suitable solutions with a very high-level indication of pros & cons. If there is not enough experience to independently choose a topology, this scheme will help set the direction in the right way.
In the recent Unity 6 release, a Multiplayer Center was added, which can also help choose a technology stack and a suitable topology option for the project according to the specified parameters. Of course, it will offer products specifically from Unity, but no one will prevent you from using analogs. Although solutions from Unity will be the simplest and most accessible to use. I like them.
Recommendations
Different teams and different projects have different requirements. Everyone has different conditions. And general recommendations will not lead to the best solution, but rather to some common one. Therefore, it is not necessary to follow all the recommendations for choosing a topology or other aspects. But you need to do this consciously, understanding the reasons and possible risks. This awareness comes only with personal experience, working in various conditions and different teams.
And, based on my experience and the experience of related teams, I have a few recommendations.
1️⃣ Singleplayer:
You should never forget about singleplayer if the genre allows it. No matter what the management says, if singleplayer is possible for the genre, it will appear sooner or later. Making a singleplayer out of a multiplayer is as difficult as making a multiplayer out of a singleplayer. So it's better to lay the groundwork for working in multiple modes right away during development.
2️⃣ Dedicated server and Host:
When developing a game with a dedicated server, it is worth immediately laying down support for the host mode. Firstly, it is practically a free singleplayer (the client just needs to become a host for itself). Secondly, it is not difficult to do during the development itself, but it will require a lot of effort if done later.
The host mode and the dedicated server mode do not have a significant difference in terms of implementation: the codebase is also divided into Client, Server, and Shared. The only difference is where the server logic is running. And nuances arise when the server logic works alongside the client logic. Conflicts, logic duplication, or other issues may arise. They are usually resolved by additional checks or restrictions. And they are very easy to find: just run the developed feature in both modes and make sure that it works equally well everywhere.
While the developer is immersed in the context of the developed feature, it will not be difficult to make additional checks. But to do this later, after some time, you will have to immerse yourself in the context from the very beginning and fix the codebase, which will have grown with other dependencies, which can complicate the work and shake the stability of the project with a chain reaction.
3️⃣ Bot support:
Due to inexperience, they often do not think about it or think about it, but not immediately. A multiplayer game, especially at first, may not have enough users. This leads to two important problems:
The player waits a long time for the game to start, as there is a long search for session participants;
The player may end up playing alone.
Both of these problems lead to a deterioration in retention rates. Players do not want to wait long. And players do not want to play something that is not in demand. If there is no one in the game, then the game is probably not worth attention. And playing a multiplayer game without users is boring.
Therefore, it is worth considering the possibility of simulating other players during development: prepare a convenient API for managing game characters and develop an AI system. Bots will be able to quickly fill in the missing places in the session and brighten up the gameplay for lonely players. This will also allow you to create training or educational sessions where the player can independently familiarize themselves with the game's capabilities or hone their skills.
4️⃣ Disconnect handling:
Another important point that is not usually thought about right away. Players can leave the game, either voluntarily or under the influence of other factors.
What to do in such cases? How critically does the gameplay change for other players if someone leaves the game? Will the player be able to return to the game? And many other questions that need to be answered when developing a project. The answers can be absolutely diverse, but it is better to know them from the very beginning. Some information may be fundamental.
For example, if it is a PvE game, the control of the disconnected player's character can be transferred to the AI to smooth out the negative consequences for other players. And the disconnected player can be prohibited from connecting to others for the duration of the match, so that they can only return to the already started match. And when connecting, return control of the character back to the player.
For intentional exit from the match, penalties or temporary bans can be imposed. And if the host leaves the game, then you also need to take care of the hot change of the host in the session.
This all implies the development of some additional systems that may require very deep placement in the project. And it is much easier to lay such systems at earlier stages than at later ones.
Conclusion
The most commonly used connection topology options and their features were considered. It should become a little clearer which option to choose for your game and your budget. But over time, you will need to try each one. Topology is not something that can be chosen once and then used in every project. The choice will have to be made regularly, weighing all the "pros" and "cons" for each new case.
Having decided on the type of connection, this connection then needs to be organized in some way. Players will need to be guided from the introductory screens to the actual joint gameplay. And the arrangement of these behind-the-scenes processes will be the subject of the next part of this series.
Write comment