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!

Incoming in the next release (6.6)

Future plans

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

    As for the Delphi version: see here.

    This is already in-progress, 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.

  • Fully working visual editor

    I outlined my details in this post. I want to edit things within Lazarus and Delphi (like GLScene and FireMonkey 3d), and I want to have a standalone editor (like Unity3d), and I want to edit at runtime too. And I think we can do it:)

  • More physics

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

  • Mobile view3dscene (as Android and iOS application)

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

    I have not decided yet whether it would be based on our view3dscene source code, as desktop "view3dscene" contains a ton of GUI features that would not work comfortably on Android / iOS. Instead, we can develop a simple application that allows to open files, switch navigation type, turn on/off collisions and make screenshots (features that are available through the current view3dscene toolbar).

    This is already started by Jan Adamec!

  • glTF format support and PBR

    glTF is a cool format for 3D models by Khronos. See glTF overview, glTF specification and extensions, glTF sample models, Blender glTF 2.0 exporter.

    It supports meshes, advanced materials, animations. The file format is a readable JSON, but additional binary files are used to transfer coordinates, so it's fast to load from disk straight to GPU. It's also a Khronos format, so it's developed by people who really know what they are doing (the same people develop OpenGL[ES] and WebGL, Vulkan, KTX, Collada ...).

    Because of this, it may (or already is?) become a widely supported 3D format across a range of 3D software. So we want to have really good support for it — reading all the features (including animations), and preserving the efficiency of binary-encoded meshes (to do this, we will probably invent some new X3D nodes).

    See this post for my 2018 roadmap -- it includes glTF and PBR.

    See here for documentation what is PBR (Physically-based Rendering) and do I plan to add it to X3D and Castle Game Engine, and thus seamlessly render glTF materials too.

    Strategy of implementation (if you'd like to help, speak up!):

    1. (This is already started in branch pasgltf:)

      Create a unit X3DLoadIternalGLTF, consistent with other such units e.g. src/x3d/x3dloadinternalstl.pas.

      It should define a function LoadGLTF that takes a URL and returns TX3DRootNode. See the examples in all other x3dloadinternal*.pas how to construct X3D graph, and read the documentation of our scene graph (X3D) to know what is possible.

      The function LoadGLTF should be "registered", which for now just means that glTF should be added as a new format to X3DLoad unit. Just follow what other formats are doing (like STL) and add appropriate few lines.

      Inside LoadGLTF, read the file (using Download(URL)) and parse it.

      One approach to parsing glTF is to use Bero's PasGLTF. This is what I advice to try first. You will need to figure our the API by reading the source code and examples, but it should be straightforward. You will need to add PasGLTF along with dependencies (like PasJSON) to CGE source code, just like Kraft is added now (see in src/compatibilty/).

      The stuff mentioned above is already started in branch pasgltf. You can use it, and CGE will be able to open glTF 2.0 files using PasGLTF, and output basic information about them on the log.

    2. Only if PasGLTF will be unsuitable for some reason (but this is plan B, don't start with this!): We can also implement our own glTF reading. Just use FpJson (which is the JSON unit we already use for Spine loading and CastleComponentSerialize) for the JSON part.

    3. The initial task is to read meshes with transformations. I expect you will have to use nodes like Transform, Shape, IndexedFaceSet, Coordinate.

    4. I expect you to test it with glTF sample models and the output of Blender glTF exporter.

    5. Once the above is working, we can look into more advanced glTF features:

      1. Read textures and texture coords.
      2. Reading 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). Maybe some new X3D nodes should be introduced.
      3. Reading materials with PBR parameters. Modifications to CGE, including adding new X3D nodes will be needed for this, see my links above about PBR.
      4. Reading animations. X3D should be capable of expressing glTF animations, using interpolators and H-Anim for skinned animation.
  • 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.

  • 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. 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="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)

  • Support Material.mirror field for OpenGL rendering

    (This feature is already in progress, but with somewhat different API: Instead of Material.mirror, we give you more straightforward way to use RenderedTexture for a mirror. This approach is different, doesn't look so perfect, but it has many other advantages, it is also more straightforward to maintain. So, for practical purposes, it replaces the Material.mirror idea.)

    An easy way to make planar (on flat surfaces) mirrors. Just set Material.mirror field to something > 0 (setting it to 1.0 means it's a perfect mirror, setting it to 0.5 means that half of the visible color is coming from the mirrored image, and half from normal material color).

    Disadvantages: This will require an additional rendering pass for such shape (so expect some slowdown for really large scenes). Also your shape will have to be mostly planar (we will derive a single plane equation by looking at your vertexes).

    Advantages: The resulting mirror image looks perfect (there's no texture pixelation or anything), as the mirror is actually just a specially rendered view of a scene. The mirror always shows the current scene (there are no problems with dynamic scenes, as mirror is rendered each time).

    This will be some counterpart to current way of making mirrors by RenderedTexture (on flat surfaces) or GeneratedCubeMap (on curvy surfaces).

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

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

    3. (Low priority) Support for ftp. By using LNet or Synapse, unless something ready in FPC appears in the meantime. Both LNet (through LFtp unit) and Synapse (FtpGetFile) support ftp.

    4. (Low priority) Support for HTTP basic authentication. This can be done in our CastleDownload unit. Although it would be cleaner to implement it at FpHttpClient level, see this proposal. Or maybe just use LNet or Synapse, I'm sure they have some support for it.

    5. (Low priority) Support X3D LoadSensor node.

    6. (Low priority) Caching on disk of downloaded data. Just like WWW browsers, we should be able to cache resources downloaded from the Internet.

      • Store each resource under a filename in cache directory.
      • Add a function like ApplicationCache, similar existing ApplicationData and ApplicationConfig, to detect cache directory. For starters, it can be ApplicationConfig (it cannot be ApplicationData, as ApplicationData may be read-only). Long-term, it should be something else (using the same directory as for config files may not be adviced, e.g. to allow users to backup config without backuping cache). See standards suitable for each OS (for Linux, and generally Unix (but not macOS) see basedir-spec; specific Microsoft, Apple specs may be available for Windows and macOS).
      • Probably it's best to store a resource under a filename calculated by MD5 hash on the URL.
      • For starters, you can just make the max cache life a configurable variable for user. Long-term: Like WWW browsers, we should honor various HTTP headers that say when/how long cache can be considered valid, when we should at least check with server if something changed, when we should just reload the file every time.
      • Regardless of above, a way to reload file forcibly disregarding the cache should be available (like Ctrl+Shift+R in WWW browsers).
      • A setting to control max cache size on disk, with some reasonable default (look at WWW browsers default settings) should be available.

      Note: don't worry about caching in memory, we have this already, for all URLs (local files, data URIs, network resources).

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