Networking
The R-Type game features a multiplayer mode, backed by a custom advanced networking protocol. The following document explains the high-level architecture of the protocol. You can refer to the RFCs for detailed information about the protocol and the design decisions.
Design goals
While the protocol is designed to be as simple and modular as possible (to allow some parts to be reused in other games), it should also be designed around the constraints of a fast-paced co-op game like the R-Type.
The protocol is designed around the following goals:
- Good gameplay experience: the player should be able to enjoy the game
in the best possible way, even in bad network conditions.
- R-Type is a fast-paced game, where moving a pixel too far or a millisecond too far may be the difference between a win and a loss.
- The game is a co-op game, not a PvP game. Even if coordination with teammates should feel reactive when possible, we should prioritize the interaction with the game-controlled entities.
- We should avoid any rollbacks/jumps of any entity due to bad network conditions (resulting in a possible loss of synchronisation with the server).
- The player must have the lowest perceptible latency when playing online. For example, we should avoid any latency between the player input and the screen update.
- Graceful degradation: the game may be played in bad network conditions.
The protocol should be designed to provide the best experience possible in
these conditions.
- The protocol should use the least amount of bandwidth possible.
- We should handle high latency or packer loss/temporary disconnection gracefully, without resulting in a loss of synchronisation with the server.
- Dumb clients: the game will provide a global leaderboard, where players can compare their performances. The server must be the source of truth of the game state, and no client should be able to manipulate this state.
The protocol will be used for all communications between the client and the server, including real-time synchronization of the game state or more traditional communications (such as fetching the global leaderboard or in-game chat).
High-level design
The game networking is built around multiple components that are designed to be modular and reusable:
- Transport: the transport layer is protocol built on top of UDP, responsible for sending and receiving packets.
Previous work
The following articles were used as inspiration for the design of the protocol:
- Quake 3 Source Code Review: Network Model
- Peeking into VALORANT’s Netcode
- Reliability and Congestion Avoidance over UDP
Other open-source libraries/protocols were also used as reference: