> For the complete documentation index, see [llms.txt](https://kinematicsoup.gitbook.io/reactor/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kinematicsoup.gitbook.io/reactor/architecture/architecture-server.md).

# The Runtime Server

## Summary

How the Reactor runtime server works: the server that owns and runs a room's game state, the clients connected to it, and the syncing between them. This page covers the update loop, what the server sends to clients, server scripts and ownership, and how bots and clusters extend it. It is part of the [Reactor Technical Overview](/reactor/architecture.md).

## What the Runtime Server Is

The runtime server holds authority in a Reactor game by default. Each running game server is a **room**: a server running according to a **room type**, the configuration and compiled scripts it was published with. The server owns the true state of the room, and it manages the connected clients, its **players**, and the syncing of game state to them. Clients request changes by sending input, and by default the server decides what happens.

Reactor compiles your server scripts into a **Server Runtime**. The server can run a physics simulation for its entities, but physics is optional: entities can be driven entirely by the scripts you write.

Unity is not present on the server, so its namespaces stay out of reach for server and common scripts. Reactor's scripting system supplies analogues for the Unity functionality server code needs: vector and math types, transforms, physics, coroutines, curves, and more. You write against Reactor's types in place of `UnityEngine`.

## The Update Loop

The server runs a fixed-rate update loop. On each frame it:

1. Manages client connections and disconnections.
2. Handles client input, RPCs, and owned-entity updates.
3. Handles cluster RPCs and events.
4. Runs the server scripts.
5. Optionally runs a physics simulation step.

How often the server sends state to clients, relative to how often it updates, is set by the **sync rate**. The server can send on every update or less often.

The **sync rate** is the number of update frames between syncs. It is an integer greater than zero: a sync rate of 2 means the server sends data after every two update frames. A sync happens at the end of an update frame, so several frames can run between syncs. Tune the sync rate to trade bandwidth against how often clients receive updates.

## What the Server Sends

When a sync happens, the server encodes only what each client needs for that update:

* **Transforms**: an entity's position, rotation, and scale.
* **Properties**: pieces of state attached to a room, player, or entity, each identified by a numeric id. The server sends only the values that changed since the last sync.
* **Events**: remote procedure calls (RPCs), player joins and leaves, and entity spawns and destroys.

Two systems keep this traffic small:

* **Compression** keeps each update small.
* **Sync groups** control visibility. A client receives only the entities in the sync groups it belongs to, so a large world does not force every client to receive every object. Sync groups are Reactor's interest-management tool. See [Interest Management via Sync Groups](/reactor/tutorials/syncgroups.md).

## Server Scripts

Your server-side behaviour lives in three script types, each attached to a different kind of object:

* **Server Room Script**: logic for the room as a whole, such as client authentication rules, entity spawning, or scoring.
* **Server Entity Script**: logic for a single networked object.
* **Server Player Script**: logic tied to a connected player.

Each script gives you access to its Room, Entity, or Player object. On that object you register event handlers for the things that matter (a player connecting or disconnecting, an RPC arriving, a physics contact, a per-frame update) or assign state. The scripts run on the server, so what they decide is authoritative by default.

> *Server scripts and common scripts cannot reference Unity; use Reactor's script analogues instead. Keep shared logic in common scripts, presentation in client scripts, and authoritative rules in server scripts.*

## Ownership and Permissions

By default the server controls everything, but Reactor can hand a player specific rights over an entity. An entity can have an **owner** and a **controller**, and its **permissions** define what the owner may do: drive the entity's transform, change its properties, or feed it input through a player controller.

Use this for client-authoritative movement where you want it, such as a player controlling their own character, while the server keeps authority elsewhere. Permissions apply per entity, so you decide how much trust to extend and where. Owned-entity update validators give finer control still: the server can inspect each update an owner sends and accept, adjust, or reject it. See [Client Authority and State Relay](/reactor/tutorials/authoritative_client.md).

## Bots and Clusters

Two features extend the basic server model:

* **Virtual players (bots)** occupy a player slot on the server. Injected input drives them in place of a network connection, and they run through the same player scripts as real players, so behaviour you write once applies to both. See [Virtual Player Bots](/reactor/tutorials/virtual_players.md).
* **Clusters** let rooms that run the same image in the same geographic area share property state and send RPCs to one another. See [Basic Orchestration Using the Cluster](/reactor/tutorials/cluster_room_management.md).

## Where to Go Next

* [The Client](/reactor/architecture/architecture-client.md): how the other side of the connection consumes this state.
* [The Backend](/reactor/architecture/architecture-backend.md): how rooms get published, launched, and found.
* [Running Rooms Locally and Online](/reactor/tutorials/basics.md): build a first room end to end.