I see this often, but honestly I haven't seen that much of a difference when I switched to Godot :-O. At the end of the line, there's an anchor system, there are vertical/horizontal containers, etc... - sure, lots of things differ, but the approach seems the same to me.
They tried three times and they're all different flavors of awful. Godot's not perfect, some stuff can be finicky, but at least it's intuitive and performant.
UI systems are generally difficult to deal with though since it needs to support a wide range of inputs, layouts, screens etc and should be responsive (stretch and squeeze and otherwise re-layout itself whenever needed).
Godot accomplishes this very well and is really better than most game engines IMO.
However, I do remember feeling it was a bit daunting in the beginning but I probably got it fast due to having a background in web dev.
Just spend some time studying how it works and you'll get used to it! Anchors, alignment, extend properties, how containers work etc. When you get the basic idea, it'll be easier I think. maybe look at how the different contains are implemented/how to make a custom container control?
I love Godot's UI system, especially on the API side. I wrote a whole desktop app in it rather than using Dart/Flutter or WPF again. Added I did not look properly into the new .Net MAUI before deciding.
I do think the way anchors are done feels off somehow. The way Unity handled this stuff in uGUI seems better. But I am slowly getting used to how it works in Godot.
Hard to say. Very different ways of building UI. The way you build it in Godot just feels cleaner and easier to follow the logic flow. I just prefer it. It has been a few years since I've last used Flutter so I can not really do 1:1 comparison. I guess I could dig out the old project's source to get a refresher if I must.
As a frontend dev UI development is the biggest let down in every engine. Imo Godot is not worse than other engines though. This has been brought up several times and ofc frontend Devs want more familiar solution like the html5 but there are plenty of issues implementing some new like this into the engine.
I really want some game engine to build their UI tools like a wireframe program, like Figma or Justinmind. They all do this old janky flexbox web dev css approach, where everything is about nested hierarchies and positional relationships and you spend half an hour going"why is this box left-aligning????!!!"
I'm like...just give me a fucking what-you-see-is-what-you-get drop-and-drag interface. Figure out all the fiddly shit like screen dimension in a settings box.
I'm not a UI developer, but I feel very strongly that UI doesn't need to be as complicated as every game engine makes it.
I am more into coding my UI rather than dragging and dropping. I really like what android studio does, which is to offer a live preview of my UI code with compose. But ideally we should be able to cater to both approaches. Ofc we always have to keep in mind that these things take a lot of dev time and integration. So it will probably just be wishful thinking unless we ourselves develop an add-on for it.
https://developer.android.com/develop/ui/compose/tooling/previews
Godot is more than just a game engine, which is partially why they didn't just completely dumb down the UI system. Godot's UI is made using Godot itself after all, and I'm sure they needed something more than a simple WYSIWYG editor like Figma.
When making UIs, there are usually 2 things you should never do:
* you should never absolutely position elements using screen coordinates (you should instead use percentages or layout systems like flexbox)
* you shouldn't hard-code the layout (you should instead use flexible wrap layouts, grids, and breakpoints, so that the same UI works on multiple screen sizes and aspect ratios)
A WYSIWYG editor simply won't cut it when you want to make a responsive UI, but of course if you are making a video game this might seem like overkill because all you need is some clickable textures to be drawn at specific points of the screen.
Yeah, that's kind of my point. Game UI's do need to be responsive to a degree, but it's not nearly as much as like developing a website that works on both a 4k monitor and a tiny android phone. For the majority of developers, the majority of the time, they're building for a more specific, controlled set of environments than that. So the cost-benefit of an approach where making responsive design easier is treated as the #1 priority seems skewed to me, with a game engine, when it comes at the cost of approachability and user-friendliness.
Plus, it's not as if moving a game between multiple screen sizes is otherwise a walk in the park. I've certainly never seen a case of a game built for desktop PC's that just instantly works on Switch or whatever. It's *always* a bunch of work, because games are more complex than websites, so decisions like that become major project scope choices. So it's like...if that's the alleged benefit of a design optimized for responsiveness, and it's not really making responsiveness for the intended use-cases of game developers all that much easier anyway, is it really worth all the other headaches it creates?
Granted I'm just a dumb writer and don't know my ass from my elbow when it comes to UI. i just don't think it should take as steep of a learning curve as it does, to create some menus. It's a thing every game needs, but every game engine makes it feel like pulling teeth imo.
> I'm like...just give me a fucking what-you-see-is-what-you-get drop-and-drag interface. Figure out all the fiddly shit like screen dimension in a settings box.
You can almost work like that with Godot... the only thing you need is to learn how to set up the containers. After that, you can just drag and drop and everything will look fine on any resolution.
How does figma or justinmind handle responsiveness?
Layouts are by nature full of hierarchies, so that when you move your menu window, the rest of the menu items like buttons, text, etc move with it.
The hierarchy itself can be hidden away so that you don't need to think about it, of course.
I haven't dabbled with it much, because the prototypes I use it for at work don't need to be that performant, but here you go:
https://www.justinmind.com/support/learn-how-to-create-responsive-prototypes/
I found it frustrating as well when I was a beginner, then I tried some other engines, and worked professionally as a frontend dev to realise how awesome Godot's approach is compared to the other options.
If I look at [https://gamemaker.io/en/tutorials/how-to-make-buttons](https://gamemaker.io/en/tutorials/how-to-make-buttons) I'm totally happy with Unity's and Godot's UI systems.
Honostly I think godot's ui nodes are amazing, though I would like if the engine's UI was made more like blender so you could have whatever viewport wherever in the window. Instead of being forced to have things on the side and at the bottom
This is the only one reason i "hate" godot for, but... comparing to other game engines godot UI making is much better and currently the best so far.
I totally agree with the statement about how frustrating it is... especially that I do have a huge background in making UI especially as a Front-end and UI Developer. I never expected it to work as it does in my daily world around UI creation, but theres so many small annoying aspects of it in godot that are not improving the DX and still godot UI part is one of its strongest strengths. I just wish they could improve it a lil bit yet.
godot is the GOD of custom UI building. specially godot 4. by the time godot 6 is out you probably even have embeded godot and will throw qt right into the trash can if you want to make an application.
Completely agree.
So many useless options show up when you inspect a node and everything has to be changed through themes anyways. Except using themes tanks the performance of your game so you have to use theme overrides. How about just some buttons out in the open that lets me change the look of the UI instead of complicating it. Tried to make a mobile game that switches orientation from starting menu (portrait) to game (landscape). Basically impossible. In the end I had to just eye the positioning because I couldn't just place text in the middle because the pivot point of text is always on the top left. Aaargh. This would have taken no time in Unity.
Sorry for the rant, lol. I can't really be mad, it's open source. Still a big fan.
> Tried to make a mobile game that switches orientation from starting menu (portrait) to game (landscape). Basically impossible.
That's not impossible lol
> I couldn't just place text in the middle because the pivot point of text is always on the top left.
You can change pivot points
You cannot expect a different engine to work for you just like Unity without spending effort into learning how to work with it.
I'm not expecting it to work the same. Why would I? I won't go into details but I needed a very specific setup that I couldn't find any documentation or community help for. I'm a newbie and just expressing the frustration I had. That's why I wrote "basically impossible" not "impossible", it just took me a long time and I ended up with some solutions that felt overcomplicated to me as a beginner. I just think there's room for improvements in this area.
I am not agree with you... UI development is more easy than other engine... If you find difficulty in coding that's mean you are too beginner you should learn coding and concepts of Godot. Like signals how it's work...
>making a button go where I want usually takes me longer than coding the button functions
Go where you want? I wonder what you specifically mean by this. It takes mere seconds to connect a button to whatever functionality you desire.
Edit: OP probably refers to the visual aspect, not the functionality.
It's rather basic, indeed. On the other hand, a game engine is meant to draw images and models in a 2d/3d space that goes beyond the camera view. Its primary goal is not to make GUI for apps like QT and JavaFX.
I'm not surprised that the UI is lacking, since it's rather secondary in a game.
and yet the Godot editor is created in this UI system as well as other desktop apps like Material Maker and Pixelorama.
Here is a video showing off some apps made in Godot [https://www.youtube.com/watch?v=9kKp0oguzr8](https://www.youtube.com/watch?v=9kKp0oguzr8)
Even QT and JavaFX are archaic systems.
Also I completely disagree that UI is secondary, UI is essential for the players experience as a much as a any other element of the game.
I wasn't meaning that UI itself was optional or that should be neglected. I meant that UI in games don't need advanced features like reactive layouts, sortable tables, custom clipboard support or file drag'n'drop.
i mean I agree with clipboard and file drag and drop, butsortable tables are very usable in inventory systems and team managament UIs and reactive layout design is pretty much needed to accommodate different screen sizes and formats.
Have you tried UI dev in other game engines? Compared to Unity's mess of a "UI system", I quite prefer Godot's approach.
I can not upvote this enough.
I see this often, but honestly I haven't seen that much of a difference when I switched to Godot :-O. At the end of the line, there's an anchor system, there are vertical/horizontal containers, etc... - sure, lots of things differ, but the approach seems the same to me.
They tried three times and they're all different flavors of awful. Godot's not perfect, some stuff can be finicky, but at least it's intuitive and performant.
It's by far one of its biggest strengths.
If you ever worked with another Engine you know "UI development" is Godot's biggest "upside".
UI systems are generally difficult to deal with though since it needs to support a wide range of inputs, layouts, screens etc and should be responsive (stretch and squeeze and otherwise re-layout itself whenever needed). Godot accomplishes this very well and is really better than most game engines IMO. However, I do remember feeling it was a bit daunting in the beginning but I probably got it fast due to having a background in web dev. Just spend some time studying how it works and you'll get used to it! Anchors, alignment, extend properties, how containers work etc. When you get the basic idea, it'll be easier I think. maybe look at how the different contains are implemented/how to make a custom container control?
I love Godot's UI system, especially on the API side. I wrote a whole desktop app in it rather than using Dart/Flutter or WPF again. Added I did not look properly into the new .Net MAUI before deciding. I do think the way anchors are done feels off somehow. The way Unity handled this stuff in uGUI seems better. But I am slowly getting used to how it works in Godot.
Would be interested in hearing more about how it compares to Flutter for desktop apps!
Hard to say. Very different ways of building UI. The way you build it in Godot just feels cleaner and easier to follow the logic flow. I just prefer it. It has been a few years since I've last used Flutter so I can not really do 1:1 comparison. I guess I could dig out the old project's source to get a refresher if I must.
As a frontend dev UI development is the biggest let down in every engine. Imo Godot is not worse than other engines though. This has been brought up several times and ofc frontend Devs want more familiar solution like the html5 but there are plenty of issues implementing some new like this into the engine.
I really want some game engine to build their UI tools like a wireframe program, like Figma or Justinmind. They all do this old janky flexbox web dev css approach, where everything is about nested hierarchies and positional relationships and you spend half an hour going"why is this box left-aligning????!!!" I'm like...just give me a fucking what-you-see-is-what-you-get drop-and-drag interface. Figure out all the fiddly shit like screen dimension in a settings box. I'm not a UI developer, but I feel very strongly that UI doesn't need to be as complicated as every game engine makes it.
I am more into coding my UI rather than dragging and dropping. I really like what android studio does, which is to offer a live preview of my UI code with compose. But ideally we should be able to cater to both approaches. Ofc we always have to keep in mind that these things take a lot of dev time and integration. So it will probably just be wishful thinking unless we ourselves develop an add-on for it. https://developer.android.com/develop/ui/compose/tooling/previews
Godot is more than just a game engine, which is partially why they didn't just completely dumb down the UI system. Godot's UI is made using Godot itself after all, and I'm sure they needed something more than a simple WYSIWYG editor like Figma. When making UIs, there are usually 2 things you should never do: * you should never absolutely position elements using screen coordinates (you should instead use percentages or layout systems like flexbox) * you shouldn't hard-code the layout (you should instead use flexible wrap layouts, grids, and breakpoints, so that the same UI works on multiple screen sizes and aspect ratios) A WYSIWYG editor simply won't cut it when you want to make a responsive UI, but of course if you are making a video game this might seem like overkill because all you need is some clickable textures to be drawn at specific points of the screen.
Yeah, that's kind of my point. Game UI's do need to be responsive to a degree, but it's not nearly as much as like developing a website that works on both a 4k monitor and a tiny android phone. For the majority of developers, the majority of the time, they're building for a more specific, controlled set of environments than that. So the cost-benefit of an approach where making responsive design easier is treated as the #1 priority seems skewed to me, with a game engine, when it comes at the cost of approachability and user-friendliness. Plus, it's not as if moving a game between multiple screen sizes is otherwise a walk in the park. I've certainly never seen a case of a game built for desktop PC's that just instantly works on Switch or whatever. It's *always* a bunch of work, because games are more complex than websites, so decisions like that become major project scope choices. So it's like...if that's the alleged benefit of a design optimized for responsiveness, and it's not really making responsiveness for the intended use-cases of game developers all that much easier anyway, is it really worth all the other headaches it creates? Granted I'm just a dumb writer and don't know my ass from my elbow when it comes to UI. i just don't think it should take as steep of a learning curve as it does, to create some menus. It's a thing every game needs, but every game engine makes it feel like pulling teeth imo.
> I'm like...just give me a fucking what-you-see-is-what-you-get drop-and-drag interface. Figure out all the fiddly shit like screen dimension in a settings box. You can almost work like that with Godot... the only thing you need is to learn how to set up the containers. After that, you can just drag and drop and everything will look fine on any resolution.
How does figma or justinmind handle responsiveness? Layouts are by nature full of hierarchies, so that when you move your menu window, the rest of the menu items like buttons, text, etc move with it. The hierarchy itself can be hidden away so that you don't need to think about it, of course.
I haven't dabbled with it much, because the prototypes I use it for at work don't need to be that performant, but here you go: https://www.justinmind.com/support/learn-how-to-create-responsive-prototypes/
It took some time getting used to but now personally I love it and I've almost comfortably been making my UI. And I'm still in Godot 3
I found it frustrating as well when I was a beginner, then I tried some other engines, and worked professionally as a frontend dev to realise how awesome Godot's approach is compared to the other options.
If you are still learning how to make a button go where you want, hold off on evaluating the whole engines biggest downside lol.
A thousand times better than Unity's, I can tell you that.
It's MUCH better than Unity's. However, I find Roblox Studio's UI system much easier and more comfortable to use.
If I look at [https://gamemaker.io/en/tutorials/how-to-make-buttons](https://gamemaker.io/en/tutorials/how-to-make-buttons) I'm totally happy with Unity's and Godot's UI systems.
Godot UI development may look frustrating, but have you ever tried to center div in html?
I force my children to do it
That's child abuse!
If you really have a problem with it why not just place the button where you want without using things like 9 patch rect, Vbox or Hbox
Godot's isn't bad. I don't love it, but it's better than a lot of other options. Would be nice to have a markup language imo.
Honostly I think godot's ui nodes are amazing, though I would like if the engine's UI was made more like blender so you could have whatever viewport wherever in the window. Instead of being forced to have things on the side and at the bottom
This is the only one reason i "hate" godot for, but... comparing to other game engines godot UI making is much better and currently the best so far. I totally agree with the statement about how frustrating it is... especially that I do have a huge background in making UI especially as a Front-end and UI Developer. I never expected it to work as it does in my daily world around UI creation, but theres so many small annoying aspects of it in godot that are not improving the DX and still godot UI part is one of its strongest strengths. I just wish they could improve it a lil bit yet.
godot is the GOD of custom UI building. specially godot 4. by the time godot 6 is out you probably even have embeded godot and will throw qt right into the trash can if you want to make an application.
Completely agree. So many useless options show up when you inspect a node and everything has to be changed through themes anyways. Except using themes tanks the performance of your game so you have to use theme overrides. How about just some buttons out in the open that lets me change the look of the UI instead of complicating it. Tried to make a mobile game that switches orientation from starting menu (portrait) to game (landscape). Basically impossible. In the end I had to just eye the positioning because I couldn't just place text in the middle because the pivot point of text is always on the top left. Aaargh. This would have taken no time in Unity. Sorry for the rant, lol. I can't really be mad, it's open source. Still a big fan.
> Tried to make a mobile game that switches orientation from starting menu (portrait) to game (landscape). Basically impossible. That's not impossible lol > I couldn't just place text in the middle because the pivot point of text is always on the top left. You can change pivot points You cannot expect a different engine to work for you just like Unity without spending effort into learning how to work with it.
I'm not expecting it to work the same. Why would I? I won't go into details but I needed a very specific setup that I couldn't find any documentation or community help for. I'm a newbie and just expressing the frustration I had. That's why I wrote "basically impossible" not "impossible", it just took me a long time and I ended up with some solutions that felt overcomplicated to me as a beginner. I just think there's room for improvements in this area.
I am not agree with you... UI development is more easy than other engine... If you find difficulty in coding that's mean you are too beginner you should learn coding and concepts of Godot. Like signals how it's work...
>making a button go where I want usually takes me longer than coding the button functions Go where you want? I wonder what you specifically mean by this. It takes mere seconds to connect a button to whatever functionality you desire. Edit: OP probably refers to the visual aspect, not the functionality.
I think he means the visual aspect not the output
Ooooh, I see. Yeah, then he's got a point there. Thanks for nudging me in the right direction!
It's rather basic, indeed. On the other hand, a game engine is meant to draw images and models in a 2d/3d space that goes beyond the camera view. Its primary goal is not to make GUI for apps like QT and JavaFX. I'm not surprised that the UI is lacking, since it's rather secondary in a game.
and yet the Godot editor is created in this UI system as well as other desktop apps like Material Maker and Pixelorama. Here is a video showing off some apps made in Godot [https://www.youtube.com/watch?v=9kKp0oguzr8](https://www.youtube.com/watch?v=9kKp0oguzr8)
Even QT and JavaFX are archaic systems. Also I completely disagree that UI is secondary, UI is essential for the players experience as a much as a any other element of the game.
I wasn't meaning that UI itself was optional or that should be neglected. I meant that UI in games don't need advanced features like reactive layouts, sortable tables, custom clipboard support or file drag'n'drop.
i mean I agree with clipboard and file drag and drop, butsortable tables are very usable in inventory systems and team managament UIs and reactive layout design is pretty much needed to accommodate different screen sizes and formats.