I built SimpleNet, a modular C++ networking library powered by the ENet protocol, to simplify the process of creating real-time multiplayer applications. I made this as networking in games was often overwhelming, with needing to handle packet serialization, client/server systems and error detection from scratch. SimpleNet abstracts much of that boilerplate work, providing a clean, event-driven framework for sending and receiving data, managing connections and keeping multiplayer interactions reliable. This is currently still being updated!
​
One of my main goals with SimpleNet was flexibility. Each part of the system, whether it’s packet handling, client/server management or debugging tools, can be used independently or extended, making it easy to adapt to different project requirements. This modular design means I can start small, quickly prototyping multiplayer features and then scale or customize as their projects grow more complex.
​
To demonstrate its capabilities, I created a small multiplayer test game that uses SimpleNet to synchronize players across multiple clients. This project not only showcased the library’s reliability and low setup cost but also highlighted its potential as a lightweight, developer-friendly networking solution for game projects of varying scale.
How It Works
Photo Of Case Usage of Using SimpleNet. This Is Demonstrating Using appendPOD() to send data to the server. Can Be Found By Pressing The View Code Button.
SimpleNet uses ENet's reliable UDP transport layer to handle fast, low-latency communication between servers and clients. A server instance can be created to manage connections while each client communicates using structured packets that contain gameplay data like player movement or game events.​
The system uses callback-based event handling so developers can define custom reaction when clients connect, disconnect or send data. Packets can easily be built and read with template-based methods like appendPOD() and readPOD(), making it straightforward to send and receive structured game data without writing manual serialization code.
Key Features
-
Server and Client Systems - Simple setup for hosting and connecting players using ENet’s reliable UDP model.
​
-
Packet Serialization - Template-based read/write system for transferring structured data (e.g. positions, states, actions).
​
-
Event System - Callback structure for handling connection, disconnection and message events efficiently.
​
-
Error Handling Tools - Basic tracking for connection health and debug output for testing.
​
-
Modular and Scalable Design - Works in Visual Studio projects or integrated into engines like Unreal Engine 5.
Photo Of Case Usage of Using SimpleNet. This Is Demonstrating Creating Clients & Servers. Can Be Found By Pressing The View Code Button.
Comparison Between SimpleNet & ENet
Reflection on the Cons of SimpleNet
While SimpleNet streamlines most aspects of networking by abstracting ENet's low-level operations, it isn't without trade-offs. Because it's built on top of ENet, integrating SimpleNet into a new project requires configuring both libraries which adds extra setup compared to just using ENet alone.
Additionally, SimpleNet's abstraction does limit access to some of ENet's more convenient low-level controls. For example, ENet allows developers to manually configure per-packet reliability flags and modify peer timeout behavior in more specific detail. However, SimpleNet standardizes much of that for each use; Making packets being handled through predefined structures and generic send/receive methods making it difficult for developers to override transmission flags or implement advanced per-packet prioritization without modifying the library itself.
Challenges
Throughout the development of SimpleNet, I encountered several technical and architectural challenges that shaped the library into a more stable and developer-friendly networking solution. Below are a few of the major challenges I faced and how I resolved them:
​
-
Challenge 1 - One of the core design questions behind SimpleNet was determining how much of ENet's low-level functionality to expose. For context, ENet offers very granular control, such as custom timeouts, bandwidth throttling, packet flags, etc. If I abstracted too much, users would lose access to these advanced optimisations; But if I exposed too much, SimpleNet would lose its purpose as a simplified, modular library.​​
​
-
Solution - To resolve this, I implemented a layered design approach. I exposed optional "advanced access" hooks that allow developers to retrieve ENet peer objects or adjust specific channel/packet parameters when needed. This preserved SimpleNet's simplicity while still supporting fine-tuning for more demanding use cases.
​
-
Challenge 2 - A more technically specific challenge I had was that, in my first version of SimpleNet, the library used raw memory copying for serialisation. This caused occasional crashes when sending structs with non-trivial types (eg, std::string, ints, floats, etc.). This happened due to me enforcing a POD-only packets, making the library too restrictive.
-
Solution - To fix this, I implemented a byte-stream serializer/deserializer class that writes variables safely with size prefixes. This worked as safe, explicit serialisation eliminated undefined behaviours and made SimpleNet flexible enough to handle complex data structures cleanly.