After quickly falling in love with Godot and several months of serious use I'm having to give up on it due to Godot's lack of funding to fix its more than 6000 open issues on Github:
https://github.com/godotengine/godot/issues
Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021:
https://github.com/godotengine/godot/issues/45628
When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze".
Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.
I found and fixed a small Godot bug, starting from zero knowledge of the engine code, in about a day and a half free time. It's really not hard to just patch stuff yourself if you're comfortable with C++.
Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
How do you people feel about the Godot object and lifetime model? I found it hard to test my code because of how objects are tied to the tree, that emulating the tree isn't easy during testing, and that initialization during live use is different than if you instantiate manually, making it hard to rely on a constructor, since you might not be able to use it live.
I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.
It’s something that’s pretty nice once you’ve implemented these lifecycles a bunch.
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug
It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate.
I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.
I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?
GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.
I still rely on GDNative for really performance critical systems though.
Former professional game dev getting into Godot recently for fun and maybe for hire.
What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?
Godot is effectively not accepting contributions, and masquerades as open source. List comprehension, one of the most sought-after features and requested by dozens of people, is repeatedly undermined by maintainers, because they happen to dislike the syntax. Godot offers nothing similar in terms of processing arrays, so it makes any code involving them ugly and more complex than it needs to be.
There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project.
The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
I find it a bit untrustworthy when someone frames a language design issue as representative of the way the project is run. List comprehension is a feature that comparatively few languages have, and I can easily imagine that the GDScript team has other things they consider a priority.
For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
Why would you want list comprehensions in a game engine? It's just sugar to make looping over a list or array look more functional but not particularly useful in a game.
I have to agree with @pycbouh. While a lot of things python does is good, I really don't like list comprehension, especially when it becomes nested.
numbers = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
print([n for sublist in numbers for n in sublist if n % 2 == 0])
# > [2, 4, 6, 8]
Not very readable, and you save what, 3 lines? Not worth.
Some might enjoy writing code like that, others might dislike it. The current lack of such functionality doesn't hold anyone back that much and therefore doesn't get prioritized. It might get introduced in the future, but when there is still lots of discussion for and against adding it instead of how best to actually implement it, you know that the time has not yet come.
Personally, I enjoy both LINQ in C# and Streams in Java, perhaps more than a one liner. But again, that's a personal preference and the opinions are often split about syntax related questions.
GDScript went through a major rewrite for Godot 4, so they avoided adding lots of new features in the meantime and focused on getting it stable.
The rewrite should make it easier to add new features now.
Also the design of Godot values ease of use and simplicity to an great degree. They are very conservative about adding new features and I think they have a point there.
Also list comprehension is an odd example, I wouldn't really rank it that highly when it comes to features I miss. More annoying for me is not having traits or interfacse. You are expected to go full in with "everything is a node" and are a bit limited when it comes to more advanced abstractions. I understand why they are reluctant adding them though and I respect their commitment to keeping things simple.
Is there a reason you wouldn't use a game engine to create general purpose cross-platform apps? Is it cumbersome to create textual, structural interfaces (e.g. a twitter clone, google sheets clone, or an ecomm checkout flow)?
You certainly could. You would probably run into a lot of issues in areas that games don't care about that much like multiple windows, smooth window resizing, fancy text layout and input, fast initial load times, matching OS themes and widget behavior, low resource usage at idle, copy/paste/drag/drop, software rendering, etc.
Well, the Godot editor is actually a Godot applications, they are dog-fooding their own UI.
So it is absolutely possible to create complex applications with it.
Games engines are generally not used for apps, as games are optimized differently to apps. Games need to run smoothly at a high refresh rates at all times while apps can not hog all CPU power but need also be optimized to not needlessly drain the battery. This is no an issue in Godot specifically because it offers a low processor usage mode though.
So yes, Godot is a decent solution for apps. Only real issue is support for accessibility. There are screen reader plugins but if you want to do it properly, you might be better of with an app using native elements.
Flutter is essentially just that. Its graphics are built on Skia Graphics Engine and the tooling is designed to cater for UI interaction needs instead of gaming needs.
Apple's own UI libraries use their graphics engines too(SpriteKit, SceneKit), unfortunately supported only on Apple platforms.
Yeah, likely you won't get as many tools to help with structured GUIs and expected hooks to the operating system commands that your user will want to use, but if what you're looking for is unstructured, quirky, or artsy content, possibly the way old school flash sites wanted to be, then it's certainly a fun option for cross platform apps.
But for web, that could be too much for browsers to handle. Godello loading at webbrowser has only some time watching at spinner, when you have fast Internet connection, loading about 10 MB of code, WASM etc.
But when I tried to save Godot 3D game example to HTML5, and load it to webbrowser, Chromium etc browsers can not handle that much data.
Some webbrowser users have slow connections. If there are many users, they start to complain webpages loading too slowly. With Godot everything is browserside, and generated with save button, from that it's hard to move anything to serverside.
But if you instead code frontend and backend with Javascript, it's possible to move more of frontend Javascript code to run serverside.
The thing I am working on is intended to be useable to also build GUI apps and command line tools.
The tech that is often used in game engines, especially related to GPU support but also memory management and GUI structure is often 10-100x faster than what is commonly used elsewhere.
Text rendering can be just as nice as any desktop app, it is not trivial but not rocket science either, and quite a few smart guys have been doing nice work in this field.
My blunt review of Godot after using it for about 3 weeks, it's the community's Unity.
But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible.
It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why.
Why not use Python, why, why not use? I don't know, haxe.
Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people.
All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen.
I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice.
Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal,
However, if you want to just make games for the sake of making games.
> Why not use Python, why, why not use? I don't know, haxe.
Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
They do small, frequent software updates, it's called minor and patch versions. But when you're making a tool for creative professionals you don't want to release major versions of the tool every year, because these professionals care more for consistency and using their current skillset more than shiny new features in the next version.
Their users. Game engines are big and complex and the foundation of building a big and complex product. You can't have your foundation introducing fundamental changes on a regular, unpredictable basis.
Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.
A lot of games are fragile, and have poor or no test coverage. So if the engine changes, it can break or have all sorts of unforeseen consequences. So you want to be building in an engine that isn't changing.
They do, it's called the master GitHub branch. But generally if you're shipping something that doesn't get updated as often (you don't want to update via Google Play or Steam as often as a website would) you'd like a little stability...
Friends in the industry all say it's a nonstarter that it does not (and will not) have cross platform support, as much as they hate Unity. Godot's official stance on it is that you should hire a team to port it for you lol...
I think you mean it doesn’t include “console support” not “cross-platform” support, and as it is very much cross-platform across desktop and mobile targets.
And your friends are clearly just working in a different way than the many people who Godot is a good fit for.
Even beyond hobbyists and new game developers, there are plenty of business models and artistic visions that don’t need a console port or that can indeed outsource it once there’s some financial momentum.
Their official stance is that they can not release the code for consoles because of NDAs. You won't find any open source engine with console support because of that. They are hoping that consoles loosen up and open source their SDK.
Godot has excellent cross platform support, just not for consoles that requires NDA's and stuff to develop for. This can't be helped on the Godot side but is the fault of the console manufactures who make the rules.
Also paying a third party to port a game to a different platform is not really that uncommon, even in the Unity world. I remember the Dev of The First Tree did exactly this.
It is not like you can just put your game in the PlayStation-store even if you use Unity or Unreal. There is a process to it and your game has to fulfill certain standards.
A good strategy is to first publish for PC and see if the game gains any traction. If it does, well the console port will pay for itself. If not, you saved yourself lot's of work.
If you're long on the games industry we are probably in the last generation of game console architecture. Everything is going to be Windows or Linux boxes with PC hardware next gen.
I could see Nintendo bucking this trend but they have enough IP to be their own island.
It might be smart for Godot to punt; it lets them go faster than Unity and catch up
I'm not a game dev, but I read you can deploy to desktop (across multi os), mobile and web. That sounds pretty multi platform to me. What am I missing?
churnedgodotdev|3 years ago
Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.
TillE|3 years ago
Godot is not beautiful modern code or anything, but it's definitely not inscrutable layers of spaghetti which require deep expertise. It's very readable and compiles reasonably fast.
herewulf|3 years ago
I've been funding it (a small amount monthly) for a long time now. I wish it had existed about 15 years ago in college when I had lots of time on my hands for toying with game making.
strictfp|3 years ago
I can't remember the exact details around this, since I only used Godot for a couple of jams and the last time was a year ago. But I was wondering if others have had the same reaction, perhaps this could be fixed? I love the engine in general, but this thing irked me.
b33j0r|3 years ago
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug
blamestross|3 years ago
On a more serious note, I do expect test-ability isn't a high customer priority for Godot. Godot is self-hosted, maybe check how they run their tests?
omoikane|3 years ago
TillE|3 years ago
I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.
nemothekid|3 years ago
I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?
Mikeb85|3 years ago
This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++.
In fact, I'd argue C++ is far better than a bolted on C#...
drmidnight|3 years ago
I still rely on GDNative for really performance critical systems though.
opyate|3 years ago
I asked someone on Twitter about this the other day [0], and I'm genuinely curious: what is it about C# that makes game development serious?
0. https://twitter.com/LegatXyotic/status/1552219744723402756
fezfight|3 years ago
https://github.com/dotnet/sdk/issues/14556
somehnacct3757|3 years ago
What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?
_aavaa_|3 years ago
deworms|3 years ago
There was even a pull request implementing this feature opened, but they claim the assigned maintainer just didn't have the time to review it yet (over 5 years!). One person can effectively stall all progress out of spite. That's no way to run an open source project.
Just look at this discussion: https://github.com/godotengine/godot-proposals/issues/2972
seba_dos1|3 years ago
The way contributions are accepted (or not) is completely unrelated to the project being open source or not. It's always up to the maintainer to decide whether a feature should be merged or not. Open source projects are not popularity contests.
detuur|3 years ago
For a programming language, 5 years is not at all an unusual delay when we're talking about an extension to the basic syntax.
rng_civ|3 years ago
Don't like how they run it? Fork it. The maintainers have ZERO obligation to merge your PRs, especially when they don't actually agree with it.
Mikeb85|3 years ago
KronisLV|3 years ago
I'm not sure about this one, I can understand why someone might agree with some of the arguments about list comprehension making readability worse, like stated in this comment: https://github.com/godotengine/godot-proposals/issues/2972#i...
Some might enjoy writing code like that, others might dislike it. The current lack of such functionality doesn't hold anyone back that much and therefore doesn't get prioritized. It might get introduced in the future, but when there is still lots of discussion for and against adding it instead of how best to actually implement it, you know that the time has not yet come.Personally, I enjoy both LINQ in C# and Streams in Java, perhaps more than a one liner. But again, that's a personal preference and the opinions are often split about syntax related questions.
cardanome|3 years ago
The rewrite should make it easier to add new features now.
Also the design of Godot values ease of use and simplicity to an great degree. They are very conservative about adding new features and I think they have a point there.
Also list comprehension is an odd example, I wouldn't really rank it that highly when it comes to features I miss. More annoying for me is not having traits or interfacse. You are expected to go full in with "everything is a node" and are a bit limited when it comes to more advanced abstractions. I understand why they are reluctant adding them though and I respect their commitment to keeping things simple.
devmunchies|3 years ago
modeless|3 years ago
cardanome|3 years ago
So it is absolutely possible to create complex applications with it.
Games engines are generally not used for apps, as games are optimized differently to apps. Games need to run smoothly at a high refresh rates at all times while apps can not hog all CPU power but need also be optimized to not needlessly drain the battery. This is no an issue in Godot specifically because it offers a low processor usage mode though.
So yes, Godot is a decent solution for apps. Only real issue is support for accessibility. There are screen reader plugins but if you want to do it properly, you might be better of with an app using native elements.
mrtksn|3 years ago
Apple's own UI libraries use their graphics engines too(SpriteKit, SceneKit), unfortunately supported only on Apple platforms.
phreack|3 years ago
xet7|3 years ago
For example, here is kanban PoC made by someone:
https://github.com/alfredbaudisch/Godello
But for web, that could be too much for browsers to handle. Godello loading at webbrowser has only some time watching at spinner, when you have fast Internet connection, loading about 10 MB of code, WASM etc.
But when I tried to save Godot 3D game example to HTML5, and load it to webbrowser, Chromium etc browsers can not handle that much data.
Some webbrowser users have slow connections. If there are many users, they start to complain webpages loading too slowly. With Godot everything is browserside, and generated with save button, from that it's hard to move anything to serverside.
But if you instead code frontend and backend with Javascript, it's possible to move more of frontend Javascript code to run serverside.
stephc_int13|3 years ago
The tech that is often used in game engines, especially related to GPU support but also memory management and GUI structure is often 10-100x faster than what is commonly used elsewhere.
Text rendering can be just as nice as any desktop app, it is not trivial but not rocket science either, and quite a few smart guys have been doing nice work in this field.
lbotos|3 years ago
999900000999|3 years ago
But it's just not there yet, things which take seconds in Unity take minutes in Godot. Or are just impossible.
It's not done yet, it's going to probably be done in either late 2023 or 2024. Godot 4 needs to come out, and they need to add mono. I've never been more frustrated with a programming language before I found Godot script, just why.
Why not use Python, why, why not use? I don't know, haxe.
Even Godot's creator tried to calm everybody down, you're comparing what's basically a souped-up hobbyist project by maybe two or 300 volunteers to professional products by multi-billion dollar companies of tens of thousands of people.
All that said, I am fighting through Godot right now and I'm having the most fun with game development I've had in years. I try to armory as well, which is not nearly as advanced as Godot, but has the most welcoming community I've ever seen.
I Feel like, back when I first learned a program when I work with Godot. With mono, which is on 3.5 which is very nice.
Too long. Read, if you want to make a commercial product, you're still stuck using Unity or Unreal,
However, if you want to just make games for the sake of making games.
Godot.
herewulf|3 years ago
Neither Python nor Haxe (presumably) have built-in types for vectors, quaternions, and matrices. Quite nice convenience features. Though I'd rather write in a lot of other languages than GDscript.
mkw5053|3 years ago
M4v3R|3 years ago
colechristensen|3 years ago
Releasing big versions means your game can use version X.Y with only bugfixes to the engine added as updates and you don't have to make fundamental changes when the game engine changes.
jibe|3 years ago
Mikeb85|3 years ago
prox|3 years ago
jayd16|3 years ago
That said, I would say a lot of changes can be breaking because backwards compatibility is a much lower priority then code speed or size.
marcodiego|3 years ago
jmcgough|3 years ago
swatcoder|3 years ago
And your friends are clearly just working in a different way than the many people who Godot is a good fit for.
Even beyond hobbyists and new game developers, there are plenty of business models and artistic visions that don’t need a console port or that can indeed outsource it once there’s some financial momentum.
BudaDude|3 years ago
cardanome|3 years ago
Also paying a third party to port a game to a different platform is not really that uncommon, even in the Unity world. I remember the Dev of The First Tree did exactly this.
It is not like you can just put your game in the PlayStation-store even if you use Unity or Unreal. There is a process to it and your game has to fulfill certain standards.
A good strategy is to first publish for PC and see if the game gains any traction. If it does, well the console port will pay for itself. If not, you saved yourself lot's of work.
See also: https://godotengine.org/article/godot-consoles-all-you-need-...
somehnacct3757|3 years ago
I could see Nintendo bucking this trend but they have enough IP to be their own island.
It might be smart for Godot to punt; it lets them go faster than Unity and catch up
genpfault|3 years ago
* Export to desktop platforms: Windows, macOS, Linux, UWP, and BSD.
* Export to mobile platforms: iOS and Android.
* Consoles: Nintendo Switch, PlayStation 4, Xbox One via third-party providers
[1]: https://godotengine.org/features
DigiDigiorno|3 years ago
unknown|3 years ago
[deleted]