Projects and commandspreview
The game.yaml file, project layout, and every moxzi-game and moxzi-player command.
game.yaml#
format_version: 1
project:
id: com.example.drift
title: Drift
version: "0.1.0"
sdk_abi: 1
entry: src/Main.mo
asset_roots: [assets]
simulation_hz: 30| Field | Required | Meaning |
|---|---|---|
format_version | Yes | 1 |
project.id | Yes | A reverse-domain id, such as com.example.drift. Saves and iOS app ids use it |
project.title | Yes | Window and app title |
project.version | Yes | Your game's version |
sdk_abi | Yes | 1 |
entry | Yes | The Motoko file containing the entry actor, relative to the project |
asset_roots | Yes | Directories containing assets |
simulation_hz | Yes | Ticks per second. Must match moxzi_describe |
motoko_packages | No | Libraries for mo:NAME imports, as NAME: path. Paths must be inside the project |
motoko_stack_kib | No | Stack size for the game's Motoko code, in KiB |
capabilities | No | Host services the game may use. http allows HTTPS outcalls, if the player supports them. Without it, the game has no network access |
Imports that are always available: mo:moxzi/… (the game SDK) and mo:game-assets/Assets (your asset bindings, generated at build time).
Using libraries#
There's no mops support in game projects yet. Copy a library's source into the project and name it in motoko_packages. Pong does this with the Motoko base library:
motoko_packages:
base: vendor/base-0.16.0/srcCalling the Internet Computer#
A game with capabilities: [http] can use the ic-agent library to query and call canisters, for example to submit a score. Vendor it with motoko_packages as above.
Commands#
| Command | Does |
|---|---|
moxzi-game check PROJECT | Reads game.yaml and asset metadata. Doesn't compile |
moxzi-game init-assets PROJECT | Creates .meta.yaml files for assets that don't have one. Never changes existing files |
moxzi-game bindings PROJECT | Prints the generated Assets module |
moxzi-game build PROJECT OUT | Compiles and packages the game into OUT, which must not exist |
moxzi-game validate PACKAGE | Checks a built package's structure, file hashes and limits |
moxzi-game run-headless PACKAGE TICKS native|pulley | Runs the simulation for TICKS ticks without a window and prints a JSON report |
moxzi-game inspect-checkpoint SAVE | Prints a summary of a save file |
moxzi-player PACKAGE native|pulley|aot [SECONDS] | Plays a package. With SECONDS, exits after that long |
moxzi-game build needs the compiler. Set MOXZI_BIN, MOXZI_COMPILER and MOXZI_LINKER (see Your first game).
Execution backends#
| Backend | Meaning |
|---|---|
native | Compiles the game's wasm to machine code when it loads. The usual choice on a Mac |
pulley | Interprets the wasm. Slower; used where compiling at runtime isn't allowed, such as iOS |
aot | A build with the game compiled ahead of time into the player. Experimental |
Player options#
| Option | Effect |
|---|---|
--save FILE | Save the game to FILE periodically and on exit |
--restore FILE | Start from a save file |
--message-fuel N | Instruction limit for each call into the game. Default 20,000,000. A call that exceeds it traps |
A built package#
| File | Contents |
|---|---|
package.json | Generated description of the package. Don't edit it |
main.wasm | The compiled game |
assets/ | Copies of your assets |
catalog.json, build.json | Asset catalogue and build provenance |
compile.log | Compiler output |
If a tool says package.json is missing, you've given it a project directory where it expected a built package.