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

# The Client

## Summary

How the Reactor client works: the Unity application your players run. This page covers connecting to a room, client scripts and input, and how prediction helps mask network latency. It is part of the [Reactor Technical Overview](/reactor/architecture.md).

## What the Client Is

The client is the Unity application your players run. It connects to a room, sends the player's input to the server, and renders the state that comes back. By default the server is authoritative over game state, but a game can be written so the client is fully or partially authoritative. The client presents the current state of the world and makes it feel responsive.

## Connecting and Receiving State

A client connects to a room using a **connection** suited to its platform:

* **TCP**: reliable, with broad platform support.
* **Reliable UDP**: lower overhead, suited to fast-paced games.
* **WebSocket**: for browser builds.

After a short handshake and authentication, the client receives encoded frames from the server. It decodes each frame and applies the results to Unity: it spawns GameObjects for new entities, updates transforms, applies property changes, and raises events your scripts can handle. The incoming data is compressed, and the client reverses that encoding to rebuild the world.

## Client Scripts and Input

Client behaviour lives in **Client Room Scripts** and **Client Entity Scripts**. They handle presentation, such as reacting to a property change with a sound or animation, or updating UI when a player joins or leaves. They do more than presentation too: they can send RPCs to the server, handle incoming RPCs, and drive synced input state.

A **Player Controller** is one optional way for a client to control an entity. It reads local input each frame and sends updates to the server. A client can also control an entity through **ownership permissions**, which let it update the entity's transform and properties directly; the server detects those changes and syncs them to the other players.

## Prediction and Smoothing

Network state arrives less often than the client renders. Snapping entities to each server update would make motion choppy. Prediction is one tool for masking that gap, alongside player controllers and owned entities. **Predictors** decide how an entity moves between server updates, interpolating between server frames and extrapolating when a frame is late:

* **Interpolation** blends a remote entity toward each new server position. Use it for other players and for projectiles.
* **Input prediction** drives the local player's own entity straight from their input, so control responds without waiting for a round trip to the server.
* **Converging prediction** combines both. It predicts from local input, then reconciles against the server's authoritative position as updates arrive, easing toward the correction instead of snapping.

You choose a predictor per entity to match how it behaves. When the server is authoritative, prediction changes how an entity looks between updates, not what the server decides, and the visible state converges back to the server's values. See [Motion Prediction](/reactor/examples/predictors.md) for the predictors in practice.

## Where to Go Next

* [The Runtime Server](/reactor/architecture/architecture-server.md): the source of the state the client renders.
* [The Backend](/reactor/architecture/architecture-backend.md): how the client finds a room to connect to.
* [Server-Authoritative Player Controller](/reactor/tutorials/player_controllers.md): build a controlled, predicted player entity.