Skip to content

Authoring flow

The engine is game-agnostic. Adding a new automation — whether it’s a new daily loop for Whiteout Survival or the first scenarios for Kingshot — is the same loop:

  1. (Optional) Create a module if your automation doesn’t fit an existing feature domain — scaffold it from the dashboard’s /modules page (see Creating a module).
  2. Capture a screenshot of the game state you want to automate.
  3. Label the regions on that screenshot (buttons, badges, text areas) in the Labeling editor.
  4. Save — the editor writes the region coordinates into area.json and stores cropped templates in references/.
  5. Write a DSL scenario in YAML that references the regions you just named (match, click, cond, while_match, …).
  6. Run it — either from the dashboard’s debug runner, or by letting the cron scheduler pick it up.
  7. Iterate — re-label if the UI changes, tweak DSL conditions, tighten thresholds.

There is no game-specific code anywhere — only modules/<game>/ directories with analyze.yaml (overlay rules), scenarios/*.yaml (DSL), and region crops under references/. The Python engine never knows it’s running on Whiteout Survival or Kingshot; it just executes whatever scenarios are loaded.

DSL (YAML)UI mode
Wheremodules/<game>/scenarios/*.yaml in your editorDashboard’s debug runner (/debug-run)
Best forAnything more than a 3-step sequence; version-controlled changesOne-off taps, exploring what works before committing to a scenario
PersistenceCommitted to the repoIn-session only
PowerFull DSL: loops, conditions, sub-scenarios, schedulingLinear sequence of steps against current screen state

Most contributors author scenarios in YAML and use the UI runner to test them. The UI mode is rarely the final form — it’s an exploration tool.

When stuck, ping us in the #install channel on Discord — we review first PRs and can pair on the labeling pass.