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

  • Delphi compatibility

    As for the Delphi version:

    • This will the free version of Delphi available as Delphi Starter Edition. I'll port (and maintain compatibility) with the latest Delphi Starter Edition available. Embarcadero seems willing to update the Delphi Starter Edition with each new version of Delphi, which is quite great.

    • Of course, bugreports and patches to fix support for any other Delphi version are also always welcome.

    • If someone wants to sponsor another Delphi version, then I can maintain a port to it too.

      I'm afraid that any commercial edition of Delphi costs a lot, so I cannot afford to buy it on my own. Especially since, personally, I usually work on Linux with FPC + Lazarus these days:)

    This is already in-progress, see here.

  • API improvements. I plan to attempt some long-planned API upgrades. These include:

    • Ultra-flexible TCastleTransform class instead of most current T3D* classes. The unit Castle3D will be replaced by a new unit CastleTransform with the TCastleTransform class, that will perform the tasks of current T3D, T3DCustomTransform, T3DTransform, T3DOrient classes. So it's more flexible, and has a name that does not (falsely) suggest it's only for 3D games.

      Also TCastleTransform will be an ancestor of TCastleScene. So you will be able to change Translation, Rotation etc. of a TCastleScene directly, without the need to "wrap" it inside TCastleTransform container.

    • Vector API improvements, using TVector3 as an advanced record, instead of current TVector3Single. This is already done, see here.

Future plans

  • Visual designing of the castle components

    Editing of engine 3D and 2D things within Lazarus and Delphi. For a "start": 1. designing the scenes and transformations under SceneManager.Items and 2. designing the 2D controls under TCastleControl.Controls.

    Inside a Lazarus form. Like GLScene and FireMonkey 3d.

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

    1. Visually design 2D controls within TCastleControl.

    2. Visually design T3D hierarchy in SceneManager.Items. So you could look and move whole TCastleScene instances.

    3. Make published, and editable through Lazarus, various properties currently only public. E.g. we need to figure out some way to edit vectors and matrices in Lazarus (they are records/old-style objects internally).

    4. Design X3D nodes hierarchy (inside the TCastleScene) visually, which means you can edit shapes, materials, textures...

  • Physics

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

  • view3dscene as an Android application

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

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

  • 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)"
    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. Make TCastleScene descend from T3DTranform?

      Also, allow SceneManager.MainScene to have some transformation (right now, it's not 100% correct).

    5. Unify OpenGL and OpenGLES shaders

      Currently, our desktop OpenGL shaders do always Phong shading. To get Gouraud shading on desktop OpenGL, you need to use the (old) fixed-function pipeline. This is somewhat dirty, it would be more natural to be able to switch our shader pipeline between Phong and Gouraud shading.

      Moreover, our desktop OpenGL shaders right now use old GLSL stuff gl_Xxx. This allowed them to work even on old GPUs, but makes the implementation quite complicated, as the mobile OpenGLES shaders cannot use the gl_Xxx variables. So the code of the shader pipeline is complicated, with a lot of conditions to do things differently on (desktop) OpenGL and (mobile) OpenGLES. Right now, all sensible GPUs handle shaders, and for truly ancient GPUs — we can just fallback on the fixed-function pipeline. So the code can be simplified.

      Moreover, our mobile OpenGLES shaders right now always do Gouraud shading. It would be sensible to allow using Phong shading on selected shapes, even on mobile, as in some cases the performance is acceptable.

      Summing it up:

      • Remove the shader pipeline using GLSL gl_Xxx variables. Bring the OpenGL and OpenGLES code paths closer together.

      • Offer to switch between Gouraud and Phong shaders, on both OpenGL and OpenGLES, in the shader pipeline.

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

  • glTF format support

    It is an excellent 3D format from Khronos, that can be read and rendered efficiently. There are existing exporters to glTF from Blender and other software available.

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

  • Advanced networking support

    Basic networiking support is done already, we use FpHttpClient unit distributed with FPC, see relevant news entry. Things working: almost everything handles URLs, we support file and data and http URLs.

    Things missing are listed below (some of them may done by adding integration with LNet or Synapse, see also nice intro to Synapse on FPC wiki).

    1. Support for https. By sending patches to add it to FpHttpClient. Or by using LNet or Synapse (they both include https support).

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

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

    4. Ability to cancel the ongoing download. Add a "cancel" button to CastleWindowProgress for this. See the task below (background downloading) for ideas how to do it. See the TDownload plans in the comments of CastleDownload.pas.

    5. Ability to download resources in the background, while the game is running. Technically this is connected to the previous point: being able to reliably cancel the download. See the TDownload plans in the comments of CastleDownload.pas.

      There is a question how to do it. We can use TThread for downloads, maybe even a couple of threads each for a separate download. We can use API that doesn't block (like LNet or Sockets, with Timeout > 0). We can do both.

      Using separate thread(s) for download seems like a good idea, the synchronization is not difficult as the thread needs only to report when it finished work.

      The difficult part is reliably breaking the download. Using something like TThread.Terminate will not do anything good while the thread is hanging waiting for socket data (TThread.Terminate is a graceful way to close the thread, it only works as often as the thread explicitly checks TThread.Terminated). Hacks like Windows.TerminateThread are 1. OS-specific 2. very dirty, as TThread.Execute has no change to release allocated memory and such. The bottom line: merely using TThread does not give you a reliable and clean way to break the thread execution at any time.

      This suggests that you have to use non-blocking API (so LNet or Sockets is the way to go, FpHttpClient and Synapse are useless for this) if you want to reliably break the download. Using it inside a separate thread may still be a good idea, to not hang the main event loop to process downloaded data. So the correct answer seems use LNet/Sockets (not FpHttpClient/Synapse), with non-blocking API, within a TThread; thanks to non-blocking API you can guarantee checking TThread.Terminated at regular intervals.

      I'm no expert in threads and networking, so if anyone has any comments about this (including just comfirming my analysis) please let me (Michalis) know :)

    6. Support X3D LoadSensor node.

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

  • iOS improvements:

    • Services on iOS. For now, most of our services are only on Android. Most of them are possible also on iOS, e.g. TInAppPurchases, or Apple Game Center as an equivalent to Google Play Games from Android.

    • Package the vorbisfile library. To be able to read OggVorbis sound files.

    • Enable texture compression. Because of Apple's weird implementation of PVRTC format (only square textures are allowed), for now we disabled texture compression on iOS. This should be done better, at least to enable the texture compression of other formats.