Priorities

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.

As much as our nodes are made to be compatible with multiple physics engines, the existing integration of Jolt 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.

Some post-processing effects are currently 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. It’s starting to become common for desktop computers to support hardware ray tracing, and mobile devices are starting to follow. 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.

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.

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.

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

From the results of the 2025 community poll, Android is the fifth most targeted platform (34.4%) and is the third largest source of revenue. Yet Godot developers targeting Android suffer from lack of tools and plugins to allow them to properly integrate with the ecosystem and monetize their efforts. Starting with Godot 4.6, we will be working to close this gap.

In our What’s New in Android & XR article from June 2025, data was shared about the growing user-base of the Android editor, as well as the pain points encountered by its users. This priority will track the work to address the observed needs and to improve the stability and user experience of the editor.

Right now, the editor supports the Wayland display server through XWayland by default. Native Wayland support is already available, but is only used if enabled in the Editor Settings. To improve performance and desktop integration out of the box, we should further stabilize native Wayland suppot and enable this functionality by default.

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.

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.

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.

Static type hints are a well-loved feature in GDScript, as not only does it improve performance, but it lowers the amount of possible typing issues.

We intend to implement static typing for areas that currently lack them. We are thinking about enforcing the typing of signals and callables.

While GDScript is fast enough to operate as glue between nodes and to 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.

Since Godot 4.6, the engine can be compiled as a library for embedding in desktop applications. We are looking to extend this feature to mobile platforms and implement features such as reinitializing the library.

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.