Building and publishing
How to turn your project into something players can run: a Windows or Linux executable, or a web build that runs in a browser.
The publish flow
-
Add a build target. A build target says which platform to build for, how your BT code ships (the code form), and where the result goes. Targets live in your project file's
build_targets(.ctproject). In Studio, open Build Settings → Targets; every project already has Windows, Linux and WebAssembly targets. -
Pick a code form. See Choosing a code form below.
-
Build. In Studio, pick the target in the toolbar and press Build (Ctrl+B), or click Build Artifact. From a terminal:
ctgame build --target "Windows Release" MyGame.ctproject -
Ship the output folder. A desktop build is one executable (plus one library file for Shared AOT). A web build is four files you upload to a web server. See Packaging and Web.
Optional: give the target a deploy folder and use Build & Deploy (or
ctgame build --target NAME --deploy) to copy the finished build to, for
example, a shared drive or a local test folder.
A target's output folder is wiped and refilled on every desktop build. Keep nothing else in it, and don't point it at your project folder.
Desktop builds are made for the computer you build on: build Windows games on Windows and Linux games on Linux. Web builds can be made on either.
Choosing a code form
| Source | Bytecode | Embedded AOT | Shared AOT | Linked AOT | |
|---|---|---|---|---|---|
code_mode | source | bytecode | aot_embedded | aot_shared | aot_linked |
| What ships | 1 executable | 1 executable | 1 executable | Executable + bin/program.dll (or .so) | 1 executable |
| Startup | Compiles your scripts every launch (slowest) | Loads precompiled code | Machine code ready, no compiling | Machine code ready | Machine code ready (fastest) |
| Script source in the package | Yes, readable | No | No | No | No |
| Needs a C compiler and CMake | No | No | No | No | Yes |
| Debug BT in a shipped build | Desktop, one target setting (Debugging); no C compiler needed | Desktop, one target setting | No | No | No |
| Windows / Linux | Yes | Yes | Yes | Yes | Yes |
| Web | Yes | Yes | No | No | No |
Quick advice
- Testing a build: Source (no compile step when you build, so builds are quickest).
- Web release: Bytecode (use Source if your game has its own C code that scripts call; see Web).
- Desktop release, no extra tools installed: Embedded AOT (one file, no compiling at startup) or Bytecode.
- Desktop release where the game must not create executable memory while running (some locked-down or anti-cheat environments): Shared AOT or Linked AOT.
- Desktop release as one plain executable with the fastest startup, and you have a C toolchain: Linked AOT.
AOT means ahead-of-time: your scripts are compiled to machine code when you build, not when the game starts. Details and limits for each form are in Code forms.
Pages
| Page | What it answers |
|---|---|
| Code forms | What each code form does, when to pick it, its limits |
| Platforms | Where games run, and what players need installed |
| What you need installed | Tools you need on your computer for each kind of build |
| Packaging | Which files get included, what ships, icons, the output folder |
| Files a build produces | What each output file is, and whether to ship, commit or delete it |
| Web | Web output files, hosting requirements, testing locally |
| Adding C code | Writing C for your game and calling it from BT |
Related: ctgame (command-line builds),
Building from Studio,
game.json,
Asset registry.