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?
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.
- 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?
I’m dying at this.
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.
What do they think this blog post is? A diary entry?
A whole new genre was created: Unity customers being upset feel their career is in danger write nonsense blog posts about other engines to make them feel better.
It’s free real estate.
(It’s a game engine, FREE. / It’s a free game engine for you, Jim. Well you gotta bring code and assets, but the engine is free. / It’s a 2D and 3D engine, it’s got Vulkan in the backend)
Poor Performance
Godot actually runs on my shitty laptop, what are these people using, literal potatoes?
@DJSpunTheDisc @anteaters counterpoint, unity editor is unusable to linux
I’m saying godot runs better than unity (when it comes to development) so this rather improves our points lol.
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:
- 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.
- 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.
- 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.
- 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.
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?
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.
Compare Godot’s last 5 years to Unity and it’ll give you a whole new appreciation of ‘General directionless development’
As bad as unity is, Godot (and most foss that doesn’t have big financial banking) is several times worse.
If you are asking me to put my salary on the line for the next 5 years of my life developing godots future is far far more uncertain
@ShittyRedditWasBetter @vivadanang if my life is on the line I wouldn’t put trust in any business’s proprietary black box solution.
That’s likely a poor choice if you want an optimized will supported game. Especially if you need a large team to develop it
I agree that it would be nice to have a “solid” roadmap to see what is planned for the future. It’s not easy to put up actual goals and implement them in a FOSS project but that is something that the core team might be able to do. In the past there were only blog posts about the general ideas for the upcoming releases (i think 4.1 was supposed to be mainly stability improvements and bugfixes after the big 4.0 release).
dunno where you’ve been the last 5 years, but being a unity dev has been far from certain. dots, pipelines, ugui, fragmentation of runtimes, it’s been ridiculous.
FOSS has less to do for or nae than my belief that Unity has screwed the pooch in a way that destroys trust. going after past products and asserting they can charge per install?
GET FUCKED
any partner you work with that tries that shit you need to lose immediately - that’s a real, valid and true threat to your business man.
I think you need to step back and get some perspective on how violently unity fucked themselves with this shit show.
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.
Fucking exactly. And here to finish my article, a person that called Godot a “scrappy little engine” built by a “gameplay engineer”.
Godot is obviously not a flawless diamond placed behind museum glass, but don’t give me this bullshit that this article is written solely in the name of technical due diligence.
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.
Full time developers are indeed a must for a controlled and reliable development of the engine. I’m not sure if W4 games is supposed to be the provider of this or the Godot Foundation.
They took the post down?
Good. Seems like a knee jerk post.
I think the whole https://blog.odorchaidhe.games/ website is down.
It’s seems to be a github pages site, and github is up?
Yes. Either the whole blog was taken down intentionally or maybe the author messed up the script for deploying the blog.
Getting a 404 for that blog. Any other github blogs to test it properly? It’s looking like the author just deleted it altogether
Yes, I wasn’t implying that github pages is having issues or something.
What I’m saying is that the entire blog is down, so it’s not like they took down this particular article.
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 by creator
