Unity NetCode for GameObjects: The Future of Multiplayer Gaming?

In the recent Intenics Hackathon, I explored Unity NetCode for GameObjects, comparing it with traditional networking options like KryoNet (Java) and LiteNetLib (.Net).

6 months ago   •   3 min read

By Benjamin Justice
Table of contents

In the recent Intenics Hackathon, I explored Unity NetCode for GameObjects, comparing it with traditional networking options like KryoNet (Java) and LiteNetLib (.Net).

Screenshot from my prototype developed during the hackathon
I used rock-paper-scissors for my Unity NetCode for GameObjects prototype

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).

Screenshot of a ServerRpc (Remote Procedure Call) using Unity NetCore for GameObjects

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:

  1. 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.
  2. 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.
  3. 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.


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.

Spread the word