Skip to main content
A rule is when a condition holds, do an effect — and it is data, so you can add it, read it back, and change it while the simulation runs. This guide covers both the compact string form and the fully-typed declarative form.
Start a local server first — see the Quickstart. All commands target http://localhost:3917; every POST sends Content-Type: application/json.

​
Add a rule

The quickest way is the string DSL on POST /rule/create:
  • when — death, timer:N (N seconds), health-below:N, score:N, or phase:NAME.
  • filter — any, team:N, or entity:N.
  • actions — space-separated verb target amount, where verb ∈ heal, damage, score, spawn, despawn, teleport, color, text, endgame and target ∈ this, source, entity:N.
The rule is now part of the world. Read the rule set back at any time:
Each tick of /step, the engine evaluates every rule against the table and applies the effects of those whose condition holds.

​
Change rules mid-run

Because rules are a live part of the world, you can add one while the simulation is running — no restart, no recompile:
Rules are sticky: neither /reset nor applying a new scenario clears the rule set — /reset despawns entities only, and a scenario appends its rules. There is no rule-clear endpoint, so for a clean rule set, restart the server. Keep this in mind when iterating.

​
The fully-typed form

The DSL is shorthand. The complete data form is the rule list inside a scenario, where the condition and each action are typed values you can generate, diff, and store:
The typed condition is {"kind": "<snake_case>", ...} — death, timer (+interval), health_below (+threshold), score (+threshold), phase (+phase). Each action is {"action": "...", "target": "this" | "source" | {"entity": N}, ...}. Because every part is data, a world’s entire logic ships as a file you can read, diff, and re-apply.