Castle Game Engine

Castle Game Engine is an open-source, cross-platform 3D and 2D game engine designed for developers who need professional-grade tooling with the performance and clarity of modern Object Pascal. It solves the challenge of building high-fidelity games that run on Windows, Linux, macOS, iOS, Android, Nintendo Switch, and web browsers, all from a single shared codebase.

The engine ships a fully integrated visual editor (castle-editor) for designing 3D and 2D scenes, configuring UI layouts, placing lights, cameras, and physics components, and building and running projects—without leaving the IDE. It also provides a command-line build tool (castle-engine) for CI/CD pipelines and scripted workflows, both driven by the same declarative CastleEngineManifest.xml project format.

Castle Game Engine supports industry-standard asset formats including glTF 2.0, X3D, Spine skeletal animations, IFC, Collada, MD3, and more. Its rendering system covers physically based rendering (PBR), shadow volumes, shadow maps, screen effects, mirrors, bump mapping, and gamma-correct color handling. The physics subsystem integrates the Kraft engine for colliders, rigid bodies, joints, and forces, with live simulation available directly in the editor.

The engine targets both Free Pascal Compiler (FPC) and Delphi, integrates with Lazarus IDE and Visual Studio Code via official extensions, and includes comprehensive documentation, 90+ automated tests, and extensive CI coverage. Its LGPL license with a static linking exception means you can ship closed-source commercial games without open-sourcing your game code.

What You Get

• Visual Editor (castle-editor) - A full WYSIWYG LCL-based editor for designing 3D/2D scenes, placing components (cameras, lights, primitives, UI controls), editing properties, running physics simulations live, and building/running your projects without leaving the tool.
• Command-Line Build Tool (castle-engine) - A manifest-driven CLI that invokes FPC or Delphi with correct flags, manages platform targets (Android, iOS, web, Switch), handles packaging, and integrates cleanly into GitHub Actions, GitLab CI, Jenkins, and Docker workflows.
• Multi-Format Asset Pipeline - Native loading of glTF 2.0, X3D 3.0/4.0, Spine skeletal animations, IFC, Collada, MD3, STL, and more, with Blender and Sketchfab import support and built-in Sketchfab browser in the editor.
• Advanced Rendering - Physically based rendering, shadow volumes, shadow maps, composable GLSL shader effects, mirrors, bump mapping, gamma-correct lighting, transparent blending, shape batching, occlusion culling, and float-based terrain textures.
• Physics Integration - Kraft physics engine integration with components for colliders, rigid bodies, joints, layers, and forces, with visual live simulation inside the editor.
• Audio System - Cross-platform spatial audio via OpenAL (desktop), WebAudio (browser), and FMOD, with sound components designable directly in the visual editor.
• Web and WebAssembly Target - Compile the same Pascal codebase to WebAssembly using FPC’s WASM32 target, with JavaScript glue generated by pas2js and automatic WebIDL-based bindings for browser APIs.
• IDE Integrations - Official VS Code extension (syntax highlighting, code completion, build/debug), Lazarus package registration (TCastleControl LCL component), and Delphi IDE menu with VCL/FMX TCastleControl and Delphi package support.

Common Use Cases

• Indie cross-platform game development - A solo developer builds a 3D adventure game using the visual editor for scene composition, Spine animations for characters, and deploys simultaneously to Windows, Linux, macOS, iOS, and Android using the same Pascal codebase.
• Browser-based game or simulation - A developer targets the web by compiling the engine and game code to WebAssembly with FPC’s WASM32 target, getting a deployable web app with no runtime dependencies beyond a browser.
• Scientific or architectural 3D visualization - A research team loads IFC models or custom X3D scenes into a Castle Engine application with a TCastleControl embedded in a Lazarus or Delphi desktop form for interactive inspection and simulation.
• Educational game with physics - A game studio uses the Kraft physics integration and the visual editor’s live simulation to prototype and tune a physics-based puzzle game, iterating on collider shapes and rigid body properties without recompiling.
• Legacy Pascal codebase with 3D UI - An enterprise team with an existing Delphi application adds real-time 3D visualization by dropping a TCastleControl component into a VCL or FMX form and integrating the engine’s rendering pipeline into their existing workflow.
• Console game development - A team with a Nintendo Switch development kit uses Castle Engine’s platform abstraction and build tool to compile their game for Switch, sharing all game logic with their PC and mobile builds.

Under The Hood

Architecture Castle Game Engine is organized as a strict dependency hierarchy of layered modules: base/ provides foundational utilities (vectors, colors, logging, class utilities), base_rendering/ adds low-level GPU abstractions (shaders, textures, OpenGL/ES context), scene/ builds the 3D scene graph and X3D node system on top, ui/ adds 2D UI components, and window/ provides platform-specific windowing and input backends. Large units use a distinctive include-file splitting pattern with {$define read_interface} / {$define read_implementation} guards to keep compilation units logically unified while distributing their code across multiple .inc files. The central castleconf.inc include file unifies compiler detection (FPC vs. Delphi), platform detection (Windows, Linux, Android, iOS, WASM), and feature flags—every unit includes it as its first directive, enforcing a single point of truth for build configuration. The build tool and visual editor are architecturally isolated from the engine core and communicate with it only through the declarative CastleEngineManifest.xml project format, enabling them to be replaced or extended without touching engine internals.

Tech Stack The engine targets both Free Pascal Compiler (FPC) and Delphi, with conditional compilation throughout to handle differences between the two. Rendering uses desktop OpenGL or OpenGL ES (for mobile and web) via thin abstraction layers, with GLSL shaders for all effects. Physics runs through the bundled Kraft library (a pure Pascal rigid body engine). Audio is handled by OpenAL (desktop), a WebAudio API backend (browser, via auto-generated WebIDL bindings), and optional FMOD integration. Web builds use FPC’s WebAssembly target for engine and application code, plus pas2js compiling a JavaScript glue layer; browser API bindings are generated automatically from Mozilla WebIDL files using webidl2pas. The build system supports GNU Make, lazbuild (Lazarus), and Delphi’s msbuild, all driven by the same manifest format. CI/CD runs on GitHub Actions with ten workflows covering quick tests, full cross-platform builds, Delphi compilation, API reference generation, and example verification.

Code Quality The project maintains over 90 test case files under tests/code/testcases/ using the custom CastleTester framework (an FPCUnit derivative compatible with both FPC and Delphi), covering vectors, cameras, class utilities, color handling, component serialization, composite images, controls, download, file I/O, and many more subsystems. Coding conventions are strictly documented and enforced: PasDoc comments are required on all public identifiers, the with statement and inline assembler are banned, PascalCase is used for all identifiers including single-letter loop variables, and all compiler warnings must be fixed. Deprecated APIs are preserved with the deprecated directive for backward compatibility. The ten GitHub Actions workflows provide comprehensive automated coverage across platforms. Documentation density is high: a full manual, API reference (PasDoc-generated), extensive inline comments, and abundant examples across dozens of categories.

What Makes It Unique Castle Game Engine occupies a rare niche as a production-quality, actively maintained game engine that compiles entirely from Pascal source—supporting both Free Pascal and Delphi—while targeting modern deployment environments including WebAssembly and Nintendo Switch. The WebIDL-to-Pascal binding pipeline (downloading Mozilla’s WebIDL specs and running webidl2pas) is an unusual technical approach that gives Pascal code type-safe access to browser APIs without writing C FFI glue. The X3D node system is used as a live scene graph—not just a file format—meaning declarative X3D descriptions drive the renderer in real time, enabling hot-reload of scenes and runtime inspection via the built-in debug inspector (F8 key). The include-based unit splitting pattern and the code-generated X3D node property bindings are distinctive Pascal-ecosystem techniques that enable a large codebase to remain maintainable without an external code generation toolchain.

Self-Hosting

Castle Game Engine is dual-licensed in practice: the engine core (everything in src/ except the visual editor) is under LGPL 2.0 or later with a static linking exception, exactly matching the license used by the Free Pascal runtime (FPC RTL) and the Lazarus Component Library (LCL). This means you can link the engine into a closed-source, proprietary commercial game or application as a static library without any obligation to open-source your game code—you only need to share modifications you make to the engine core itself. The visual editor (tools/castle-editor/) is separately licensed under GPL, which applies only to the editor executable; your games are not affected. Examples are under a permissive BSD-style license (do whatever you want). For developers evaluating self-hosting, the most relevant concern is the LGPL + static linking exception on the engine core, which is intentionally permissive for commercial use.

Running Castle Game Engine yourself means compiling from source using Free Pascal Compiler (FPC) and optionally Delphi. You are responsible for maintaining your own FPC/Delphi toolchain, keeping the engine updated by pulling from the GitHub repository, and managing platform-specific build environments (Android NDK, iOS Xcode, Nintendo Switch SDK for console). The engine has no cloud-hosted services, telemetry, or external dependencies beyond the compilers themselves. The build tool (castle-engine) wraps FPC/Delphi invocations and handles packaging, but all compilation happens locally on your hardware. The continuous integration workflows provided (GitHub Actions) are available as reference, but you must set up and maintain your own CI infrastructure.

There is no commercial hosted or SaaS tier for Castle Game Engine—it is entirely self-hosted and community-supported. Support is available through the official forum and Discord server, maintained by the project lead (Michalis Kamburelis) and community contributors. There are no SLAs, managed upgrades, or enterprise support contracts. The project is sustained through Patreon contributions and direct donations; companies who depend on the engine are encouraged to support the project financially but there is no paid tier with additional features or guarantees. Compared to commercial engines like Unity or Unreal, you gain full source access and LGPL commercial freedom, but you absorb all operational responsibility for toolchain management, platform certification, and long-term maintenance.