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.
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
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.
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).
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.
Removed by mod
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.
When I click on the link I get “Site not found” :/
I’ve been developing with Godot for about 2 years now and have loved every minute of it, personally
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
