I seriously doubt it. Game engines are, first and foremost, designed to provide a 2D or 3D graphics environment and input handling, they don't typically have the richness of UI components that you would expect for building a desktop app. Godot is no exception here, its UI components are very dated and limited in comparison what modern web-based applications can do. Furthermore, Godot specifically is limited to a single window (apart from popups) last I checked.
The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on.
I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.
> Game engines are, first and foremost, designed to provide a 2D or 3D graphics environment and input handling, they don't typically have the richness of UI components that you would expect for building a desktop app.
Games are full desktop applications, ad often have full-featured GUIs overlaid on top of a 3D-rendered playfield.
Certain game genres, especially strategy games and RPGs, regularly implement full UI toolkits, with floating windows, list and table widgets, combo-boxes, toolbars and menu bars, etc. Some games have a superset of standard desktop widgets in order to account for standard UI functionality along with very game-specific needs.
Look at Paradox's grand strategy games for some examples of this. Some people refer to them as "spreadsheet games" because of the complexity of game data and statistics exposed through application-like UI controls.
Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either.
> You should be using C# for stuff like that. Ignore the Godot API, just use .NET 8.
I use the non-dotnet version of Godot, I'm not happy with the confusing licensing Microsoft has put around .NET [1]. If anything, I'll go the gdextension route, but it hasn't been painful enough yet to do that. For a UI you couldn't ignore the typing system since you'd need to feed the data into it and read from it a lot.
.NET is licensed under MIT[0]. There are additional concessions[1] regarding the code that used to be proprietary specifically to make all the Mono bits to be legally sound.
> Could you give me a link please? The Godot editor itself can't do multi-window and I haven't found a clear explanation on how to do that in the games either.
The other problem with Godot specifically is that every thing is tied to GDScript/the Godot typing system (yes, even the C# and gdextension APIs) and you need to deal with its inconsistencies. I'm currently implementing something as simple as a schema validator (think JSON schema) and it's nightmareishly tough in comparison to any other language I have implemented this in. And then we are not even talking about the almost universal lack of error handling in a large portion of the built-in functions, or really silly things like that opening a TCP connection apparently requiring active polling. I could go on.
I love Godot, it's super simple to build game-related things with, but holy macaroni do I wish they had thought things through just a little more when they implemented them. I would never want to build a data-heavy desktop app in Godot.