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.

                                        DaveTheCoder The closest that I'm aware of is the Blog:
                                        https://godotengine.org/blog/
                                        If that doesn't satisfy your definition of "road map",

                                        Well, no, unless there is a specific post about the road map. What is in there are progress notifications and some notes about the immediate future but not a clear long-term route of path and direction.

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

                                          It looks to me like a very uninformed, fairly belligerent opinion, which usually prompts me to respond with disdain. The comment about the author fixing everything really made me roll my eyes.

                                          1. Uncertain console support

                                          This quote is really all you need to know:

                                          In all, supporting consoles properly is very costly and beyond the possibilities of Godot as a project to do so.

                                          If consoles are really your target, not just a pie-in-the-sky goal, you should probably look elsewhere. Free software cannot, by definition, address that.

                                          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?

                                          There are other explanations. A data structure might be used because it makes things easier when supporting different platforms.

                                          Or it might be used because no one has actually demonstrated that changing it would make a significant difference. It's easy to say that you should always use this or that, but if you don't show actual tests under realistic conditions, it's just an opinion.

                                          It might even be used because it's a major change, and the people with the most experience are busy fighting fires at the moment, and they don't have time to do something that might cause even more.

                                          You might also consider that these explanations are valid.

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

                                          I've never encountered a piece of software that actually stuck to their projected schedule. That includes software with dozens of paid programmers. A road map for a project built by thousands of volunteers with different agendas would be guesswork at best. Anyone could produce that for you.

                                          Godot has a very uncertain future. So what? Unity's not looking all that steady these days either. The difference is, I've got the godot codebase on my computer. If all the godot contributors beamed up to Alpha Centauri tomorrow, I could keep using godot, legally, indefinitely. That calms any trepidations I might have.

                                          ...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"

                                          That's not how I interpreted the quote, but ok. What "way" do you think we're defending? Free software? It's not a defense to say that this is how volunteer projects work; it's just a statement of fact.

                                          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?

                                          You could look at the links on the godotengine.org site to answer this, unless you don't believe them. If that's the case, why would you believe anyone here? The project developers don't generally hang out here, so what other information are you hoping for?

                                          The main project decisions are made by people with the authority to accept pull requests to the godot github. Whatever politics may be involved, it really boils down to that. If you make a change and submit a pull request, it might be accepted, even if it never occurred to any of the core developers.

                                          Godot is just a collection of software, and the developers are just people who added to it. The actual software development is not as organized as a company, and you're going to be disappointed if you try to think of it like that.

                                          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)

                                          Production ready for what? You've already read people say that 4.1 isn't stable, and you should stick with 3.x. You've heard people say that you'll never make a AAA game with godot. Then again, someone might manage it any day now, for all I know.

                                          The only person whose opinion you should trust on that would be someone who's actually made a popular game of the type you're interested in making, with godot. That's likely to be a small set of people, who probably have better things to do than hang out on the forum.

                                          If I was paranoid and didn't trust your stated motivation, I'd guess that either you were looking for someone to trash godot with you (not likely). Or you were padding your post count (meh). Or you wanted someone to show you a golden road to getting the problems you have with the engine fixed. (As far as I know, it doesn't exist.) Fortunately, I'm not that paranoid. 🙂

                                              Is it super wearing to see how we are focusing on what is wrong in the critical thoughts. Cherry-picking sentences that we can nullify and focus only on that ones. It is not my intention to be right in what I say, it was not my intention to say "everything is right" in this article when I shared it here. My intention is: "Is there something here we can reflect on, and learn from?". And focus on this, ignoring the rest, or even expressing our gratitude that someone took so much time writing it and saying: "Hi, thanks for your thoughts, this and this we have been working on it already, on this I don't agree, can you extend?. This other is important and helped us to reflect, we will back to you".

                                              duane If consoles are really your target [...] Free software cannot, by definition, address that.

                                              I am not expecting Godot to have an "export to console" button in-house (for the reasons that have been mentioned). I am just expecting that a project created with Godot can be ported to the consoles, even if it is done by a third-party service, and that there is not any intrinsic technology dependency that makes this impractical. A good answer will be to see examples of Godot 4 projects successfully ported to consoles.

                                              I am reading here, and I am not finding any example of a successful Godot 4 ported game (I see a show case in youtube but don't know if they are Godot 4). I read this though:

                                              That being said, we support console porting for Godot 3 and 4, GDScript or C# (other lang support also possible). We might be even doing a port of a Godot 2 title soon, but we'll see 🙂

                                              Also some notes about technical limitations:

                                              You can use compute shaders if you like. All current platforms support it nowadays, but it might not be a good idea on the Switch as it would severely affect performance. This would require further assessment in order not to have problems later.

                                              duane If consoles are really your target, not just a pie-in-the-sky goal, you should probably look elsewhere

                                              I really hope this is not right. It may be, right now, "a pie-in-the-sky goal", but definitely I would love to have once a game in the Switch. And it is possible as shown in the show case above. But a lot of things have changed in Godot 4 and I would like to know if it is still doable in an affordable way, and what are the caveats.

                                              duane You might also consider that these explanations are valid.

                                              I do

                                              duane I've never encountered a piece of software that actually stuck to their projected schedule

                                              My neither (25+ years software architect experience, 8+ years CTO), believe me, I know this by heart. This doesn't undermine the importance of having one.

                                              duane A road map for a project built by thousands of volunteers with different agendas would be guesswork at best

                                              The fact that the project has thousands of volunteers with different agendas makes the importance of having a long-term road map even more important. It may be a guesswork but it makes common objective visible.

                                              duane What "way" do you think we're defending?

                                              The "we are doing everything totally right, God blesses us, and anyone showing a slight critique thought should be expelled when not burned to the ground" way.

                                              duane Godot is just a collection of software, and the developers are just people who added to it. The actual software development is not as organized as a company, and you're going to be disappointed if you try to think of it like that.

                                              I understand this. I am a very satisfied user of many open-source software, including Godot. The fact it is open source doesn't compete with a proper PR review organization. Of course, things can be leaking, it happens in all software projects, but I was curious about the infamous "inexperience-based" data structure decisions. That if they are true, they should be spotted by an experienced developer doing the code review. Again, this has been clarified.

                                              Production ready for what?

                                              We are fooling ourselves if we are ignoring the obvious flaws of Godot 4. We just have to take a look at the change log in 4.x versions.

                                              If I was paranoid and didn't trust your stated motivation, I'd guess that either you were looking for someone to trash godot with you (not likely). Or you were padding your post count (meh). Or you wanted someone to show you a golden road to getting the problems you have with the engine fixed. (As far as I know, it doesn't exist.) Fortunately, I'm not that paranoid

                                              Or you can just have a positive thought about my intention. I am a humble hobbyist (so far) indie developer who is very happy to have found Godot (almost 1 year ago, coming from 2 years with Unity), and who likes it a lot. And who is worried about the orientation may have been leaning towards, and who is interested to know if the community is healthy (humble and self-critique) and has a warm attitude towards newbies and that the decisions and the long-term goal resonates with me.