Read on for details!
We support a wide range of formats for 3D and 2D data.
Our main scene format is X3D, which is an open standard and you can export to it from virtually any 3D modeler. X3D can express 3D data with interactive features, scripting, prototypes etc.
While X3D is our "scene graph" format, the whole engine is designed as a general-purpose 3D / 2D engine, and many other model formats are supported as well: glTF 2.0, Spine JSON, VRML, Collada, 3DS, Wavefront OBJ, MD3, STL, Spine JSON and others.
You can use any 3D modeler to design your 3D and 2D data. Blender? 3DS Max? Anything else? In part, that's because X3D (and it's predecessor, VRML) is an open and popular 3D format, and decent exporters for it exist in practically every 3D authoring tool. For detecting "placeholders" on levels you can configure the detection method to match your authoring tool.
In case of Blender, we have a description of how to create and export data along with some custom exporters (but to export the static 3D data from Blender, you can just use the standard X3D exporter!).
Animations are supported, in two flavors: interactive animation interpolated at runtime, or a "precalculated" animation (for fastest playback, but at the cost of using more memory).
We can save (aka "serialize") the current state of the world to an X3D file, which can then be read back by our engine. You can use it e.g. to make a full-featured 3D editor on top of our engine! See TCastleSceneCore.Save and Save3D for basic methods to do this.
Various conversions between 3D model formats and even some editing capabilities are provided out-of-the-box by our tools.
Reading and writing of images in various formats, processing them and using as OpenGL textures. Besides many common image formats (PNG, JPG, PPM, BMP, and much more), included is also support for Khronos KTX and DDS (textures with compression, mipmaps, 3d, cube maps) and RGBE format (Radiance HDR format). See:
Handling of fonts. We can read fonts in many formats (like .ttf) using FreeType library, and render them at any size, with anti-aliasing or not. Fonts can also be embedded inside a Pascal source code, which allows us to provide default fonts (available as-is), and to use fonts even when FreeType library is not available. You can also use colorful fonts from a texture. Font rendering allows international characters in UTF-8. See manual about text and fonts and unit CastleFonts.
You can compile and package your games for various platforms:
It's easy to compile the same game to many platforms.
We have a build tool to make it easy to compile and package your games. Creating complete, ready-to-be-released Android and iOS applications is trivial. We automatically generate an Android apk or iOS XCode project.
Trivial to use integration with many services on Android: games (achievements, leaderboards), in-app purchases, ads, sound, vibrations, and much more. See Android Project Services documentation.
Trivial to use integration with many services on iOS, like Apple Game Center, in-app purchases, Facebook SDK, Google Analytics and Game Analytics.
The engine can be compiled into a library useful from other programming languages.
This does not expose the complete engine API (for now), but it does expose a simple 3D model loading,
rendering, animation, interaction. So you can e.g. make your own VRML / X3D browser.
We have an example in engine sources
that shows how the engine can be embedded in a C++ Qt application.
ComposedShaderor enhance with
Effect, see links above).
We have a comfortable and extensible implementation of scene manager and 3D objects. You have a ready implementation of levels, creatures (with AI), items, players and other things typical to 3D games.
Engine manual contains detailed information about this.
3D and 2D. Not everything is about 3D. Our API is perfect for 2D games too, with flexible (and pixel-perfect) rendering of 2D images, movies, text and everything you can compose from them (like GUI controls). We also support Spine which is very cool for creating 2D animations.
Rigid body physics. We are integrated with a powerful Kraft Physics Engine and you can easily use dynamic physics in your games.
Octrees are used for various collision detection tasks. For dynamic scenes, a hierarchy of octrees is used, allowing accurate and fast collision detection even when the scene constantly changes. There are many ways to use collision detection, for example you can query for collision between a specific TCastleTransform instance and the rest of the world (by methods like TCastleTransform.Move, TCastleTransform.Ray TCastleTransform.Height) or you can ask the whole world whether it collides with some geometric shape (calling methods like TCastleTransform.BoxCollision, TCastleTransform.SphereCollision TCastleTransform.RayCollision on the main 3D world instance: CastleSceneManager.Items).
examples/tiled/in the engine code.
tools/sprite-sheet-to-x3ddistributed as part of the engine.
castle_game_engine/examples/subdirectory. For even more examples, see some larger games we have developed using Castle Game Engine and their sources (for example on GitHub Castle Game Engine organization).
TCastleWindow) and Lazarus components (
TCastleControl) to make simple X3D and other 3D models browser, on a Lazarus form or independent from Lazarus LCL. The engine is integrated with Lazarus — we have various Lazarus components.
CastleWindowunit). And so on. Of course, ultimately you can just use everything from our engine, nicely integrated — but the point is that you don't have to.
The engine is developed for the Free Pascal Compiler, an open-source cross-platform compiler. We have Lazarus components for RAD development, although the core engine doesn't depend on Lazarus LCL and you can develop full games with pure FPC (we have our own OpenGL window management unit, if you want). The whole engine is 100% clean Object Pascal code.