Table of Contents

1. Introduction

Don’t see the feature you need? Tell us on the forum or Discord.

If you would like to see some feature implemented sooner, please support the engine development on Patreon!

2. VR and AR

VR: Michalis has access to Oculus Quest since the beginning of 2022. Port most likely using OpenXR (to include the widest possible range of devices using a single cross-platform API).

Oculus Quest 2: Developer Mode for Castle Game Engine enabled!

AR: most likely using Android / iOS built-in frameworks, as these make AR widely available on modern phones.

3. (planned for 7.0) New material components (allowing also material editing in the editor)

We want to allow you to edit materials in the CGE editor,

This also means exposing new set of Pascal components to manage materials easier.

4. More Delphi platforms

See about existing Delphi compatibility. We plan to support more platforms with Delphi: Android, Linux, iOS…​

5. Load and animate glTF more efficiently

We should read meshes in a way that keeps binary layout of data in glTF, so that it is ultra-fast to load, and it is loaded almost straight from glTF to GPU.

Some modifications to CGE may be required here (CastleGeometryArrays will have to be made more flexible for this). New X3D nodes should be introduced, like BufferGeometry (same as X3DOM?).

We should also perform skinning fully on GPU, avoiding CoordinateInterpolator done on CPU.

6. More physics

More physics engine integration. The details are listed in the manual about physics, subsection "TODO". In short:

  • TCastleWalkNavigation should support physics out-of-the-box.

  • Older physics based on octrees should be phased out.

  • TCastleSceneCore.ExposeTransforms should work both ways, to allow to attach bodies and colliders to parts of the scene. This will enable e.g. ragdolls.

  • We should add more physics backends, like PhysX or Bullet.

7. (IN PROGRESS) Web platform (rendering using WebGL) support

Using FPC support for the WebAssembly:

Some "glue" may also be done using pas2js. This is a nice solution to expose to our WebAssembly code the JS API we need, like WebGL. Alternatively, we could just do it in plain JS.

This is already in-progress by Trung Le (Kagamma), Andrzej Kilijański and Michalis.

I wrote a longer post about plans and status of this here: .

8. (IN PROGRESS) Particle systems

With a designer. Example usage: blood, snow, rain, fire, smoke…​ 2D, 3D.

This is already in-progress by Trung Le (Kagamma). Use cge-3d-particle-emitter or Effekseer Integration. See CGE components.

9. (IN PROGRESS) Steam integration, and engine available as Steam app

Official Steam integration in CGE, see . We already used it for The Unholy Society, we want to either “just publish that approach” or propose a new, improved (without an intermediate “wrapper” library) approach.

We should also upload CGE as app to Steam.

This is already in-progress by Eugene Loza (branch: ), we also have a draft application on Steam for CGE :).

10. Release mobile view3dscene (as Android and iOS application)

Associated with glTF, X3D and other formats that the view3dscene (and Castle Game Engine) handles. Available in the App Store / Google Play Store. For free or for 1 USD (not sure yet; but definitely without ads, I really dislike ads).

11. Terrain designer

Easily design a height map (X3D TElevationGridNode node, with trees, rocks, grass). Saved and loaded as an X3D file.

Implementing this feature will most likely be split into a couple of small releases:

  • Edit the heights.

  • Edit the grass and trees and rocks.

  • Efficiently render huge amounts of grass and trees and rocks.

Implement nice shaders to show it, like this BareGame example.

What we have now: The engine includes a unit CastleTerrain to generate terrains in various ways (most notably, from smoothed random noise). We have examples/terrain/ demo to play around with it. We have the "Wyrd Forest" game that also uses CastleTerrain, and also includes a simple editor of terrain settings.

What we need: Visual, interactive editor for the ElevationGrid (the thing you get from TTerrain.Node call). To make hills, valleys in a comfortable way. And comfortably plant there stuff (rocks, grass, trees…​).

12. Vulkan renderer

Vulkan renderer.

We have a simple example code that shows how you can start a new renderer: see examples/research_special_rendering_methods/new_renderer_skeleton/.

13. Make TCastleScene, TCastleTranform and friends to be special X3D nodes

This would make the whole TCastleViewport.Items a single graph of X3D nodes, allowing for more sharing in code. The TCastleTranform would be just like TTransformNode, but a little diferently optimized (but it would become toggable at runtime).

14. Possibility to reorder/merge all shapes, across all scenes (better blending, better batching)

This is a change in renderer routines. Right now each TCastleScene is too much like a "black box", even though the typical case is that 1 viewport renders a lot of scenes.

We have TGLRenderer.ViewportRenderBegin, TGLRenderer.ViewportRenderEnd, these are a step in the right direction. But we can do much more.

All the shapes from across all scenes should be able to "interact" with each other just like right now shapes inside a single TCastleScene can "interact". This means:

  • All partially transparent shapes, from all scenes, should be collected and sorted together, so that they are rendered in the correct order.

    This means that you no longer need to do manual sorting to have blending work correctly across scenes.

    This means that TCastleViewport.Items.BlendingSort can be actually a robust solution covering all cases, and GitHub #463 has a trivial answer (just set TCastleViewport.Items.BlendingSort := bs2D).

    This means that blending should be a much shorter page, because TCastleViewport.Items.BlendingSort should really be everything you need.

  • When DynamicBatching is active, we can have one "batching renderer" instance for the viewport (so, reused by all scenes) and it can merge shapes even from different scenes.

    This means that DynamicBatching is much more powerful.

    This means that rendering thousands of TCastleImageTransform with the same URL is just 1 draw call.

    This means that examples/isometric_game/ is an easy and efficient solution to render large maps.

15. Distance field fonts

See about Distance field fonts. See code from Chris Rorden showing how to do it in Lazarus.

16. Mobile

16.1. Wireframe on OpenGLES

Since glPolygonMode is not available at all on OpenGLES, we need to be able to generate wireframe geometry arrays on CPU, adding a "wireframe" option to CastleArraysGenerator that will generate a different (line) primitive for TGeometryArrays. Then the renderer can use such TGeometryArrays for OpenGLES.

This is started now, by having Shape.shading = "WIREFRAME" option, see Shape.shading field. We need to

  • make it available for all geometry shapes

  • make this feature more flexible, so that the renderer can switch between wireframe/non-wireframe rendering without any cost.

  • And then we can implement Attribute.WireframeEffect on OpenGLES correctly,

  • and allow to set Wireframe on specific viewports (so that some viewports may view wireframe, independent of others) on OpenGLES.

16.2. On-screen keyboard on iOS (done on Android)

16.3. TGLImage.GetContents on OpenGLES

TGLImage.GetContents is not available on OpenGLES, as it doesn’t support glGetTexImage. Fixing it is a matter of implementing alternative way that draws texture to FBO and grabs using SaveScreenGL (using glReadPixels internally).

One has to use TGLRenderToTexture to render quad with a texture (making sure the framebuffer size, quad size, and texture size match, and without filtering) and then use glReadPixels to get the pixels from FBO. This will work on mobile (and also on desktops, although it will be less optimal alternative to glGetTexImage).

17. macOS: Package engine as one big application bundle

This will:

  • be simpler to users, as the engine will be "one single application" for macOS users.

  • avoid troubles resulting from Apple translocation. It right now prevents the CGE editor from detecting CGE path.

  • avoid current duplication of castle-editor/data in distributed package, thus making it smaller by ~60 MB.

See macOS.

18. macOS: Have signed app bundle for the editor

This will allow to run CGE editor on macOS by just double-clicking it, out-of-the-box.

See macOS.

We should also enable developers to easily sign their own applications packaged with CGE build tool.

19. (IN PROGRESS) fps_game should be redesigned using editor, CreatureCreatures / CastleResources / CastleLevels / CastleItems / CastlePlayer should be replaced with a better API

In progress. See news post. On branch fps-game-upgrade.

These 5 units (CreatureCreatures / CastleResources / CastleLevels / CastleItems / CastlePlayer) expose a high-level API, that sits on top on existing classes (like TCastleScene and TCastleTransform). But I am not 100% happy with their API. Reasons:

  • The API is too specialized at some points (3D games with creatures / items pickable),

  • It is confusing how it maps to API underneath (e.g. TPlayer somewhat controls the TCastleNavigation).

Gradually I will want to express their features in different ways, in ways that are more closely and obviously connected with TCastleScene / TCastleViewport / TCastleNavigation. Basically, I’m very happy with current API of TCastleScene and TCastleTransform, and I want to make it more obvious how it is related to creatures/placeholders and other concepts introduced in CastleLevels and CastleCreatures and CastkeResources. Currently they use TCastleScene and TCastleTransform inside, but the relationship is non-obvious.

It’s not going to happen any time soon, but it will happen gradually, over the course of next 1 or more years. That is, some of the features of the 5 units mentioned above will become available in other ways too (more flexible, and more obviously connected to TCastleScene).

I know this sounds vague, because I have not yet clarified these plans in my head:) These 5 units are useful, they provide various features on top of TCastleScene. I’m not going to just "ditch" them or even deprecate them, before I made a better API that also has these features. For example:

  • New TCastleScene.Load should be able to take a callback (or some class instance) to easily perform the "placeholders" functionality of TLevel.Load in a flexible manner (user can decide what to replace with what).

  • There will be TCastleSceneView that provides part of the functionality of T3DResource (multiple TCastleSceneView share a single TCastleScene but can show different animation frame of it), but without some often-unnecessary "baggage" from T3DResource (like refcounting of T3DResource, and it’s special Prepare/Release methods).

  • It should be possible to add an A.I. (like TWalkAttackLogic) to any TCastleTransform instance.

I know I want to go in this direction. Based on the questions (including on Discord) I see that the API of these 5 units is not clear to people. It wraps TCastleScene / TCastleViewport / TCastleNavigation, but in ways that are not obvious, and that is something I want to improve.

Again, bear in mind that it will not happen any time soon :) You can safely and happily use these units, probably for a few years to come.

But it is something I think about for the future, and it may explain some of my decisions. E.g. that is why I don’t plan special integration of TCastleCreature with castle-editor. Instead I want to enable you to add future TWalkAttackLogic to any TCastleTransform one day. And thus we will have "easy creatures" in CGE but with more flexible API.

20. Bridge TDrawableImage with TCastleScene, enable drawing UI into TCastleScene, to have UI rotated in 3D with perspective.

21. MDL and/or MaterialX integration

We can make 3D modeling of realistically-looking stuff much easier by reusing libraries of realistic materials.

22. USD – Universal Scene Description support

Explore possibility to support USD – Universal Scene Description format as a first-class citizen, alongside glTF and X3D, in CGE.

23. Integration with Nakama (scalable server for social and real-time games and apps)

Nakama is an open-source server (which you can extend) and client API (which you can use from various game engines — see ) to get easy networking capabilities. You can host the server yourself or pay to get ready hosting.

I think this, combined with CGE API, may give us networking capabilities comparable with some popular solutions known from other game engines.

Allowing to trivially get multi-player functionality in your games.

24. Project settings editable using GUI

We will expose both current CastleEngineManifest.xml and data/CastleSettings.xml as something you can edit yourself with GUI.

But we don’t want to create and maintain a custom GUI for them, instead the plan is to:

  • Create Pascal components with published properties representing their data.

  • Make the project settings files just "JSON design files" for the editor.

So you’ll have a file like project.castle-project and using editor menu item like "Project Build Settings" will really just open a design project.castle-project (JSON) in the editor, and it will be just a serialized TCastleProject component. Same for "Project Runtime Settings" which edits data/settings.castle-project-settings.

Bonus: we’ll associate *.castle-project with the system, to open when you double-click it e.g. from Windows installer.

Bonus: you can add non-visual components to data/settings.castle-project-settings and load them using Container.DesignedComponent('xxx'). This is great e.g. to add sounds or fonts or other data that you want to later load in CGE, from any view.

There are a few details that have to be ironed out here:

  • how should the new equivalent of CastleEngineManifest.xml and data/CastleSettings.xml interact. We will likely keep 2 files, project.castle-project and data/settings.castle-project-settings, as

    • Some information doesn’t need to be packed into data, part of it could even be considered "somewhat secret" (e.g. SDK IDs for Android analytics should not be present anywhere in the non-Android builds).

    • Some information should be packed into data automatically, by default, everything. To enable that Bonus: you can add non-visual components feature.

  • most intuitive names for all the things above (menu item names, component names, extensions etc.) :)

25. User interface (or any other simple property of CGE component) animation in editor

Expose simple component(s) (TCastleUserInterfaceBehavior descendants?) that allow to animate anything in CGE editor. They should have

The use-case should cover animating anythign that you see in CGE editor directly: e.g. UI stuff (like TCastleUserIterface.Translation, TCastleImageControl.Color), 3D stuff (TCastleTransform.Translation, TCastleTransform.Rotation etc.).

For now: you have to animate UI from code, updating any values you want in Update and change any value you need (like MyControl.Translation) using routines like Lerp or SmoothStep.

26. Screen effects - expose as nicer components

Address a few shortcomings of our screen effects (examples/screen_effects_demo/, ):

  • Change terminology. "Screen effect" is non-standard, "post-processing effects" are better.

  • Expose as components some standard effects, like blur, changing colors in HSV, grayscale. They should have easy Pascal properties, serializable to JSON, and wrap the related X3D nodes underneath.

  • Expose as component a customizable shader effect allowing you to provide GLSL code in a text box (TStringList editor) in CGE editor.

  • This depends on making a more generic TCastleComponentEditorList to expose TCastleScreenEffects.ScreenEffects list nicely.

27. Export any TCastleTransform hierarchy to X3D

Currently you can only export TCastleScene to X3D.

28. Export TCastleScene, or any TCastleTransform hierarchy, to glTF

Currently you can only export TCastleScene to X3D.

This will likely also imply rename of tovrmlx3d to castle-convert.

29. Allow animating selected graph properties, without changing the graph

Right now our X3D graph usage is similar to HTML DOM usage from typical web applications: we modify the graph at runtime, everything that changes stuff (like animations) just changes the graph. This is simple to use, it nicely allows to animate everything in X3D and gives developers an easy way to modify everything at runtime.

The downside is that we waste significant memory, and loading time, in some cases. If you want to play different animations on each TCastleScene, then they need to have a different graph even though they are loaded from the same URL. Hence using e.g. TCastleScene.Clone or TCastleSceneCore.Cache really internally makes multiple copies of the graph. This could be more optimal in the future. E.g. assuming your model only uses glTF skinned animation or animates simple transformation position/rotation/scale, we could make the graph read-only, and only maintain small "diff" information at each instance.

30. FMOD Studio support

Right now our FMOD backend uses only "FMOD Core API".

We want to enable using higher-level FMOD events that drive the sound banks exported from "FMOD Studio".

31. Wwise backend

Allow using AudioKinetic’s Wwise as sound backend, and as a middleware to design sounds.

To improve this documentation just edit the source of this page in AsciiDoctor (simple wiki-like syntax) and create a pull request to Castle Game Engine WWW (cge-www) repository.