Project Settings¶

Project → Project Settings holds everything the project itself carries: how the game is identified, how its canvas and window are set up, which folders it reads from, and what each platform adds on top of that. Every value on this dialog is saved in project.yaml and travels with the project in version control.

Machine-specific settings — the compiler, the CMake and Emscripten paths, the default export folder — are not here. They live in Editor Settings.

The dialog is a modal with six tabs and an OK / Cancel footer: nothing is written until you press OK. Settings that differ from their default show a small restore arrow next to the label; click it to put the default back. Hover the (?) marker at the end of a row for the setting's description.

General¶

Project¶

The Export Window shows the same Start Scene and writes back to this setting, so the two never disagree.

Version Control Files refreshes both files whenever the project is saved, and never replaces one the editor did not generate — see Version Control. It also turns on the Git status the editor shows.

Loading¶

The loading screen that SceneManager::loadScene shows at startup and between scenes. Exported games and the editor's Play apply these at startup.

See Loading screens for how a transition runs and how the loading scene can animate its progress and fade out.

Application¶

One identity, shared by every platform. Each platform section can override any of these four values; leaving an override empty inherits from here.

Because each platform has its own rules for these fields, the editor validates as you type and reshapes the value at export:

Canvas¶

See Multiple Resolutions for what each scaling mode does at runtime.

Window¶

Controls the OS window desktop builds create at startup.

The Icon is the desktop icon for all three desktop platforms: it is embedded into the Windows executable, used as the window and taskbar icon on Linux and Windows, and becomes the dock icon on macOS. Apple bundle icons and Android launcher icons are separate settings on the Platforms tab. A file inside the project is stored as a project-relative path, so the setting survives moving the project folder.

See Project Workflow — VSync and Window for the per-backend behavior tables, and Editor Settings for the editor window's own VSync.

Directories¶

Asset and Lua references are stored relative to those two roots, so changing one migrates the whole project in a single step — see Assets and Lua directories. Script directories are about the C++ build rather than what the running game reads; see C++ Build Setup → Script directories.

The native resource pack has runtime restrictions — packed entries are read through Data, not File — described in Export Window → Native resource pack.

Build¶

The standard belongs to the project rather than to your machine — a script using consteval needs C++20 wherever it is built — so it is saved in project.yaml and travels with the project. Play and export both compile scripts with it, and an export compiles the engine with it too.

Which compilers can satisfy it is machine-specific: pick one under Editor Settings → Desktop. C++17 works anywhere the editor runs; C++20 and C++23 need a recent MSVC, GCC or Clang.

Physics backends¶

Turn off a backend the game never uses and the export leaves it out — its library, its bodies and joints, and their C++ and Lua API — for a smaller build that compiles faster, which matters most on Web and mobile. Desktop, Web and Source Code exports all honor it, including the generated Xcode and Android Studio projects.

Play is not affected: the editor always runs with both backends, so a scene can still hold a body the export will drop. The export warns when it does, naming the scenes, and the exported game runs without those bodies and joints. A C++ script that includes Body2D.h or Body3D.h stops the export build with an error naming this setting; code that must build either way can test DORIAX_PHYSICS_2D and DORIAX_PHYSICS_3D, which are only defined for an enabled backend. For picking and line-of-sight without any physics, cast against mesh bounds with RayFilter::BOUNDS.

Platforms¶

Each platform gets its own collapsible section, closed by default. A section holds only what that platform adds on top of the shared Application block: any name, identifier, version or build field left empty inherits, and the field's placeholder shows the value it would inherit as you type.

These settings are written into the exported project. Web, Linux and Windows settings apply to every export mode that reaches those platforms; macOS, iOS and Android settings are applied to Source Code exports, which is where the Xcode and Android Studio workspaces are generated.

Web¶

A custom shell replaces {{DORIAX_DEFAULT_HTML}} with the page Emscripten generated; the build fails with a clear CMake error when the marker is missing. Two more optional markers give you control over placement: {{DORIAX_TITLE}} is replaced with the app name, and {{DORIAX_HEAD_INCLUDE}} receives the favicon link, the head include, and the styles the two checkboxes add. Without that second marker the block is inserted before </head>.

A game sent to several portals needs one export per portal, since each build includes one SDK. Choosing YouTube Playables also adds YouTube's SDK <script> to the page head, which YouTube requires to load before the game. See Monetization → Web portals.

Linux¶

The launcher entry is written beside the executable at build time, together with app_icon.png when the Window icon is set. Installing it is what gives the game an icon in menus and docks — and on Wayland, in the window itself.

Windows¶

Writes the executable's version resource. The desktop icon comes from the Window tab and is reused here.

Both version fields take up to four numbers from 0 to 65535. Type a shorter one and the dialog shows the padded result underneath — Exports as 1.0.0.0 — so there is no guessing about what lands in the resource.

macOS¶

iOS¶

Apple bundle identifiers accept letters, digits and hyphens (com.company.my-game), and Apple versions accept at most three numbers — the dialog warns inline when a value does not fit.

AdMob App ID and Tracking Description apply only with Google AdMob on; otherwise the export removes both keys from Info.plist. The App ID has the form ca-app-pub-…~…, and the dialog warns when it gets an ad unit ID (with /) instead. Without App Store Purchases, the export leaves the StoreKit adapter out of the app. See Monetization for using both services.

Android¶

The permission list covers the common Android permissions by manifest name. Two shortcuts sit above it: None clears the list, and Game Defaults selects INTERNET, ACCESS_NETWORK_STATE and VIBRATE. Declaring a permission in the manifest is not the same as being granted it — runtime-permission prompts are still your own code's job.

Google's SDKs go into the export only when their service is enabled, so a game without ads or purchases ships without them. Both need newer Android versions than the default Min SDK: the export raises it to 24 for AdMob and 23 for Play Billing, with a warning, and compiles against SDK 35 or newer. When Min SDK is lower, the dialog says so under the checkboxes. As on iOS, it also warns when AdMob App ID holds an ad unit ID.

With AdMob on, also declare in the Play Console that the app contains ads and uses the advertising ID. See Monetization for using both services.

Where the values are stored¶

Everything on this dialog is written to project.yaml, and only values that differ from their default are written — a project that never opens the Platforms tab keeps a clean file.

Two things that used to live in project.yaml no longer do: the compiler kit (cmakeCCompiler, cmakeCxxCompiler, cmakeGenerator) and the parallel job count (cmakeBuildJobs). They are machine-specific, so they moved to the editor's settings.yaml — see Editor Settings. Opening an older project migrates those four values automatically, once, and never over settings the current machine already has.

See also¶

• Editor Settings — the machine-level counterpart
• Project Workflow — project anatomy, scenes, bundles, save strategy
• Version Control — what to commit, and where per-user state is kept
• Export Window — where these settings are applied