Custom Networking Module¶

With the architecture of MAGES NXT, when it comes down to swapping between core modules, its flexible design allows developers to implement and incorporate their own solutions for various underlying functionalities. One solution we are currently working on is a Custom Networking Module powered by the open-source Riptide Networking Library. This lightweight networking library allows us to have more control over our networking architecture as we are building our networking infrastructure from the ground up, achieving better overall co-op performance compared to third-party networking solutions that are designed for more general usage purposes (PUN).

Riptide Networking Library: Read More

Although alternatives within professional environments may offer expedited integration for multiplayer sessions, they are often subject to subscription fees and feature bloat, resulting in inflated costs and complexity (e.g., anti-cheat checks), leading to increased processing overhead and greater difficulty in manual intervention and optimization of their architectures.

We believe that by further minimizing send rates and reducing the network packet sizes to include data that precisely match our exact needs, will yield us reduced bandwidth usage results that will allow us to increase our CCUs (concurrent users) and objects per session. So far, our internal testing results seem quite promising in this regard. Further batch sending/processing optimizations have been made to improve the overall application performance. Once again, since we have more control with such a solution, depending on our usage scenarios, we can meticulously adjust certain values that can distribute the load between network bandwidth usage and CPU processing, by altering our send rates, our packet batching process, whether we opt for encoding/decoding our data, and so on.

Furthermore, we will exercise control over our server infrastructure, which should result in reduced monthly CCU costs. As far as the server architecture is concerned, we will include an always-on master server that will be responsible for the initial handshake connection of our users. They can then request a private session to be created and receive a list of the already available sessions for them to join. Each session will be powered by a lightweight custom relay server that we will have full control of, and all of our servers will be hosted on our preferred cloud services.

Last but not least, such unparalleled access over our networking architecture allows for easier collaboration with other custom networking features (our upcoming Physics Dissection Module).