In the recent Intenics Hackathon, I explored Unity NetCode for GameObjects, comparing it with traditional networking options like KryoNet (Java) and LiteNetLib (.Net).
Traditional Networking in Games
Older networking libraries for games, such as KryoNet and LiteNetLib, work at a basic level. They let game developers decide what data to send and to whom. This demands careful planning but offers freedom to optimize for different game types, from massive multiplayer online (MMO) games to turn-based ones. It also enables the implementation of specialized networking patterns, such as deterministic lockstep.
Usually, I use Networking Controllers on both the client and server sides. These controllers break down network events and feed inputs into my local event system or a similar setup.
Unity's NetCode for GameObjects
At this hackathon, I tried Unity's new NetCode for GameObjects. It operates at a higher level, synchronizing game objects directly. Developers need to specify which properties of game objects should be synchronized and in what direction. It also supports remote procedure calls for events on connected peers (servers or clients).
This method is good for peer-to-peer games or small server-client games like real-time strategy or cooperative games (think Valheim or Overcooked).
NetCode for GameObjects seems designed for indie developers who want to add multiplayer features later in their game development. Usually, adding online multiplayer late in development is discouraged, but with NetCode for GameObjects, it becomes feasible, especially for simpler cooperative games.
This is great news for developers new to multiplayer gaming but have a successful single-player game. For instance, the creators of "Don't Starve" would have found it easier to add multiplayer with this tool.
Limits of NetCode for GameObjects
While great for small-scale multiplayer, NetCode for GameObjects has its limits:
- Massive Multiplayer Needs: In huge multiplayer games, you need to manage messages carefully to reduce network traffic. For example, a player's attack on an enemy should be handled with minimal data transfer. NetCode for GameObjects might overcomplicate this with too many remote calls, whereas a simpler event-based system could be cleaner.
- Server Requirements: Using Unity for servers demands more system resources, affecting hosting costs and scalability. A straightforward C# application uses less memory and doesn't require Unity licenses or specific Unity versions on build servers, simplifying the development process.
- Scene Management: Unity servers need to be in the same scene as clients. This can be challenging, especially for server-focused developers not used to working with scenes. It often leads to extra server-specific code to manage these scenes.
Conclusion
NetCode for GameObjects is suitable for small-scale, peer-to-peer games. However, its limitations in build system compatibility and scene management make it less appealing for my server development background. I prefer the flexibility of traditional networking libraries like LiteNetLib for larger Unity multiplayer projects.
For developers new to multiplayer and working on small-scale projects, NetCode for GameObjects is a valuable tool. For others, traditional libraries like LiteNetLib might be a better fit.
Also, Unity NetCode for GameObjects finally makes some statements on my old blog post on game networking obsolete. Peer to Peer can be cheep now. So use it for coop games.
