What moxzi.game is
What does the framework give me, and what do I write?
You write the game. The framework writes the plumbing.
A moxzi.game project is Motoko, YAML and assets. Game state lives in actors and stays authoritative there. The framework owns Rust: rendering, host services, platform export. There is no game-specific Rust host to write, and no game logic in JavaScript.
The shape#
| You supply | The framework supplies |
|---|---|
game.yaml — the project descriptor | the shared Bevy player and its adapters |
Motoko under src/ — the authoritative simulation | snapshot/delta mirroring into disposable render proxies |
assets under assets/ | host services, save/lifecycle, platform export |
The renderer is disposable. Tear the Bevy proxy down and rebuild it and the game does not notice, because the actors were the truth the whole time.
actor* at scale#
Lanternfall runs 2,048 courier actor* instances in one canister — each with its own state, its own identity, its own upgrade path. That is the alpha.6 language feature doing the work: an addressable actor for every courier, without a canister for every courier.
Play it in a browser tab →
actor* is experimental and behind two compiler flags — --experimental-local-actors <N>, plus --experimental-local-actor-persistence when instances are held in a stable variable. moxzi-game build passes what a project needs; see Build a game. A Motoko library that uses actor* declares it in its mops.toml ([moxzi] features = ["local-actors", …]) and moxzi build adds the flags for its consumers — see Projects and packages.
Deterministic, headless, measurable#
The same package runs without a window. moxzi-game run-headless executes a fixed number of ticks and writes a report; the checkpoint and measurement tools compare native and browser runs against each other. A game you can simulate is a game you can test.