Skip to main content
createGameExecutor(game) produces the final rules surface. Tableverse hosts it, the local server runs it, and your tests can call it directly.

Start a game

createInitialState takes one init object:
  • seed — a deterministic RNG seed. The same seed reproduces the same shuffles and rolls.
  • players — the authoritative roster, in seating order. These identity strings are what the engine matches against a command’s actorId and a view’s playerId.
  • setup — matches your .setupInput() schema. Omit it when your definition declares no setup input:

Public methods

Execute a command

On success, continue from result.state. The executor does not mutate the input state. On rejection, result.state is the original state and result.events is empty. Common engine-level reasons include unknown_command, not_active_player, invalid_command_input, and command_not_allowed_in_stage. Your .validate() callback can return game-specific reasons. For a discoverable command, begin with its initial step:
An incomplete result contains options. Send an option’s nextStep and nextInput in the next discovery request. A complete result contains input ready for executeCommand. The executor returns null when the command, actor, step, input, or generated options are invalid.

Read available commands and views

Use canonical state only inside trusted rule and test code. Send getView() output to players.
Frontends normally use TableverseClient instead of calling the executor. The client supplies the viewer identity and actor ID through the host.

Test the executor

Verify complete command and stage flows with Vitest.