Thread by @winterpixelco

I'm really somewhat confused by the @godotengine core devs reaction to @o3dengine #o3de. I'll prefix this thread with the fact that we REALLY love @godotengine. There's some massive pros to the project (FOSS being the largest)
(1/25)

The #o3de announcement is definitely a welcome addition to the FOSS community, but a few of the @godotengine core devs seem kinda bewildered that amazon would invest time and money here rather than sponsoring or helping #godotengine in some fashion.
(2/25)

See: https://t.co/D9z7cpe8GF https://t.co/vuJanUJNAd (3/25)

https://twitter.com/vnen/status/1412609214212710401

https://twitter.com/reduzio/status/1412471226841378817

https://twitter.com/Akien/status/1412708207567441922

But to me, it's pretty clear. The fact is, it's somewhat tough for seasoned and experienced game/c++ developers to work with the #godotengine src. The codebase and lead dev are very opinionated (which is USUALLY a good thing).
(4/25)

And I'm not talking about necessarily contributing, this is about working in the codebase itself. (5/25)

For example: I can't use godot Strings in any other modern c++ template collection because String doesn't implement move op 😞. This leads to workaround after workaround in our codebase itself. (A simple example true, but one of many).
(6/25)

And there are just some very unergonomic things about the godot source right now. Stuff that would just never fly with experienced teams or devs. And from what I've seen it seems to put off experienced devs and more established teams.
(7/25)

Recently I've come to discover this old godot issue (as I understand this issue has somewhat become a sore spot in the #godotengine community).
(8/25)github.com/godotengine/go…

Regardless of the presentation of the aforementioned issue (probably not the best), the technical criticisms in the issue are sound. (9/25)

And that aside, a lot of criticisms of godot src code come in the form of "Why does godot src do things like this". And the general answer from the core team is, "godot does A this way because of X,Y and Z". And I have no problem with this reasoning. (10/25)

But the reasoning has to be sound. What I'm starting to see more and more of is that X,Y and Z tend to be false premises, which end up resulting in bad decisions. (11/25)

And I don't believe it's intentional, I think it's just due to the lack of actually using the engine by the core team to ship real products. (12/25)

This is really why dogfooding is SO important, and why Epic/Unreal have such an unbelievably great advantage with their engine development practices. (13/25)

I was told in IRC back when godot dev team used IRC for communication, that godot src is very NIH (not invented here) by design. I wasn't familiar with this term but boy am I now. (NIH is the tendency to avoid using any third party code other than your own). (14/25)

Need a STL? Godot has their own impl. Need a physics engine? Godot has their own impl. Need an http stack? Godot has their own impl. Need a scripting lang? Godot has their own impl. etc, etc, etc. (15/25)

There are obviously pros and cons to this, but IMO it's currently balanced on the wrong side here. It leads to slower development velocity, because when you do everything you have to maintain AND fix everything. An absolute massive amount of work! (16/25)

There's a very real reason Unity just uses Box2d as it's 2d physics engine... (17/25)

And ya, when you implement everything yourself, you're going to have to implement range iterators (as well as a whole bunch of other things but don't get me started). (18/25)

https://twitter.com/JFonS_/status/1412832008192069632

For example, our project was just absolutely HAMMERED with malloc/free overhead per frame. Literally TENS of THOUSANDS of calls. The reason? Godot's 'stl' doesn't do map iterators (just due to lack of resources)... (19/25)

I encourage the godot core src team do some introspection here and not just wonder why the project doesn't seem to attract certain types of resources, sponsors, or developers. It might be gut check time. (24/25)

And please amazon just consider open sourcing #gamesparks as well... You'll promote #aws which is always the real endgame, and if you're willing to do so with the lumberyard tech buy you might as well do it there too if u have no direction what to do! (25/25)