Discord : LucasG#8004
Currently working from Canada.
Share this page:
LinkedIn
Facebook
Twitter
WhatsApp
Email
Telegram
The RekT protocol (Rapid Encrypted Knot Transfer) was developed as part of the project course during the Winter 2023 semester at UQAC (University of Quebec at Chicoutimi), taught by Valère Plantevin. The project involved simulating several hundred players on a single game map using Unreal Engine. The course was attended by a group of eight students aiming to deepen their knowledge of online multiplayer video game development. The course followed a “research” format, meaning we were left to our own devices to tackle challenges and independently learn about new technologies and concepts. Nevertheless, we provided weekly progress reports to ensure the project was on track.
The group was divided into two teams. The “game engine” team (five members) was responsible for understanding how the Flecs ECS (Entity Component System) worked to manage all player actions on the client side. They also had to replace Unreal Engine 5’s replication system to support the protocol developed by the second team. The “network” team, consisting of three members, was tasked with writing a pub/sub protocol and coding a broker (server) capable of handling as many connections as possible with minimal resource consumption.
For this project, I was part of the second team, and the following sections of this article will detail the networking aspects of the project.
For our team, the work was divided into two phases. The first phase was focused on research and design, during which we learned about how pub/sub protocols function and compiled a list of requirements for a network protocol in video games. This allowed us to draft our own protocol, the RFC for which can be found here. The second phase involved coding a broker that uses our protocol to enable the “game engine” team to simulate connections with up to 300 players or more!
In short, our goal was always to push for greater performance and optimization!
The RekT protocol (Rapid Encrypted Knot Transfer) is a UDP-based network protocol designed to meet the speed and optimization demands of multiplayer video games with a large number of players. Inspired by the Tachyon protocol, RekT primarily focuses on fast data transmission. Aware of the specific requirements of multiplayer games with a high player count (300+), RekT aims to minimize latency and optimize network performance.
During the initial connection, RekT employs a handshake system to verify client authenticity and register them as valid connections on the server. Once the connection is established, the protocol operates on a pub/sub (publish/subscribe) model using topics and objects (groups of topics). This allows clients to subscribe to relevant topics to receive only the data they are interested in.
To simplify implementation, RekT does not currently support authority systems or encryption. However, we are aware that data security must be considered and could be added in future versions of the protocol.
To maintain an active connection with the server, clients must periodically send requests or “heartbeats” to signal activity when no other requests are necessary. If a client fails to maintain this connection, the server will disconnect them.
The development of the RekT server’s coding phase progressed gradually, overcoming the challenge of mastering the Rust programming language, which was entirely new to us. Our work took the form of a project with three major versions, which I will briefly summarize below. You can check out the GitHub repository to view the code.
Version 1 — Learning the Language: In the “GYM” folder of the project, we focused on learning the Rust language. This step was crucial for acquiring basic knowledge, understanding the syntax, and absorbing Rust’s programming best practices. In this version, we succeeded in enabling two clients to communicate with each other without implementing the heartbeat system (connection maintenance verification) or ping calculation. Since the broker was synchronous, we were unable to handle multiple tasks simultaneously. This limitation led us to move to the next stage with version 2.
Version 2 — First Asynchronous Broker with Tokio: The “Async_broker” folder was dedicated to creating the first functional version of the broker using the Tokio library for asynchronous programming. Although all features were present, this version failed to meet the performance and speed expectations required by the RekT protocol. Our approach to using Tokio’s asynchronous tasks struggled with resource sharing, leading to significant memory duplication and excessive simultaneous asynchronous task creation. This resulted in exponential RAM consumption and disproportionate CPU usage.
Version 3 — Optimization and Message Design Pattern: The “Async_broker_message” sub-folder focused on further optimizing the broker and correcting improper usage of the language. We adopted the message design pattern to improve the management of concurrent asynchronous tasks, drastically reducing the number of simultaneous tasks and better managing variable propagation between tasks. Additionally, we revisited the shared data structures used across tasks to minimize cloning and rely as much as possible on references. This optimization phase was critical in enhancing the broker’s processing capacity and achieving the performance requirements of the RekT protocol and the overall project.
To test the work of both teams, the “game engine” team created a very simple game playable by an AI. The game consists of a basic maze with colored doors. To pass through these doors, players must match their color to the door’s by pressing a key to switch between colors.
This project was a success for us because we managed to implement all the necessary steps to independently learn the skills required to meet the project’s needs. Our professor acknowledged the effort we put in and praised the final result, which was highly satisfying!
In the gif above, you can see 300 replicated AIs playing the game while being synchronized over the network. The movements remain smooth and consistent despite latency and potential network lag.
In the gif below, we take a closer look at the behavior of the AIs near a red door.
Currently working from Canada.