Reactor Multiplayer Engine
Reactor is built around performance at scale, a workflow that doesn't get in your way, and infrastructure that keeps running without babysitting.
01 · Performance & Scale
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
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
Reactor uses delta-based compression to send only what changed, per object, per tick. In a head-to-head benchmark 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.
Open benchmark on GitHub →| Solution | Relative bandwidth |
|---|---|
| Reactor | 1× (baseline) |
| Competitor A | 9.5× |
| Competitor B | 11× |
| Competitor C | 13× |
| Competitor D | 17× |
Bandwidth per synced object. Full methodology and source available on GitHub.
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.
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.
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.
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.
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.
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
Reactor removes the parts of multiplayer development that cost the most time: rewriting controllers, hand-rolling prediction, managing separate build pipelines for client and server. Most of it is handled for you, or optional.
Client Authority · Unity Ownership
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.
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 in your foundation to build on top of Reactor.
Tutorial: Spawning and Controlling Entities from the Client →Player 1
Player 2
Player 3
Validation: intercepts before replication
override ksMultiType OnValidate(
uint propertyId,
ksMultiType current,
ksMultiType incoming)
{
if (incoming.Float > maxSpeed)
return current; // reject
return incoming; // accept
}Player Controllers · Input Prediction
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.
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.
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.
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.
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.
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.
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
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
Reactor's cloud layer handles everything between "I want a live server" and "players are playing," without a DevOps contract or a separate infrastructure team. Rooms stay online, orchestration is scriptable, and data persists across instances.
Months
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
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.
∞
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
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
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
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
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 | ✓ | ✓ |
Install Reactor via Unity's Package Manager and follow the tutorials. A local development server is included. No account required to start.