Planned features (roadmap)

Don't see the feature you need? Tell us on the forum:)

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

Future plans

  • More visual editor.

    Extend our editor.

    • Add gizmos to manipulate (translate / rotate / scale) 3D and 2D objects inside a viewport / scene manager.

    • Make the "files browser" at the bottom actually useful (display asset icons, allow to drag them onto a design etc.).

    • Cover all use-cases mentioned in original post about the editor:

      1. I want to edit things within Lazarus and Delphi (like GLScene and FireMonkey 3d),
      2. I want to have a standalone editor (like Unity3d; check!),
      3. I want to edit at runtime too.
    • Implement everything planned for the editor, and close all TODOs :)

  • Delphi compatibility (was planned for 6.6 release, postponed to 6.8).

    Already started, see here.

    If you want to help in this effort by coding:

    • The suggested approach is to extend the existing "examples/delphi/base_tests/base_tests.dpr" to use more and more CGE units, fixing any Delphi compatibility that occurs (e.g. XML units, JSON units etc.).

    • The order of adding units can folow the map of dependencies. So first we make sure all/most from "base" compiles, then "files", then "images", then "fonts"...

    • Once we get to CastleUIControls unit compiling, we can implement TCastleControl on VCL and/or FMX, and actually display something.

  • More glTF: PBR, efficient meshes, animations

    Note that static glTF models already load OK in CGE.

    Things to do:

  • More physics

    More integration with physics engine. The details are listed in the manual about physics.

  • Release mobile view3dscene (as Android and iOS application)

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

    Associated with X3D and other 3D / 2D 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).

  • Continous integration (Jenkins) for free for all open-source projects.

    We have a Jenkins + Docker infrastructure to compile and test CGE, and CGE-based applications. I want to finish some stuff there and make it publicly accessible, and free for open-source projects.

  • Terrain designer

    Easily design a height map (X3D ElevationGrid 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:

    1. Edit the heights.

    2. Edit the grass and trees and rocks.

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

  • Blender X3D exporter improvements

    Current Blender X3D exporter doesn't support animations, configuring collisions (X3D Collision node), 3D sound sources and more. We would like to fix it!:) This will be useful for everyone using Blender and X3D, not only with our engine.

    See also our page about creating data in Blender and hints about exporting from Blender to X3D.

    Depending on the future, it is possible that this feature will be replaced with "better support for glTF animations". Currently, the reality is that glTF has more momentum as an interchange format than X3D.

  • Android Cardboard (VR)

    Maybe also other VR devices — depending on demand, and our access to test devices.

  • Ready components to replicate data over the Internet

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

  • More renderers

    Vulkan renderer.

    Maybe Metal renderer. Only maybe, as it's an API used by only one platform — iOS. So far, OpenGLES serves us good on iOS. In practice, this depends on the future, how much will Metal matter in a few years.

    Maybe Direct3D renderer. Only maybe, as it's an API used only on Windows. So far, OpenGL serves us good. The rare platforms where OpenGL had problems on Windows are 1. really old right now (really old Intel GPUs), 2. we can consider using an OpenGLES->Direct3D bridge, like ANGLE, for them.

    Help with this is most welcome. We have a simple example code that shows how you can start a new renderer: see new_renderer_skeleton.lpr. So get the engine from GitHub, and start changing the new_renderer_skeleton.lpr. Just fill the TCastleSceneVulkan.PrepareResources and TCastleSceneVulkan.Render inside.

  • Larger scene processing and rendering improvements:

    1. More animations blending

      To smoothly fade in/out animation, with cross-fade between animations, for things played by TCastleScene.PlayAnimation.

      Animation cross-fade time for creatures from resource.xml files could be configured using a CastleScript expression, so values like this could be possible:

      fade_duration="0.5"
      fade_duration="animation_duration * 0.1"
      fade_duration="min(animation_duration * 0.25, target_animation_duration * 0.25, 0.5)"
      

      Animation blending is already working, see here! However, it still has two TODOs for now (it does not yet work for castle-anim-frames or resource.xml).

    2. Batching

      Batching of shapes that have equal appearance for start, to optimize the rendering.

    3. Make TCastleScene, T3DTranform and friends to be special X3D nodes

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

    4. Distance field fonts

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

  • WebGL (HTML5) support

    But this waits for the possibility from FPC to recompile to web (that is, JS or WebAsembly, probably through LLVM). Then our engine will jump on to the web platform. (Unlike the current web plugin, which is soon deprecated by all browsers, unfortunately.)

  • Scripting in JavaScript

    Allow to use JavaScript (ECMAScript) directly inside VRML/X3D files (in Script nodes). This will follow VRML/X3D specification. Implementation will be through besen (preferably, if it will work well enough), SpiderMonkey, or maybe some other JS library.

  • Particle systems

    With a designer, probably.

    Probably following the X3D "particle system" component, so it will be saved and loaded as an X3D file.

    Example usage: blood, snow, rain, fire, smoke... 2D, 3D.

    It would be nice to be able to export Blender particle engine to it, but possibly it's not really doable (different particle physics in Blender than X3D, we should go with own designer following more X3D).

    (Note that we already have 2D particle system in CGE, see cge-2d-particle-emitter by Kagamma)

  • Make a demo showing how to use Castle Game Engine together with RNL - a real-time network library, in Pascal, very suitable for games, by Benjamin Rosseaux.

  • More networking support

    Basic networking support is working already, see the manual.

    Missing features / ideas:

    1. Maybe integrate with LNet or Synapse, see also nice intro to Synapse on FPC wiki. Maybe Indy.

      Bear in mind that future engine version should work under both FPC and Delphi, so choosing one library that works under both FPC and Delphi is a plus.

    2. Asynchronous downloading.

      So that you don't need to hang waiting for download.

      The API design is already inside castledownload.pas, look for the line "API for asynchronous downloader is below, not implemented yet".

      Using threading (TThread) to implement this is optional, as you can update the data during the ApplicationProperties.OnUpdate in the main thread (if only you use non-blocking API like LNet). Note that you need to use non-blocking API anyway (as we must be able to cancel the ongoing download, and you cannot instantly unconditionally terminate a running TThread). Using threads may still be reasonable for efficiency (no need to slow down the main thread), but then it should be 100% invisible to the user of TDownload class. From the point of view of engine user, the TDownload must be available in the main thread.

      This will also enable cancelling the ongoing download. Maybe add a "cancel" button to CastleWindowProgress to cancel ongoing view3dscene downloads.

  • Easy way to use 3rd-person camera movement in your games.

  • Make 100% rendering features available on OpenGLES too.

    We have some small TODOs to make OpenGLES (mobile) renderer as capable as OpenGL (desktop).

  • Use Cocoa under macOS

    We already have a native look and feel, and easy installation, under macOS by and using LCL with Carbon or Cocoa on macOS. Our programs do not have to use X11 and GTK under macOS.

    However, the current solution is not optimal. Carbon is deprecated and only 32-bit (so memory is limited). Cocoa is not stable in LCL yet. Depending on LCL has it's own problems (mouse look is not smooth with LCL message loop).

    The proposed task is to implement nice Cocoa backend in CastleWindow unit. You can of course look at LCL implementation of Cocoa widgetset, but I expect that we can implement it muuuch simpler (and more stable) as CastleWindow backend. Contributions are welcome. This is an easy and rewarding task for a developer interested in macOS.

  • API improvement: Make SceneManager.MainScene not necessary.

    In the future, everything should be possible without assigning SceneManager.MainScene, and eventually SceneManager.MainScene property should be deprecated, later it should be ignored, and later it should be removed.

    Currently, the engine requires you to assign scene to SceneManager.MainScene to achieve some features. For example:

    1. To have some X3D lights shining on all scenes, these lights should be in SceneManager.MainScene.

    2. To use a Background or Fog X3D node, this node needs to be inside SceneManager.MainScene.

    3. The initial camera position may be derived from Viewpoint in the SceneManager.MainScene.

    All these features should have a different solution, that doesn't require marking any scene as "main". This is not a trivial job, and it needs case-by-case solutions. For example (addressing above examples):

    1. Every scene could have a Boolean property like TCastleScene.LightsAffectAllScenes.

    2. The editor could allow to point a specific Background or Fog node to be currently used (which could come from any X3D scene).

    3. The initial camera position can already be given in various alternative ways.

  • API improvement: CreatureCreatures / CastleResources / CastleLevels / CastleItems / CastlePlayer should be replaced with a better API.

    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:

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

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

    Gradually I will want to express their features in different ways, in ways that are more closely and obviously connected with TCastleScene / TCastleSceneManager / TCamera. 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 TGameSceneManager.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 / TCastleSceneManager / TCamera, 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.

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

    See also here.