Roadmap

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!

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

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

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.

See https://github.com/castle-engine/castle-engine/files/10324944/new-material-components.txt for rough plans.

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

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.

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

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: https://castle-engine.io/wp/2023/04/08/web-target-progress-and-plans/ .

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.

Official Steam integration in CGE, see https://trello.com/c/RNDjQhqe/71-steam-headers . 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: https://github.com/castle-engine/castle-engine/commits/castle-steam ), we also have a draft application on Steam for CGE :).

This is almost done, thanks to Jan Adamec. We need to release it :)

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

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:

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

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

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

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.

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:

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

This will:

See macOS.

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.

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:

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:

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.

See also here.

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

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

https://github.com/heroiclabs/nakama

https://heroiclabs.com/docs/nakama/getting-started/index.html

Nakama is an open-source server (which you can extend) and client API (which you can use from various game engines — see https://heroiclabs.com/docs/nakama/client-libraries/ ) 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.

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:

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:

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.

Address a few shortcomings of our screen effects (examples/screen_effects_demo/, https://castle-engine.io/x3d_extensions_screen_effects.php ):

Currently you can only export TCastleScene to X3D.

Currently you can only export TCastleScene to X3D.

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

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.

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

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