this seems a well-argued article to me the ‘General directionless development’ seems the most concerning point, I don’t think the ‘let’s go with what the community ask\want’ model is gonna work in the end.

what do you think?

  • VeeSilverball@kbin.social
    link
    fedilink
    arrow-up
    22
    ·
    1 year ago

    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.

    • TsarVul@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      Well reasoned points.

      Regarding your 2nd point, absolutely correct. But man does it look good in a hit piece such as this article. Appeasing the needs of the many is a delicate procedure that sometimes involves using in-engine data structures and not just fixed length arrays, much to the chagrin of the author. Less maintenance at the very least.

      Regarding your 4th point, Godot can accommodate the need for precompiled shaders, it can add adapter layers around its Vulkanic render pipeline, it can technically play by console rules. But there is the one thing that it can’t do. It can’t just publish usage of a proprietary API to a public git repo. That will always be the albatross around Godot’s ass. But I would pose the following question: is this a flaw of Godot or a flaw of the status quo, which forces FOSS into a permanent song and dance to be on equal footing with private enterprise?

    • CloverSi@lemmy.comfysnug.space
      link
      fedilink
      arrow-up
      1
      arrow-down
      1
      ·
      edit-2
      1 year ago

      The irony of this line from the post is particularly amusing:

      your willingness to talk about things you could not possibly have all the information about this confidently, and with so little tact, is a sign of inexperience.