Reactor Multiplayer Engine
The Same Engine for Co-op
and Crowded Worlds.
Reactor is built for performance that holds at scale. The workflow stays out of your way, and the infrastructure keeps running without babysitting.
Why Reactor
What Other Engines
Make You Build Yourself.
Prediction and reconciliation are built in
Other engines give you primitives and expect you to build the authority model yourself. Reactor ships with one, so your time goes into configuring how it behaves rather than building it from scratch.
The server only runs simulation code
No renderer, no audio, no client systems. The server process loads only what affects game state, which keeps memory and CPU overhead predictable.
Message ordering is enforced
RPCs, property changes, and entity events are sequenced by the engine. Consistent ordering is not something you build on top of Reactor.
Minimal code to get online
Reactor does not require framework boilerplate before you can write game code. Getting a server running and syncing entities is a small amount of code.
01 · Performance & Scale
Designed to Sync Worlds
Previously Considered Impossible.
Realistic physics, large crowds, and persistent worlds with thousands of moving parts. Reactor handles these without exotic server setups or specialist networking knowledge.
Network Culling
Sync Groups: Only Send
What Each Player Needs.
In a large open world with 20,000 entities, each player only needs to see the nearest 5,000. Reactor's sync group system partitions the scene into spatial cells and automatically assigns players to the groups containing nearby entities, reducing per-player bandwidth and server load as your world grows.
All entities default to group zero, which syncs to everyone. From there you define cell size, group assignment logic, and player enrollment in a single server room script. Reactor handles the rest.
Tutorial: Network Culling Using Sync Groups →Ultra-Low Bandwidth
~2 Bytes Per Object.
9.5× the Competition.
Reactor compresses the wire format for you, automatically, with no serialization code to write. It sends only what changed, per object, per tick. In a head-to-head bandwidth comparison against five leading Unity multiplayer solutions, Reactor delivered 9.5× better bandwidth efficiency than the next closest and 17× better than the least efficient.
That gap translates directly into scale: where other tools sync 500 objects, Reactor syncs 5,000. And because bandwidth costs less, your hosting bill stays predictable as your player count grows.
View bandwidth comparison on GitHub →- Multi-stage bit reduction
- Transforms are delta-encoded per field per tick, then run through several reduction passes that shrink every update before it reaches the wire.
- Tunes itself to your game
- The compression adapts to your game's motion in real time and gets tighter as play patterns emerge. You never profile or hand-tune it.
- No setup required
- The server keeps every connected client in sync automatically. Nothing to configure, nothing to maintain.
120hz Tick Rate
Server-side simulation up to 120hz. Network tick rate is independently configurable. Tune the balance between bandwidth and fidelity per room type without changing simulation logic.
Server-Side Physics Queries
Full physics scene query API available in server scripts: raycasts, overlap tests, and sweep tests. Validate hit detection, trigger area checks, and line-of-sight queries entirely server-side.
Collision Filters
Named collision groups configured in the Unity inspector. No code required. Assign entities to groups and define per-group collision and notification rules. Full collision event API for server-side response.
Object Pooling
Built-in entity factory system supports object pooling out of the box. Reuse game object instances across entity spawns to avoid allocation overhead in high-churn scenes like projectile-heavy games.
Motion Interpolation
Object motion is smoothed automatically regardless of server tick rate or network conditions. Interpolation responds dynamically when the server slows, masking temporary poor conditions without developer intervention.
Time Scaling
Adjust server physics simulation speed at runtime using Time.TimeScale. Implement slow-motion effects, fast-forward simulation, or variable tick pacing without touching your game logic.
02 · Developer Experience
Start Fast. Add Complexity
Only When You Need It.
Server and client scripts are written in C# inside the Unity Editor, using the same scripting environment as the rest of your game. You don't rewrite your controllers, hand-roll prediction, or maintain separate build pipelines for client and server. Reactor handles most of that, and the rest is optional.
Client Authority · Unity Ownership
Use Your Existing
Unity Controllers.
No Rewrite Required.
Add ksUnityOwnership and ksAutoSpawn to any game object. When a player connects, the server assigns them ownership, and from that point the client drives the object's transform and properties directly. No player controller port, no server-side physics rewrite.
The server assigns and transfers ownership. One player can own multiple objects simultaneously. Scripts react to ownership state via ksOwnershipScriptManager: enable for the local owner, disable for everyone else, or destroy on disconnect.
Ownership permissions are per-entity and configurable at runtime. When you're ready to harden against cheating, the server-side validation system intercepts property updates before replication. Security is additive: you don't need it to start.
Tutorial: Spawning and Controlling Entities from the Client →Player 1
Player 2
Player 3
Server: assign and transfer ownership
// Assign to a player
Entity.SetOwner(player, ksOwnerPermissions.ALL);
// Transfer with restricted permissions
Entity.SetOwner(otherPlayer, ksOwnerPermissions.TRANSFORM);
// Release ownership
Entity.SetOwner(null);Player Controllers · Input Prediction
Instant Feel.
Server Authority.
Reactor's player controller system runs the same controller code on both the client and the server simultaneously. On the server, it applies inputs authoritatively. On the client, it runs ahead of the server to give the feeling of immediate response with no input lag and no waiting for a round-trip.
Custom predictors let you tune how the client reconciles divergence from the server. The default linear predictor handles most cases. For complex movement such as vehicles, physics chains, and curved paths, implement a custom predictor using ksCurves or your own interpolation math.
Player controller: runs on client and server
// Runs identically on both sides
public class AvatarController : ksPlayerController
{
[ksEditable] private float m_speed = 5f;
public override void Update()
{
ksVector3 velocity =
new ksVector3(
Input.GetAxis(Axes.X), 0f,
Input.GetAxis(Axes.Y)
).Clamped(1f) * m_speed;
velocity.Y = RigidBody.Velocity.Y;
RigidBody.Velocity = velocity;
}
}[ksEditable] fields are exposed in the Unity inspector and configurable per-asset. No code changes needed to tweak speed, turn rate, or jump force across different room types.
Local Development Server
Rapid prototyping without cloud deploys. Build server configs with Ctrl+F2, rebuild the runtime with Ctrl+F3, and start a local instance in one click. Iterate in seconds, not minutes.
Clean Code Separation
Server, client, and common scripts live in separate assembly folders. Reactor enforces the boundary at build time, preventing accidental Unity references in server code or server logic leaking to clients.
Script Assets
Store configurable server parameters as Unity assets, similar to ScriptableObjects. Assign different controller assets to different rooms without code changes. Editable fields appear in the inspector automatically.
Animation Sync
ksAnimationSync automatically syncs all Unity Animator parameters as networked properties. No manual property mapping. Add the component, set the Animator reference, and replication is handled.
Coroutine Support
Write async server logic naturally using coroutines. Sequence timed events, stagger spawns, implement cooldowns, and build complex event chains without callback nesting or state machines.
Live Server Debugging
Attach Visual Studio to a running local server instance and debug server scripts with full breakpoints, watch windows, and call stacks. The same workflow as any other C# project.
Publishing Workflow
From Unity to
Live Server
in Four Steps.
The entire publishing and deployment workflow lives inside the Unity Editor. No separate CI pipeline, no CLI tools, no context switching. Build, publish, launch, and monitor from the same window where you write your game.
Build configs Ctrl+F2
Compiles room, scene, and entity configurations for local testing. Auto-rebuilds when server scripts change.
Test locally Start Local Server
Runs a local server instance. Connect from Play mode. Attach a debugger. Iterate without deploying.
Publish image Reactor → Publishing
Packages server runtime and configs into a versioned image. Binds the client build to the image automatically.
Launch instance Reactor → Servers
Select region, scene, room, and resource configuration. Launch with one click. Monitor and restart from the same panel.
03 · Infrastructure
Deploy Once.
Run for Months.
Reactor's cloud layer handles everything between "I want a live server" and "players are playing," with no DevOps contract and no separate infrastructure team. Rooms stay online for months at a time. Orchestration is scriptable, and data persists across instances.
Months
Long-Running Persistence
Rooms run reliably for months without requiring restarts. System-level updates are the only reason to cycle an instance. Build persistent worlds, always-on game servers, and social spaces that never reset between sessions.
1-Click
Integrated Hosting
Launch server instances in any supported geographic region directly from the Unity Editor. Select CPU and memory configuration per room type, set Keep Alive to auto-restart on unexpected crashes, and monitor running instances without leaving Unity.
∞
Scriptable Orchestration
The Cluster API is available to all running rooms, enabling complex multi-server game systems from within a single framework. Build matchmaking lobbies, sharded open worlds, guild systems, or chat rooms, all by scripting how rooms spawn, message, and share state.
KV
Inter-Room Data Persistence
The Cluster data store provides a simple key-value mechanism for sharing state across all rooms in a cluster. A built-in event system lets rooms subscribe to data changes in real-time: player inventory, leaderboards, cross-room flags, and live world state.
v1 / v2
Client-Server Version Binding
Clients are bound to a specific published image. Clients on an old version only see servers running that version, while new clients connect to updated instances. This enables staged rollouts, platform-specific builds, and live updates without forcing everyone to restart.
Roles
Team Management & Access Control
Organize team members into roles (development, QA, and live operations) with appropriate access levels. Real-time and historical resource usage analytics available via the web portal. Public room tags let clients browse instances before connecting.
Self-Hosting
Dedicated Private Hosts
When You Need Full Control.
The local SDK supports self-hosting for up to 32 CCU per instance at no cost, useful for internal testing, LAN play, or evaluation. For production self-hosting, dedicated private hosts are available on any cloud provider.
Features requiring the Reactor Cloud (scriptable orchestration and inter-room data persistence) are available via the hosted service. Everything else runs identically on self-hosted infrastructure.
Self-host limits vs. cloud
| Capability | Local SDK | Reactor Cloud |
|---|---|---|
| CCU per instance | 32 | Configurable |
| Local server testing | ✓ | ✓ |
| Managed hosting | n/a | ✓ |
| Cluster orchestration | n/a | ✓ |
| Inter-room persistence | n/a | ✓ |
| Private dedicated hosts | ✓ | ✓ |
Proof in Production
Same Game, Same Developer.
One Tenth the Cost.
Braains.io creator Jayun Noe rebuilt his 50-player web hit as braains2 on Reactor: 100 players, double the tick rate, triple the physics objects, and a move from 2D to 3D. Ten times the data per frame, and total bandwidth still went down.
10×
More Data Per Frame
Double the players and tick rate, more than double the physics objects, plus a move from 2D to 3D.
8×
Less Bandwidth
Full-server traffic dropped from 300 kbps to 35 kbps despite the heavier game.
4 wks
To a Playable Build
The original braains.io took 15 weeks to reach the same milestone.
~1/10
Cost Per Active User
Bandwidth cost per monthly active user fell to roughly a tenth of the original.
Same developer, same concept, same audience: one version built without Reactor and one built with it. The Reactor version moves ten times the data and costs about a tenth as much to run.
Read the full case study →Ready to Build
Without the Ceiling?
Install Reactor via Unity's Package Manager and follow the tutorials. A local development server is included. No account required to start.