Skip Navigation
34 comments
  • The probative value of the article is massively outweighed by its prejudicial effect.

    In other words, it's a smear campaign. The author is literally saying, oh I can fix all of these issues, but I don't know what other issue might come up. This is horse raddish. Balloon juice. A downright dismissal. As if you'd have better luck with the walled-off garden that is Unity or UE. They simply stated issues the community has already been talking about, and framed it as Godot is a lost cause not even worth fixing.

    And here's the bullshido that the author implemented. They sprinkled in the thing about Godot being tied to the Vulkan API. This is valid criticism. Surprise surprise, a FOSS engine being worked on by a handful of paid devs and some volunteers has more work that it needs done on it. But now if you disagree with the thing I said about it being a smear campaign, they throw Ol' Faithful at you:

    "An engine is a tool, not a cult." "Oh, you disagree with the article. Are you saying that Godot is perfect?" "So you're saying that there are no technical issues with Godot?" "You can only release low poly games with 3D Godot."

    As soon as the status quo was disturbed, suddenly the imperfections of Godot are on full blast. Juan Linietsky and Co. are now to drop literally everything they were doing and address the smear campaign's concerns, lest it be successful. I suppose that's both a positive and a negative.

    • The author is literally saying, oh I can fix all of these issues, but I don’t know what other issue might come up.

      That's very often a reasonable thing to say.

      The problem here is that Godot is the one that is up-front with its limitations, while the others are always trying to hide them. So yeah, this becomes smearing on this context. And completely false.

      • Yes! It very often is a reasonable thing to say! In the sense that if you fix one bug, you might be creating a couple more bugs. Like opening a can of worms. But the author in this case used this as a retort to the community saying "if you have an issue with the engine, and you can fix it, then please contribute the fix to the github repo". So ultimately, the argument seems to be why would one contribute fixes to the engine when one might have to fix another issue afterwards. This is antithetical to the nature of FOSS and immediately discredited the author, in my mind, as having a technical discussion in good faith. I'd love to give quotes that brought me to this conclusion, but the article seems to have been taken down as I write this.

        They are better served using Unreal Engine and there's nothing wrong with that.

  • Some of my own thoughts, which rebut the article in parts:

    1. Godot does have "barbell performance" - you can make it go fast if you drop to C++ and do low-level engine things to add new nodes, resources, etc. You can also make it go fast when you use the premade nodes without a great deal of script in between(and the nodes are, FWIW, pretty flexible and composable). What it doesn't do at present is the thing Unity users are used to, which is "fast scripting". Fast scripting still means working around the garbage collector and the overheads of going between native and a runtime. C# is a kind of flytrap for the needs of high-end games, and Unity has only seemingly surmounted the issues by doing a lot of custom engineering for their use-case. That is, you don't really code standard C# in Unity, you code Unity's C#, which is nearly as bespoken as GDScript.
    2. Saying the engine is coded in a naive way is actually not as smart as it seems, because there's a maintenance cost to always doing things in exactly the most optimal way. The target for what is fastest changes every time the platform changes. As a (up until recently) relatively small project, it's overall better that the engine stay relatively easy to build and straightforward to modify, which is what it's done. The path it's taken has helped it stay "lightweight". The price of that is that sometimes it doesn't even take low-hanging fruit that would be a win for 90% of users.
    3. The 3D in Godot 4 is capable of good test scenes, but everyone seems to agree that it's not really ready for production for speed reasons. Any specific point on this just backs that up. And that's disappointing in one sense, but pretty okay in others. If you need high-end graphics, Unreal will welcome you for the time being.
    4. On that note, developing for console always comes with fussy limitations, at minimum just meeting TRC/TCR/lot check; that's why professional porting is a thing. Engine devs usually end up in the position of maintaining these multiple-API abstractions because it's necessary for porting. It's the same deal with the audio code, the persistent storage, the controllers, the system prompts, it just goes on and on like that. So, rewriting the rendering bindings to do things in the D3D way and not the Vulkan way is actually a bit of a whatever; it's more rendering code. It changes some assumptions about what binds to what. But it accesses the same kind of hardware, running the same kind of shaders. A lot of ports in the not-so-distant past basically had to start over because the graphics hardware lacked such a common denominator.

    The author's bio says that they have been doing this as a professional for about 5 years, which, face value, actually means that they haven't seen the kinds of transitions that have taken place in the past and how widely game scope can vary. The way Godot does things has some wisdom-of-age in it, and even in its years as a proprietary engine(which you can learn something of by looking at Juan's Mobygames credits the games it was shipping were aiming for the bottom of the market in scope and hardware spec: a PSP game, a Wii game, an Android game. The luxury of small scope is that you never end up in a place where optimization is some broad problem that needs to be solved globally; it's always one specific thing that needs to be fast. Optimizing for something bigger needs production scenes to provide profiling data. It's not something you want to approach by saying "I know what the best practice is" and immediately architecting for based on a shot in the dark. Being in a space where your engine just does the simple thing every time instead means it's easy to make the changes needed to ship.

  • Good article, I thought it was fair! As I don’t use reddit or twitter anymore I’m surprised at that comment, I know I’d heard some mumbling a around working with high fidelity assets but I didn’t realize it was that bad. I think the asset store has a higher ratio of good vs bad compared to others because of the lack of payment incentive, but I also only try out the popular plugins so I can’t speak about the rest.

    I think the recent donations will help fund hiring devs to implement the features people actually want. Did they do the summer of code this year? It usually has some interesting developments, the revamped tile editor in 4.X started as a project there. The new color picker too, it’s so much better than the old one

34 comments