Castle Game Engine Features

Contents:

1. Summary

• Use any 3D or 2D software to create your models in any format: X3D, glTF, VRML, Collada, OBJ, MD3, Spine...
• Develop cross-platform applications, for desktop (Windows, Linux, macOS...), mobile (Android, iOS) and consoles (Nintendo Switch).
• Visual editor to design games UI and to build applications, powerful command-line build tool under the hood.
• Optimized rendering with a lot of graphic effects (shadows, mirrors, bump mapping, shader effects...).
• Build and edit the scene graph (X3D) at runtime. Create 3D processing, visualization tools and CAD applications.
• Extensible system for game objects, with physics, creatures with AI and navmesh, and more.
• Access numerous services, like in-app purchases and game services on mobile devices.
• Create cross-platform user-interface with anchors and automatic scaling.

Read on for details!

2. Demo reel

3. Many 3D and 2D formats supported (X3D, glTF, Collada, Spine...)

• 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.

  Our manual describes a lot of ways to use 3D and 2D objects, for example see simple loading of 3D models.

• We have an optimized renderer for OpenGL and OpenGLES2.
  

• 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:

  • manual about standard 2D controls,
  • manual about drawing custom 2D stuff,
  • CastleImages (reading, writing, processing images on CPU),
  • CastleGLImages (rendering and other processing of images on GPU).

• 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.

4. Portable (standalone, mobile, console, web browser plugin)

• You can compile and package your games for various platforms:

  • Any modern desktop operating system (Linux, Windows, macOS, FreeBSD, more...), with any CPU supported by FPC (like i386, x86_64, ARM, Aarch64...).
  • Mobile platforms (Android, iOS),
  • Nintendo Switch.
  • Web browser plugin (Linux, Windows, for browsers supporting NPAPI). This is deprecated now, we're looking closely at WebAssembly target in FPC or pas2js to enable us compilation to modern web.
  

• 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 examples/library/qt_library_tester/ that shows how the engine can be embedded in a C++ Qt application.

5. Graphic features and effects (shadows, mirrors, bump mapping...)

• Scene manager is used for centralized 3D world handling, with custom viewports possible.
  
• Shadows by shadow maps. Our shadow maps are very comfortable to use, and shadows from multiple light sources are correctly rendered. We also have experimental Variance Shadow Maps implementation.
  
• Shadows by shadow volumes (full implementation, with z-fail / z-pass switching, silhouette detection etc. — but for now limited only to a single light). See shadow volumes documentation.
• Bump mapping (normal maps), specular maps, shininess maps and more are avaiable. Our custom Blender X3D exporter can automatically generate the necessary information. Various bump mapping algorithms are implemented: from the classic bump mapping (take normal from the texture), up to the steep parallax bump mapping with self-shadowing.
• Shaders:
  • We have classes to easily use GLSL shaders (see CastleGLShaders unit). But usually you don't need to use them, because...
  • You can design and control GLSL shaders inside X3D. So GLSL shaders are fully available for model designers, programmer doesn't have to do anything.
  • We have developed special extensions to composite shader effects, to enable custom GLSL effects cooperate with each other and with built-in shader effects.
  • We fully support rendering both in fixed-function and programmable pipelines. In the latter case, the whole shading is expressed through GLSL shaders (that you can override with ComposedShader or enhance with Effect, see links above).
  
• Screen-space effects in GLSL are very easy to define and use, in pure X3D or in Pascal code.
• Many texturing features:
  • multi-texturing (see X3D texturing component docs),
  • cube map texturing (can be loaded from separate files, DDS files, or captured during runtime, see X3D cubemap texturing component docs),
  • 3D textures (see X3D 3D texturing component docs),
  • compressed textures (supporting both desktop and mobile compression formats, like S3TC, ATITC, PVRTC, ETC).
    The compressed and/or downscaled texture versions may be automatically generated and used, you simply declare them in the material_properties.xml file and use our build tool to regenerate all texures at building.
  • anisotropic filtering (just use TextureProperties.anisotropicDegree in X3D),
  • GPU texture memory profiler, extremely valuable to optimize your texture memory usage (important on mobile platforms).
  
• Speeding up rendering by hardware occlusion query, a simple approach and more involved Coherent Hierarchical Culling. See UseOcclusionQuery, UseHierarchicalOcclusionQuery properties.
• Anti-aliasing (by OpenGL multi-sampling), see AntiAliasing property.

6. Scene manager and comfortable API

• 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.

  • You can extend it in many ways.
  • You can also make your own 3D objects (if your game 3D world doesn't fit in our idea of creatures/levels etc.) by descending from TCastleTransform.

  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).

7. And much more!

• Comfortable 3D sound engine, using OpenAL, with intelligent sound source management, supporting WAV and OggVorbis formats. Includes X3D integration ("Sound" component of X3D specification), so content creators can define sound sources themselves.
• view3dscene tool to view and inspect your 3D models, before loading them in your game.
• 2D controls (buttons, panels, tooltips, on-screen menus etc.) are available. Customizing their look is very easy. Also creating your own 2D controls, using smartly stretched images and text, is very easy. Good for games, where making a custom-looking GUI (that fits with your game theme) is important. See CastleControls unit.
• Although the main focus of the engine is real-time rendering, we have also implemented a software ray-tracer, just to show that it's possible! Two ray-tracing algorithms may be used: deterministic (classic Whitted-style ray-tracer) or Monte Carlo path tracing. All the engine 3D formats are supported, with smooth normals, textures, reflections, shadows... See the gallery and the CastleRayTracer unit.
• Playing movie files. This includes loading and saving as image sequence or "real" movie files (ffmpeg is needed to encode / decode movie files). While the implementation is limited to a small movies for now (as memory consumption is large), it's perfect for flame or smoke animation in games. We even have a simple movie editor as an example program in engine sources. See TVideo, TGLVideo2D and related classes.
• You can read maps designed using Tiled Map Editor. A default visualization (as a 2D control) is included in the engine, but you can also read the map information and display it on your own, in 2D or 3D. See the examples/tiled/ in the engine code.
• You can convert a spritesheet from Cocos2D or Starling formats into X3D. See the program tools/sprite-sheet-to-x3d distributed as part of the engine.
• We have many example programs. Browse 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).
  
• We have ready window classes (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.
• Engine components are independent when possible. For example, you can only take model loading and processing code, and write the rendering yourself. Or you can use our OpenGL rendering, but still initialize OpenGL context yourself (no requirement to do it by our CastleWindow unit). 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.
• Engine can be used to develop natively-looking tools, not just OpenGL games, since our OpenGL controls integrate with any GUI library (Lazarus LCL, GTK, WinAPI, Carbon...). You can embed the engine in a normal GUI program. You can use multiple OpenGL controls and windows visualizing (the same or different) game world. There are also various classes for processing 3D data without any rendering (like TCastleSceneCore), these are of course useful too (e.g. to write ray-tracers).

• 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.