- L3 was already in place (Phase 4 slice 10): plugins built against Unity's module assemblies bind to Tassix through Roslyn-generated type-forwarding facades, covered by an e2e fixture plugin.
cargo xtask package -- --scene <scene.json> [--scripts <dll>]... | --project <Unity project> --out <dir> [--title <name>]builds release and writes a game folder: the player renamed for the game,managed/,dotnet/(the newest installed .NET 10 hostfxr and Microsoft.NETCore.App, which the host now looks for beside the executable before any install), the game's files, andgame.json(title, window size, scene or project, scripts, asset cache).- The player reads
game.jsonwhen its command line names no scene, project or scripts, and opens its window with the game's title and size. - Cooking: packaging runs the game headless for a few frames with the package's cache, which cooks imported models and images there and compiles a Unity project's scripts into its Library, so the packaged game starts without compiling (about a second for the Unity sample).
- Checked: the packaged Coin Dash sample renders the same frame as the development player, from its own runtime; the Unity sample project packages and runs.
- Not yet: packaging in CI, trimming the managed runtime (Roslyn ships for exec and facades), installers, other platforms.
- Next: NativeAOT builds of the managed runtime.
Phase 6 · Slice 1 ·