The Axmol workbench: engines, projects, and build toolchains — with a general-purpose coding agent built in
The assistant is a general programming and debugging tool first. Axmol awareness — the engine index, the project digest, a toolchain pinned to the engine's own 1k/build.profiles, and a shell the agent can drive and verify itself
Early stage — see Releases for what is shipping. The GUI is C# / .NET 8 / Avalonia (net8.0, targeting three platforms; validated on Windows, macOS / Linux not yet verified), and it is validated against the engine's current release line rather than one pinned build.
- Engine management — download, import, set default, repair, and uninstall. Repair keeps a backup; uninstall keeps a recycle directory.
- Project management — create C++ or C++ + Lua projects through Axmol's own CLI, pinning engine version and script kind; choose the project directory and editor.
- Build & run — pick a platform and Debug / Release at build time, with outputs kept separate; a progress window shows phases, compile steps, and elapsed time, and can be cancelled.
- Toolchain — status detection mirrors the engine's own rules: expected versions come from the engine's
1k/build.profiles, and the lookup order follows the engine (cmake/ninja/jdk/llvm/emsdkcheck the system first,axslcc/nugetprefer the engine tree,sdkmanageris engine-tree only). Installation is delegated to the engine's ownsetup.ps1(tools land inside the engine tree, not in Hub's data directory). Build, run, and deploy are delegated toaxmol build/run/deploy— see docs/adr/0002. - AI assistant — Ask / Plan / Agent modes with explicit plan and tool approval. Inactive conversations can raise native notifications for approvals and run completion, failure, or timeout; unread approvals mark the Windows taskbar or macOS Dock icon. Linux notifications go through
notify-send, and a click on one opens that conversation — through the link in the notification body, its action button, or the desktop entry the notification is attributed to; Linux app-icon badges are not available. - Logging — build and run logs are shown in-app and saved to the data directory.
- Chinese / English — switch languages instantly in Settings, and choose the data directory, default project directory, and Visual Studio / VS Code.
Platform/architecture support is expressed by a single build-target model (BuildTargets), constrained by host OS and engine major version (v3 adds windows-arm64, linux-arm64, wasm64).
Game target platforms and Hub's own runtime platform are different things. The Windows GUI is implemented; macOS / Linux GUIs are not yet.
| Game target | Required host | Status |
|---|---|---|
| Windows x64 | Windows | Managed MSVC / SDK; Debug and Release build and Hello World run verified |
| Android ARM64 / x64 | Windows, Linux, macOS | ARM64/x64 Debug and ARM64 Release APK/AAB build, signing, and alignment verified on Windows; on-device pending |
| WebAssembly wasm32 | Windows, Linux, macOS | Real build and local HTTP preview verified on Windows; browser WebGL scene pending |
| Linux x64 | Linux | Build and run entry points wired; native host pending |
| macOS ARM64 / x64 | macOS | Xcode build entry points wired; native host pending |
| iOS / tvOS, device and simulator | macOS | Build plan and unsigned entry points wired; signing, deploy, and on-device run pending |
| UWP / Xbox x64 | Windows | Target management and build plan; isolated toolchain and packaging not done, execution blocked |
The CLI cross-publishes win-x64, linux-x64, osx-x64, osx-arm64; only the Windows host has actually been exercised. Android supports Debug / Release signed APK / AAB; Release uses the project key, and the ARM64 release package has been actually built and verified. See docs/android-release-signing.md for the full signing workflow.
Installer packages are not yet code-signed, and first-install verification on a clean Windows 10 / 11 is not done yet.
Use a published Windows installer and pick a writable install directory. The installer bundles the .NET runtime — no .NET SDK needed; the engine and dev tools are downloaded on demand, not bundled with the Hub.
- In Settings, choose the data directory, default project directory, and language. The data directory needs enough space for engines, tools, and build caches.
- On the Engines page, install the engine version you want to target. On the Toolchains page, select that engine version and run
setup.ps1to prepare the toolchain. - On the Projects page, create a project ("C++" or "C++ + Lua"), then click Build and pick a platform and configuration.
- Open the output directory after a successful build; click Run to launch. Android needs a connected device with an explicit serial.
MSVC uses the Microsoft official installer, which requests UAC and registers a new system-level Build Tools instance. Hub itself does not modify global environment variables or Git config. When you explicitly run engine setup, Hub passes -hub: AX_ROOT and PATH are changed only in the setup process, not persisted to the user environment or shell profiles. On Windows, setup may still change the current user's PowerShell execution policy and request elevation. Hub does not auto-select an existing Visual Studio instance to modify.
The detailed guide — running the GUI from source, the runtime verification flags (--verify-shell, --verify-theme, --verify-foundation, --smoke, --smoke-pages, --verify-ops, plus the two headless ones --check-secrets and --check-linux-integration), the CLI contract, and packaging — lives in docs/building-from-source.md.
You need a .NET SDK, and it needs a recent enough compiler. The projects target net8.0, but the Avalonia 12.1.3 analyzers/source-generators are compiled against compiler version 4.14 — an older SDK 8 patch (e.g. the 8.0.1xx that apt install dotnet-sdk-8.0 gives you on Ubuntu) only carries compiler 4.8, which silently fails to run the source generator and the build errors out with CS0103: The name 'InitializeComponent' does not exist. .NET 10 SDK always works (it ships a far newer compiler), so it's the safest choice on a dev machine. The SDK version you install and the net8.0 target in the build output are two different things — that's why a successful build still prints AxmolHub -> .../net8.0/AxmolHub.dll. See docs/ci.md §2.4 for how CI pins its own SDK (10.0.x) and why the dev-machine wording is only a floor.
Per-OS installation steps for the required .NET 10 SDK live in docs/building-from-source.md (macOS and Ubuntu; Windows via winget install Microsoft.DotNet.SDK.10).
Quick start:
dotnet build src/AxmolHub/AxmolHub.csproj -c Release
dotnet run --project src/AxmolHub -- --data-root ./dataThe CLI exposes a --json contract for scripts, CI, MCP, and the Axmol Editor; see docs/cli-json-contract.md.
src/
AxmolHub/ Desktop GUI (net8.0, three platforms) and icon
AxmolHub.Core/ Engine, toolchain, download, state, build, and deploy logic
Scripts/ Runtime PowerShell wrappers, copied into each client's output
AxmolHub.Cli/ Host CLI entry point
tests/
AxmolHub.Checks/ Behavior checks with no external test framework
manifests/ Fixed tool versions, download URLs, and SHA-256
installer/ Velopack packaging, icon conversion, and install-check scripts
licenses/ Third-party license texts
docs/ Design decisions (ADR) and user-facing guides (Chinese)
docs/images/ README screenshots
Engine sources, SDKs, compilers, personal projects, caches, dev notes, and Git history live outside this source tree. artifacts/, data/, bin/, obj/, and personal settings are excluded by .gitignore. Binary attachments belong in GitHub Releases.
Welcome. Please include the Hub / engine version, OS, target platform, Debug / Release, reproduction steps, and relevant logs; redact private directories, device serials, and credentials before posting.
Keep changes scoped: UI logic in AxmolHub, build and state logic in Core, and the CLI reuses Core. Runtime PowerShell scripts belong to Core/Scripts/ and are copied into each client's output, not into any single client project. New UI strings must provide both Chinese and English. Toolchain versions do not live in Hub — the source of truth is the engine's 1k/build.profiles, and installation is the engine's setup.ps1 (see docs/adr/0002). Third-party NuGet packages may only go into AxmolHub (currently Velopack + Avalonia.*) and AxmolHub.Agent (the AI capability layer: Microsoft.Extensions.AI* + System.Security.Cryptography.ProtectedData); Core, Cli, and Checks keep zero NuGet dependencies of their own — their offline cold build is a deliberate property.
Axmol Hub does not collect telemetry or personal information. It opens a network connection for three things: to fetch engine and toolchain version information and to download the engines, toolchains, and dependencies you choose to install or update (from axmol.dev, GitHub, and configured mirrors); to the model provider you configure, for sign-in, the model list, and the requests you send; and to the one address shown on an approval card when the assistant reads a web page with web_fetch (https only, at most 1 MiB, and the page's scripts and styles are stripped before its text reaches the model). The last channel is on by default and can be switched off in Settings; turning it off removes the tool entirely. If you declare a server-side tool for a provider (serverTools in ai/providers.json), that provider's service may also read pages on its own to answer you — Hub sends the declaration, not the request, and the same Settings switch withholds it. Nothing is declared for any built-in provider until a gateway has been measured honouring one. Log files written for troubleshooting stay on your machine.
Installer packages are currently unsigned. Until code signing is arranged separately, Windows installers trigger a SmartScreen warning and macOS packages need xattr -r -d com.apple.quarantine (or Apple notarization) before opening.
Privacy: see Privacy policy.
Axmol Hub's own code is MIT. Third-party files, engines, SDKs, compilers, and runtimes keep their own licenses — see THIRD_PARTY_NOTICES.md. The HUB icon was produced with a generative image tool; source PNG and multi-size ICO are kept in src/AxmolHub/Assets/.