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

  • Fully working visual editor (release 6.8)

    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.

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

  • Support Material.mirror field for OpenGL rendering

    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 Mac OS X) see basedir-spec; specific Microsoft, Apple specs may be available for Windows and Mac OS X).
      • 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