Commands

gozen reads a game directory (game.yaml, data/, assets/) and checks, simulates, documents and packages it. Results go to stdout and diagnostics to stderr.

gozen <command> [<sub-command>] [OPTIONS] [ARGUMENTS]
gozen help <command> [<sub-command>]   # the same as the command with --help
gozen help GZN1101                     # explain a diagnostic code

A group alone (gozen sim) exits 2 and lists its commands. gozen sim --help shows the group’s page.

Conventions #

• Exit status: 0 for success and help, 1 when a check, I/O, simulation or capture fails, 2 for invalid arguments. A name the command line gives that the game does not have (a troop, a location, a persona, a shot) is an invalid argument.
• A diagnostic may end with a code such as [GZN1101]; its first digit is the default exit status. Warning enforcement with check --strict or --baseline uses exit 1 without changing the code. gozen help GZN1101 explains it, and Error codes lists them all.
• Options follow the GNU style. --seed 7 and --seed=7 both work, a few common options have a one-letter form (-n 100, -o DIR, -v, -h), options may come before or after the arguments, and -- ends the options. A single-dash long option such as -seed is rejected with exit status 2.
• Commands that write a directory (sim design, notes, export, release, trial, capture) refuse one that already exists, even if empty, and an output inside an input. They never overwrite.
• Every command except export, run, capture, faces and mosaic detection needs nothing beyond the gozen binary: no cgo, display or sound device. export also needs a matching prebuilt runtime bundle.

The examples below use game as the game directory, lesson as a troop and grotto as a dungeon location. Explicit configuration and output paths are relative to the working directory. Game asset paths, including release --prefix, remain game-relative. Omitted configuration paths use the defaults listed for each command. Use --version or version to print the version; -v is reserved for verbose command output.

new #

Create an editable game directory from a bundled template. No Go compiler is needed. The destination must not exist. A random game ID prevents save collisions; use --id to choose one deliberately and keep it unchanged after distributing a game.

gozen new first-game --template rpg --title "My first game"
gozen check first-game
gozen new first-story --template novel
gozen new first-campaign --template campaign

Run gozen run first-game to play. Edit game.yaml for the title, data/world.yaml for dialogue and places, and data/rules.yaml for characters and battle rules. The starter pictures are original placeholders you can replace.

new and theme list also accept --format json or --format jsonl:

gozen new machine-game --id machine-game --format json
gozen theme list --format jsonl

JSON is one versioned result document. JSONL theme listings contain one item per theme and a final summary. Machine-mode errors are JSONL on stderr with the same GZN codes and exit statuses; output formatting does not change the created game. Other commands currently retain the result shapes described in their sections.

check #

Loads every definition, resolves references and expressions, checks that the assets exist, and lays out dialogue with the game’s font. Warnings go to stderr. By default they do not fail the check. --strict fails with exit 1 when any warning is reported; diagnostic codes stay unchanged, including GZN0xxx warnings.

gozen check game
gozen check --only structure game  # structure only, before the game has fonts
gozen check -- -draft              # a directory whose name starts with a dash
gozen check --format json game     # every error and warning as JSON, for a tool or an agent

ok: 2 locations, 1 events, 1 actors, 2 skills, 0 items, 1 enemies, 1 troops, 0 ai sets
data/world.yaml:26:5: locations.grotto.encounters: unknown troop "lessn" [GZN1101]

The data field contains diagnostics such as:

[
  {
    "file": "data/world.yaml",
    "line": 8,
    "col": 15,
    "path": "events.bad.do[0].battle",
    "message": "unknown troop \"wolves\"",
    "severity": "error",
    "code": "GZN1101"
  }
]

--only layout lays out every line of dialogue and every choice with the game’s font and display rules, and reports the ones that overflow. Warnings alone exit 0.

gozen check --only layout game

Warning budgets #

gozen check game --strict
gozen check game --write-baseline warnings.json
gozen check game --baseline warnings.json

--baseline FILE enables enforcement on its own. It allows the recorded warning counts for each diagnostic code and game-relative source file; only increased counts fail (exit 1). New codes and files start with zero allowance. Decreases pass, but do not rewrite the baseline. Combining --strict with --baseline uses these allowances instead of zero. All warnings remain visible in text, JSON and JSONL, including those within the budget. Errors always fail.

--write-baseline FILE writes versioned JSON to a new file after a valid check, including zero counts when clean. It does not overwrite an existing file or record a game with validation errors. Review a newly written baseline before replacing an older one. It does not disable --strict or comparison when those options are also supplied. Paths are relative to the current working directory; warning file names inside the JSON are relative to the game. A baseline records the --only scope, which must match when it is used. It detects count growth, not replacement of one warning by another within the same code/file bucket.

sim #

Plays the game by its rules alone, with no window or sound. Every sim command but sim script, which writes a trace, accepts --format text|json|jsonl. JSON returns {"version":1,"command":"sim ...","status":"ok","data":...}. JSONL emits ordered items when the result has multiple entries, followed by one summary. Fatal diagnostics go to stderr as JSONL and retain their GZN codes. Selectors, seeds and output paths have the same effect in every format.

sim battle #

Fights the troop with the starting party (or --party, or a saved state) under AUTO and prints the win, loss, flight and draw rates and the average turns. The numbers are the same as the F7 balance panel. The same --seed gives the same result.

gozen sim battle game --troop lesson -n 100
gozen sim battle game --troop lesson -n 100 --party scout --level 5 --seed 7
gozen sim battle game --troop lesson --state memo.save --hp                 # from a note, HP left after a win
gozen sim battle game --troop lesson --state memo.save --as-is --streak 10  # keep the saved HP, count wins in a row
gozen sim battle game --troop lesson -n 1 -v                                # the messages of the first battle

lesson: 100 battles  win 100%  lose 0%  fled 0%  draw 0%  avg turns 1.0  avg standing after a win 1.0

sim dive #

Takes the starting party down a dungeon location, fighting --battles battles on each floor, buying better equipment from --shops, resting, and fighting the bosses. Prints the level, HP, gold and win rates of each floor.

gozen sim dive game --location grotto --floors 3 --battles 5
gozen sim dive game --location grotto --floors 3 --boss 3:lesson --grind 0.8
gozen sim dive game --location grotto --floors 4 --rest 2 --boss 2:lesson --tries 50

floor Lv   battles lost   turns  hp_left mp     gold   scenes boss    troops
B1    1    5       0      1.0    1.00    1.00   15     0      -       lesson
B2    1    5       0      1.0    1.00    1.00   30     0      -       lesson
B3    1    5       0      1.0    1.00    1.00   45     0      -       lesson

sim floors #

Generates the floors of a dungeon location and prints each map with the steps to the stairs and the expected encounters. With --try, compares seeds on one floor.

gozen sim floors game --location grotto --from 1 --to 3
gozen sim floors game --location grotto --floor 1 --try 3
gozen sim floors game --location grotto --no-map

sim design #

Plays the game headless with the personas of designeval.yaml (players, rewards and time weights). With --out, also writes summary.json, timelines, band.png and report.md to a new directory. Without --out, it creates no report files. A simulation error keeps the report and exits 1. A small configuration is in the CLI test fixture.

gozen sim design game -o report
gozen sim design game -o report --only walker -v

sim campaign #

Plays the game’s campaign (Campaigns) many times, headless, with a strategy for the player, and prints the win rate, the turns the campaigns ended in, the mean of the regions each faction held at the start of each turn, the factions that fell and when, the orders given, and how the marches went. Campaign i uses the seed --seed + i, so the same --seed gives the same result. Use --compare strategies or --compare tactics to play each entry on that same seed range. The comparison table includes win rate, mean ending turn, and mean regions held; its region details show ownership changes per campaign, mean turn of the first ownership change, end holder counts, and the player’s win rate by turn when it held that region. --format json writes the comparison and region details as JSON.

gozen sim campaign game
gozen sim campaign game --as random -n 500 --format json
gozen sim campaign game --tactic guard
gozen sim campaign game --compare strategies
gozen sim campaign game --compare tactics --format json

sim routes #

Explores the game’s starting event and automatic arrivals without a display. It reports paths that reach clear and game-over outcomes, authored options that were never offered on explored paths, and flags already reported as set but never read by gozen check (GZN0112). The run is bounded by path count, event requests per path, and elapsed time. Findings are informational unless --fail-unreachable is set. Runtime errors and timeouts exit 1 regardless of that flag. JSON includes whether the path limit cut exploration short.

gozen sim routes game
gozen sim routes game --format json

sim breed #

gozen sim breed <game-dir> starts from species with a positive recruit chance and follows the breeding rules. It prints each reachable species, the fewest generations and one recipe, then the unreachable species. --format json returns reachable rows (id, family, rank, steps, parents) and an unreachable ID list. The recipe gives the male and female parent sexes and the obtainable child sex (sex and parent_sexes in JSON). The graph tracks obtainable sexes and plus values. Parent levels are assumed raisable for this graph; test min_plus recipes in an actual playthrough as well. See the collection recipe.

For example, run gozen sim breed examples/go-zen/game --format json after gozen check examples/go-zen/game to inspect the sample’s 40 non-boss species. gozen book examples/go-zen/game also prints their recruit settings and rules.

gozen book GAME describes the game in Markdown. --format text is the same Markdown; --format json returns the same sections in a version-1 result envelope. Definitions are keyed by ID. --format jsonl emits one item per section and a terminal summary.

Use --section lineage for only the monster family trees. Its JSON data.monsters array includes recipes, capture locations and nested lineage trees. Family recipes carry concrete parents and families; repeated species use ref, and an unreachable species has a null lineage.

gozen book game --format json
gozen book game --section lineage --format json

sim script #

Plays the game with a script of run --dev --script, without a window, sound or screenshots, as fast as it goes, and writes the same trace. The same options and --seed give the same game as run with the same script: the same say, request, order, dev_do, battle, autosave and state lines at the same ticks, and the same state in end. Use it to measure long plays without Xvfb.

gozen sim script game --start camp --script check.txt --trace sim.jsonl
gozen sim script game --start camp --party scout --level 3 --seed 7 --script check.txt --trace -

What needs the window is left out:

• shot NAME takes no picture, and neither do the automatic shots of lines, play and walking; the trace has no shot line.
• The trace lines that come from drawing, view, stand, layout and menu, are not written, and --trace-shots is not available. music lines say which song was asked for; whether it had started depends on how fast songs decode in the background.
• Every other command, wait, gap, press, hold, read, until, walk, do, order, end_turn, skip, quit and the rest, runs as in run, tick for tick. click X Y and drag X Y TO_X TO_Y (press, move over eight ticks, let go) run too, but a position that is only known once drawn is not checked.

With --script - the script is read line by line from the standard input and the trace goes to the standard output (unless --trace FILE is given). Each time the game is ready for the next command, a line {"t":"ready","tick":N,"busy":false,"location":"camp","waiting":""} is written and the trace flushed; waiting is text, choice, command (a battle waits for a command) or empty. A program can read the trace up to ready, decide, and send the next line, so one process plays as long as needed. The command snapshot writes {"t":"snapshot","state":{...}} with the whole state, the same as the state of end; it works in run --script as well. A line that does not parse is written as script_error and skipped. The end of the input, or quit, ends the run with end.

gozen sim script game --start camp --script - < check.txt

Saves are kept in memory unless --save-dir is given. Startup options that run has for scripted plays are available: --start, --battle, --party, --level, --flags, --gold, --items, --floor, --calm, --event, --line and --answers. The default --seed is 1. Without --trace -, it prints the ticks played and the lines written.

sim batch #

Plays many sim script cases in one process. Starting sim script reads and checks the whole game, which for a large game takes longer than a short script plays; sim batch reads each game directory once and plays every case from a new game on those definitions. A directory is read again only when one of its files changes.

The cases are JSON Lines, one object a line, from --cases FILE (- is the standard input). args are the arguments of sim script, the game directory first; id is any name the result carries back:

{"id": "night", "args": ["game", "--start", "camp", "--seed", "5", "--script", "night.txt", "--trace", "night.jsonl"]}
{"id": "fight", "args": ["game", "--start", "camp", "--seed", "6", "--script", "fight.txt", "--trace", "fight.jsonl"]}

gozen sim batch --cases cases.jsonl

When a case ends, stdout receives a version-1 JSONL envelope with command: "sim batch", type: "item", its id and status (ok or failed). Its data contains the case’s id, exit, stdout and stderr: the exit status and output that sim script with the same arguments would have produced. A final summary contains succeeded and failed counts; any failed case makes the batch exit 1. Fatal input or processing errors go to stderr and may prevent this summary.

The trace goes where the case’s --trace says, and is the same as sim script writes. Each case has its own seed, saves and state. A line that does not parse gives a result with exit 2, and the next line is played. Cases cannot use - for their script or trace. A program can stream cases and read each result before it sends the next. Cases play one at a time; to play them in parallel, run several processes.

run #

Opens a game directory containing game.yaml, data/ and assets/. No Go source or game-specific executable is needed. It uses the same runtime as exported games.

gozen run game
gozen run game --fullscreen --mute
gozen run game --dev --save-dir test-saves
gozen run game --dev --script check.txt --shots shots --trace run.jsonl

Options can come before or after the directory; use -- before a directory starting with a dash. gozen run --help lists the shared game options. Pass the game directory as an operand.

--dev enables author tools and live reload from that directory. Scripted runs isolate saves unless --save-dir is supplied. Ordinary play uses the game’s id under the user’s Gozen configuration directory; use --save-dir to keep separate copies apart. Relative output paths are relative to the working directory, which the command does not change.

A display and the platform graphics and audio libraries are required; use Xvfb for unattended Linux runs. Recording additionally needs ffmpeg. Help, check, and sim do not need a display. Closing the window exits 0; startup and I/O failures exit 1; argument parsing and startup option errors exit 2.

The command reads loose assets; it does not encrypt or package them. Keep the runner version with a distributed game. Custom Go loops and save-store callbacks are outside the supported authoring interface.

trace #

Prints a trace written by the game’s --trace in recorded order. Use - instead of a file to read standard input. With --check, lists faults of the standing pictures and the music and exits 1 if there are any. Check mode rejects display filters.

--format json returns selected records and counts of every input kind in the result’s data. --format jsonl emits the selected records as items, then a summary with counts. Check mode returns issues with their GZN codes, ticks and messages; standing_pictures_checked is false when the trace contains no standing-picture records.

gozen trace run.jsonl
gozen trace run.jsonl --only say --only battle --from 10 --to 60
gozen trace run.jsonl --check

notes #

Reads the notes the game writes with F9 and builds an HTML page with thumbnails in a new directory. The notes are not changed.

gozen notes notes --out notes-html
gozen notes notes -o review-html

capture #

Capture PNG images and animated GIFs directly from game YAML. No separate game binary or ffmpeg is needed. Each job starts with fresh state and memory-only saves.

gozen capture game --config captures.yaml --out promo
gozen capture game --config captures.yaml --out selected --only camp --format json
xvfb-run -a gozen capture game --config captures.yaml --out unattended

seed: 7
shots:
  - id: camp
    start: camp
    wait: 30
  - id: conversation
    event: finish
    line: 1
    setup:
      - set: {gold: 42}
    wait: 30
  - id: greeting
    start: camp
    wait: 30
    gif:
      fps: 10
      duration: 3s
      width: 640
      script: |
        press ok

id names the output file. start selects a location; event or scene selects an event or gallery scene. line, picture and answers select a position within that event. battle requires start without scene or event. party, level, floor, flags and calm configure a location start. setup uses existing YAML commands and must finish without waiting for player input. Gallery defaults run before setup.

The top-level script runs before wait (default: 120 simulation ticks). gif.script runs during the animation. Scripts use the existing input commands; capture jobs own image output, so script commands that also write images are rejected.

Output contains the images, shots.json and index.html. Configuration and script validation errors stop the batch before rendering. Runtime job failures have a reason in the report and no image; other jobs continue. A partial batch exits 1.

With --against previous, each row of shots.json also says how the job differs from previous/shots.json: change (unchanged, changed, new or removed), changed, diff_pixels, diff_ratio and diff_bbox ([x, y, width, height], or null when no pixel changed). A difference is reported, never an error: it does not change the exit status. Existing output directories are preserved. Asset policies check every sampled frame, including transient GIF images. Ordinary games need no --raw.

GIF defaults are 10 FPS, three seconds and at most 640 pixels wide. Limits are 1–30 FPS, 10 seconds, 1280 pixels per side, 921600 pixels per frame, 2–300 frames, and 64 MiB of retained paletted pixels. Combined limits may require reducing width, FPS or duration. GIFs loop without sound. Frame delays use centiseconds; the final delay includes any fractional frame interval.

Capture needs a display and platform graphics libraries. Use Xvfb for unattended Linux runs. Timeout checks occur between game updates and draws; they cannot terminate a stalled graphics driver.

book #

Writes the locations, events, scenes, troops and items of the game to stdout as one Markdown document. A quick way to review a whole game, or what an agent wrote. The headings follow the game’s language.

gozen book game > book.md

release #

Checks the approval records and the assets the game refers to, then copies the game to a new directory, taking replaced assets from an overlay. Any unapproved reference fails the build.

gozen release game --out release --inspect inspect.jsonl
gozen release game --out release --overlay overlay --inspect inspect.jsonl

trial #

Builds a demo tree using the range in trial.yaml. Analysis retains branches it cannot prove unreachable and reports their conditions. Use forbid patterns to reject retained definitions or assets that must not ship; see trial checks.

gozen trial game -n                            # count what would be kept, write nothing
gozen trial game --out trial --list trial.txt        # build, and list what was kept and dropped
gozen trial game --out trial --overlay overlay --inspect inspect.jsonl

The trial holds what gozen export takes from a game: the pruned game.yaml and data/, the assets the kept part uses, and, unchanged, lang/, streams/, the license notices and LICENSES/. The translations are copied whole, so they still hold the text of what was cut. A symlink anywhere in the game fails the build, as it fails an export. The YAML is written anew: comments and flow style are not kept, and every text is quoted.

Without --overlay, the trial of a game that has asset-policy.yaml keeps that file: its assets are as unapproved as the game’s, so gozen export refuses the trial as it refuses the game. Build the trial with --overlay and --inspect to get an approved tree, which holds no policy. The list is written after the tree, and a run that fails leaves neither.

Picture tools #

Tools for the pictures of a game. prompt assembles image-generation text from a catalog, and mosaic pixelates regions of images; both are described on Production tools.

models fetch #

Downloads fixed revisions of the detection models (censor, face, head) into the user cache and checks each file against a SHA-256 written in gozen. mosaic and faces use a model in the cache when --model is omitted.

gozen models list     # the models and whether each is in the cache
gozen models fetch face       # the face detector of faces

faces #

Finds the face in each standing picture a painted scene (stage:) cuts a balloon face from (the people placed in a stage and the actors’ face pictures) with the anime face detector that gozen models fetch face downloads, and writes the boxes with each picture’s size and SHA-256 to assets/faces.json. The game only reads that file and runs no model, so a web build shows the same faces. A doll’s icon (a face drawn for the balloons) comes first and is not searched, then its face_at, then the box; a picture without a box gets a guessed face, and gozen check warns of it and of a picture changed since.

gozen models fetch face                          # download the model once
gozen faces game                                 # find the faces
gozen faces game --preview faces-check           # and look at the boxes and the cut faces

It needs a gozen built with cgo, an ONNX Runtime shared library and the model, as gozen mosaic does; a build without cgo says so and fails.

puppet #

Loads a moving portrait (portrait YAML) with the game renderer’s validation and prints where each face, closed-eyes and mouth picture lies on the base picture. A difference picture as large as the base is cut down to the part that differs.

gozen puppet streamer/puppet.yaml                        # check it and show the positions
gozen puppet streamer/puppet.yaml --out streamer-packed  # write it with small difference pictures

It needs nothing beyond the gozen binary: no cgo, display or sound device.

theme #

A dungeon theme is a wall, a floor, a ceiling and a door picture with colors that go together. The gozen binary carries thirteen themes (cave, ice, ruins, castle, crystal, temple, sewer, forest, tomb, keep, dream, mine, vine); gozen theme add copies one into a game, and theme: cave in a dungeon or one of its looks then fills the walls, floor, ceiling, door and colors that the YAML does not write. The pictures are not part of the game runtime, so a game that uses no theme does not carry them.

theme list #

Prints the name of each theme with a line on how it looks.

gozen theme list

theme add #

Copies wall.jpg, floor.jpg, ceiling.jpg, door.jpg (1024x1024) and theme.yaml (the far fog and map colors), with LICENSE.txt for the pictures, to assets/dungeon/themes/<name>/ of the game. No network is used. A file the game already has is kept, so your own edits stay.

gozen theme add game --name cave          # the files of the cave theme go to game/assets/dungeon/themes/cave/
gozen theme add game --name cave --force  # replace the files that are already there

An unknown theme name exits 2 (GZN2402), and a directory without game.yaml exits 1 (GZN1110). A game that says theme: cave without the folder fails gozen check with GZN1111 and the line run gozen theme add <game-dir> --name cave. The pictures claim no copyright (CC0 1.0), see ASSETS.md.

version and help #

gozen version
gozen --version

Prints the version recorded by go install, or devel for a build from source.

gozen help takes the words of a command (gozen help sim battle is gozen sim battle --help), or a diagnostic code:

gozen help sim battle
gozen help GZN2101

export #

Use --out DIR for the new output directory and --runtime DIR for the matching runtime bundle. Both paths are relative to the working directory. --format json returns one version-1 envelope whose data contains directory and target; --format jsonl returns one terminal summary. Both formats create the same package as text output. Errors go to stderr with their existing GZN codes where available.

Desktop #

Unpack the CLI archive and the gozen-runtime archive from the same release. Choose the runtime for the computer that will play the game.

gozen export my-game --out output --runtime runtime --target windows-amd64

The output contains:

output/
  gozen-player.exe
  game/
    game.yaml
    data/
    assets/
  runtime.json
  runtime-licenses/

Move the whole output directory to the player’s computer and run gozen-player.exe. On Linux and macOS, the executable is gozen-player. Go, Python and the authoring CLI are not needed to play. A display and the platform graphics and audio libraries are required. Saves use the game’s existing ID and per-user save directory; they are not written into the package.

The target defaults to the current computer. Accepted targets are linux-amd64, linux-arm64, windows-amd64, windows-arm64, darwin-amd64 and darwin-arm64. Cross-target packaging does not execute the target binary. macOS packages are plain directories, without signing or notarization.

The command checks the runtime version, target and player checksum. It performs no download or compilation. The destination must not exist or overlap an input. A game with asset-policy.yaml must first pass gozen release; export the resulting approved tree. A trial built without --overlay keeps the policy of its game and is refused in the same way.

Export copies game.yaml, YAML under data/, lang/ and streams/, runtime asset formats under assets/, root license notices and the contents of LICENSES/. Other root directories, including saves/ and shots/, are not copied. Hidden paths are excluded and symlinks are rejected.

Under assets/, export includes images (PNG, JPEG, GIF, WebP), audio (OGG, WAV, MP3), fonts (TTF, OTF, TTC), YAML, TXT, Markdown and faces.json. Files named LICENSE* or NOTICE* are also retained. This selects files by path and extension; it does not inspect their contents. Keep author notes, captures and source art outside these runtime directories. Assets are copied without conversion or encryption. Keep third-party notices in LICENSES/ or alongside their assets.

Web #

Use the gozen-runtime_VERSION_js_wasm.tar.gz archive from the same release as the CLI. Unpack it into web-runtime.

gozen export my-game --target web --out site --runtime web-runtime

Upload the contents of site/ to a static HTTP or HTTPS host:

site/
  index.html
  gozen-player.wasm.gz
  wasm_exec.js
  runtime.json
  runtime-licenses/
  game/
    files.json
    game.yaml
    data/
    assets/

The same WASM player runs every exported game. Editing YAML or replacing assets requires a new export, not a new Go build. wasm_exec.js is supplied by the same Go toolchain that built the player; export verifies both files’ checksums. Opening the HTML directly with a file: URL is unsupported.

Relative URLs support hosting under a subdirectory, such as /games/my-game/. The player is served gzipped, which the page undoes as it downloads. Pictures become WebP (paletted pictures lossless) and other files that gzip makes smaller are served gzipped; game/files.json lists what each file is served as. The browser downloads the files listed there, the pictures and sounds last, and starts once the others have come; the recorded stream voices are fetched only as the watch view comes to their lines. Large asset sets still increase startup time and memory use. The file selection and approval requirements are the same as desktop export.

Saves use browser local storage. They persist on the same origin (scheme, host and port) with the same game ID. They do not sync across devices or move with a changed origin. YAML and assets remain downloadable; export does not hide them.

CPU profiles and reusable exports #

Set GOZEN_CPUPROFILE=cpu.pprof before a command to record its CPU activity:

GOZEN_CPUPROFILE=cpu.pprof gozen sim script examples/workshop/game --start workshop --script tour.txt
go tool pprof cpu.pprof

A profile includes setup and decoding as well as gameplay. Compare the same fixture and seed; use go test -benchmem benchmarks for allocations. Profile creation and closing failures are reported on stderr.

gozen export game --target web --runtime web-runtime --out site2 --reuse site reuses compatible generated output where the exporter permits it. Keep the earlier export directory when iterating; omit --reuse for a fresh export. See gozen export --help for output and runtime options. Reuse does not replace checking the authored game.

Command and option index #

This complete inventory is checked against gozen help --format json. Options are listed per command, including short aliases; use that command with --help for values, defaults and requirements. Shared implementation options can appear on several image tools; their effect depends on the action.