# Castle Game Engine: a Pascal 3D and 2D engine built around one manifest

> Castle Game Engine is a cross-platform 3D and 2D game engine written in modern Pascal, pairing a visual editor with a command-line build tool that both read CastleEngineManifest.xml. The interesting part is the toolchain integration for Lazarus, Delphi and VS Code; the interesting weakness is that the stable line of the project is still an alpha.

**castle-engine/castle-engine** — Cross-platform (desktop, mobile, console, web) 3D and 2D game engine. Powerful visual editor. Support for glTF, X3D, IFC and more. Fast clean code using modern Pascal. Free and open-source.

- Repository: https://github.com/castle-engine/castle-engine
- Website: https://castle-engine.io/
- Stars: 1,259 · Forks: 172
- Language: Pascal
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/castle-engine-castle-engine

## The gap Castle Game Engine targets

Castle Game Engine is aimed at a narrow but real audience: developers who already work in Object Pascal and want a complete 3D and 2D runtime instead of assembling one from rendering libraries. The project describes itself as a cross-platform engine covering desktop, mobile, console and web targets, with a visual editor for design and a build tool for command-line builds. The language story is the strongest differentiator. The code is described as fast, clean, modern Pascal, and the engine targets Free Pascal with Lazarus as well as Embarcadero Delphi, which means a team can move between an open source compiler stack and a commercial one without leaving the language.

The scope inside the engine is broad. The visual editor designs viewport contents, with scenes, cameras, navigation, primitives and lights, and it also lays out user interface elements such as buttons, images and labels. Rendering features listed include composable shader effects, shadows, mirrors, physically based rendering, bump mapping and gamma correction. Content import covers glTF, X3D and Spine, with IFC represented by a dedicated example directory. For a Pascal developer starting from an empty repository, that is a real breadth of capability rather than a thin wrapper over a low level renderer.

The trade-off is that the whole thing is one person's life project with a community around it, so the surface area you inherit is the surface area the maintainer chose to keep.

## How CastleEngineManifest.xml ties the editor and the build tool together

The architectural decision worth understanding is how little duplicated configuration the workflow contains. Both the visual editor and the command-line build tool read the same project settings from CastleEngineManifest.xml. That single file is the pivot of the whole toolchain: it is where the engine path, the project type and the target platforms are declared, and it is what lets the same project be opened in the editor, compiled from a terminal, or built from Visual Studio Code or an IDE without anyone maintaining a parallel build script.

The project data model follows from that. A project holds scenes rather than loose meshes and cameras, so that a level is a navigable graph the editor can display and the engine can load. Components cover both halves of a game, the 3D and 2D world and the interface layer with its buttons, images and labels, which means the same scene format can carry gameplay and user interface together.

The build side follows the same pattern. The Makefile in the repository root exists to build the tools and the editor and to register Lazarus packages, and its examples target delegates to the build tool rather than calling the compiler directly, so the manifest stays the single description of what gets built. The one documented exception is bootstrapping: when compiling the build tool itself, the build calls the compiler directly, because that is what the maintainer expects people to do.

## Getting the editor running and compiling from source

The README is explicit that it is not the place for a full install guide. It points to the installation manual page at castle-engine.io/install and then gives a short path: download the engine from the downloads page, unpack the release, and run the editor executable that ships inside it. The unpacked binary archive is therefore the practical starting point, and it also carries the API reference offline, openable straight from the file system.

If you take the source route instead, the README tells you to read the compiling from source page first, and the root Makefile describes the Unix workflow. The following block shows the two make invocations the Makefile names for the two Unix flavours:

```bash
make
gmake
```

On Linux and most other Unixes the plain `make` call builds the tools that do not depend on LCL, the editor, registers the Lazarus packages, and places tools and the editor into the `bin/` subdirectory. On FreeBSD the Makefile expects `gmake` instead. On Windows the Makefile expects Cygwin with its make package, and it warns that Cygwin's directory has to come before the Free Pascal and Delphi directories on the PATH, because their make implementations cannot execute the shell scripts the Makefile relies on. That PATH ordering detail is the kind of thing that costs an afternoon if you hit it without warning.

The API reference is not only online. In a binary release you can open the file `doc/reference/index.html` in any browser without a network connection, which is convenient on a machine with restricted egress.

## Lazarus, Delphi and VS Code all reach into the same project

The editor is not the only front end, and this is where the project is more accommodating than most engines of its size. The README names three alternatives. Visual Studio Code gets a first-party extension under the identifier `castle-engine-team.castle-engine`, which adds Pascal completion and syntax highlighting and wires CGE projects into the editor so you can build, debug and run them without leaving the IDE. Lazarus is supported by registering the engine's packages, which the editor does for you through the button named "Register Lazarus Packages" found under "Preferences -> FPC and Lazarus". Delphi is supported by installing the engine's Delphi packages, which adds a "Tools -> Castle Game Engine" menu with commands such as "Set Engine Path..." and "Configure Delphi to Use Engine".

The Lazarus path is the most concrete in the repository. The package file and the project group are named in the README, and the group is what builds the important packages and tools such as the editor and the build tool:

```bash
castle_engine_lcl.lpk
most_important_lazarus_packages_and_tools.lpg
```

Installing `castle_engine_lcl.lpk` gives Lazarus users the LCL component `TCastleControl`, so a live 3D or 2D view can be dropped onto a regular Lazarus form. That is the cheapest way to get a native control into a desktop application that is mostly standard LCL work. The deeper point for a team is that these are integrations rather than ports. The Delphi packages, the VS Code extension and the Lazarus registration all point back at the same engine sources and the same manifest, so tool choice is a decision about the editing surface rather than about the runtime.

## Content formats and the examples tree as a learning path

The examples directory is unusually broad, and it is the best available map of what the engine can actually do. The top level splits into 2D and 3D games, then continues into animations, audio, curves, fonts, localization, game controllers, network, physics and creature behaviors. There are also directories that read more like research notes than like games: advanced_editor, research_special_rendering_methods, component_gallery, isometric_game and isometric_game_3d, and a ifc directory for building industry format content. A historic_first_web_demos folder points back at the web target the project claims to support.

Format support lines up with that tree. glTF, X3D and Spine are named in the feature summary, and IFC has its own example directory, which together cover modern interchange, scene description, skeletal animation and building information modelling. A separate sprite sheet editor was mentioned in the v7.0-alpha.2 release notes, and the same release description also lists terrains, new cameras and a batch of new components for lights and primitives.

For an engineer evaluating the engine, this directory is worth more than any feature bullet. The component_gallery folder, in particular, is a live inventory of what you can instantiate, and the physics, network and game controller folders show the shape of the subsystems you would otherwise only find in the API reference.

## The licence that GitHub could not classify

The engine is available under LGPL version 2 or later with a static linking exception. The README says this is the same licence used by the Free Pascal RTL and the Lazarus LCL, and states the practical effect plainly: you can make commercial and closed-source games with the engine, and you only have to share your modifications to the engine core. The details sit on the licence page of the project site, and the repository carries a COPYING.md file alongside it.

GitHub's own classification for the repository is Other, because the terms include an exception that its automated licence detector does not recognise. That mismatch is worth flagging for anyone running an automated licence audit in their build pipeline, since a scanner reading only the badge or the label will report an unclassified licence rather than the LGPL family. Reading the licence text and the project's licence page is the only way to confirm what the static linking exception permits in a given distribution shape, and this is a legal question rather than an engineering one.

The engine core is a separate question from the assets, the example media and any third party content in the examples tree, and the README does not spell out how those interact with the terms. If a product depends on bundled example content, that gap has to be closed on your own.

## Version numbering, the snapshot tag, and the upgrade question

The release list explains a lot about the project's rhythm. There is a tag named snapshot, described as the latest release of Castle Game Engine and auto-updated, but it carries a date of 2019-03-31, which tells you that tag is a moving target whose label date says nothing about the current state. The numbered builds are the meaningful ones: v7.0-alpha.2 from 2022-09-12, and v7.0-alpha.3 from 2024-08-21, whose notes cover physics, blending, batching, shadows, Delphi packages on Linux, UI masks, editor user experience work, Android and iOS work, float textures, VS Code integration and Sketchfab support.

So the 7.0 line is still alpha, and the newest numbered build carries a date well before the recent activity. The repository is not archived, and the last push was on 2026-10-16, so the code is moving, but the numbering has not caught up. If you pin a project to a release, you are pinning to a build from 2024. If you track the default branch, you are tracking an API surface that the project itself marks as alpha and that has changed underneath two alpha cycles already.

This is the sharpest trade-off in the whole evaluation, and it deserves to be settled before any code is written rather than after the first framework refactor. A 7.0 alpha that names physics, batching and shadows in its release notes is also a 7.0 alpha that is expected to change how those subsystems are configured. Pinning to a tag costs you the newest editor fixes; tracking the branch costs you occasional breakage in your own source. The README does not document a rollback procedure or a compatibility policy between alpha builds, and no performance benchmarks are published for any of the features listed in the release notes.

## Where the documentation stops

The gaps in the written material are specific and worth naming. Installation is delegated to an external manual page, so the repository itself carries no dependency list, no step-by-step setup and no pinned compiler version. The Makefile assumes GNU make, a shell and either Free Pascal or Delphi, and it does not enumerate what else those compilers need installed. The README does not document rollback, upgrade or migration between alpha releases, and it does not publish a compatibility table. There are no published benchmark numbers for the renderer, the physics engine or the batching work mentioned in the release notes, and no user count, adoption figure or production title is offered either.

The absence of published performance data is the one that should shape expectations. A claim like physically based rendering or composable shader effects tells you the feature exists in the code, not how fast it runs on your hardware, and the two things teams most often get wrong about a new engine are its frame budget on low end devices and its build times on CI. Both have to be answered by building the examples and measuring on your own machines, which is exactly what the examples tree is set up to let you do.

What the project does supply is unusually clear for an engine of this size: a named installation page, a named downloads page, a named compiling page, an offline API reference inside the binary archive, a licence page, an API reference site, a forum and Discord channel, and a page for credits and supporters. The support surface is real, and it is also the right place to ask the question the repository itself leaves open, which is what the alpha line promises before a stable 7.0 ships.

## Conclusion

Pick Castle Game Engine if your team already writes Pascal, wants a single engine for desktop, mobile, console and web targets, and accepts working against an alpha API surface; stay on your current stack if you need a stable tagged release with a dated changelog and a documented upgrade path, because v7.0-alpha.3 dated 2024-08-21 is the newest numbered build even though the last push was on 2026-10-16. Before adopting, verify the three things that decide most projects: the build tool on your own compiler and target platforms, the licensing of the engine core versus your game code, and the contents of the examples/ directory closest to your own game.

## FAQ

### Which languages and IDEs can I use with Castle Game Engine?

The engine is written in modern Pascal and works with Free Pascal and Lazarus as well as Embarcadero Delphi. The README also describes a Visual Studio Code extension that provides Pascal completion and syntax highlighting and can build, debug and run projects from inside the IDE.

### How do I install Castle Game Engine and start the editor?

The project points to its installation manual page and recommends downloading a release from its downloads page, unpacking it, and running the `bin/castle-editor` executable inside. For a source checkout, read the compiling from source page, then use GNU make, where the root Makefile builds the tools and the editor and registers the Lazarus packages.

### Can I use Castle Game Engine for a commercial closed-source game?

Yes, according to the licence terms. The engine is available under LGPL version 2 or later with a static linking exception, the same licence used by the Free Pascal RTL and the Lazarus LCL, so you can make commercial and closed-source games and only have to share your modifications to the engine core.

### What is the difference between the Castle Game Engine editor and the build tool?

The editor is used to design and build your applications, while the build tool builds them from the command-line. Both read the same project settings from the CastleEngineManifest.xml file, so the two are alternative entry points to the same project rather than separate build systems.

## Sources

- [castle-engine/castle-engine on GitHub](https://github.com/castle-engine/castle-engine)
- [Issues](https://github.com/castle-engine/castle-engine/issues)
- [Project website](https://castle-engine.io/)
- [README](https://github.com/castle-engine/castle-engine/blob/master/README.md)
- [Releases](https://github.com/castle-engine/castle-engine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/castle-engine-castle-engine