This page is our wishlist : it details the improvements that we consider most important to make the Godot Engine a better tool for its users. The items were created by talking to the volunteer maintainers for each area about the current state of things, their personal goals, and what kind of contributions they are looking for. As with any wishlist, these points are an idealized version of what is to come in the project’s future. To realize them, we will need the support from you, whether you are a representative for a company looking to sponsor Godot or a game developer capable to contribute to the codebase directly. The Godot Engine has always been a community effort — there is only so much ground we can cover with Godot Foundation contractors at the moment. We hope that by publishing this list, we can align our communal efforts: by showcasing which areas need to see improvements the most and what the next steps would be for anyone taking action. Let this list be an indicator of… what kind of contractors we would like to hire if donations increase, what areas are ripe with good first issues for new contributors, and where corporate sponsors could lend a helping hand Reliable headless command line export unfold_more unfold_less 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. Pull requests GitHub Actions: Test project exporting on CI #109146 Reliable headless command line export 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. GitHub Actions: Test project exporting on CI #109146 Improve performance of scene multithreading unfold_more unfold_less 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. info Note As part of this work we need to create high quality tests and benchmarks. Both to ensure that we do not break anything, but also to validate the performance improvements. Improve performance of scene multithreading 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. As part of this work we need to create high quality tests and benchmarks. Both to ensure that we do not break anything, but also to validate the performance improvements. Make optimizations throughout the core unfold_more unfold_less 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. info Note To aid in this, we want to create more educational materials on profiling performance issues (both for CPU and GPU workloads). Make optimizations throughout the core 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. To aid in this, we want to create more educational materials on profiling performance issues (both for CPU and GPU workloads). Create more benchmarks unfold_more unfold_less 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. info Note We do have a public benchmark page! You can follow Godot’s main branch performance on the following website: https://benchmarks.godotengine.org/ Create more benchmarks 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. We do have a public benchmark page! You can follow Godot’s main branch performance on the following website: https://benchmarks.godotengine.org/ Adapt the way Godot exposes physics to mirror Jolt unfold_more unfold_less 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. warning Warning We do expect it will create some compatibility issues. Proposals Add per-shape collision filtering to the 3D physics system #7400 Add per-shape physics materials to the 3D physics system #7401 Adapt the way Godot exposes physics to mirror Jolt 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 do expect it will create some compatibility issues. Add per-shape collision filtering to the 3D physics system #7400 Add per-shape physics materials to the 3D physics system #7401 Overhaul SDFGI to improve performance and quality unfold_more unfold_less 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. Pull requests Upgrade SDFGI to HDDAGI #86267 Overhaul SDFGI to improve performance and quality 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. Upgrade SDFGI to HDDAGI #86267 Significantly improve post processing effects and add common effects unfold_more unfold_less 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. Proposals Add support for motion blur #2933 Port community motion blur addon #12258 Pull requests Overhaul screen-space reflections #111210 Implement XeGTAO (and also VBAO) #113304 Implement motion blur feature based on the community plugin #115027 Significantly improve post processing effects and add common effects 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. Add support for motion blur #2933 Port community motion blur addon #12258 Overhaul screen-space reflections #111210 Implement XeGTAO (and also VBAO) #113304 Implement motion blur feature based on the community plugin #115027 Add a rendering compositor to allow controlling render pass order unfold_more unfold_less 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. Proposals Implement a Rendering Compositor #7916 Add a rendering compositor to allow controlling render pass order 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. Implement a Rendering Compositor #7916 Enhance graphics debugging including VRAM debugging and better information from the current profiler unfold_more unfold_less 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. Pull requests Add pages on graphics debugging and profiling #11253 Enhance graphics debugging including VRAM debugging and better information from the current profiler 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. Add pages on graphics debugging and profiling #11253 Add shader templates to allow overriding the built-in shaders unfold_more unfold_less 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. Pull requests Custom shader templates #94427 Add custom shader template support to rendering server (core) #111939 Add shader templates to allow overriding the built-in shaders 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. Custom shader templates #94427 Add custom shader template support to rendering server (core) #111939 Implement texture and mesh streaming unfold_more unfold_less This feature would enable the streaming of assets to progressively load scenes, textures, and models in order to boost performance and loading times. Proposals Add support for texture streaming #3177 Implement Mesh streaming #6109 Pull requests Implement texture mip-level streaming #113429 Implement texture and mesh streaming This feature would enable the streaming of assets to progressively load scenes, textures, and models in order to boost performance and loading times. Add support for texture streaming #3177 Implement Mesh streaming #6109 Implement texture mip-level streaming #113429 Expose a ray tracing API and eventually use it for built-in effects unfold_more unfold_less 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. Pull requests Vulkan raytracing plumbing #99119 Expose a ray tracing API and eventually use it for built-in effects 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. Vulkan raytracing plumbing #99119 Add a deferred renderer unfold_more unfold_less 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. Proposals Add a project setting to enable deferred rendering #8295 Add a deferred 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. Add a project setting to enable deferred rendering #8295 Overhaul LightmapGI to improve baking workflow, performance, and features unfold_more unfold_less 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. list_alt_check Trackers [TRACKER] LightmapGI (GPU lightmapper) issues #56033 Overhaul LightmapGI to improve baking workflow, performance, and features 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. [TRACKER] LightmapGI (GPU lightmapper) issues #56033 Implement WebGPU backend for web exports unfold_more unfold_less 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. Proposals Add WebGPU support #6646 Implement WebGPU backend for web exports 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. Add WebGPU support #6646 Improve and polish new SkeletonModifier3D unfold_more unfold_less 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. info Note We identified at least two features that we wish to add Add a bone constraint (based on the Blender spec) Add spring bones (based on the VRM1 spec) Proposals Implement Skeleton re-targeting node #3379 Pull requests Add RetargetModifier3D for realtime retarget to keep original rest #97824 Implement LookAtModifier3D #98446 Improve and polish new SkeletonModifier3D 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. We identified at least two features that we wish to add Add a bone constraint (based on the Blender spec) Add spring bones (based on the VRM1 spec) Implement Skeleton re-targeting node #3379 Add RetargetModifier3D for realtime retarget to keep original rest #97824 Implement LookAtModifier3D #98446 Overhaul Skeleton2D animation unfold_more unfold_less 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. Overhaul Skeleton2D animation 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. Provide some way to access internal subresources of imported scenes unfold_more unfold_less 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. Proposals Add ability to reference subresources and inspect them in filesystem #8750 Provide some way to access internal subresources of imported scenes 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. Add ability to reference subresources and inspect them in filesystem #8750 Implement GDScript refactoring tools unfold_more unfold_less 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. Proposals Add “refactor” tooling to rename symbols in the script editor #899 Implement GDScript refactoring tools 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. Add “refactor” tooling to rename symbols in the script editor #899 Implement editor support for creating/updating source code for GDExtensions unfold_more unfold_less 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. Proposals Allow creating GDExtension plugins from inside the Godot editor #90979 Implement editor support for creating/updating source code for GDExtensions 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. Allow creating GDExtension plugins from inside the Godot editor #90979 Asset import & export Improve compatibility with Blender unfold_more unfold_less 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. info Note For materials, Khronos has a selection of material extensions . Improving compatibility with Blender materials will require Blender exporting data using these extensions, and then Godot adding support for it. info Note For constraints, VRM has a series of glTF extensions that add feature to glTF, including VRMC_node_constraint which adds aim, roll, and rotation constraints. However, note that Khronos and VRM recently announced a collaboration, so some of this functionality may end up being replaced by Khronos extensions. Also, users do not have to wait if they want this feature - a GDScript implementation of VRM is available thanks to @lyuma .

Improve compatibility with Blender 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. For materials, Khronos has a selection of material extensions . Improving compatibility with Blender materials will require Blender exporting data using these extensions, and then Godot adding support for it. For constraints, VRM has a series of glTF extensions that add feature to glTF, including VRMC_node_constraint which adds aim, roll, and rotation constraints. However, note that Khronos and VRM recently announced a collaboration, so some of this functionality may end up being replaced by Khronos extensions. Also, users do not have to wait if they want this feature - a GDScript implementation of VRM is available thanks to @lyuma . Improve import dialog to provide more control over imported resources unfold_more unfold_less 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. Improve import dialog to provide more control over imported resources 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. Add preview icons on imported scenes unfold_more unfold_less 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. Pull requests Generate thumbnails on imported scenes. #96544 Add preview icons on imported scenes 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. Generate thumbnails on imported scenes. #96544 Improve importer performance unfold_more unfold_less 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. Improve importer performance 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. Investigate delays in Window creation unfold_more unfold_less It is known that compared to Godot 3.x, there’s some delays while creating new Window , especially on Windows. Issues Godot 4 editor UI (menus) significantly slower than 3.x #71795 Investigate delays in Window creation It is known that compared to Godot 3.x, there’s some delays while creating new Window , especially on Windows. Godot 4 editor UI (menus) significantly slower than 3.x #71795 Distribute separate debug symbols unfold_more unfold_less 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. info Note This is currently implemented for Android, but we wish to extend this to all other platforms that support separate debug symbols. Proposals Distribute official builds with full debugging symbols #1342 Android: Enable native debug symbols generation #105605 Distribute separate debug symbols 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. This is currently implemented for Android, but we wish to extend this to all other platforms that support separate debug symbols. Distribute official builds with full debugging symbols #1342 Android: Enable native debug symbols generation #105605 Improve behavior of multiple monitors with different resolutions and DPI scaling factors unfold_more unfold_less Godot games should be able to seamlessly work when dragged across multiple monitors even when the monitors have different resolutions and DPI scaling factors. Pull requests [WIP] Implement native DPI scaling. #86022 Improve behavior of multiple monitors with different resolutions and DPI scaling factors Godot games should be able to seamlessly work when dragged across multiple monitors even when the monitors have different resolutions and DPI scaling factors. [WIP] Implement native DPI scaling. #86022 Help developers bring games to Android unfold_more unfold_less 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. Help developers bring games to Android 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. Improve the Android editor unfold_more unfold_less 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. Improve the Android editor 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. Use native Wayland support by default unfold_more unfold_less 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 support and enable this functionality by default. Use native Wayland support by default 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 support and enable this functionality by default. Improve Web export size unfold_more unfold_less 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. info Note We’re thinking about finding a way to offer alternative official Web exports with certain features disabled (such as 2D-only builds). Improve Web export size 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. We’re thinking about finding a way to offer alternative official Web exports with certain features disabled (such as 2D-only builds). Improve loading time for web builds unfold_more unfold_less 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. Proposals Async PCKs support #13625 Pull requests Add AsyncPCK support (+ Web implementation) #114690 Improve loading time for web builds 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. Async PCKs support #13625 Add AsyncPCK support (+ Web implementation) #114690 Make action map system available to WebXR unfold_more unfold_less 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. info Note And eventually other platforms. Proposals Implement generalized XR action map system for use outside OpenXR #6548 Make action map system available to WebXR 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. And eventually other platforms. Implement generalized XR action map system for use outside OpenXR #6548 Continue development of the Godot XR Tools library unfold_more unfold_less 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. Continue development of the Godot XR Tools library 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. Implement namespaces for scripting languages unfold_more unfold_less 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. Implement namespaces for scripting languages 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. Polish and ensure that class_name is robust and works in all cases unfold_more unfold_less 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. list_alt_check Trackers [TRACKER] GDScript class_name #99766 Polish and ensure that class_name is robust and works in all cases 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. [TRACKER] GDScript class_name #99766 Attain full coverage of static type hints unfold_more unfold_less 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. Pull requests Implement typed dictionaries #78656 Attain full coverage of static type hints 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. Implement typed dictionaries #78656 Improve runtime performance unfold_more unfold_less 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. info Note In addition to optimizing the current interpreter, we’re investigating whether to use AOT (ahead-of-time) or JIT (just-in-time) compilation techniques. Proposals Improve the performance of the GDScript VM #6031 Improve runtime performance 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. In addition to optimizing the current interpreter, we’re investigating whether to use AOT (ahead-of-time) or JIT (just-in-time) compilation techniques. Improve the performance of the GDScript VM #6031 Add traits to GDScript unfold_more unfold_less 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. Proposals Add a Trait system for GDScript #6416 Add traits to GDScript 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. Add a Trait system for GDScript #6416 Enable users to export their C# projects on the Web unfold_more unfold_less 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. Pull requests [.NET] Add web export support #106125 Enable users to export their C# projects on the Web 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. [.NET] Add web export support #106125 Unify standard and .NET builds into a single build unfold_more unfold_less 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. Unify standard and .NET builds into a single build 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. Host a .NET-specific documentation website unfold_more unfold_less 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. Host a .NET-specific documentation website 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. Improve Godot’s usability as a library unfold_more unfold_less 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. info Note This feature is better known as “LibGodot”. Pull requests Migeran LibGodot Feature #90510 LibGodot: Core - Build Godot Engine as a Library #110863 Improve Godot’s usability as a library 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. This feature is better known as “LibGodot”. Migeran LibGodot Feature #90510 LibGodot: Core - Build Godot Engine as a Library #110863 Allow GDExtensions to communicate with one another unfold_more unfold_less 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 . Allow GDExtensions to communicate with one another 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 . Add the ability to enable/disable GDExtensions in project settings unfold_more unfold_less 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. Add the ability to enable/disable GDExtensions in project settings 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.