Priorities

As the community grows and uses more and more add-ons, we found out that the current add-on startup logic is reaching its limits, as sometimes, you need to reload the editor for new add-ons to work. That’s why we intend to overhaul it to make the experience seamless.

As bigger projects often rely on CI (continuous integration) to test and deploy their projects, they need to be able to export games from lean environments that don’t implement a graphical interface (headless). For this, we need to make headless command line export more reliable, as there’s currently some issues that prevent it from working flawlessly.

We put a lot of effort lately to add ways to split the work of nodes into multiple threads. This can lead to great leaps in terms of performance. Unfortunately, many nodes are structured in a way that makes it difficult for them to take advantage of multiple threads. We need to audit our current nodes and fix the ones that are relying on being single threaded.

Much of the engine would benefit from a careful evaluation of the current performance bottlenecks and improvements to ensure that it is running as fast as possible. Godot 4.0 drastically improved the overall architecture of Godot, but there is still a lot of legacy code that is not benefitting from the architectural improvements. We need to seek out those areas and fix them.

In order to make the best decisions, we need to rely on measurable data. In order to be able to do this, we need to create more benchmarks. It gives the added benefit over time that we can spot regressions more easily, together with unit tests, as we started lately to track performance of nightly builds.

Jolt is an open-source (MIT licensed) modern, multi core friendly rigid body physics and collision detection library, tailor-made for video games. We want to make it available to users by default, the current GodotPhysics 3D engine would still be available as an option.

As much as our nodes are made to be compatible with multiple physics engines, the existing integration of Jolt (via the godot-jolt add-on) is not optimal, as there are numerous features that can’t be implemented in Godot due to the current way the system works. In addition to integrating Jolt as the default 3D physics engine, we want to modernize our node bindings in order to fully exploit the new library.

We’re really proud of our in-house technology for global illumination, but we think that we can push performance and quality even further. This is a long-term effort, but is something we are very excited about and would like to see finished.

Post processing effects are a weak spot in Godot’s renderer. The performance and quality are both worse than we would like. We want to overhaul or replace most of our post processing effects in order to achieve both better performance and higher quality.

The goal of the rendering compositor is to give users fine control over the order of rendering operations and allow them to implement more custom behavior within the renderer.

Debugging and profiling are necessary tools to release high-fidelity games. Right now Godot’s debugging and profiling tools are relatively basic and unpolished. We want to make it easier to diagnose rendering issues and pinpoint performance problems instead of users having to rely on guessing and checking.

Shader templates can be used to have full control over the shaders used to render your assets. This allows you to both optimize your shader by removing unnecessary parts and to dramatically change your shader by adding custom behavior.

This feature would enable the streaming of assets to progressively load scenes, textures, and models in order to boost performance and loading times.

Hardware ray tracing is slowly becoming more widespread. Soon it will be common for all desktop computers to support hardware ray tracing and soon after mobile devices will as well. We want to expose an API for hardware ray tracing through our RenderingDevice so that users can begin to make use of it. Then, eventually, we want to use that API to leverage hardware ray tracing in the Forward+ renderer.

Deferred rendering is a technique that can be used to increase performance in certain situations at the cost of flexibility. As Godot users create more complex games, we are seeing more games that would benefit from trading the flexibility that comes with our current renderer for more performance.

LightmapGI needs a lot of polish and improvements for us to meet the goals we have set for it. Baking times are slower than we want and it often takes too much manual effort to get bakes to achieve the quality that users need.

WebGPU is a new and modern API that offers direct access to GPUs, exposing features that are not otherwise available on the web. Once WebGPU is supported, it will be possible to export high-fidelity Forward+ and Mobile projects to the Web.

The SkeletonModifier3D abstract node introduced in 4.3 helps users to modify and add new functionality to bones via script. We want to build upon that new structure to add new features to it.

While the experience of dealing with 3D skeletons improved greatly upon the years, the same cannot be said of the 2D one. Our wish is to overhaul Skeleton2D animation in order to make it easier to animate and develop complex 2D figures.

Godot doesn’t know how to handle project file changes that happen on non-imported files, such as scripts, when it happens outside of the editor. This can be a common occurrence for users that use an external code editor. This can lead to numerous errors and inconveniences, such as scenes refusing to load. We intend to make this a relic of the past.

Some file formats are actually containers that hold multiple resources. FBX and GLTF files are one of these, as they not only contain 3D models, but also can contain animations and textures. Currently, the only way to expose these resources is to tell the editor to pull these out on import.

We are thinking about providing a way to users to access internal subresources.

A lot of modern IDEs offer refactoring tools in order to rename variables and symbols across the codebase. We intend to add this feature to our internal GDScript code editor.

Right now the editor is not able to open or edit GDExtension classes. It effectively treats them like binary blobs. We want to make opening and editing GDExtension classes easier to do from within the engine and provide some of the comforts from regular scripting to GDExtension.

As Blender is both a FOSS and a very popular 3D editor choice by the majority of our users, it makes sense to improve compatibility with it. You can already import .blend files, but it’s limited to models, textures, lights, and cameras.

Godot imports .blend files by calling into Blender and asking Blender to export a .gltf file, which Godot then imports. Therefore, everything we want to export from Blender needs to be exported to the glTF data, including glTF extensions, and then Godot needs to import those, all in order for that data to make its way to Godot.

Godot currently has an advanced import dialogue which allows you to tweak many properties while importing assets. We want to polish and expand this dialogue to be more powerful. At the very least we would like to improve the preview lighting, expose more tools for material editing, and expose many more common properties.

Currently, imported scenes (such as .glb, .fbx, and .blender files) show the scene icon in the FileSystem tab, making it difficult to filter out these files. Showing a preview icon of the scene would greatly help users in their workflow.

As users create larger games with more assets, we need to continue improving the performance of our importer to ensure that users spend as little time waiting for import as possible.

Scene inheritance is the concept of creating a scene based on an existing one. It is a feature that should work well in theory, but can be quite finicky in reality.

AccessKit offers a cross-platform way to implement accessibility features for UI toolkits, such as Godot. Integrating screen reader support into Godot will offer us and game developers opportunities to make more accessible products, such as the Godot Editor itself or games made with Godot.

It is known that compared to Godot 3.x, there’s some delays while creating new Window, especially on Windows.

Debug symbols allow developers to obtain more information when Godot crashes or logs an error. Currently, developers will only have debug symbols if they compile the engine from scratch. By distributing debug symbols for the official builds, developers would be able to easily diagnose crashes without making a custom build of the engine.

We often receive issue reports about gamepad support, as the numbers of gamepads never cease to increase. As we wish to support as many input devices as possible, we want to work towards better support.

Godot games should be able to seamlessly work when dragged across multiple monitors even when the monitors have different resolutions and DPI scaling factors.

When your game launches on Google Play, you will start to get automated reports from players highlighting issues like freezes, crashes, or poor performance. Right now that information is hard to make sense of due to the lack of debug symbols. We want to make it easier for users to utilize these reports either by providing debug symbols, or streamlining the process for developers to upload debug symbols themselves.

External textures are textures where their data comes from an external source. For AR, it means getting the camera feed (or anything that can be rendered) from the host operating system and displaying it over in Godot.

Right now the Wayland compositor is limited to making use of a single window. In order to achieve parity with other platforms, we need to add support for creating multiple windows.

As Godot grows in features, it also grows in size. Web games need to be as small as possible and the size of the engine is becoming a pain point for web games. We need to find ways to reduce the binary size as much as possible and provide tools to developers to easily cut features and reduce the size further.

Currently, if no specific steps are taken by the game developer, resources for a game on the Web are bundled into one single .pck file. As users need to download the entire game’s assets at front, we need to find a better way to split the loading throughout the game, only when needed. This would greatly improve the starting time of the game.

For most platforms, the current official Godot builds suffice. Games may not use every feature the build has under the hood, but storage is usually not an issue. But Web platform games require the developer to optimize the load size (as bandwidth can be limited) and the load speed (Internet speed can vary).

We are investigating how we can reduce the build size, starting by offering an easy way to the users to customize their builds.

Before 4.3’s introduction of single-threaded builds, we had some compatibility issues, especially on macOS and iOS devices. The problem is maybe less important than it once was, but we continue to be alert about compatibility issues that can exist now or at any point in the future.

OpenXR’s action map is similar to Godot’s input map, in that it allows mapping inputs to in-game actions. We’d like to enhance Godot’s support of OpenXR action maps by allowing the developer to apply modifiers to the actions, such as setting thresholds, enabling haptics, or converting analog inputs (like thumbsticks and trackpads) to D-Pad-like actions.

OpenXR uses the “OpenXR action map system” for handling input, whereas WebXR (and any other XR SDKs added via GDExtension) will use their own way of handling input. This complicates making a game that will work on both OpenXR and WebXR. We’d like to add a generalized XR action map system, which will use the OpenXR action map system on OpenXR, but provide a fallback implementation that can be used with any XR SDK.

Currently, when using OpenXR, you can use the Compatibility renderer or the Forward+ and Mobile renderers, but only when using Vulkan. We want to add support for DirectX12 and Metal so that users on all platforms can benefit from OpenXR.

The end goal is the ability to deploy Godot XR applications made with the executable downloaded from the website on any Android OpenXR conformant device.

This feature is already supported for the Meta vendor solution. Once a core API is becoming available in OpenXR, we intend to adopt this feature quickly.

The Godot XR Tools library offers out of the box locomotion and interaction solutions built on top of Godot’s core functionality. We intend to continue developing these tools.

One of the main complaints of the GDScript language is the lack of namespaces. A namespace is a way to group code by a common name. This permits the reuse of classes using the same name, as long as they can be differentiated by their namespace.

But the problem can be found with .NET and GDExtension too. The problem occurs at the registration phase of classes in our internal database.

With namespaces, plugin developers could use their own class names without worrying about clashing with users’ internal ones.

class_name is an handy feature. It permits the user to name their classes and refer to it directly instead of having to preload the class using its path.

Unfortunately, using class_name comes with a few caveats. We do hope to fix these issues in order to give users a better experience with this feature.

While GDScript is fast enough to operate as glue between nodes and program basic logic, its performance is lackluster when it comes to pure data crunching. We would like to improve the processing capabilities of the language and its run-time.

The main way to reuse code when writing code in GDScript is to use inheritance. While it works well for the most part, it leaves developers to rewrite a lot of code when that method cannot be used. So traits is the path we’re going forward to solve that issue.

The technology stars seem to align in order to enable us to export C# projects on the Web. We fully intend to make this a reality as soon as possible.

For the time being, users are required to download an entirely separate Godot build in order to use C# features. With our new upcoming .NET module, we intend to support C# with a simple plugin.

Everyone wins, as users won’t have to choose a special version to run C#. It reduces the number of builds on our side by half. Also, it will simplify .NET maintenance.

While the API documentation is complete, it currently lacks a specific .NET API. Both for newcomers and experienced users, it can be difficult or imprecise to translate the GDScript/C++ API to C#.

We intend to host a new website that will host an API documentation oriented for .NET users.

Currently, the engine’s capabilities are only accessible if the application itself is a Godot application. However, there are many situations where an application might want to use Godot as an intermediary. One case would be an application that uses native OS API for it’s UI, but needs Godot to render a complex 3D scene. Our goal is to make Godot available as a library to expand the possible uses of the engine.

GDExtension was created to allow developers to create extensions as if they were coding a module directly in Godot’s source code. Currently, modules can depend on one another, but this is not yet possible for extensions. We aim to expose the necessary API to be able to. So, for example, an extension built with godot-rust would be able to extend an extension built with godot-cpp.

For the time being, there’s no way to disable a GDExtension from a project without deleting the related files themselves. We plan to create a dialog akin to the Plugin tab in the Project settings in order to easily enable and disable GDExtensions.