I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served.
Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.
>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.
This dismissal of honest performance benchmarks is why I'm glad you're not leading Godot. We're not talking about some esoteric cloth simulation code being nitpicked. These are core architectures issues costing you 2x performance minimum, simply due to how the c++ and C#/GDSctipt/GDExtension layers talk.
Take this as a warning, not a dismissal. Unity went down this exact path and we see how viable it became for large scale game development. I sympathize with you for those who are outright trashing the GDScript for being a scipting language, and I do wish those arguments would die down (it's simply language wars). But there are definitely fixes here that would improve all diferent bindings, even if they never diverged (which IMO, they should).
>This is like showing up for dinner and insulting cooking before you’ve even tasted the meal
cooking is subjective (mostly), performance is not. This is more like asking why the cook is trying to carefully drain out the water with a loose lid instead of using a strainer. Sure, it may work for the cook and they've done it all this time, but I'd rather give a safer solution that won't burn them long term, or spill out excess food.
> This dismissal of honest performance benchmarks…
No, I was criticizing premature optimization. I explicitly stated “there are definitely opportunities to improve Godot”. I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting.
If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively? Better memory utilization, better processor performance[1], and no more garbage collection stutters. Oh right, it’s not your preferred language.
I’d rather we all just make games instead of fighting language wars, but seeing so many of these posts in the last week makes the community feel hostile.
>I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’ Well, if it’s not right for you then move on, thanks for visiting.
The author has already crossed the part out suggesting to remove GDScript. Which was overblown as it was one of 3 different suggestions.
Either way, even for the rude provocateurs, two wrongs don't make a right. I've follow Godot with a loose ear and it's not a surprise that there are significant performance issues in the engine. I'm glad someone is digging deeper rather than just saying "Godot isn't ready for 3D" and dismissing opportunites to grow.
>If we’re to be so focused on performance then why not ditch c# also and only use c++ or rust exclusively?
Because you didn't get to the part of the article where it is mentioned that GDExensions uses the same api bindings as GDScript. So they are all affected by this, no matter what binding you make. Your only recourse is diving into the guts of Godot and rearranging how it works. Which is first of all, already in flight by the core team (redundancy) and secondly, not a kind of change you can easily PR in if you want to contribute (which is more hostile to the engine than any random post on social media).
And yes, this is the dismissal I'm talking about. "well just use another engine" is a pretty bad approach for a growing community when receiving honest feedback with benchmarks to back it up. The author makes a long post detailing the inner guts of the engine and people cherry pick one conclusion they don't like and want to push the author out of the community.
I appreciate that the author crossed out his suggestion to remove gdscript vs removing it. I will give him credit for transparency. That doesn’t negate the original intent.
I am aware of the part about how this affects bindings for all languages. My point still stands that this is premature optimization. The author even admits, “In some projects 95% of the CPU load is in an algorithm which never touches the engine APIs. In that case, none of this matters.”
So again, if this is about performance then why not remove c# as well? If we’re to “tear it all down and start again” we might as well do it in rust. Oh? If I want a rust game engine I should look at Bevy. Is saying that really a second “wrong”?
I don’t have anything against this author specifically. I respect that they did more than simply look at the showcase screenshots to make their assessment. My initial comment was more a general expression of frustration with the prevailing attitude on various forums. I like reading r/godot to see individuals creating games, not creating grief. (Frankly, I found the Unity memes to be a bit mean spirited as well.) I acknowledge my initial comment did nothing to remedy the situation but I was tired of hearing it. I have since stopped reading that subreddit. Enjoy your c# crusade.
>My point still stands that this is premature optimization.
Given that the author knows they will make hundreds of raycasts a second, and that the perf suggested that they can at most make 700 for an entire 16hz frame, I can't agree in this case. This is the exact kind of "we'll fix it later" kind of unoptimization that makes gamers wonder why games still hit 30fps on modern hardware (I've worked on such a tile, in UE4. the engine doesn't save bad practices and useage).
>My initial comment was more a general expression of frustration with the prevailing attitude on various forums.
don't generalize your rants when you see a good example of criticism. That just lumps in the good with the bad and makes you look like you're lashing out at any criticism.
>Enjoy your c# crusade.
Enjoy prowling r/godot, I suppose. If that's the conclusion you gleam out of my comments, you fit right into Reddit. Making unrelated rants and being confused on the disagreement and seeing everyone as out to make your life specifically, miserable. Glad I left that behind months before it became fashionable to leave.
> I took offense to devs joining the community and nearly immediately proclaiming ‘this is all wrong and you have to do it my way.’
Is this in response to the article in question? Because they are spot on with their assessments and those API issues need to get sorted. They impact bindings and all extensions including C++. The core devs seem to concur on this, it's just a matter of how it happens.
I was generally frustrated with the parade of posts about how bad Godot is from former Unity devs. This happened to be the article that I commented on.
Unity may have damaged themself enough with this that AppLovin might get another chance to buy. Unity’s stock price has dropped 8% since this was announced.
Another fun fact, the Unity CEO and several board members sold some of their stocks a few weeks ago. [1]
True, acid rain was not caused my lead but there was public and industry resistance to requiring all vehicles use catalytic converters. Lead had to be removed from fuel because it corroded the catalytic converter. It was chaotic for several years but the car industry was able to make it work. The market didn’t remediate acid rain, regulation did.
I only hobby in game dev. I have read some basics of ECS and IMO it seems a lot more intuitive than the “normal approach”. I think this is a case of using familiar tools we are comfortable with, not necessarily better. Unity’s ECS implementation is a hot mess though. I am looking forward to seeing what Bevy delivers as it matures.
I agree that copying an existing product will be easier and is usually cheaper and more performant because you can leverage your competitor’s R&D and lessons learned. I presume this is why some tech companies’ product lines are full of clones.
Human civilization made it all the way to 1990’s without commercial internet. Maybe keeping children off the internet would make them better prepared for society.
Now look at the a mid 50's former housewife trying to find a job. It's a cruel world. Try getting hired as even a secretary if you don't know how to use Office.
Not the OP but I do run Teams on Apple Silicon and it is still a bug-ridden mess. Crashes, rendering bugs, file attachment bugs. At least once a week, usually more. Searches fail to find results that I can manually locate by scrolling through the chat history. I have reinstalled the app more than once.
I have shared these observations in their feedback pop ups and I know Microsoft loves collecting telemetry. Why should they dedicate more money/resources to fix defects when it clearly hasn’t stopped them from growing their market share?
Teams is the first example I use to begrudgingly explain to someone that quality doesn’t matter.
As per the hypothesis I stated, I think your problem is running Teams on an Apple system. I'm not defending Microsoft releasing a shitty product here, but I think it's most likely they didn't bother to properly test/debug it for other OSes and configurations than "embracing Windows and the Office ecosystem".
> The whole point of static types (well one big reason at least) is to improve the actual code quality.
I have worked on multiple typescript projects that had terrible code quality. Types do not make you write SOLID code.
I find functional programming and well-used functional patterns do result in higher quality code. Typescript’s type system makes writing functional code more difficult. The documentation even recommends against it[1].
IMO typescript is easy to prescribe as a panacea, “just use typescript”, whereas understanding how to write SOLID code takes time.
My world changed when I started thinking in a strongly typed way (not just using string and number) and representing state changes as different types rather than interpreting than through property values. Once you do that then your code becomes mapping from one type to the next.
For example, if `type ShoppingCart = EmptyCart | LoadedCart` then `addToCart` is just a map from `ShoppingCart` to `LoadedCart`. It makes invalid states impossible to represent and flows become clearer. Add in good FP and composition becomes easier.
I am not against types but I do find typescript’s type system to be deficient. Additionally, functional programming is not incompatible with type systems but typescript’s type system in particular makes it more difficult.
Several of the terrible typescript projects I referred to still used property values to represent state (like your example). Just because every definition has a type doesn’t make it good code. Shitty typed code is still shitty code. My concern is that many in our industry conflate typescript with quality and stop there.
I'm curious which part you find deficient? It's biggest downside is probably being Turing complete but that doesn't make it deficient, rather it's too easy for devs to code incomprehensible types with it.
Zuckerberg hired Joel Kaplan as Facebook’s VP of public policy to shape political speech policy. Kaplan was a former clerk for Antonin Scalia, a lawyer for W. Bush during the 2000 recount and eventually his chief of staff[1]. Kaplan regularly intervened to stop enforcement of terms of service violations for, as you said, “one political side”[2]. He also successfully advocated to _not_ update Facebook’s recommendation algorithm to promote neutral, non-political content because it would make Facebook appear bias against conservatives[3]. Despite all of this “one political side” continues to claim they are unfairly targeted.
Wired did an article on this earlier this year. It talks about the ecological concerns and the international politics surrounding these deep sea mining efforts.
Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.