> 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.md).

# Reactor Technical Overview

## Summary

A high-level tour of how the Reactor multiplayer system is built. This page introduces the three parts of a Reactor game: the runtime server, the client, and the online backend. It shows how they fit together, and each part links to a page that goes deeper.

## The Big Picture

Reactor is **server-authoritative by default**. The game runs on the server, which syncs its state of the world to connected clients. Clients send input to that server, receive the resulting state back, and render it for the player. Keeping authority on the server makes a game consistent across players and harder to cheat. A game can also grant a client authority over specific entities through ownership, when that fits the design. See [Ownership and Authority](/reactor/architecture/ownership-and-authority.md).

A running Reactor game has three parts that work together:

```
        +----------------------+
        |       Backend        |   Publish, launch, and
        |   (online services)  |   discover game servers
        +----------------------+
           ^                 ^
    publish|                 |find a room (list + public data)
    & launch|                |
           |                 v
   +----------------+   input   +------------------+
   | Runtime Server | <-------- |      Client      |
   |  (authority)   | --------> |  (Unity player)  |
   +----------------+   state   +------------------+
```

* [**The Runtime Server**](/reactor/architecture/architecture-server.md) simulates the game and holds authority over all state.
* [**The Client**](/reactor/architecture/architecture-client.md) is the Unity application your players run. It sends input and renders the state the server sends back.
* [**The Backend**](/reactor/architecture/architecture-backend.md) is KinematicSoup's online service. It stores your published server images, launches and tracks rooms, and helps clients find public rooms.

You coordinate the game's network behavior in C# with three kinds of scripts: **server scripts**, **client scripts**, and **common scripts** shared by both. They are the tools for networking, not the whole game; you build the rest of the game with whatever code and tools you like. Reactor compiles your server scripts into a **Server Runtime** that ships with the game server, and your client scripts into the client. Authoritative logic stays on the server where players cannot reach it.

> *New to the vocabulary here (room, room type, entity, player, image, host, cluster)? See the* [*Terms*](/reactor/overview.md#terms) *section of the overview.*

## How the Parts Work Together

Follow a game from build to gameplay to see how the parts connect:

1. **Author.** You build your game in Unity with server, client, and common scripts.
2. **Publish.** Reactor compiles the Server Runtime, bundles an **image**, and uploads it to the backend.
3. **Launch.** The backend starts a **room** from that image on a host in a region you pick. The room begins running.
4. **Discover.** A player's client asks the backend for available rooms and reads their public data to choose one.
5. **Connect.** The client opens a connection to the room, authenticates, and joins it.
6. **Play.** The client streams input to the server. The server simulates and streams authoritative state back, and prediction keeps it smooth. The loop runs until the player leaves or the room stops.

The part pages below cover each step in more depth.

## The Three Parts in Depth

* [The Runtime Server](/reactor/architecture/architecture-server.md): the authoritative simulation, covering the update loop, what it sends, server scripts, ownership, bots, and clusters.
* [The Client](/reactor/architecture/architecture-client.md): connecting, client scripts, input, and how prediction helps mask latency.
* [The Backend](/reactor/architecture/architecture-backend.md): publishing and images, launching and orchestration, room discovery, and accounts.

## Systems in Depth

Deep-dive pages on how each system works, at the public-API level:

* [Client Connection Process](/reactor/architecture/connection-process.md): finding a room, the handshake, and joining.
* [Server Object Model](/reactor/architecture/server-object-model.md): the Room, Player, and Entity structures.
* [Ownership and Authority](/reactor/architecture/ownership-and-authority.md): owners, controllers, permissions, and validation.
* [Automatic Client Data Syncing](/reactor/architecture/data-syncing.md): properties, transforms, sync groups, and prediction.
* [Messaging and RPCs](/reactor/architecture/messaging-rpcs.md): room, entity, and batch remote procedure calls.
* [The Server Update Loop](/reactor/architecture/update-loop.md): running code each frame and the time API.

## Where to Go Next

* [Getting Started](/reactor/overview.md): installation, project layout, terms, and the Unity tools.
* [Running Rooms Locally and Online](/reactor/tutorials/basics.md): build a first client/server room end to end.
* [Networked Properties and RPCs](/reactor/tutorials/properties_and_rpcs.md): the core state-sync and messaging tools.