Building Plasma
Plasma uses PlasmaBuild to compile the engine and generate IDE workspaces. Start with Building for Windows for installation and your first editor build.
Build Platforms
The Windows x64 editor is the workflow covered here. Android has separate target and packaging rules in Code/BuildSystem/PlasmaBuildAndroid.pb.cs; see Docs/AndroidWorkflow.md in the engine repository for requirements and limitations. A platform appearing in a generated workspace does not mean every target supports it.
Build System
Run commands from the engine repository root. Build metadata lives in C# rule files:
| File | Purpose |
|---|---|
*.module.cs | Source files, include paths, definitions, and module dependencies. |
*.target.cs | Executables or libraries, dependencies, and build steps. |
*.workspace.cs | Targets included in an IDE workspace. |
PlasmaEngine.workspace.cs selects PlasmaEditor. Its target rules include editor dependencies and runtime tools such as Player, Inspector, ShaderCompiler, and Fileserve.
Generate a workspace:
plasmabuild generate workspace --workspace PlasmaEngine --ide vs2026
Or build directly without generating a solution:
plasmabuild build PlasmaEditor --platform Windows --arch x64 --configuration Development
The repository includes workspace scripts for Visual Studio, VS Code, Rider, and CMake. Generated CMake files provide IDE integration backed by PlasmaBuild. Make persistent build changes in the rule files, then regenerate the workspace.
Build Types
Use the full configuration names in commands:
| Configuration | Intended use |
|---|---|
Debug | Investigating C++ problems with a debugger. |
Development | Everyday editor and engine development; the default configuration. |
Release | Optimized profiling and performance measurements with development diagnostics. |
Shipping | Final runtime builds with development facilities disabled. |
Both Development and Release map to the engine's internal Dev build type. Release retains assertions, profiler scopes, Tracy, and diagnostic statistics while enabling optimization. Use it for performance comparisons instead of assuming a Development build has release performance.
Older PlasmaBuild installations or generated workspaces may list only Debug, Development, and Shipping. Use a PlasmaBuild version compatible with the checkout and regenerate the workspace if Release is unavailable.
Shipping disables facilities such as profiling and allocation tracking. Debug-symbol generation is controlled by build rules; do not assume Shipping builds can never produce symbols.
Build Outputs
Windows development binaries are written to Binaries/Windows_Development, including PlasmaEditor.exe. Other configurations use their corresponding output directory. Intermediate build data and generated project files live under Intermediate/.
Keep companion executables, DLLs, and deployed runtime files together. Copying only the editor executable does not produce a usable engine installation.
Vulkan
Vulkan headers are included in the engine's third-party sources, so compiling the Vulkan renderer does not require the Vulkan SDK. Install the SDK when you need validation layers or Vulkan development tools.
The renderer loads Vulkan dynamically. Running it still requires a compatible GPU and Vulkan driver/runtime; an optional SDK does not make the runtime optional.
Use the Vulkan-Hpp dispatch configured by RendererVulkanDLL.h. Direct calls to Vulkan C entry points can cause linker errors because the renderer uses dynamic dispatch.
Static Linking
Static linking can remove apparently unreferenced registration code. Follow the relevant platform and module rules when integrating statically linked code. The current Android packaging workflow uses shared libraries for NativeActivity; it does not require all engine code to be statically linked.