Over the past week, I’ve looked hard at Godot as a potential alternative to Unity in the wake of the disastrous Unity pricing model change.

As a professional engineer (or a former one), I cannot give my professional opinion of this engine after such little time with it, even with source code access. I admit I have not run a single profiler, I have not exported a single build. I have skimmed less than 10% of the source code. I have played around in GDExtensions, but not in anger. I have not tried C# at all.

2. Poor Performance

This is, again, a huge topic, and I don’t want to make hard claims without hard data. To be absolutely crystal clear, I have not profiled Godot nor worked on a complete enough and representative project in Godot to observe performance issues firsthand.

Apparently everyone and his dog needs to write about Godot right now after taking a passing look at it because it is hot shit at the moment?

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.

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.

Compare Godot’s last 5 years to Unity and it’ll give you a whole new appreciation of ‘General directionless development’

And then finally, I found this post., where a longtime contributor complains of the general lack of direction and philosophy, in March 2020.

Maybe there’s indeed a lack of direction and philosophy, but I’d be careful with citing that specific PR, for it was made by someone known for making some rather bizarre accusations of godot and who is no longer a godot contributor due to their past behaviour.

Right off the bat, the author misses perhaps the best thing about this engine - it’s incredibly fast at prototyping ideas. This is obvious to anyone who has used it to try and make something.

Hopefully the donations will allow them to hire professional developers that will guide them in the correct direction. It’s good enough for hobbyists like myself and I hope there is a potential that it’ll grow to be a serious competitor for other engines.

They took the post down?

Good. Seems like a knee jerk post.

I’ve been developing with Godot for about 2 years now and have loved every minute of it, personally

When I click on the link I get “Site not found” :/

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

deleted