Wow. I was through this very interesting conversation in Reddit, and I read the whole blog post of one of the links mentioned by OP:

(If it is down try the webarchive copy.)

If you are interested in the community philosophy and the future of Godot, It is really worth reading. It is painful and merciless, but very interesting.

I really appreciate a self-critique attitude. I think it is important to keep the eyes open, be humble, and learn from the perspective of others. I wish the maintainers and the leadership of the Godot dev team are willing to listen and to see the critique with objectivity.

It used to be said: "The smoke is seen earlier by the people outside, than the fire by the people inside"

    d2clon It is really worth reading.

    This is not worth reading. If you value your nerves, your mental health and your connection to reality. There is a lot of rambling and lies.

        Tomcat There is a lot of rambling and lies.

        This is not adding anything valuable to the conversation if you don't explain in which points there is rambling and in which points are lies

            Tomcat i can't validate whats a lie or not, but there is rambling, and i don't like rambling.
            i'll read a more brutal and shortened version without the nice-guy padding like: "it's not necessarily their fault" or "this is actually a good thing", if it exists.
            otherwise, there's a reason i study away from institutions: politics and drama. this looks like both.

            d2clon It used to be said: "The smoke is seen earlier by the people outside, than the fire by the people inside"

            its hard to see the fire burning out my eyes. for brevity, whats the top 3 reasons i should be scared for my career?
            (i can't tell what's going on in your avatar photo, but it looks funny)

                  I'm not sure why, but the original link seems to be down. Probably a technical issue. Fortunately, I found a copy, which I will post in the hope of helping this erudite writer out, and to allow us to make fair use of such valuable information.

                  I have to disagree with Tomcat's judgement, this post is well written. It uses a tried and true formula -- a paragraph saying, "This is only my opinion, of course, and I could be wrong", followed by several saying, "But I'm not." This is an excellent format for a political speech.

                  Wait... It's meant for computer professionals... oh. Moving on.

                  The post covers several good points about godot that I agree with. It's free software (not open source -- lots of things are "open source" without being free as in freedom). It's being actively developed (probably a good thing... maybe). It's got "many active and helpful users... for a minority engine". That's us! It's been used for games, and it's easy for beginners. Nice.

                  I do have a few issues with "the bad" and "the ugly".

                  "Poor performance... I have not profiled Godot nor worked on a complete enough and representative project in Godot to observe performance issues firsthand." Nevertheless it needs serious optimization. Hmmm.

                  Hypothetically, what would you do if one of your esteemed colleagues said, "I haven't done any profiling, but we need to rip out all of the existing data structures and use better ones for speed."? I'd probably recommend that she take a short nap.

                  "Poor Documentation" and "Directionless Development". I wonder how long this writer's been dealing with free software. All free software projects suffer from these -- yes, even gnu and linux. When you pay someone, you get to tell them to work on the things you think are important. When they volunteer their time, they're going to work on the things they think are important. Surprisingly enough, this sort of democracy frequently works.

                  "I am willing and able to fork the engine, this area is what I did for money for years. I believe I can fix everything I’ve seen so far." Wow. Of course, you're only talking about the "problems" you picked out, and I don't see you actually doing it, but good on ya.

                  "Unprofessional Messaging" I read that as, "I went to r/godot and they weren't nice to me." Moving on.

                  "Inexperienced and non-professional developers" Ummm... non-professional is implied by "free software" -- at least they're non-professional godot developers. Inexperienced? Oh, you mean that the godot developers haven't made professional games. Well out of several thousand, that's probably true, at least statistically.

                  Then things start to get kinda nasty at the bottom. "technical ass" "hideously unoptimized" A bit redundant? "puts the ass in assets" "Built by hobbyists, FOR hobbyists."

                  The last, I like, and fully agree with. Over the last week, I've been wondering why the unity expatriates stopped at godot. I love the project (mostly), but I can't imagine what some of them see in it.

                  "poor documentation" is annoying, but as @duane said, it's free software. the documentation that exists is already way more than they were paid to write.
                  i know i would not document as thoroughly as they have if i was donating my time.

                  The fact that Godot is even considered as an (imperfect) Unity alternative speaks volumes of its qualities, knowing how large is the discrepancy of development resources spent so far on each engine.

                  If this documentation is "bad" or "annoying", well, then what do we call the Unreal docs? I don't know if anything changed with UE5 but at least for UE4 a lot of the documentation was clearly written because they had the obligation to say "oh but of course, everything is documented!" but they forgot to mention that a lot of it wasn't meaningful and just existed because there had to be something.

                  The Godot documentation is really, really good in comparison. At least what I saw of it. It's, you know, actually helpful.

                    Toxe

                    DISCLAIMER:
                    i have never touched a real game engine besides Godot :)
                    disregard my opinions as you will

                      d2clon This is not adding anything valuable to the conversation if you don't explain in which points there is rambling and in which points are lies

                      I believe you have already been answered quite clearly and understandably about the ramblings and lies.

                      But I have a question: in what exactly did you see the value of this trash and why do you propose to discuss it?

                      The fact is that all the answers you have been given do not carry any sacred revelation. It's all perfectly obvious to anyone who has even slightly immersed themselves in the subject. For this reason, I did not decipher my thesis, limiting myself to a summary. But if any of the authoritative and worthy regulars of the forum asks, I will certainly give a detailed answer.

                      The fact that he shamefully deleted his essay can be considered an admission that his position is untenable.

                          I am a huge rimworld fan (about 1500 hours in) so I was most interested in what the creator Tynan Sylvester had to say. He first started looking at it 5 years ago and found that it was almost ready for use in an indie game on the scale of Rimworld (his comments below in the spoiler). He really values C# and Godot erring away from trying to tackle advanced rendering features or other advanced features that look pretty but probably will be underutilized by the average godot user. I agree with his remarks although I strongly believe by now Godot could easily tackle the task of duplicating Rimworld.

                          Click to reveal Click to hide

                          Tynan here. Right on.

                          Allow me to ramble for a few moments.

                          To set the stage - I actually did a round of engine research 18 months ago. I looked pretty hard at SDL2 and OpenTK, making some small unfinished projects with each of them. But they really didn't satisfy. Tons of missing stuff, especially GUI-wise, in OpenTK. Both had C# support, but it didn't have the feeling of a first-class feature.

                          Unity works - but it's got some real problems. It's quite constricting; the engine is very opinionated (and its opinions are not well-thought-out) and it tries hard to not let you escape the way it wants to work. Also, the way they simply cut off my perpetual licenses from updates post version 2017 really left me with a bad taste. I don't want to buy a new copy every year for every developer; I don't want modders to be weirdly constrained by the lack of a proprietary editor. And while they're constantly adding crazy whiz-bang features that look great in demos (but which absolutely should never be used by 99% of real indie teams), their code is janky as hell. I don't want to be constantly dealing with weird Unity issues that they refuse to fix for years, or which pop in and out of existence over and over through multiple updates.

                          So I'm still looking for something that'll work.

                          My main concern with Godot at this point is that it seems to be trying to be all things to all people. It's trying to appeal to the "my first game" student market, via visual scripting and GDScript and so on. But it's also trying to hit AAA features like advanced rendering and a built-in particle engine.

                          This lack of decided focus manifests as IMO mis-spent effort on things that almost no serious indie should be using (advanced rendering features which look pretty in demo videos, visual scripting), while deprioritizing things that absolutely every indie should be using (C#).

                          From what I've read the C# support still quite rough. Good first-class C# support is a must. We need a language that's very productive, quite fast, bug-resistant (e.g. statically typed, no globals), mature, portable, has libraries, and handles very large codebases. Only C# fits.

                          GDScript looks nice for really really tiny games, but it's obviously never going to scale close to anything like RimWorld; its performance is way too low and the code isn't nearly safe enough. Most indies beyond the "my first game" level should not be using this.

                          C++ is good if you're making a hyper-optimized engine code. But productivity is really low for C++ since it's so unbelievably arcane. Very few indies should be touching C++ IMO.

                          C# covers the needs of 90% of indie work for serious projects:

                          For "my first game" level coders, learning C# is ideal; the language has great error messages, tons of documentation, and is very productive.

                          For mid-indie developers like me, C# is ideal because of the excellent balance of productivity, speed, libraries, and scalability.

                          For AAA developers, you need C++, but these people are irrelevant for Godot because they'll be writing their own engine or using something Unreal-tier anyway.

                          I don't think, at the indie level, that it's a good idea to be trying to compete with big companies in terms of graphics. So from my point of view all the whiz-band shader and particle features are NOPs at best. Making use of such features really requires a big team of artists; the Venn diagram of studios who might use Godot and studios with big artists is very close to zero.

                          I really hope the Godot team doesn't get sidetracked in working on advanced AAA rendering features, nor on "my first game"-level ease of use stuff.

                          This engine will blow up when small-but-professional indies start using the engine to make really popular games - Games on the tier of Factorio, Don't Starve, RimWorld, Hotline Miami, Stardew, Terraria.

                          I really want to do that (if indeed I am capable and lucky enough to succeed) but the engine needs to cover the bases to make that possible. Currently it's close but not quite there.

                          We don't need animations or particles or PBR or visual scripting or networking. We just need the fundamentals right. We need really solid C# support, with debugging and all, and we need the engine to be generally bug-free. I hope to use it one day!

                          I really don't get the java c# bias. It's not that great a language, even if you're willing to shovel in the extra libraries to run it. It's faster, but what are you doing with that speed that isn't built in to the engine? If you feel godot's physics aren't good enough, for goodness sake, don't rewrite them in c# -- find an engine with better physics. Same for pretty much anything else.

                          About the only advantage I see, apart from that, is the amount of code out on the net that you can plagiarize. Not a huge recommendation.

                          Sadly, I expect that the godot project will flip its stance on languages to "we still support gdscript, when possible" within a year or two, once a few core developers leave. And, I'll be off looking for another project. 🙁

                          d2clon hmm imho core dev will begin to listen to the mobs, when this forums URL is listed on godot official "community" nav page...again...
                          To err, human, to forgive, divine.
                          Not to mention ths forums or its members never committed a crime against godot, just some controversial POV or some personal speculations.

                            I have read all the comments above, and my understanding of the general response is that this article is not worth to be taken into consideration. It has been attacked from all corners with insistence.

                            I have a bitter feeling about all this. Is everything in this article completely wrong? Badly written (rambling?)? Nothing to learn from it? Not a single takeaway pearl that can be useful?

                            Or are we just defensively counterattacking to what is no more than a personal opinion?

                            So this is what I’d like to call a “professional gut feel”. Keep in mind this is only that - a gut feel - and you shouldn’t base critical business decisions off of my gut feel divorced from the context of your project and your team.

                            I am going to use the same structure as the author and disqualify myself before I make the assumption: I don't know anything about the deep core of Godot or its community structure, but... I am sure there are at minimum 1 or 2 things interesting in this article and worth taking into consideration and reflecting on them.

                            But how I see the community reacting is in a unified way to discredit the author. My thought now is: Is this community open to critique thinking?

                              d2clon I have a bitter feeling about all this. Is everything in this article completely wrong? Badly written (rambling?)? Nothing to learn from it? Not a single takeaway pearl that can be useful?

                              Instead of talking about "the article", why not pick a specific idea that's in the article and discuss that?

                              One item mentioned in the article deals with performance problems reported in this issue. Some posts were recently added at the end that indicate fixes or improvements to those problems.
                              https://github.com/godotengine/godot/issues/23998

                                  Tomcat But I have a question: in what exactly did you see the value of this trash and why do you propose to discuss it?

                                  Assuming your question is genuine and your intention is not just to discredit me to the ground. I have indeed some questions. I'll focus on the controversial parts:

                                  The Bad

                                  1. Uncertain console support

                                  • To which consoles I can port a Godot 4 project?
                                  • If yes, are there dramatic compromises to be made due to the Vulkan rendering dependency?
                                  • Successful examples of Godot 4 projects ported to consoles?
                                  • Is C# supported when porting to consoles?

                                  I go to this article: https://godotengine.org/article/godot-consoles-all-you-need-know/ and (after some rambling 🙂) I see the recommendation is to use external services. I go to the first one (https://lonewolftechnology.com/) and I see:

                                  Looks like a bit outdated. No reference to version 4?

                                  2. Poor Performance

                                  • Does the author have a point regarding the use of nonoptimized structures in the core code?
                                  • If so, is this the signal of an un-optimal code review politic, or maybe the lack of experienced developers taking care of code review?

                                  3. Poor Documentation For Some Features

                                  I agree that the documentation sometimes lacks clarity or is misleading. But I also accept it because I see its evolution and I see it is going in the right direction.

                                  4. General Directionless Development

                                  • Is it true there is no clear road map for the project?

                                  The Ugly

                                  1. Unlimited technical risk

                                  I don't understand this part. So no opinion 🙂

                                  2. Unclear and occasionally unprofessional messaging

                                  With all my respects. This thread is an example of what this part of the article says.

                                  ...the trend of criticising other engines, and other companies’ strategies, and entire software patterns is… noticeable

                                  In the sense of: "defend our way in an unquestionable way"

                                  It is not the first time I try to start a conversation about something that can be interpreted as a critique of Godot and I am quickly burned down to the ground. I try to overcome it and think it is just a small minority of the reactionary portion of the community, but I am sad about not seeing clear signs of a more open-minded and self-critique section.

                                  About the @LillyByte comments

                                  These are all very harsh thoughts, I understand they can awaken defensive attitudes. But again, I'm sure there is something there the community can use to reflect on (if it is able to overpass the first "I attack you back" impulse)

                                  • Is any of the performance bottlenecks enumerated here worth attending? if so, why are they not attended?
                                  • Is it true there is not a clear group of experienced people making the main project decisions? and that is only the leader (Juan) making all the decisions? Is it true the leader is not friendly with delegating?
                                  • Is it true that Godot 4 can't be considered production-ready? (it is a personal opinion of course, but we can honestly reflect on this point)

                                      d2clon Does the author have a point regarding the use of nonoptimized structures in the core code?

                                      Did you read the github issue I linked? It addresses that.

                                          d2clon Is it true there is no clear road map for the project?

                                          The closest that I'm aware of is the Blog:
                                          https://godotengine.org/blog/

                                          If that doesn't satisfy your definition of "road map", then the answer is: There is apparently no road map.

                                              DaveTheCoder d2clon Does the author have a point regarding the use of nonoptimized structures in the core code?

                                              Did you read the github issue I linked? It addresses that.

                                              Fair enough clarification about this point. Cristal clear here.