I think I've figured out why the above comment has stuck in my craw enough to make me type up five separate long paragraph posts and delete all of them. all of those complaints can be boiled down to, "the project lead isn't focusing on stuff that helps me specifically. that makes it bad", or at the very least that's the vibe I'm getting.

which is extra confusing in an open source project, because you can do what the godot 2.1 user up there actually did and fix stuff on your own. it's not ideal certainly, but it's a tradeoff. you can go to a bigger engine and have a potentially bigger chance the engine devs will fix it for you but if they don't you're completely stuck. can't do it yourself, just gotta hope and pray.

your only other option is to make your own engine from scratch. which admittedly could be the best approach for some projects, but I'm guessing it would be faster for most to fork godot into something they tailor into their needs.

I won't say godot's the best engine overall but in terms of open source even godot 3 never had much competition. before godot most OSS games used love2D, which isn't even an engine. in that light being compared to unity in the first place is a major win.

edit: there is one potential competitor in bevy, but that's on version 0.11.0 and only started existing in the last three years. and that's literally all I can think of for actual OSS engines that could compete with godot

I do agree with your conclusion, but saying "clearer project direction is better" feels like a tautology.

    samuraidan fix stuff on your own

    Unfortunately, that's the main argument that Godot followers tend to employ. "Do it yourself" is generally not a helpful piece of advice when addressing concrete issues with Godot. To understand this specific aspect of Godot, you can refer to the Freedom chapter. End-users expect a working product; they don't anticipate fixing core engine issues themselves, as the majority of game developers are not engine developers.

    samuraidan but I'm guessing it would be faster for most to fork godot into something they tailor into their needs

    This is also how some game developers venture down the road to becoming engine developers, only to realize later that they're slowly abandoning the development of their own game due to the numerous issues left to fix in the engine. πŸ™ƒ

    samuraidan you can go to a bigger engine and have a potentially bigger chance the engine devs will fix it for you but if they don't you're completely stuck

    Those "bigger engines" usually provide several ways to do one thing out of the box, which alleviates the majority of potential roadblocks. The availability of extensive customization options makes it nearly impossible to encounter issues with sufficient expertise. Thus, saying that one is completely stuck using those engines is an exaggeration, especially when it's possible to workaround bugs and limitations. Also, while it's true that all engines will have bugs and limitations, they vary in degrees.

    samuraidan in that light being compared to unity in the first place is a major win.

    Reminder: the lead developer of Godot said:

    Friendly reminder that Godot does not compete with Unity or Unreal. It’s not a commercial product and it does not take part of that market.

    See also Godot's Simplicity topic at Godot forums for more context.

    samuraidan saying "clearer project direction is better" feels like a tautology.

    I don't understand why you perceive this as a tautology. Could you please explain your viewpoint? It's obvious that having a clear project direction is always desirable. However, I wanted to emphasize that Godot core developers explicitly state that Godot has no clear direction and are essentially proud of this fact, see a recent video interviewing Juan and others.

    Quote from Juan Linietsky, lead developer of Godot:

    The interesting thing about Godot is that I don't really have like a super clear vision about it...

    If I were to lead a project like Godot, I would never take pride in stating that I have no clear vision for it. Hearing this from a project lead sounds weird, to say the least. Don't you think?

      Xrayez If I were to lead a project like Godot

      Who's preventing you? Make your project and show how it should be.

      I read all your replies.
      First, about "fix it yourself" - I am not an engine developer, I have no idea how to fix something in engine. Over the years I tried, but looking at source code I was just met with infinite nesting of functions and couldn't understand what's happening and where issue is.
      There is a bug with physics that haunts me in all my projects because I try to use physics everywhere: https://github.com/godotengine/godot/issues/44589 and somewhere, some godot contributor or developer said that physics requires to be rewritten completely to fix that issue, because of end frame calculations or something, I'm not sure, it was a long time ago and I'm not a low level programmer.

      My experience with godot for years have been me whining and complaining (btching) about broken features and borderline mental breakdowns, because almost everything I try is broken. You want to use Gridmap for 3d that Godot markets as a unique in engine feature? Well too bad, because Gridmap is not really compatible with editor, because it wont have collision untill runtime, so your interaction with it is pain. Not an issue? Okay, how about you need to restart editor each time you add a new tile? The thing you make every day multiple times a day because you're making a game? Oh well, too bad because it's a known issue from 2019 that still hasn't been fixed. (It maybe is fixed in G4 but I see G4 as completely separate non related to me engine, because it is unrelated, I cannot port projects to it).

      I created this post because of pure frustration, I hate working with this engine, it might be too emotional or something but it is a truth. This engine seems like fake tech demo engine. It's easy to create something with 30 minutes of work to showcase shaders or something, but that's about it. Everything else just doesn't work ever.

      I wish this engine had 3 working features and was a good tool instead of 30 broken features you cannot rely on at all. I tried making so many genres and I don't remember single thing that works.
      .tscn nested scenes? Broken, saving scene doesnt save it sometimes or doesnt update all files. If you have open world game and have your world chunks saved as .tscn files, it'll be pain to work with because you have to save them and then edit one in separate scenes without having clear picture of whole world level or lighing, because its in parent's node. Or better, in my STALKER like project, when I open location scene, editor crashes each second time I open a scene. It works fine first time but second nah.

      File system is broken, it cannot update files and digging old versions from cache sometimes. You cannot edit materials, because they'll be updated in editor but not in game or on disk. Or something its other way around - they're updated but editor shows old version, it's a mess.

      Graphical stuff is broken too, roughness is very weird. What does specular is still a mistery to me. I don't know about gamedev graphics enough so I wont write lots of text here, but I think it's least broken part of this engine. Also, funny that each time I encounter weirdness with graphics, people tell me to write my own shader instead. People tell me to fix and write stuff myself so much I'm not even sure would I even need an engine if I was able to do all that myself?
      Oh and I guess that counts there too. Why are there 2 material slots for each mesh instance? It's so frustrating, it doesn't make logical sense to me as a user. I wanted to change materials for a mesh recently, so instead of just doing that, I have to write code, does meshinstance has materials, or does meshinstance's .mesh has? .mesh has? Well too bad because you now have to iterate all surfaces for that mesh to get materials, because there isn't a function to get all materials for .mesh. There is in MeshInstance but it's diferent material slot...

      Physics are incredibly broken. It's awful. Things falling under ground, weird area/rigidbody interactions where collisions are ignored even with continous collision
      Ragdolls are atroscious, most of the time body falls apart in two while legs are still being animated, and to make it work properly you have to have root motion bone otherwise no ragdolls in game for you.

      Animation player is broken, it cannot even smoothly play walking animation, for real you either have a chop after last frame to first frame, or you wait in last frame for one animation frame before going to first frame.

      I don't know, these bugs are already engraved into my muscle memory and I cannot even remember all of them, it's awful, they're infinite and in everything. Name me any part of G3 3D and I'll tell you what bug there is.

      Experience with godot has been absolutely awful.
      It needs a direction, it cant be lake wide puddle deep because it doesn't work. They shit out gridmap - it doesn't work. The shit out physics - it doesn't work. They shit out animations - it doesn't work. The fcking AnimationTree had broken connection lines that you couldn't grab at zoom!=100% for years, sometimes it feels like they didn't even care.

        I know about that quote where they aren't trying to be unity. what I'm saying is that people even thinking to do that in the first place makes it head and shoulders above any other open source engine. I don't think UpBGE or Solar2D ever even had to say that in the first place because no one was making those comparisons to start with.

        I guess my frustration with all these complaints is twofold: this engine is still ridiculously young comparitively, unity's been around for eighteen years and unreal's been around since 1998. of course it's going to be more buggy than they are. if it's still as buggy in ten years and not as stable as unity is now, then I'll take those comparisons more seriously.

        second is that a lot of them are people wanting godot to be something it isn't and never said it was. it's not trying to be Triple-A game engine. those exist already.

        and yes, I'll admit "fix it yourself" isn't really a solution so much as it is a bandaid in most cases, I'm just sitting here flabbergasted that so many people are confused why this ten year old isn't an adult already.

        oh and just so it doesn't sound like I'm cult of godot or whatever, if you really are encountering so many bugs and problems that it's impossible to make your game and you really can't make it work... switch engines. there's nothing wrong with that.

          Favkis Oh and I guess that counts there too. Why are there 2 material slots for each mesh instance? It's so frustrating, it doesn't make logical sense to me as a user. I wanted to change materials for a mesh recently, so instead of just doing that, I have to write code, does meshinstance has materials, or does meshinstance's .mesh has? .mesh has? Well too bad because you now have to iterate all surfaces for that mesh to get materials, because there isn't a function to get all materials for .mesh. There is in MeshInstance but it's diferent material slot...

          This one in particular sounds entirely like lack of knowledge/understanding on your part. The material slot on the mesh is for a default placeholder material or what you can think of as fallback. For the most part you should be using the MeshInstances material override slot.

          But in case of, lets say, an end user running your game on hardware where your override material fails to compile a successfully executable shader(because maybe the graphics driver is buggy or that vendors GPU claims certain API support but doesn't implement it properly or fully) the fallback material on your mesh can be used to display something, maybe not great looking or ideal, but at least something.

          If you do choose to use the meshes own material slot like that I'd recommend keeping the shader of the fallback material as simple and basic as possible. Or alternatively ignore it's existence altogether.

          Hey, despite your frustration, I must say you have some cool projects going; congrats on the great work!

          I'm not sure if those are isolated issues or not (as I haven't experienced those bugs you describe). But I would advise you to ask the community about the things you need to solve. See if others have found solutions or workarounds or could help you understand how certain features work. This way, it's constructive and can lead to better productivity.

          People sharing the same passion tend to help each other out.

          I understand you are frustrated. But just putting out complaints (with no shaped questions people can help you solve) and negativity tends to fuel more negativity and rarely solves anything.

          Favkis Name me any part of G3 3D and I'll tell you what bug there is.

          As already said here β€” the engine is young. And one of the reasons for creating version 4 is that some things are easier to solve by rewriting from scratch than trying to fix. Yup, that's the cost of an open architecture and a small team.

          But version 3 will get updates. It's a work in progress.

          Your videos are a great demonstration of the engine's capabilities. If the developers had familiarized themselves with them, it's quite possible that they would have listened to your questions carefully.

          "fix it yourself" is not offered to you, but to a troll-critic. 🧌

          Favkis I created this post because of pure frustration, I hate working with this engine, it might be too emotional or something but it is a truth.

          The problems you have outlined, which you experienced in Godot, are valid to me, and I confirm it. Don't let others undermine your perception of what constitutes a bug or mature software. Given your situation, I personally suggest considering alternatives at this point, regardless of whether you'd like to continue using Godot for other purposes. I realize that switching engines may be a significant endeavor, but abandoning your current tools might be a better option rather than hoping and waiting for Godot to arrive (which is futile by definition).

          samuraidan it's not trying to be Triple-A game engine.

          Then why does Juan, the lead developer of Godot, writes articles with misleading titles such as this one:

            samuraidan I guess my frustration with all these complaints is twofold: this engine is still ridiculously young comparitively [emphasis mine], unity's been around for eighteen years and unreal's been around since 1998. of course it's going to be more buggy than they are. if it's still as buggy in ten years and not as stable as unity is now, then I'll take those comparisons more seriously.

            The argument that "Godot is still young" is also as common as the "Fix it yourself" argument among Godot followers. Since Godot is closer to Unity (even though it's not a fair comparison, see Juan's tweet again I mentioned earlier), let's dive into Godot's history.

            Prior to open-sourcing the engine, Juan and Ariel co-founded Codenix, a game development consulting company through which they licensed Godot to third-party companies in Argentina. Juan says on his Twitter:

            Found some really old images (2007-2009?) of early Godot and prototyping. Codenix was the company Ariel Manzur and I created. Engines such as Unity were not mainstream, so we licensed Godot to third party companies in Argentina.

            Even earlier versions of Godot being in development can be verified in the official article by Juan titled:

            This means that Godot started its development in 2001, even though earlier versions of Godot had different names, as denoted in that article, such as "Larvotor".

            The basic calculation reveals that Godot, as a piece of software, is 22 years old now. Godot is actually 3 years older than Unity. Therefore, making an argument that "the software is not stable yet because it is young" is fallacious.

            For future reference, readers can refer to this post whenever this topic is brought up again. 😊

            by that metric we have to compare it to unity's first pre-release for this to be truly accurate. I don't know if you're just being pedantic or if you have some bone to pick at this point.

            I wonder if there's some alternate universe where you chose unity and you're doing this same weird hole-picking in every argument over on their forums right now.

            anyway I'm not even sure what the point of all this is. I know you want them to have a clearer project direction but that's all I know despite all these words.

            I guess that's the problem I'm having. I can't tell what you want. what do you want? do you want them to change project leads? change direction? become a unity clone? what is the point of this argument, even, I'm lost

              That's how discussions work.

              If you make general statements in response to concrete issues with Godot as put forward by @Favkis, I am left with no choice but to address the misconceptions that you have about Godot's history, for instance. One cannot just use the general statement along the lines of "you cannot criticize the engine if it hasn't matured yet" as a way to dismiss legitimate evidence, assuming that you want to engage in a fruitful discussion on the topic.

              I'm only interested in factual discussions. I'm also here to express my supportive words towards @Favkis, as I recall my early years in the Godot community (late Godot 2.1, 3.0+) when my feedback was ignored or my personality was attacked just because I raised issues about Godot (as if users of Godot have no right to express their critical opinion about Godot).

              samuraidan I can't tell what you want. what do you want? do you want them to change project leads? change direction? become a unity clone? what is the point of this argument, even, I'm lost

              If you truly want to know, read my book Waiting for Blue Robot, or at least this part: Have You Read the Book?. However, please note that this topic is not about me nor about my book, I only provided this information due to your exasperation, that's all.

                Xrayez If you truly want to know, read my book...

                Why not post a short summary here? Saying "if you want to understand what I'm saying, go read this" is disingenuous.

                Favkis The videos look good but I think you are pushing Godot to it's limits. Godot probably made a mistake doing it's own physics engine. It's also geared towards just adding nodes and things for a quick game development time which is kind of prone to having problems with complex behavior. It's just that trade off. You're probably one person that should have chosen Unity or Unreal. Godot can make professional simpler games, which really make more sense for most individual developers.

                Ok... I think each side has made their point. As nothing constructive is written in this discussion and seems to be leading nowhere, I'm locking it.

                Please read the new rules revised for the forum.

                @Favkis Feel free to post your projects here (they look great, as mentioned), but I ask to respect the forum rules in the future.

                MikeCL locked the discussion .