> 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/server-object-model.md).

# Server Object Model

## Summary

The server-side data structures a developer works with: the Room, its Players, and its Entities, and how they relate. It is part of the [Reactor Technical Overview](/reactor/architecture.md).

## Room

The **Room** (`ksIServerRoom`) is the container for one running game. It owns the players and entities, runs the simulation, and holds room-wide state. Key surfaces:

* **Collections**: `Players`, `Entities` (with `DynamicEntities` and `PermanentEntities`), plus counts like `ConnectedPlayerCount` and `VirtualPlayerCount`.
* **State and services**: `State` (starting, running, stopping), `Time`, `Physics`, `Cluster`, and a `Properties` map synced to clients.
* **Lifecycle events**: `OnPlayerJoin`, `OnPlayerLeave`, `OnSpawnEntity`, `OnDestroyEntity`, `OnShutDown`, and the `OnAuthenticate` hook that runs before a player joins.
* **Entity control**: `SpawnEntity` (from spawn parameters or convenience overloads), `SpawnCollection`, `GetEntity`, and `Destroy` on the entity itself.
* **Messaging**: `CallRPC` and `CallBatchRPC`, covered in [Messaging and RPCs](/reactor/architecture/messaging-rpcs.md).

Room scripts (`ksServerRoomScript`) attach to the room and hold its logic.

## Player

A **Player** (`ksIServerPlayer`) represents a connected client or a **virtual player**, which is a server-controlled bot. Key surfaces:

* **Identity and state**: `Id`, `ConnectionState`, `IsConnected`, `IsVirtual`, `Address`, and the latest `Frame` and time reported by the client.
* **Data**: a `Properties` map synced to clients, and `VirtualInput` for driving bots.
* **Ownership**: `OwnedEntities`, plus `RemoveOwnedEntities` and `DestroyOwnedEntities`.
* **Visibility**: `AddToSyncGroup`, `RemoveFromSyncGroup`, and `GetSyncGroups`, covered in [Automatic Client Data Syncing](/reactor/architecture/data-syncing.md).
* **Control**: `Disconnect` and `UpdateControllers`.
* **Lifecycle**: the `OnLeave` event, raised when the player leaves the room.

Player scripts (`ksServerPlayerScript`) attach to a player.

## Entity

An **Entity** (`ksIServerEntity`) is a networked object in the room. Key surfaces:

* **Identity**: `Id`, `Room`, `Type`, and its `Owner` and `OwnerPermissions`.
* **Transform**: `Transform` (3D) and `Transform2D`, synced to clients.
* **Data**: a `Properties` map, a `SyncGroup` for visibility, and `DestroyOnOwnerDisconnect`.
* **Physics**: a physics actor, collision filter, material, and events like `OnCollision`, `OnOverlapStart`, `OnWake`, and `OnSleep`.
* **Control**: `SetOwner`, `PlayerController`, and the owner-update validators, covered in [Ownership and Authority](/reactor/architecture/ownership-and-authority.md).
* **Lifecycle and messaging**: `Destroy`, `OnDestroy`, `CallRPC`.

Entity scripts (`ksServerEntityScript`) attach to an entity.

## How They Relate

A room contains many players and many entities. A player can own zero or more entities, and each entity has at most one owner. Entities carry the game state that syncs to clients; players carry per-client state and input; the room carries shared state and the simulation that ties them together.

> *Rooms, players, and entities each expose a `Properties` map. Properties are the primary way state reaches clients. See* [*Automatic Client Data Syncing*](/reactor/architecture/data-syncing.md)*.*

## Where to Go Next

* [Ownership and Authority](/reactor/architecture/ownership-and-authority.md): owners, controllers, and permissions on entities.
* [Automatic Client Data Syncing](/reactor/architecture/data-syncing.md): how room, player, and entity state reaches clients.
* [The Server Update Loop](/reactor/architecture/update-loop.md): when your scripts run against these objects each frame.