Game server (RGS) and protocol

The RGS (Remote Game Server) is the component that runs your game graph and produces the outcome of each round (win amount, feature state, etc.). Chong uses a standard protocol so that any client—the Play screen, a simulator, or an external integration—can receive the same stream of messages and show or use the result without knowing your graph logic.

How the RGS works

When a round is played:

1. Start: The RGS receives a request to play (e.g. with a seed, bet boost, or bonus buy). It loads your project’s graph and data (reel strips, weight tables, paytables).
2. Run: It executes your graph from the start node (e.g. Round Start or Event Start). Each node runs in order: reels spin, symbols land, wins are evaluated, cascades run, and so on. All of this happens on the server (or in the Play screen using the same logic).
3. Outcome: At the end, the RGS has a final state: which symbols are on the grid, the win amount, any feature flags (e.g. free spins remaining). It sends that outcome—and optionally the full step-by-step trace—to the client.

What the protocol is

The RGS protocol is a standard set of messages that describe a round in a way any client can understand. Clients do not need to know what your nodes do; they only need to apply small state updates (patches) and show labels (e.g. “Reels stopped”, “Win: 12.50”).

Message flow

For each round, the RGS sends messages in this order:

• round_start — Round began. Includes seed, initial config (data store), and graph metadata.
• node_exit — One message per step (node_enter omitted to halve stream size). Each includes a stable event name (e.g. reel_stop, win_evaluate) and a list of patches (state changes). The client applies patches in order to build the grid and win.
• round_end — Round finished. Includes final tags (full grid state), win amount, and total step count. Clients that only need the result can use just this message.

If something goes wrong, an error message is sent instead of round_end, with step index and error details.

Patches (state updates)

Each patch is a single change the client can apply without knowing node logic:

• tag_set — Add a tag to an entity (e.g. symbol on a cell, or global).
• tag_remove — Remove a tag from an entity.
• return_value_set — Set a return value (e.g. win amount, feature state).

By replaying all patches in order, the client can reconstruct the full game state at any step—useful for animation, replay, or debugging.

Event names

Each step has an event name (e.g. reel_stop, win_evaluate, cascade_drop). These are derived from your node types so the client can show human-readable text or trigger sounds and animations without hard-coding your graph structure.

Why it matters for you

• Play screen: The same protocol drives the Play view. When you run a round, you see the grid and wins by applying the same patches; the collapsible “Protocol JSON” at the bottom shows the raw messages.
• Integration: An external game client (e.g. operator front-end) can connect to an RGS that speaks this protocol and display your game without implementing your graph logic—they just apply patches and show event names.
• Simulators and tools: Simulators and analytics can consume the same stream for batch runs or debugging.

What the client never sees

The protocol is designed so that no node or graph configuration is sent to the game client. The client does not receive nodes, graph structure, reel strips, weight tables, paytables, or any other config. The client only receives:

• round_start with executionId, seed, and optional roundContext only—no dataStore, no graphMeta (no node count, entry node id, or graph info).
• Outcome data: which symbols landed where (patches and tags on cells), win amount, feature state.
• Event names for display—no internal data outputs from nodes.

So your game logic, maths, RTP, and configuration stay on the server; the client only gets what it needs to display the round.

Summary

The RGS runs your graph and produces an outcome (win, final state) and a sequence of protocol messages. The protocol uses round_start, one node_exit per step (with patches and event names; node_enter is omitted to halve size), and round_end (or error). Clients apply patches in order and use event names for display; they never need to know what your nodes do. All node types in your graph participate automatically—no extra setup required. Nodes, graph structure, reels, weights, and paytables are never sent to the client.