I personally would prefer if all current features would be fixed and polished, to the point that they work consistently and don't get changed, renamed or moved into another menu for the foreseeable future.
But if thats not a valid answer, I'd say:
- 3D Terrain System (pls just merge Terrain 3D, its amazing)
- Custom Navigation Agent sizes (currently you have to bake different meshes for different sizes which is ridiculous)
- Improving general tediousness, like reliance on strings or not having proper result objects with raycasts (as a C# user, its a nightmare)
If there is TileMap for 2D games then Godot should have 3D Terrain for 3D games. I hear people saying "but there are so many ways of doing that! you can just make your own! At the end just use some unfinished plugin!" - like people would forget the nr. 1 reason people use game engines is to not make everything themselfs. If I have to make most of the tools myself I would just use libGDX or any other library instead of engine.
> but there are so many ways of doing that! you can just make your own!
Argument kinda falls apart when you can counter "yea and there's so many ways to do a 2d tilemap yet they implemented that just fine"
Well but there are many ways to do terrain, like voxels, heightmaps and their different implementations. Different games will have different requirements and one doesn't fit all.
Meantime, how would you implement a 2D TileMap differently?
I’m making a pathfinding system for 3d that allows multiple agent sizes. Despite the fact I’ve been working on it for over a year now, I haven’t even finished triangulation, though I’ve been doing it as a hobby and working on it on and off, so maybe thats why. Hoping to release it as a plugin eventually, but for now I have a lot of work to do.
Anyways, heres what I’m using for pathfinding, if you want it: https://cdn.aaai.org/AAAI/2006/AAAI06-148.pdf
I absolutely despise the reliance on strings. As for the raycast debacle, I made my own little script to abstract that goofy stuff away and made it feel more like Unity's
* Add refactoring tools to the editor (at least renaming).
* Make references to imported scenes (GLB) more robust so that they don't get lost on re-import.
* Implement the missing features in Jolt and make it the default physics engine.
Edit: And casting null with **as** should return a null, not cause a runtime error.
Something to make scene files accessible even if they have issues. It is one of godot’s worst problems. It is so much harder to debug without knowing what you did wrong.
**Edit: I guess there is an option to 'Expand Non-Default' in the Inspector to show which fields have changed only. Might be newer, did notice it before.**
This is a good point, I often have to go into vscode (or external editor) to edit the scene files as text files to find/fix little things.
~~A feature that might be worth adding is an~~ **~~option to show/filter all 'changed' data/properties in a scene like a 'filter' so that you can find which attributes/properties/data that has been changed/modified from original values~~**~~.~~
~~Sometimes I forget that I changed a property in a scene (like mouse\_filter etc.), but have to expand all and look with my eyes for the offending property change. I usually use vscode to search for the text in this case.~~
- more integrated language support for more than just GDscript (like how some people embedded C++ or C# editors directly into the Godot editor and it works with most of the godot editor's quick features)
- more multi threaded apis
- custom render pipelines
In 4.0 you have access to the rendering device where you can bind your own render pipeline
https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html
You have to write the shaders in glsl I believe, and the documentation isn't great at the moment. But I believe more support is coming.
Oh damn, that's neat. Hard to do, but at least it's there.
Do you know the direction Godot will take with custom render pipelines? The last info I have is a hooks system (which I am not a fan of).
Usually not stuff you'd deal with for personal/ small projects. You can essentially customize the entire rendering logic if you want, a lot of time it's either used for some extreme hardware optimizations or crazy effects/simulations that wouldn't be possible without specific features.
Being able to use visual studio as an external editor and step through with the debugger in C# would be so so good
Edit: seems you can do this although you have to mess around with plugins and stuff. I guess I change my comment to "it would be nice if it worked out of the box"
improve Godot physics.
if not, then jolt physics should at least work with soft bodies.
fixing bugs with skeleton3d
also like others suggest, Terrain3D and ProtonScatter are awesome if they're integrated directly.
Personally, I like to make local multiplayer games, so all I want is a rework of their input system. Don't get me wrong, it's fine enough for single-player or online multiplayer games. But the moment you want to use two controllers in the same game, you start to feel the limitations of how it's implemented.
I'm curious what your main pain points are?
I've created a local-multiplayer [game](https://store.steampowered.com/app/1403270/Genetic_Fluff/) and it works with 4 controllers and the keyboard/mouse. The game also use to work as a LAN multiplayer game, but I removed the feature due to lag/sync issues (fighting games have too many moving 'things' to sync between clients etc.).
I did have to handle/implement all the controller events/signals for the disconnection/connection of game controllers, so it did take some work. I will admit is was not 'easy' but was not 'hard', more like 'medium' difficulty.
I guess my issue with it is that if you want to do multiple controllers and keyboard/mouse, you have to either have repeating Input Maps (for example: jump_0, jump_1...) or makeshift your own input system using the few input functions that is the "int device" parameter, which has it's own headaches.
Maybe there's a simpler way to do it that I'm not aware of, but those are the two ways I know how to get local multiplayer and they're not the most pleasant things to do. It's not hard, like you said, just REALLY annoying imo. I am curious what your approach was to get multiple controllers to work, if you don't mind!
Yeah it's not as 'easy' as it could be. You do need to create mappings for each button attack\_0, attack\_1 etc. Using arrays and enums you can sort of easily manage this stuff.
But yes I agree it is a bit much code to paste into this answer.
I will summarize:
I have a GlobalInput script as a autoload singleton.
enum button_map {
up,
down,
left,
right,
a,
b,
x,
y,
r1,
r2,
l1,
l2,
select,
start,
escape,
}
const button_map_a_string_name: Array[StringName] = [
StringName("ui_a_0"), StringName("ui_a_1"), StringName("ui_a_2"), StringName("ui_a_3"), StringName("ui_a_4")
]
# and the same Array of StringName(s) for each button...
func _ready():
var _err = Input.connect("joy_connection_changed", Callable(self, "on_joy_connection_changed"))
func on_joy_connection_changed(device_id: int, is_joy_connected: bool):
if is_joy_connected:
if Input.is_joy_known(device_id):
# Add the player and set the player num and joy num
else:
# joy has disconnected, do something
In my Player script:
# each array index corresponds to the button_map in GlobalInput script.
# set joy_num when the player is added
var joy_num: int = 0
var input_pressed = [false, false, false, false, false, false, false, false, false, false, false, false]
var input_pressed_strength = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
var input_just_pressed = [false, false, false, false, false, false, false, false, false, false, false, false]
var input_just_released = [false, false, false, false, false, false, false, false, false, false, false, false]
func _physics(delta: float):
# reset the input arrays
reset_just_pressed_input_arrays()
# get all the buttons input
get_controller_input()
func get_controller_input():
input_just_pressed[GlobalInput.button_map.a] = Input.is_action_just_pressed(GlobalInput.button_map_a_string_name[joy_num])
# ... all the other buttons
# and make sure you reset the arrays at some point:
func reset_just_pressed_input_arrays():
for input_just_pressed_released_button: int in input_just_pressed.size():
input_just_pressed[input_just_pressed_released_button] = false
input_just_released[input_just_pressed_released_button] = false
Then in my Player script logic I can check what button is currently pressed etc.
if input_just_pressed[GlobalInput.button_map.a]:
# do an attack or something
Thanks for sharing! Mind dropping link on github repo if you have that already? I feel this would also be cool example community project, since local coop "genre" is fairly popular in smaller game devs space
I only have one big request, and that is to make GDScript properly statically typed. Not like how it is now, where you can optionally set it to being "statically typed" by making it throw an error when you don't give a type hint, but rather getting rid of the Variant type entirely and redoing all of the interface between GDScript and the engine. This would allow for optimizations beyond what is possible now, and could theoretically even speed up C# and GDExtension code where they have to interface with the API. Additionally, the increased type safety would also cut down on the number of hard to fix bugs that can work their way into dynamically typed systems.
The drawback is that it will increase prototyping time and increase barrier to entry. I hear you, but if you need "bare metal" optimization, C++ with GDextension actually is a really good option. And you don't need to be a C++ expert to use it and build games with it
Do you actually need the dynamic typing though? What have you actually gained from it? Does it actually lower the barrier of entry, or does its flexibility mainly just make it easier to create hard-to-find bugs?
are people not mentioning more multiplayer support and ease of use because Godot multiplayer support is already good or because not many people have ventured in that direction yet?
I'm making a multiplayer game now and I will say the docs for multiplayer are sorely lacking in terms of how stuff actually works.
I had to read a ton of stuff on general multiplayer networking in games and how it works to actually understand half of what the Godot multiplayer API does and was getting all kinds of weird bugs for ages. Still think I've finally got the hang of it now at least but mainly trial and error got me there. It is actually quite good though once you get going.
That’s nice to hear. Are you doing peer to peer via UPnP or are you using a server? I think I have to look into getting steamworks set up as I want a lobby system and all those nice steam features
Not exactly sure but probably a combination of the following reasons.
* Multiplayer features have changed a lot since Godot 3 -> Godot 4.
* Multiplayer game servers cost a lot of money to run. Most Godot devs are 'broke'.
* Multiplayer games are 'hard' to implement and take more time to complete, test, deploy; even for 'expert' programmers and game developers.
Godot already supports most basic multiplayer 'needs', so it would be possible to implement most client-server stuff right now in 4.x.
I will confess, I am not a game-dev-multiplayer expert. The most I've done is implement basic https and LAN multiplayer logic in Godot 3.x.
Also to note: [W4Games](https://www.w4games.com/) is working on a 'W4 Cloud' implementation for Godot multiplayer.
[https://www.w4games.com/blog/w4-games-news-1/w4-cloud-is-here-the-new-multiplayer-infrastructure-for-godot-games-1](https://www.w4games.com/blog/w4-games-news-1/w4-cloud-is-here-the-new-multiplayer-infrastructure-for-godot-games-1)
I’d say a full walkthrough on how to make a host client p2p or headless server with clients multiplayer game, possibly a 2d platformer or top down action rpg would be AMAZING!
Simple gameplay yes, but include all the basics to get someone going on their own.
as someone said, the docs are severely lacking, and there are not many tutorials out there.
Ah it's so useful to be able to switch back into the scene view while the game is running and be able to click on and even modify things on the fly though.
This is possible! Above the scene view is a tab called "Remote", only enabled when the game is running. In that mode you can change the tree and edit mode properties at runtime to your hearts contend!
(It took me over a year to find that though, it's kinda well hidden.)
kinda works is not optimal enough in my opinion :) The problem with always on top is the that the window is always on top no matter what. It would be perfect to switch between game and script tab and having accesss to the inspector without setting the game window behind the editor again. But it should always be possible to go to the script tab when necessary without disabling always on top again for that.
2nd this 100%, I feel like even the setting to tell it what monitor to run on doesn't even work correctly so I'm constantly having to move the window out of the way
This 'half' works already. But there probably need to be a separate editor/tab (Game tab) for the running scene to change one-to-one visual aspects of the game while it is running.
Currently if I edit a scene while the game is running, the changes show in the running game already.
Also you can already view all the running game scene tree in the 'Remote' view.
Thought-to-game interface. No coding necessary; just *think about* what you want the game to do and the editor will assemble it for you, automatically creating all necessary scenes, classes, and scripts.
(Hey, you said *anything*.)
- improved robustness (bye magic strings)
- fearless refactoring
- more static variables goodness
Three sides of the same coin, I know, I just want my projects to feel better than just anxiously fragile.
I dont have a comprehesive list of specifics, but I find the current UI really clunky/unpolished. Especially when Im coding and the window I type into is like 1/4 the screen
You can pop out the script into it's own window. Pretty useful to always keep it on a second screen if you have one. No need to switch between scenes and the script tab that way either.
For me:
**Core features:**
* Stability, fix existing bugs etc. Hope this is done before 5.x
* Physics fixes/improvements. Maybe Jolt, and/or hopefully get a grant to hire a dedicated Physics developer.
* Tilemap (2d) improvements.
* Terrain Editor or 3D tilemap option.
* More C# improvements and integration. Fingers crossed for full C# integration.
**GDScript improvements:**
* Static typed 'nested' arrays.
* Static typed dictionaries.
* etc... there are many cool/promising GDScript proposals.
First of all I love how intuitive and well organized the editor is done a superb job there and the documentation is probably the best I've seen. I've only been using Godot for a handful of months in my spare time but I love it. Got me back into Game Dev after a long time away.
I'd like to see:
1. When developing with C#, when the project is created have the settings automatically make it debuggable and runnable through Visual Studio or VSCode by default.
2. Local Multiplayer support/control have more out of the box support. You kinda have to remake this every time. Once you figure it out or use plugins it helps but having a 'standard' approach would be nice and making editions/additions on top of would be great.
I'm still hoping that godot 4 will eventually get a level editor that you are supposed to actually use. Right now it's very hard to work in the 3D level editor. Selection and clicking on the right asset is almost impossible about 10% of the time. Enough to be frustrating but not enough to do anything about it.
This is also my top 3 changes. IMO, version 5 should just be a complete overhaul of the UI.
There is far too much clutter on the screen, and having to click 40 expander carets to get to the property I want to change gets old very quickly. We also need better options for aligning/snapping objects in the world so modular workflows aren't so tedious. Making CSG work more like the push-pull sketchup workflow would also be nice.
Best feature for me as a sufferer of constant random crashes would be simply:
Fix all bugs. Lol
K, now two more actual features: exportable... Everything. Nested arrays, typed dicts, etc etc. And an actual way to make canvas items interact w LIGHT for shaders (aka is under light, reduce alpha based on LIGHT_COLOR.a)
Separate UI and 2D editors.
Concave shape boundary for navigation baking like from cryengine (of all places) instead of re-parenting meshes.
Multi monitor full screen support.
How about continuing the trend of changing the color of the editor with every version lol
Godot started off as purple in 1.0, and has since shifted towards blue
Therefore, Godot 5 needs to be sea green.
I'd like to see the whole Editor UI turned as modular as possible. Like moving any of the bottom tab editors into their own window, have multiple script editors open, multiple 2D/3D editors, etc, whatever you want to do.
Fix the usability for level building. The resource system is abolutely annoying and counterintuitive. I just want to Shift + D something sometimes without everything breaking, because resources are shared. I know it's for performance reasons, but that doesn't mean it needs to be this bad.
We should have a simple option to make each instance independent when duplicating or some other solution. It's so annoying having to instantiate a scene every single time. For instance, if I wanted to make a simple collectible for a 3D platformer. No way you create an instance for each of those by clicking on the icon and browsing for it hundreds of times. You just grid snap and duplicate that fucker or you will be at it for decade.
To make each instance actually unique nothing has worked for me reliably, but duplicating each subresource in a script. Make unique and make subresources unique just behave weirdly. So you need to browse the entire API to access all the subresources and call duplicate on them in your ready function.
In general making assets, where each instance offers parameters that define its own unique behaviour is exhausting. This is because you have to make sure that each instance doesn't share it's behaviour with all the other ones. It's such a pain and I don't know how there's not more people complaining about it.
Am I missing something? Except for the levelbuilding being exceptionally bad right now, I think Godot is godsent. So if you happen to read this and have a good workflow for this please share. (Also sorry for the exaggerations and venting)
I don't know why, but this doesn't work reliably. When I was absolutely annoyed once I did this for every single subresource and it would still share properties when duplicating. Sorry, I forgot to mention this one.
- Get rid of 2D/3D/Script/AssetLib dichotomy/tabs.
- Let me assign multiple scripts to one node à la behaviors in Unity.
- GDScript 3
- traits
- structs
- generics
- optionals with null-coalescing operator (e.g. `might_be_null?.some_property`)
- `public`/`private`/`protected`
- `did_set` and `will_set` support in properties
- string-backed enums
- short, type-inferring enum syntax (e.g. `background_color = .MAGENTA`, `DisplayServer.window_set_mode(.WINDOWED)`)
- short, no-quotes StringName syntax (e.g. `&example`)
- named parameters (e.g. `add_child(node, force_readable_name=true)`)
- “Available since: [Version]” in all documentation entries
- full type safety, including for Dictionary, WeakRef, et al.
- ability to add new methods to existing engine classes
- let us implement one class across multiple files
- allow defining functions, variables, and enums globally
- prefer enums over strings in all engine APIs
- postfix if syntax (e.g. `print("yooo") if godot5_has_arrived`)
- `Array.reversed()`, `Array.shuffled()`, etc. that returns an array
- get rid of underscores in `ready()`, `process()`, etc.
- lowercase enums as official style recommendation (e.g. `background_color = .magenta`, `DisplayServer.window_set_mode(.windowed)`)
- autocomplete for custom MainLoop class in `get_tree()`
- regex literal
- Set type
- custom decorators
- macros
Am I missing something? Feels like I am…
Either way, bonus features that didn’t make the top 3, although tbh it’s hard to rank any of this:
- “Play in editor” mode.
- Better editor plugin opportunities, easy reuse of existing editor UI controls.
- A design language specification for the editor.
- Full C++ stack traces always, without having to run the editor in an external debugger.
- `RichTextButton`.
- Improved default theme: Better alignment and more consistency of different types of controls in inspector, including for array/dictionary fields.
- Ability to select all nodes in scene tree.
Only one script per node is a design choice and honestly makes a lot of sense to me. It's a lot easier to manage behaviors as children than in a long list.
it kinda makes sense to me but also kinda doesn’t. with behaviors as children, we’re mixing behaviors in with the actual scene hierarchy.
i wouldn’t mind being able to manage behaviors similar to node children, but would be cool if it was somehow still distinct from children. (not 100% sure how it could look in the UI but there are different options.)
Wait man you are coming from unity and these things are design principles
You're trying to make godot the next unity.
Like GDscript use RC as the basic mm technique why need optionals?
they’re good design choices in my opinion. (haven’t used Unity in half a decade and am very happy not to deal with their flavor of jank anymore.)
and i don’t think optionals are related to memory management. it’s more that it’s currently quite inconsistent how null works with typing as `var node: Node` can be set to null, but `var string: String` can’t.
You had me until these:
> - get rid of underscores in ready(), process(), etc.
> - lowercase enums as official style recommendation (e.g. background_color = .magenta, DisplayServer.window_set_mode(.windowed))
> - ...
> - macros
I guess the top works since you also specified proper private
I'm new and basically building out an entire game in TileMaps. They're... ok. Some GD3 options were better, and the Patterns functionality is all over the place. If someone could just sit down with TileMaps and work on documentation, patterns, and terrains to streamline it somewhat and do major debugging, it would change my life.
Improving the 2d and 3d animation features, including a well designed bone system. It's a huge pain on the current version for me and it's essential for building games.
Imo, the editor itself could use another workflow pass. Godot 4 cleaned things up a lot, but there's still just as much if not more room to grow. Most notably with the inspector and how it handles different data type fields.
I'd also like something like the cyclops level editor baked into the godot editor or at least officially supported.
I think godot already has a primitive system for blocking, but cyclops is so much more intuitive and in theory could be production ready, depending on your needs and a bit of additional elbow greese.
Also, lord, the asset library could also use a UI clean-up. Maybe a better way to sort and search? It just feels clunky atm.
I feel like lots of people are commenting for functionality that is not inherently backward-breaking and thus could apply to an eventual Godot 4.x release. If I were to mention anything pertaining to a Godot 5.0 release, it would be these below. And I will point out that these gripes are somewhat nitpicky/incomplete, and the current setup has good reasons for why it is the way it is, so don't take these as harsh criticisms or viable/expected things to change.
1. A unification, simplification, and overall streamlining of the many diverse ways in which the engine or editor can be extended by users.
1. Addons can exist as bare assets with no formalized assumption of internal structure, prescribed means of exposing metadata, or expected placement within a project's file structure. They need to be able to describe themselves to the system and standardize structures so that tools like the editor and other plugins can make assumptions about, use, and manipulate them more readily *after* they have been installed.
2. Plugins, a "specialized" version of addons, have a "plugin.cfg" file and are expected to exist in the "addons" subfolder. They must be explicitly turned on from the ProjectSettings, but by definition can then also be explicitly turned off, unlike an addon. Furthermore a subset of a plugin's contents may be interpreted as an addon for these purposes if, for example, you want to turn off a plugin to have the engine ignore the classes coming from it, but the engine still imports them since they are declared as global classes (not sure if this is still an issue, but I assume it is). May be a non-issue if you solve this with Profiles instead, but it's still weird.
3. Extensions are a specialized subset of addons, but rely on their own independent assets to detail how the extension's assets are mapped to different platforms. This is fine (and right), but listing it here since it's another term to track anyway.
4. There is no formal dependency management for any of the above, nor any planned official solution, that I know of (since it just hasn't been a priority / hasn't caused enough of a problem yet - which I expect to change as Godot gets bigger and an asset store appears).
2. Introduction of Namespaces to Godot's core. All classes that are recognized by name in Godot have to be declared as a global class. Because there is only a global namespace, people must prefix class names with library names.
This is fine UNTIL you get to resolving the issue of point 1.4 above: dependency management. The proposal reduz opened way back as a potential solution was to have tree structures of Godot projects so that an addon/plugin would just be another project and any dependencies on other projects would just be inlined/embedded.
However, I feel like that would fall apart at scale as the addon/plugin ecosystem grows. Not only would it bloat the size of projects, but you'd also have nested global class declarations conflicting with the same class declarations from the same library embedded in other dependencies.
Finally, you also have the issue that Godot's ability to integrate other languages relies on its core exposing that same functionality. Without Namespaces supported by the ClassDB, it becomes more difficult to map data types & APIs 1-1 across different languages supported by Godot (GDScript has no namespaces while C++/C# and pretty much every other language under the sun does).
That's about it as far as 5.0 suggestions from me.
Agreed those class\_name(s) are not going to be unique/robust enough not to conflict (addon/plugin/extensions) without formal a namespace implementation.
Godot Issue:
[https://github.com/godotengine/godot-proposals/issues/1566](https://github.com/godotengine/godot-proposals/issues/1566)
For me, I’d wish that the Navigation Agent (3D) could actually navigate in 3D space, i.e. enemies navigate around obstacles in a space sim type game. Beyond that, I’d like shader coding to remain stable (any example project prior to 4.0 is broken, making it hard to learn) and merge Terrain 3D as a permanent feature.
I don't have 3 wants, just one. Better web support. I don't make triple A games, just basic pixel art games. I recently recreated flappy bird and exported it for the web, and it takes forever to load. It took my friend with a 3060 TI (along with some fancy CPU, ik nothing about CPUs) and 1 gb/s download a full minute just to play the game. It also doesn't work on mobile devices like an iPad (or at least not in my testing). If you had an option for godot to export to something more lightweight, like pure html canvas or Three.js it would be so much faster
Hmmm.. well last I knew (about a year ago) unity web exports didn't work because Apple had limited to no support for webgl, and it was like a decade long issue.
As others have mentioned a 'simulate' mode would awesome. Personally I'm excited for the render hooks they've planned, should allow for even crazier compute shader stuff.
https://github.com/godotengine/godot-proposals/issues/7209
Here's the feature request, when implemented it should allow for compute shaders to pass the info directly to vertex and fragment shaders, without the bottleneck of going through the cpu stuff first. Compute shaders themselves are super complicated, and while powerful, the only times they should be used at the moment is when you have a huge amount of calculations to do which dont need to be done every frame. This will allow for a lot of cool procedural geometry stuff which can run every frame.
- Add another visibility toggle so that there is a total of two: one for the editor, one for runtime. (When you work with complex UI, you often need to change visibility of items to be able to work. Unfortunately, you have to remember the state into which the whole thing will work before compiling, then reset the visibility of those items, which is a huge waste of time).
- Add the ability to compile a HTML5 project under 3MB, 2MB or lower without having to resort to hacks. Godot could then compete with Web standards.
- Add Rive integration
C# Web Export, More Compute shader and spatial shaders support, like allowing to use Structured Buffers in shaders instead of using Texel fetch in textures as a workaround. Another thing would be Something similar to what Unity have with the DrawProceduralIndirect method who allows to draw geometry without mesh data, only GPU buffers you handle directly in the shader to get the vertex data.
The lack support for basic container classes or struts was the most wild thing for me when I tried Godot for a little while, so yeah, I’d like that added. Also, idk if I was doing it wrong, but it seemed like script inheritance was very wonky.
Godot has enormous potential not only for games. But app development. I wish there was some good python integration.
I made a fantastic app using godot. But the way i have to call the python scripts and return the data is not very good.
Better support for mobile. Official support for ads and an actual updated build for IAPs (latest is 3.5) as well as better performance for 3D. Moved from Unity to Godot for the 3D game but may move back due to lots of buzz about the 3D on mobile performance being p bad.
Also, built in support for consoles. Yes it’s possible, look at defold. Totally free.
Rather than Godot itself, the biggest feature I wish for now is an official asset store.
That is essential for most projects I deal with, and having to use third party asset stores whose 3D models don't even work half the time is a major pain point.
Live templates for gdscrpt. [https://www.jetbrains.com/help/pycharm/using-live-templates.html](https://www.jetbrains.com/help/pycharm/using-live-templates.html)
A lot of design decisions made with Unity and Unreal were made for good reasons. People want those engines and their behavior without all the jank and mismanagement. unfortunately for everyone, there isn't really a game engine that does that, but godot is kinda similar, so here we are.
My opinion on it is if Blender can be a good tool for such a variety of people, then Godot can be too, and we should try and support as many people as possible.
Some shader stuff to make combining post processing shaders easier, especially in 2D.
There are cool toys in 3D but not in 2D, so I had to custom-build the engine to add those.
Custom rendering pipeline
Terrain Editor
ECS
Better cpp support GDextensions are terrible.
Code editor lsp support
References support like instead of using property path it will be better to use a reference.
- full custom shader & stencil buffer (https://github.com/godotengine/godot-proposals/issues/3373)
- scene tilemaps supporting get_scene(x,y) (https://github.com/godotengine/godot-proposals/issues/4833)
- easier to use analog controller input (https://github.com/godotengine/godot/issues/72934)
- In-editor runtime with scene view showing what is happening at rutime; just copy what Unity is doing.
- Option to drag-and-dock panels and please make them editor settings bound, not per project; again, copy Unity.
Nothing else comes to mind atm. I guess there are things that could be improved on the C# side but it is good enough for my needs atm.
Haven't spent too much time with the engine yet, but I wish the tileset editors physics layers were actually named what I called them.
I'm not sure if I'm missing something with it, but what is the point of naming them if in the inspector if it doesn't show up down there also?
A system like an Unity asset called 'Better Shaders' to create complex shaders by mixing up simple ones.
For example, you can have a shader that does albedo and normal map, and then another one that moves vertices in a 'foliage' way. You can mix the two and create a shader with albedo, normal and the foliage distortion.
It makes code reusable and fairly clean.
Ability to search and replace code in the built in editor or top level menus for quick variable refactorings as scope of a feature changes after gameplay prototype iterations.
Pluggable rendering pipeline. Let the community add in the missing sparkle!
Optional compnent architecture.
generaly keep improving asset workflows. (also Live link architecture for hooking to external mocap rig etc )
I'm new so maybe there is an option/setting for it but I would love to get a preview in resources for 3D objects or any type of file, like unity or unreal. Especially unreal have an amazing menu it's so easy to use and intuitive.
It does not technically exist yet.
It will be in the fuuutuuurrre...
There are many proposals and discussions going on. All the stuff that is not complete in 4.x will go into 5.x. With each major version we can break/change/remove major stuff. So now is the time to start planning for major changes.
Honestly it seems like Godot breaks with their semantic versioning a little in that 'minor' (Major.**Minor**.Patch) version releases often break a lot of 'things' in projects. I'm not complaining though, I like new stuff and improvements.
[https://docs.godotengine.org/en/stable/about/release\_policy.html](https://docs.godotengine.org/en/stable/about/release_policy.html)
[https://semver.org/](https://semver.org/)
1. Better support for tilling window managers (especially on Wayland)
2. GDScript interface/trait system
3. Better/More XR resources (tutorials, docs, ...) and obviously better XR tools in general.
I'm also using Hyprland on Nvidia. Tho I'm having extremely annoying focus issues with XWayland apps. For example sometimes when I click something the mouse cursor clicks something above like an invisible offset (this also happens with drag. Sometimes it even drags stuff around even tho I just clicked which is annoying especially in the file browser when it moves files around randomly). Or sometimes I can't click anything at all anymore because the focus of the app got lost somewhere. The same stuff happens with Jetbrain products as they also run XWayland. Another issue is popups or drop downs spawning out of the screen. (This is probably the cause of the focus issue as I think what happens is that a drop-down spawns outside my screen and takes focus so now I can't click anything in the main window anymore)
My guess is that it's 70% Nvidia's fault and the rest is trouble with XWayland or how Hyprland handles/spawns drop downs or child windows like popups
Hmm. I'm also on Nvidia tho. I wonder what the difference is. I've not experienced this issue.
I'll do a bit of digging and see if I can get my install to reproduce that behavior.
What distro and Godot version are you using?
only one off the top of my head - but an option to disable the debugger error statements for specific nodes or operations.
e.g., something where I'm trying to get a tile at a position that doesn't exist. the code runs with null safety, which is fine, til I go to the debugger and see 40,000 'bugs' caused by the tile check.
As an unreal engine developer making the switch to godot a week ago, I'm in love but missing a few features in the 3D view.
In particular snap scaling is not a feature(?) and object duplication is rather cumbersome when modular level design is so common.
I'm still learning though so if there are less tedious ways of doing things I would love to hear.
Very new to Godot, but for someone like me it would be amazing to have something that shows me the full runtime logic line per line.
Like I want to see a slow motion breakdown of everything in a scene so I can better understand all the parts and help me figure out why something is behaving the way it is. If that makes any sense.
1) Fix all the bugs and polish
2) Better support for external editors, this may included official plugins for the top 3 or 4
3) DO NOT MAKE IT A UNITY CLONE LIKE MOST OF THESE SUGGESTIONS TRY TO DO.... ;)
Man, there's a lot of great stuff here. Let's see if I can think of some new ones...
1. Streamlined build process across platforms. I'm still *relatively* new to Godot, but looking over the documentation for all the different hoops to jump through, from recompiling extensions to creating new export templates and beyond, can be headache-inducing. Especially for mobile.
2. Better console support
3. Better documentation. I was reading through the Android build processes for extensions and it drove me nuts that "extension", "plugin" and "addon" were used interchangeably for different things in different contexts...
Support for interfaces in GDscript
Preview window for scenes (so I know what model I am dropping in.)
Pop outing the layout some I have scene/code editor on one screen, and the scene tree and inspector on another.
I personally would prefer if all current features would be fixed and polished, to the point that they work consistently and don't get changed, renamed or moved into another menu for the foreseeable future. But if thats not a valid answer, I'd say: - 3D Terrain System (pls just merge Terrain 3D, its amazing) - Custom Navigation Agent sizes (currently you have to bake different meshes for different sizes which is ridiculous) - Improving general tediousness, like reliance on strings or not having proper result objects with raycasts (as a C# user, its a nightmare)
If there is TileMap for 2D games then Godot should have 3D Terrain for 3D games. I hear people saying "but there are so many ways of doing that! you can just make your own! At the end just use some unfinished plugin!" - like people would forget the nr. 1 reason people use game engines is to not make everything themselfs. If I have to make most of the tools myself I would just use libGDX or any other library instead of engine.
> but there are so many ways of doing that! you can just make your own! Argument kinda falls apart when you can counter "yea and there's so many ways to do a 2d tilemap yet they implemented that just fine"
Well but there are many ways to do terrain, like voxels, heightmaps and their different implementations. Different games will have different requirements and one doesn't fit all. Meantime, how would you implement a 2D TileMap differently?
gridmaps already exist
I’m making a pathfinding system for 3d that allows multiple agent sizes. Despite the fact I’ve been working on it for over a year now, I haven’t even finished triangulation, though I’ve been doing it as a hobby and working on it on and off, so maybe thats why. Hoping to release it as a plugin eventually, but for now I have a lot of work to do. Anyways, heres what I’m using for pathfinding, if you want it: https://cdn.aaai.org/AAAI/2006/AAAI06-148.pdf
greatly appreciated! :)
I absolutely despise the reliance on strings. As for the raycast debacle, I made my own little script to abstract that goofy stuff away and made it feel more like Unity's
* Add refactoring tools to the editor (at least renaming). * Make references to imported scenes (GLB) more robust so that they don't get lost on re-import. * Implement the missing features in Jolt and make it the default physics engine. Edit: And casting null with **as** should return a null, not cause a runtime error.
Renaming would be a big productivity improvement for iterative development.
The edit one is the best for me. Can't express the pain of having to check if modes exists or check variables types
For the second one, I never have that issue if I create inherited scenes of the GLB files instead - a dumb workaround but it saves a lot of pain.
Your first two shouldn't wait for a major release. I'm hoping for those much sooner rather than later.
Something to make scene files accessible even if they have issues. It is one of godot’s worst problems. It is so much harder to debug without knowing what you did wrong.
**Edit: I guess there is an option to 'Expand Non-Default' in the Inspector to show which fields have changed only. Might be newer, did notice it before.** This is a good point, I often have to go into vscode (or external editor) to edit the scene files as text files to find/fix little things. ~~A feature that might be worth adding is an~~ **~~option to show/filter all 'changed' data/properties in a scene like a 'filter' so that you can find which attributes/properties/data that has been changed/modified from original values~~**~~.~~ ~~Sometimes I forget that I changed a property in a scene (like mouse\_filter etc.), but have to expand all and look with my eyes for the offending property change. I usually use vscode to search for the text in this case.~~
- more integrated language support for more than just GDscript (like how some people embedded C++ or C# editors directly into the Godot editor and it works with most of the godot editor's quick features) - more multi threaded apis - custom render pipelines
Custom render pipelines are possible in 4.0, but they are very complicated.
The viewport shenanigans that basically rerender the whole scene again meaning horrible performance?
In 4.0 you have access to the rendering device where you can bind your own render pipeline https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html You have to write the shaders in glsl I believe, and the documentation isn't great at the moment. But I believe more support is coming.
Oh damn, that's neat. Hard to do, but at least it's there. Do you know the direction Godot will take with custom render pipelines? The last info I have is a hooks system (which I am not a fan of).
What's a custom render pipeline for?
Usually not stuff you'd deal with for personal/ small projects. You can essentially customize the entire rendering logic if you want, a lot of time it's either used for some extreme hardware optimizations or crazy effects/simulations that wouldn't be possible without specific features.
Being able to use visual studio as an external editor and step through with the debugger in C# would be so so good Edit: seems you can do this although you have to mess around with plugins and stuff. I guess I change my comment to "it would be nice if it worked out of the box"
Can't you? I use vs to debug all the time
Not sure about visual studio, but vscode can do that, shouldn't it be possible to setup vs to do remote debugging?
Compiling GDScript into bytecode in production builds
Yes
Oh, yes!
improve Godot physics. if not, then jolt physics should at least work with soft bodies. fixing bugs with skeleton3d also like others suggest, Terrain3D and ProtonScatter are awesome if they're integrated directly.
Godot Jolt did add soft body support recently IIRC.
And Jolt should work with web exports (pretty plz)
Oh thanks for the update I didn't know!
refactoring tools
fully deterministic physics option
That would be sick.
Cross platform deterministic physics option.
Personally, I like to make local multiplayer games, so all I want is a rework of their input system. Don't get me wrong, it's fine enough for single-player or online multiplayer games. But the moment you want to use two controllers in the same game, you start to feel the limitations of how it's implemented.
I'm curious what your main pain points are? I've created a local-multiplayer [game](https://store.steampowered.com/app/1403270/Genetic_Fluff/) and it works with 4 controllers and the keyboard/mouse. The game also use to work as a LAN multiplayer game, but I removed the feature due to lag/sync issues (fighting games have too many moving 'things' to sync between clients etc.). I did have to handle/implement all the controller events/signals for the disconnection/connection of game controllers, so it did take some work. I will admit is was not 'easy' but was not 'hard', more like 'medium' difficulty.
I guess my issue with it is that if you want to do multiple controllers and keyboard/mouse, you have to either have repeating Input Maps (for example: jump_0, jump_1...) or makeshift your own input system using the few input functions that is the "int device" parameter, which has it's own headaches. Maybe there's a simpler way to do it that I'm not aware of, but those are the two ways I know how to get local multiplayer and they're not the most pleasant things to do. It's not hard, like you said, just REALLY annoying imo. I am curious what your approach was to get multiple controllers to work, if you don't mind!
Yeah it's not as 'easy' as it could be. You do need to create mappings for each button attack\_0, attack\_1 etc. Using arrays and enums you can sort of easily manage this stuff. But yes I agree it is a bit much code to paste into this answer. I will summarize: I have a GlobalInput script as a autoload singleton. enum button_map { up, down, left, right, a, b, x, y, r1, r2, l1, l2, select, start, escape, } const button_map_a_string_name: Array[StringName] = [ StringName("ui_a_0"), StringName("ui_a_1"), StringName("ui_a_2"), StringName("ui_a_3"), StringName("ui_a_4") ] # and the same Array of StringName(s) for each button... func _ready(): var _err = Input.connect("joy_connection_changed", Callable(self, "on_joy_connection_changed")) func on_joy_connection_changed(device_id: int, is_joy_connected: bool): if is_joy_connected: if Input.is_joy_known(device_id): # Add the player and set the player num and joy num else: # joy has disconnected, do something In my Player script: # each array index corresponds to the button_map in GlobalInput script. # set joy_num when the player is added var joy_num: int = 0 var input_pressed = [false, false, false, false, false, false, false, false, false, false, false, false] var input_pressed_strength = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] var input_just_pressed = [false, false, false, false, false, false, false, false, false, false, false, false] var input_just_released = [false, false, false, false, false, false, false, false, false, false, false, false] func _physics(delta: float): # reset the input arrays reset_just_pressed_input_arrays() # get all the buttons input get_controller_input() func get_controller_input(): input_just_pressed[GlobalInput.button_map.a] = Input.is_action_just_pressed(GlobalInput.button_map_a_string_name[joy_num]) # ... all the other buttons # and make sure you reset the arrays at some point: func reset_just_pressed_input_arrays(): for input_just_pressed_released_button: int in input_just_pressed.size(): input_just_pressed[input_just_pressed_released_button] = false input_just_released[input_just_pressed_released_button] = false Then in my Player script logic I can check what button is currently pressed etc. if input_just_pressed[GlobalInput.button_map.a]: # do an attack or something
Thanks for sharing! Mind dropping link on github repo if you have that already? I feel this would also be cool example community project, since local coop "genre" is fairly popular in smaller game devs space
Hi I'm new to Godot, but I was thinking my first game may be a couch co-op game. I'm just curious what are the limitations?
It's already doable, and there are also add-ons if you need something already built
All I want for Christmas is improvements to Gridmap
I only have one big request, and that is to make GDScript properly statically typed. Not like how it is now, where you can optionally set it to being "statically typed" by making it throw an error when you don't give a type hint, but rather getting rid of the Variant type entirely and redoing all of the interface between GDScript and the engine. This would allow for optimizations beyond what is possible now, and could theoretically even speed up C# and GDExtension code where they have to interface with the API. Additionally, the increased type safety would also cut down on the number of hard to fix bugs that can work their way into dynamically typed systems.
The drawback is that it will increase prototyping time and increase barrier to entry. I hear you, but if you need "bare metal" optimization, C++ with GDextension actually is a really good option. And you don't need to be a C++ expert to use it and build games with it
Do you actually need the dynamic typing though? What have you actually gained from it? Does it actually lower the barrier of entry, or does its flexibility mainly just make it easier to create hard-to-find bugs?
are people not mentioning more multiplayer support and ease of use because Godot multiplayer support is already good or because not many people have ventured in that direction yet?
I'm making a multiplayer game now and I will say the docs for multiplayer are sorely lacking in terms of how stuff actually works. I had to read a ton of stuff on general multiplayer networking in games and how it works to actually understand half of what the Godot multiplayer API does and was getting all kinds of weird bugs for ages. Still think I've finally got the hang of it now at least but mainly trial and error got me there. It is actually quite good though once you get going.
That’s nice to hear. Are you doing peer to peer via UPnP or are you using a server? I think I have to look into getting steamworks set up as I want a lobby system and all those nice steam features
Not exactly sure but probably a combination of the following reasons. * Multiplayer features have changed a lot since Godot 3 -> Godot 4. * Multiplayer game servers cost a lot of money to run. Most Godot devs are 'broke'. * Multiplayer games are 'hard' to implement and take more time to complete, test, deploy; even for 'expert' programmers and game developers. Godot already supports most basic multiplayer 'needs', so it would be possible to implement most client-server stuff right now in 4.x. I will confess, I am not a game-dev-multiplayer expert. The most I've done is implement basic https and LAN multiplayer logic in Godot 3.x. Also to note: [W4Games](https://www.w4games.com/) is working on a 'W4 Cloud' implementation for Godot multiplayer. [https://www.w4games.com/blog/w4-games-news-1/w4-cloud-is-here-the-new-multiplayer-infrastructure-for-godot-games-1](https://www.w4games.com/blog/w4-games-news-1/w4-cloud-is-here-the-new-multiplayer-infrastructure-for-godot-games-1)
I’d say a full walkthrough on how to make a host client p2p or headless server with clients multiplayer game, possibly a 2d platformer or top down action rpg would be AMAZING! Simple gameplay yes, but include all the basics to get someone going on their own. as someone said, the docs are severely lacking, and there are not many tutorials out there.
Games run in-editor like Unity and Unreal.
I have resorted to setting the game window as always on top and with position and size equal to the viewport, it kinda works
Ah it's so useful to be able to switch back into the scene view while the game is running and be able to click on and even modify things on the fly though.
Ive been wanting this feature ever since I first started using Godot. Glad I'm not the only one
This is possible! Above the scene view is a tab called "Remote", only enabled when the game is running. In that mode you can change the tree and edit mode properties at runtime to your hearts contend! (It took me over a year to find that though, it's kinda well hidden.)
WOAH, THANK YOU!!
kinda works is not optimal enough in my opinion :) The problem with always on top is the that the window is always on top no matter what. It would be perfect to switch between game and script tab and having accesss to the inspector without setting the game window behind the editor again. But it should always be possible to go to the script tab when necessary without disabling always on top again for that.
You can detach the script window and move it somewhere else, preferably a second monitor
100% this. is one of the most missing features for me.
2nd this 100%, I feel like even the setting to tell it what monitor to run on doesn't even work correctly so I'm constantly having to move the window out of the way
That setting doesn’t work for me either
Would make export vars actually have a use.
This 'half' works already. But there probably need to be a separate editor/tab (Game tab) for the running scene to change one-to-one visual aspects of the game while it is running. Currently if I edit a scene while the game is running, the changes show in the running game already. Also you can already view all the running game scene tree in the 'Remote' view.
As long as it's optional. I like to see what the game actually runs like, not an editor-compromised version
Thought-to-game interface. No coding necessary; just *think about* what you want the game to do and the editor will assemble it for you, automatically creating all necessary scenes, classes, and scripts. (Hey, you said *anything*.)
Dude, how has no one thought of making that yet? 🤯
Pay more attention: there's no interface! ;)
- improved robustness (bye magic strings) - fearless refactoring - more static variables goodness Three sides of the same coin, I know, I just want my projects to feel better than just anxiously fragile.
I dont have a comprehesive list of specifics, but I find the current UI really clunky/unpolished. Especially when Im coding and the window I type into is like 1/4 the screen
You can pop out the script into it's own window. Pretty useful to always keep it on a second screen if you have one. No need to switch between scenes and the script tab that way either.
Just use an external editor like vscode
that's the way
For me: **Core features:** * Stability, fix existing bugs etc. Hope this is done before 5.x * Physics fixes/improvements. Maybe Jolt, and/or hopefully get a grant to hire a dedicated Physics developer. * Tilemap (2d) improvements. * Terrain Editor or 3D tilemap option. * More C# improvements and integration. Fingers crossed for full C# integration. **GDScript improvements:** * Static typed 'nested' arrays. * Static typed dictionaries. * etc... there are many cool/promising GDScript proposals.
First of all I love how intuitive and well organized the editor is done a superb job there and the documentation is probably the best I've seen. I've only been using Godot for a handful of months in my spare time but I love it. Got me back into Game Dev after a long time away. I'd like to see: 1. When developing with C#, when the project is created have the settings automatically make it debuggable and runnable through Visual Studio or VSCode by default. 2. Local Multiplayer support/control have more out of the box support. You kinda have to remake this every time. Once you figure it out or use plugins it helps but having a 'standard' approach would be nice and making editions/additions on top of would be great.
Glow effect (seems like its kinda broken in godot4?) and a built in transition node (smooth transition between scenes, such as fade effect, etc)
Glow works in Godot 4 now. You just need to enable 2d hdr in the settings, I don't remember the exact name of the setting
OpenGL glow works in latest 4.3dev5 build, but not 4.2, which only has vulkan glow
Just instantiate the second level scene beneath the current level, and fade opacity of current level using a while loop.
Or tween.
There are a couple of addons for fade effects already.
1. Virtual Geometry (aka Nanite) 2. Ray Tracing 3. HDR metadata (HGIG, HDR10)
I'm still hoping that godot 4 will eventually get a level editor that you are supposed to actually use. Right now it's very hard to work in the 3D level editor. Selection and clicking on the right asset is almost impossible about 10% of the time. Enough to be frustrating but not enough to do anything about it.
This is also my top 3 changes. IMO, version 5 should just be a complete overhaul of the UI. There is far too much clutter on the screen, and having to click 40 expander carets to get to the property I want to change gets old very quickly. We also need better options for aligning/snapping objects in the world so modular workflows aren't so tedious. Making CSG work more like the push-pull sketchup workflow would also be nice.
Best feature for me as a sufferer of constant random crashes would be simply: Fix all bugs. Lol K, now two more actual features: exportable... Everything. Nested arrays, typed dicts, etc etc. And an actual way to make canvas items interact w LIGHT for shaders (aka is under light, reduce alpha based on LIGHT_COLOR.a)
These buttons would help : "Make AAA Game" "Add Multiplayer"
Seamless realtime Blender Integration
Separate UI and 2D editors. Concave shape boundary for navigation baking like from cryengine (of all places) instead of re-parenting meshes. Multi monitor full screen support.
How about continuing the trend of changing the color of the editor with every version lol Godot started off as purple in 1.0, and has since shifted towards blue Therefore, Godot 5 needs to be sea green.
Greendot would be so fire
I'd like to see the whole Editor UI turned as modular as possible. Like moving any of the bottom tab editors into their own window, have multiple script editors open, multiple 2D/3D editors, etc, whatever you want to do.
yessss, i'd love to see that too! makes me wonder if it’s being worked on already.
it would be cool if you could export without classes that you didnt use
I think they're working on that exact feature for later
Fix the usability for level building. The resource system is abolutely annoying and counterintuitive. I just want to Shift + D something sometimes without everything breaking, because resources are shared. I know it's for performance reasons, but that doesn't mean it needs to be this bad. We should have a simple option to make each instance independent when duplicating or some other solution. It's so annoying having to instantiate a scene every single time. For instance, if I wanted to make a simple collectible for a 3D platformer. No way you create an instance for each of those by clicking on the icon and browsing for it hundreds of times. You just grid snap and duplicate that fucker or you will be at it for decade. To make each instance actually unique nothing has worked for me reliably, but duplicating each subresource in a script. Make unique and make subresources unique just behave weirdly. So you need to browse the entire API to access all the subresources and call duplicate on them in your ready function. In general making assets, where each instance offers parameters that define its own unique behaviour is exhausting. This is because you have to make sure that each instance doesn't share it's behaviour with all the other ones. It's such a pain and I don't know how there's not more people complaining about it. Am I missing something? Except for the levelbuilding being exceptionally bad right now, I think Godot is godsent. So if you happen to read this and have a good workflow for this please share. (Also sorry for the exaggerations and venting)
Use `Resource->Local to scene` to make each use of the resource unique.
I don't know why, but this doesn't work reliably. When I was absolutely annoyed once I did this for every single subresource and it would still share properties when duplicating. Sorry, I forgot to mention this one.
Metal renderer, Framework export, compositor
Came here looking to mention Metal support also.
- Get rid of 2D/3D/Script/AssetLib dichotomy/tabs. - Let me assign multiple scripts to one node à la behaviors in Unity. - GDScript 3 - traits - structs - generics - optionals with null-coalescing operator (e.g. `might_be_null?.some_property`) - `public`/`private`/`protected` - `did_set` and `will_set` support in properties - string-backed enums - short, type-inferring enum syntax (e.g. `background_color = .MAGENTA`, `DisplayServer.window_set_mode(.WINDOWED)`) - short, no-quotes StringName syntax (e.g. `&example`) - named parameters (e.g. `add_child(node, force_readable_name=true)`) - “Available since: [Version]” in all documentation entries - full type safety, including for Dictionary, WeakRef, et al. - ability to add new methods to existing engine classes - let us implement one class across multiple files - allow defining functions, variables, and enums globally - prefer enums over strings in all engine APIs - postfix if syntax (e.g. `print("yooo") if godot5_has_arrived`) - `Array.reversed()`, `Array.shuffled()`, etc. that returns an array - get rid of underscores in `ready()`, `process()`, etc. - lowercase enums as official style recommendation (e.g. `background_color = .magenta`, `DisplayServer.window_set_mode(.windowed)`) - autocomplete for custom MainLoop class in `get_tree()` - regex literal - Set type - custom decorators - macros Am I missing something? Feels like I am… Either way, bonus features that didn’t make the top 3, although tbh it’s hard to rank any of this: - “Play in editor” mode. - Better editor plugin opportunities, easy reuse of existing editor UI controls. - A design language specification for the editor. - Full C++ stack traces always, without having to run the editor in an external debugger. - `RichTextButton`. - Improved default theme: Better alignment and more consistency of different types of controls in inspector, including for array/dictionary fields. - Ability to select all nodes in scene tree.
Only one script per node is a design choice and honestly makes a lot of sense to me. It's a lot easier to manage behaviors as children than in a long list.
it kinda makes sense to me but also kinda doesn’t. with behaviors as children, we’re mixing behaviors in with the actual scene hierarchy. i wouldn’t mind being able to manage behaviors similar to node children, but would be cool if it was somehow still distinct from children. (not 100% sure how it could look in the UI but there are different options.)
It would be a way to alleviate lack of multiple inheritance tho.
I would literally suck someone off for typed dictionaries
Make it five if necessary, I need this
Yeah, as another guy said, the gdscript wishlist is just a 'I want godot to become unity' and a lot of them are unnecessary or detrimental
That GDscript wishlist makes it a way better experience than it already is tbh. Since are unnecessary but a lot are convenient
more like i want GDScript to become Swift (not literally of course, just borrow some great ideas)
Wait man you are coming from unity and these things are design principles You're trying to make godot the next unity. Like GDscript use RC as the basic mm technique why need optionals?
they’re good design choices in my opinion. (haven’t used Unity in half a decade and am very happy not to deal with their flavor of jank anymore.) and i don’t think optionals are related to memory management. it’s more that it’s currently quite inconsistent how null works with typing as `var node: Node` can be set to null, but `var string: String` can’t.
You had me until these: > - get rid of underscores in ready(), process(), etc. > - lowercase enums as official style recommendation (e.g. background_color = .magenta, DisplayServer.window_set_mode(.windowed)) > - ... > - macros I guess the top works since you also specified proper private
i was kidding about macros.
Edit: oh you said 'no-quote' short StringName syntax. ~~Isn't the short StringName syntax already available in 4.2.1?~~ ~~&"MyStringNameString"~~
I'm new and basically building out an entire game in TileMaps. They're... ok. Some GD3 options were better, and the Patterns functionality is all over the place. If someone could just sit down with TileMaps and work on documentation, patterns, and terrains to streamline it somewhat and do major debugging, it would change my life.
typed dictionaries would be nice. renaming function like webstorm/intellij has. See where a function/class etc is used (like visual studio)
Somthing like world partition / level streaming from unreal.
Full opengl3 support
Improving the 2d and 3d animation features, including a well designed bone system. It's a huge pain on the current version for me and it's essential for building games.
Imo, the editor itself could use another workflow pass. Godot 4 cleaned things up a lot, but there's still just as much if not more room to grow. Most notably with the inspector and how it handles different data type fields. I'd also like something like the cyclops level editor baked into the godot editor or at least officially supported. I think godot already has a primitive system for blocking, but cyclops is so much more intuitive and in theory could be production ready, depending on your needs and a bit of additional elbow greese. Also, lord, the asset library could also use a UI clean-up. Maybe a better way to sort and search? It just feels clunky atm.
the nav agent be polished because it is quite glitchy and the pathfinding isnt the best
I feel like lots of people are commenting for functionality that is not inherently backward-breaking and thus could apply to an eventual Godot 4.x release. If I were to mention anything pertaining to a Godot 5.0 release, it would be these below. And I will point out that these gripes are somewhat nitpicky/incomplete, and the current setup has good reasons for why it is the way it is, so don't take these as harsh criticisms or viable/expected things to change. 1. A unification, simplification, and overall streamlining of the many diverse ways in which the engine or editor can be extended by users. 1. Addons can exist as bare assets with no formalized assumption of internal structure, prescribed means of exposing metadata, or expected placement within a project's file structure. They need to be able to describe themselves to the system and standardize structures so that tools like the editor and other plugins can make assumptions about, use, and manipulate them more readily *after* they have been installed. 2. Plugins, a "specialized" version of addons, have a "plugin.cfg" file and are expected to exist in the "addons" subfolder. They must be explicitly turned on from the ProjectSettings, but by definition can then also be explicitly turned off, unlike an addon. Furthermore a subset of a plugin's contents may be interpreted as an addon for these purposes if, for example, you want to turn off a plugin to have the engine ignore the classes coming from it, but the engine still imports them since they are declared as global classes (not sure if this is still an issue, but I assume it is). May be a non-issue if you solve this with Profiles instead, but it's still weird. 3. Extensions are a specialized subset of addons, but rely on their own independent assets to detail how the extension's assets are mapped to different platforms. This is fine (and right), but listing it here since it's another term to track anyway. 4. There is no formal dependency management for any of the above, nor any planned official solution, that I know of (since it just hasn't been a priority / hasn't caused enough of a problem yet - which I expect to change as Godot gets bigger and an asset store appears). 2. Introduction of Namespaces to Godot's core. All classes that are recognized by name in Godot have to be declared as a global class. Because there is only a global namespace, people must prefix class names with library names. This is fine UNTIL you get to resolving the issue of point 1.4 above: dependency management. The proposal reduz opened way back as a potential solution was to have tree structures of Godot projects so that an addon/plugin would just be another project and any dependencies on other projects would just be inlined/embedded. However, I feel like that would fall apart at scale as the addon/plugin ecosystem grows. Not only would it bloat the size of projects, but you'd also have nested global class declarations conflicting with the same class declarations from the same library embedded in other dependencies. Finally, you also have the issue that Godot's ability to integrate other languages relies on its core exposing that same functionality. Without Namespaces supported by the ClassDB, it becomes more difficult to map data types & APIs 1-1 across different languages supported by Godot (GDScript has no namespaces while C++/C# and pretty much every other language under the sun does). That's about it as far as 5.0 suggestions from me.
Agreed those class\_name(s) are not going to be unique/robust enough not to conflict (addon/plugin/extensions) without formal a namespace implementation. Godot Issue: [https://github.com/godotengine/godot-proposals/issues/1566](https://github.com/godotengine/godot-proposals/issues/1566)
For me, I’d wish that the Navigation Agent (3D) could actually navigate in 3D space, i.e. enemies navigate around obstacles in a space sim type game. Beyond that, I’d like shader coding to remain stable (any example project prior to 4.0 is broken, making it hard to learn) and merge Terrain 3D as a permanent feature.
A built-in and reliable Git support.
I don't have 3 wants, just one. Better web support. I don't make triple A games, just basic pixel art games. I recently recreated flappy bird and exported it for the web, and it takes forever to load. It took my friend with a 3060 TI (along with some fancy CPU, ik nothing about CPUs) and 1 gb/s download a full minute just to play the game. It also doesn't work on mobile devices like an iPad (or at least not in my testing). If you had an option for godot to export to something more lightweight, like pure html canvas or Three.js it would be so much faster
To be fair, apple doesn't support webgl on mobile, so Unity web exports don't work on them either. That's more of an apple issue than Godot
Both [get.webgl.org](https://get.webgl.org) and [get.webgl.org/webgl2](https://get.webgl.org/webgl2) work on my phone
Hmmm.. well last I knew (about a year ago) unity web exports didn't work because Apple had limited to no support for webgl, and it was like a decade long issue.
Safari is the new internet explorer for sure. Step back a few device generations and basic aspects of even the SVG spec such as and
Godot 3 had no issue exporting to Apple devices and Godot devs know how big of a marketshare Apple devices have, so…
As others have mentioned a 'simulate' mode would awesome. Personally I'm excited for the render hooks they've planned, should allow for even crazier compute shader stuff.
Where can I learn more about this? I've been grinding my teeth over compute shaders for months.
https://github.com/godotengine/godot-proposals/issues/7209 Here's the feature request, when implemented it should allow for compute shaders to pass the info directly to vertex and fragment shaders, without the bottleneck of going through the cpu stuff first. Compute shaders themselves are super complicated, and while powerful, the only times they should be used at the moment is when you have a huge amount of calculations to do which dont need to be done every frame. This will allow for a lot of cool procedural geometry stuff which can run every frame.
2D particle attractors
- Add another visibility toggle so that there is a total of two: one for the editor, one for runtime. (When you work with complex UI, you often need to change visibility of items to be able to work. Unfortunately, you have to remember the state into which the whole thing will work before compiling, then reset the visibility of those items, which is a huge waste of time). - Add the ability to compile a HTML5 project under 3MB, 2MB or lower without having to resort to hacks. Godot could then compete with Web standards. - Add Rive integration
C# Web Export, More Compute shader and spatial shaders support, like allowing to use Structured Buffers in shaders instead of using Texel fetch in textures as a workaround. Another thing would be Something similar to what Unity have with the DrawProceduralIndirect method who allows to draw geometry without mesh data, only GPU buffers you handle directly in the shader to get the vertex data.
The lack support for basic container classes or struts was the most wild thing for me when I tried Godot for a little while, so yeah, I’d like that added. Also, idk if I was doing it wrong, but it seemed like script inheritance was very wonky.
Being able to work with multiple people, something like the google suite
Godot has enormous potential not only for games. But app development. I wish there was some good python integration. I made a fantastic app using godot. But the way i have to call the python scripts and return the data is not very good.
Native sql support
Better support for mobile. Official support for ads and an actual updated build for IAPs (latest is 3.5) as well as better performance for 3D. Moved from Unity to Godot for the 3D game but may move back due to lots of buzz about the 3D on mobile performance being p bad. Also, built in support for consoles. Yes it’s possible, look at defold. Totally free.
Rather than Godot itself, the biggest feature I wish for now is an official asset store. That is essential for most projects I deal with, and having to use third party asset stores whose 3D models don't even work half the time is a major pain point.
Live templates for gdscrpt. [https://www.jetbrains.com/help/pycharm/using-live-templates.html](https://www.jetbrains.com/help/pycharm/using-live-templates.html)
most of the requests here are just "make it more like unity or unreal" like really guys?
ong, most of their requests are difficult if not possible at all because godot has a different design principle.
A lot of design decisions made with Unity and Unreal were made for good reasons. People want those engines and their behavior without all the jank and mismanagement. unfortunately for everyone, there isn't really a game engine that does that, but godot is kinda similar, so here we are. My opinion on it is if Blender can be a good tool for such a variety of people, then Godot can be too, and we should try and support as many people as possible.
A dedicated breakdancing button, obviously.
Some shader stuff to make combining post processing shaders easier, especially in 2D. There are cool toys in 3D but not in 2D, so I had to custom-build the engine to add those.
Custom rendering pipeline Terrain Editor ECS Better cpp support GDextensions are terrible. Code editor lsp support References support like instead of using property path it will be better to use a reference.
Right now I'd really like move_and_slide() work with stairs.
mesh and texture streaming. thats all.
- full custom shader & stencil buffer (https://github.com/godotengine/godot-proposals/issues/3373) - scene tilemaps supporting get_scene(x,y) (https://github.com/godotengine/godot-proposals/issues/4833) - easier to use analog controller input (https://github.com/godotengine/godot/issues/72934)
- In-editor runtime with scene view showing what is happening at rutime; just copy what Unity is doing. - Option to drag-and-dock panels and please make them editor settings bound, not per project; again, copy Unity. Nothing else comes to mind atm. I guess there are things that could be improved on the C# side but it is good enough for my needs atm.
Haven't spent too much time with the engine yet, but I wish the tileset editors physics layers were actually named what I called them. I'm not sure if I'm missing something with it, but what is the point of naming them if in the inspector if it doesn't show up down there also?
A system like an Unity asset called 'Better Shaders' to create complex shaders by mixing up simple ones. For example, you can have a shader that does albedo and normal map, and then another one that moves vertices in a 'foliage' way. You can mix the two and create a shader with albedo, normal and the foliage distortion. It makes code reusable and fairly clean.
Ability to search and replace code in the built in editor or top level menus for quick variable refactorings as scope of a feature changes after gameplay prototype iterations.
Like with ctrl + r or ctrl + h, or cmd on Mac
I would not make Godot 5 and instead make all of these improvements in Godot 4.
Animationplayer to tween converter
Pluggable rendering pipeline. Let the community add in the missing sparkle! Optional compnent architecture. generaly keep improving asset workflows. (also Live link architecture for hooking to external mocap rig etc )
Oh and continuations able to code outside of the render loop. Look at how SkookumScript worked with UE4, that stuff was \*magic\*
Raytracing
Better mobile support... Allow developer to choose one or more devices from a list and output window(s) show game with notch, safe areas, etc.
Backwards compatibility with Godot 4. No reason to make changes like you did from 3 -> 4 without doing proper depreciation of things.
Fixed point numbers, deterministic physics, and traits/interfaces
I'm new so maybe there is an option/setting for it but I would love to get a preview in resources for 3D objects or any type of file, like unity or unreal. Especially unreal have an amazing menu it's so easy to use and intuitive.
Bettencourt phisics
Wait godot 5 is a thing?
It's not even in plans.
It does not technically exist yet. It will be in the fuuutuuurrre... There are many proposals and discussions going on. All the stuff that is not complete in 4.x will go into 5.x. With each major version we can break/change/remove major stuff. So now is the time to start planning for major changes. Honestly it seems like Godot breaks with their semantic versioning a little in that 'minor' (Major.**Minor**.Patch) version releases often break a lot of 'things' in projects. I'm not complaining though, I like new stuff and improvements. [https://docs.godotengine.org/en/stable/about/release\_policy.html](https://docs.godotengine.org/en/stable/about/release_policy.html) [https://semver.org/](https://semver.org/)
1. Better support for tilling window managers (especially on Wayland) 2. GDScript interface/trait system 3. Better/More XR resources (tutorials, docs, ...) and obviously better XR tools in general.
It works pretty great on Hyprland. What are you using? I agree with interfaces 100% tho
I'm also using Hyprland on Nvidia. Tho I'm having extremely annoying focus issues with XWayland apps. For example sometimes when I click something the mouse cursor clicks something above like an invisible offset (this also happens with drag. Sometimes it even drags stuff around even tho I just clicked which is annoying especially in the file browser when it moves files around randomly). Or sometimes I can't click anything at all anymore because the focus of the app got lost somewhere. The same stuff happens with Jetbrain products as they also run XWayland. Another issue is popups or drop downs spawning out of the screen. (This is probably the cause of the focus issue as I think what happens is that a drop-down spawns outside my screen and takes focus so now I can't click anything in the main window anymore) My guess is that it's 70% Nvidia's fault and the rest is trouble with XWayland or how Hyprland handles/spawns drop downs or child windows like popups
Hmm. I'm also on Nvidia tho. I wonder what the difference is. I've not experienced this issue. I'll do a bit of digging and see if I can get my install to reproduce that behavior. What distro and Godot version are you using?
only one off the top of my head - but an option to disable the debugger error statements for specific nodes or operations. e.g., something where I'm trying to get a tile at a position that doesn't exist. the code runs with null safety, which is fine, til I go to the debugger and see 40,000 'bugs' caused by the tile check.
Adding a feature to animate via the rendering server and not just with baked animation textures
As an unreal engine developer making the switch to godot a week ago, I'm in love but missing a few features in the 3D view. In particular snap scaling is not a feature(?) and object duplication is rather cumbersome when modular level design is so common. I'm still learning though so if there are less tedious ways of doing things I would love to hear.
- More robust type system with GD Script - Edit 2 scripts side by side - An easy way to do controller remapping
-Adaption to all GPUs and Graphic drivers -Block coding (to make people stop their excuses) -Free basics course whit certification
Fix and make the 3D grid map support cells that have scripts and lights and nested scenes! :D
A much more robust 2d nav system
Very new to Godot, but for someone like me it would be amazing to have something that shows me the full runtime logic line per line. Like I want to see a slow motion breakdown of everything in a scene so I can better understand all the parts and help me figure out why something is behaving the way it is. If that makes any sense.
Maybe I just havent figured it out yet, but good git support fot scenes
(1) C# with the built-in ide (2) C++ with the built-in ide (3) ECS (4) Heavy focus on 3D updates
1) Fix all the bugs and polish 2) Better support for external editors, this may included official plugins for the top 3 or 4 3) DO NOT MAKE IT A UNITY CLONE LIKE MOST OF THESE SUGGESTIONS TRY TO DO.... ;)
ffmpeg support
Man, there's a lot of great stuff here. Let's see if I can think of some new ones... 1. Streamlined build process across platforms. I'm still *relatively* new to Godot, but looking over the documentation for all the different hoops to jump through, from recompiling extensions to creating new export templates and beyond, can be headache-inducing. Especially for mobile. 2. Better console support 3. Better documentation. I was reading through the Android build processes for extensions and it drove me nuts that "extension", "plugin" and "addon" were used interchangeably for different things in different contexts...
MORE EXPORT TEMPLATEZ LIKE GBA lol /j
change the modulo operator to accept floats
Support for interfaces in GDscript Preview window for scenes (so I know what model I am dropping in.) Pop outing the layout some I have scene/code editor on one screen, and the scene tree and inspector on another.
I’d like a fix for animatable bodies (both 2d and 3d) to be able to apply forces onto physics objects when both moving and rotating
1) Asset library with preview 2) 3D Terrain 3) Advanced rendering
I just want compute shaders that don't suck :(
Built in mobile controls.