Reactor: a server-authoritative Unity multiplayer engine, 9.5x less transform bandwidth than Photon Fusion 2 and NGO

Community Showcases
1

Reactor is our Unity multiplayer engine. It is built around three things: server authority, dense physics, and getting the most out of every byte on the wire. This thread is the place to follow it and ask us anything.

What it is

Reactor is server-authoritative by design. The room is the authoritative server. It can run simulations using PhysX, handles raycasts, sweeps, and overlap queries, and holds authority over entity state. Client input is treated as input to validate, not state to trust. This is not a relay with authority bolted on the side. This is intended for server-side simulation, however setting it up to sync just the basics using components and very little code is possible too.

Prediction and reconciliation are built in, so movement stays responsive without giving up that authority. There is also a shared-authority mode for simpler games and for converting a single-player controller to multiplayer. The server compiles separately from Unity, so a change to client code does not trigger a server recompile, and the reverse.

The bandwidth part

We’ve focused on making the bandwidth part as simple as possible - automatic. You choose your fidelity, and Reactor does the rest. Reactor builds a data model from your game’s state and compresses it automatically: no serialization code, no profiling, no hand-tuning as the game changes. That is usually months of unglamorous, bug-prone work, and Reactor takes it off the table.

In our controlled bandwidth comparison against Photon Fusion 2 and Netcode for GameObjects on identical scenes, Reactor moved 9.5x less transform data. The methodology is public if you want to run it yourself: benchmarks/UnityNetworkTransformBenchmark at main · KinematicSoup/benchmarks · GitHub

Real numbers from games built on it:

  • Kazap.io: about 0.5 bytes per transform
  • Braains2: under 1 byte per transform, running 100 players and 150 physics objects at 30 Hz, about 35 KB/s per player at full load
  • Ruins: frequently under a byte per transform through continuous physics destruction

A hand-tuned encoder built for one game might match this in a narrow case. The difference is that it costs you that engineering and breaks as the game changes, while Reactor gets you there on its own and keeps it there.

What it is good for

Games where the technical requirements are the binding constraint: server-authoritative physics, large crowds, high entity counts, competitive games, persistent worlds. If bandwidth or physics is what will cap your game or your hosting bill, that is where Reactor earns its place. A client can also be connected to many rooms at once, which opens up zone sharding and running services like chat, matchmaking, or leaderboards as separate rooms.

DOTS support

Reactor supports Unity’s Data-Oriented Technology Stack. For ECS-based games, the kind built for large crowds and high entity counts, that lines up directly with what Reactor is already good at. DOTS support is available now and in active development, so expect it to keep expanding.

Hosting and pricing

Free to develop locally. Free to self-host up to 32 CCU. When you are ready to go live, Reactor Cloud handles managed hosting with one-click deployment and no servers to provision. Details:
Reactor Features: Multiplayer Engine for Unity | KinematicSoup

Getting started

Install through the Unity Package Manager with a git URL. Full steps: Get started with Reactor | KinematicSoup

Examples

From our work to support Unity DOTS, Reactor can power vampire-survivors-like games with over 5k entites!

Here is a benchmark that compares the currently popular networking solutions to Reactor:

Video:

Interactive Web build: Reactor Benchmark
Github: benchmarks/UnityNetworkTransformBenchmark at main · KinematicSoup/benchmarks · GitHub

Here is a single-node test where we employed 10k headless game clients connecting to a single node and each controlling it’s own character, plus 4 more real players joining the environment:

Another use-case is to do fully synced environmental destruction like this:

The playable version is here: https://ruins.kinematicsoup.com.

Key features

  • Server-authoritative rooms with full server-side PhysX
  • Built-in client-side prediction and reconciliation
  • Automatic, adaptive bandwidth compression, no serialization code to write
  • Shared-authority mode for simpler games and single-player-to-multiplayer conversion
  • Multi-room connections per client for zoning, sharding, and microservices
  • Lean multi-threaded server runtime, tens of MB overhead, scales across cores
  • Server compiles separately from Unity for fast iteration
  • WebGL support
  • Orchestration API for spinning rooms up and down
  • DOTS support, available now and in active development
  • Managed hosting via Reactor Cloud, or self-host

Questions are welcome in this thread. We also talk netcode in our Discord: KinematicSoup

That’s the complete post with the reworked bandwidth section folded in. Only the Examples section still needs your current video/demo links before it goes up.

Want me to draft the bump reply (the physics-prediction prototype clip + a pointer to your new discussion thread) next?

2 Likes
Which Multiplayer Solution for Fast Paced Shooters?
2

No problem. If you have any questions feel free to ask.

3

@grimunk Hi, are you still active? I want to ask some question.

4

@restush96 yes we are active, and we’ve posted Reactor 1.0.0 this week. It’s available here: Download Reactor — KinematicSoup Technologies Inc.

5

Just bumping this we we’ve released some small updates to Reactor and I’ve updated the description.

We’ve been experiementing with more relay-like topologies, and it is possible to convert from other popular solutions to Reactor if you find that you’re running into limitations such as peak CCU, bandwidth, latency, or the ability to implement more advanced prediction.

6

tl;dr Reactor is Fantastic!

Greetings,

I just want to share that I’ve been building an MMO game for the last 8 or so years. It was early 2017 that I first discovered Kinematic Soup for their discussion on client side prediction, which at the time wasn’t really a widely discussed topic. The article can be found here: Client-side Prediction for Smooth Multiplayer Gameplay — KinematicSoup Technologies Inc.

It was through Kinematic Soups resources that I originally learned how to synchronize a game state on a game server. As time went on, the challenges in my project amplified and mounted up. The synchronization engine I wrote was far from polished, and the netcode was bloated. Too much was re-inventing the proverbial wheel.

Fast forward 7 years, I went back to Kinematic Soup and sought out their Reactor Engine that they had been developing for nearly as long as I have been working on my project. I’m extremely grateful to have been given access to this system before it’s release, and I only wish I had reached out sooner as it opened for me a new way to develop. The structure of my project and overall work flow is better and I have more peace of mind with how simplified everything is now, where as before there was a lot of complication.

I even decided that it was worth rebuilding my project from the ground up, around Reactor, rather than trying to shove reactor into a bloated project. It took me only a few months to catch up to where 8 years of development had gotten me.

I want to emphasis that Kinematic Soup Reactor is not a here and gone solution, but rather a carefully developed, long in the making Multiplayer Solution. It is the best solution I have ever found for handling a MMO project, and I want to share my experiences.

So what makes Reactor so good? In short, everything!

Reactor does not use any unity code, which means it is not tied down to a unity build and is much simpler, more powerful in terms of optimization and uses less CPU/Memory long term. This means you will save on costs when it comes to servers.

Reactor also compresses all of the network load better than any other solution I’ve found, and a single server is capable of handling thousands of networked entities at a single time, with the appropriate considerations and steps taken for that scale.

A wonderful part of reactor is that the server and client code is all placed into the unity project structure, keeping the code in one project solution, while strictly keeping the server code separate from the client. This allows you to attach your server scripts to game objects, letting Reactor know where things go, but at the same time not allowing your server code to depend on Unity.

Reactor also has found a way to allow clients to continue to use their Rigidbody and Colliders provided by unity, and the server uses a separate system and they both are able to compliment each other to create a synchronized game state. So the whole time you’re developing with Reactor, you will continue to use familiar code and logic, but in a completely different way than any other unity networking system has ever provided.

The local server is not unity based, which means you do not need to run the scene as a host/run a separate server or compile an extra unity build for local development. Instead all you need to do is save the changes to the server code, and the local server build will automatically recompile before you can even press play in Unity. Sometimes it feels like you’re not even making a multiplayer game with Reactor, it is just too simple at times to be real.

Reactor also handles the entire game state for you. It’s completely server authoritative, and also provides Client Side Prediction for your player controllers.

Designing a player controller that is predicted on the network is as simple as designing a normal player controller in unity.

Reactor also hosts your servers for you, and even provides a convenient cluster server, so those of us building big game worlds that need many rooms, we are in paradise.

There is a lot more that I could share, but I will leave it at this. Reactor is a really well designed multiplayer platform, and I am grateful to use it, and glad for it’s invention. I have used DarkRiftNetworking, PlayerIO, FishNet, Mirror Networking, UNet, Photon, SmartFoxServer, I even wrote my own at one point. I tried them all, but none of these are Reactor.

7

I’d like to bring you attention to another Reactor-based project called It’s Mealtime!

It’s Mealtime! is a game that combines fast paced cooking with multiple frantic challenges that will determine your restaurant’s success!

Play in teams of 4 in either competitive PvP or challenging Co-Op modes.

It’s coming to Steam! Wishlist it here: http://bit.ly/3jsHlM9
Twitter: x.com
Discord: https://discord.gg/hmBKMdg

This is a game by Team Madness Studios, and features real-time physics and multiplayer with up to 8 people. Team Madness selected Reactor during development because they made quick progress on their vision and found that the built-in physics syncing, prediction, and bandwidth efficiency of Reactor suited their needs above all other solutions available.

8

Hi,

You claimed in the past that your solution uses 10 times less bandwidth than Photon Fusion, you said you were going to make a case study for that. Was that done, and if so, where can we find it?

9

We have an internal benchmark project that will test all frameworks in a variety of scenarios. The bandwidth advantage varies depending on the test and how random the motion is. It’s always better by some multiple though and the more game-like the test is, the bigger the advantage.

There is an existing benchmark on github that is too tightly bound to Unity to easily use it with Reactor, at least for now. We did reimplement but it’s limited in that it only tests tranform updates for a fixed number of objects, and doesn’t test object teleportation, scale changes, properties, RPCs, or object creation/destruction. We’re working on another one and will release it in a course with additional samples such as our FPS1000 samples - an FPS with input prediction, physics interactions, server-side hit verification, and randomly generated levels.

10

Update

We have put up a version of Reactor that allows for self-hosting. Integrated hosting is also active - if you try Reactor and like it, you can support us by using our hosting.

It’s available from our website.

More updates are coming very soon.

11

We’ve posted a benchmark to github. It’s a simple benchmark to compare bandwidth usage of several multiplayer options.

The settings are described, as well as the results. There is a live build here: Reactor Benchmark

12

Update

Reactor 1.1.1 is out and now supports MacOS arm64. The correct local server is installed automatically.

We started work supporting Unity DOTS. Client performance is often the limit we encounter when using Unity gameobjects.

Over the last week, we put together a ‘vampire survivors’ multiplayer prototype. 3D, multiplayer, 10000+ monster mobs! Reactor + DOTS and it performs great (the video capture software, on the other hand, doesn’t).

13

Reactor 1.1.2 is now live.

Added

  • Reactor Getting Started screen
  • Added ksVector2Int and ksVector3Int with implicit conversions to and from Unity Vector2Int and Vector3Int structs.
  • Added integer vector support to ksMultitype used in Room/Entity/Player properties and RPCs.
  • Added “Stop Local Servers When Editor Exits” toggle to the Reactor settings which is enabled by default.
  • Added ksNetCounters.Types.TX_ENTITY, TX_TRANSFORM, TX_ENTITY_PROPS, and TX_ENTITY_COUNT for tracking transmitted data for owned entities.
  • Added ksRoom.OnSentFrame event that fires after the client sends a frame to the the server.

Changed

  • Improved network transform updates to apply position and rotation to gameobjects at the same time.
  • Precompiled assemblies changed to .netstandard 2.1
  • Improved network decoding performance.
  • ksConnect no longer tracks a single ksRoom instance for its entire lifetime. A Room property is now added to the ksConnect ConnectEvent and DisconnectEvent objects. The ksConnect.Room property is marked as obsolete.

Fixed

  • RUDP connection errors when sending messages exceeding 150KB
  • OnConnect is now invoked with an error status when an RUDP connection fails.
  • Fixed a bug where server scripts were sometimes not loaded correctly on room prefab instances when prefab instance scripts had different enabled states then their prefabs.
  • Fixed a bug where default entity physics settings used the wrong values on room prefab instances when the prefab instance had different values than the prefab.
  • Fixed an error message when serializing a ksMultiType.NULL property or RPC argument on the server.
  • Starting a local server when Auto Rebuild Server is unchecked will no longer prompt you to build the server runtime if it is not dirty.
  • Fixed a bug where disconnected player data was synced to connecting players if multiple players disconnected on the same sync frame.
  • Reconnecting on the same frame you disconnect or fail to connect works now and will not get a ROOM_INITIALIZE error.
  • ksNetCounters.Types.TX_EVENTS and TX_INPUT track transmitted RPC events and input now instead of always reporting 0.

DOTS Support

Our DOTS extension is also available here Releases/ReactorDOTS/0.0.1-alpha at ReactorDOTS0.0.1-alpha · KinematicSoup/Releases · GitHub

This is an alpha build and is under active development. Reactor + DOTS is a reliable way to hit huge multiplayer entity counts and high CCU counts.

You must use it with Reactor 1.1.2.

Questions welcome here as always, and we talk netcode in our Discord: KinematicSoup