To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.
And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.
if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.
One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:
> As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).
It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.
Further down though somebody points out:
> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.
This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:
> C# is faster, but requires some expensive marshalling when talking to Godot.
I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".
EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.
How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey
The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use.
If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.
Unity took several years, and a huge amount of investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense.
In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.
The developer experience is very similar to Godot, especially if you work on your scripts with external editors. Everything that has to do with building and running the app is faster than Godot though.
Initial builds with Defold are very fast, it has on demand hotreload, and very small binary sizes. The small binary size makes it well suited for working on web games.
The Godot Editor is still a tad bit nicer to use, but I do like the fact that the Defold editor is written in Clojure. I imagine it makes extending it fairly quick.
The main reason I see myself sticking with Defold over Godot is because scripting is done in Lua.
The Lua ecosystem has a lot history in the game dev space making it easy to search for answers. Lua is trivial to extend and has multiple statically typed options that compile to it. Notable statically typed languages are Typescript and Haxe. Also Lua has a lot practical use in many domains outside of the Defold editor unlike GDScripts lock-in to Godot.
Defold has no where near the size of the community of Godot, but the developers seem very active on the forum and GitHub.
I need to play around with it more before I’m 100% sold. Both Godot and Defold are great looking choices for 2D.
Since Godot is right there, I'd rather try and bring up a current up and coming engine to somewhat parity rather than give up to Epic.
Also, iteration is godawful in Unreal. Not everyone is trying to make Gears 6, so I wouldn't mind a more lean 3D engine to work with if I have low-poly or simply not-dense scenes to manage.
>These days cost of preparing assets drastically exceeds coding time anyway.
Only if performance isn't a concern. There's a reason engineers are still paid more than the equivalent artist at studios. That performance is still hard to work with or around, even in Unreal Engine
Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powerful, and the experience of the devs shows. It is one of those tools that even if you never use it again some of the ideas stay with you.
Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
We are talking about GDScript not JavaScript.... Oh wait, the parallels are remarkable
Simple language designed to be easy to learn: Check
Turns large codebases into a tangled lovecraftian mess of spaghetti code: Check
Likely to be someone's first introduction to programming languages: Check
Honestly reading the criticisms of GDScript so far is convincing me more and more that Godot is quickly going to become the next big thing, especially if the developers can figure out how to get people to use it for thier first programming project. After all most people I know who got into development started because they wanted to make their own video game.
How likely would you say the same effort is gonna go into GDScript?
Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.
Other scripting languages are also easy to learn. Vanilla Javascript is much easier than GDScript. And so is Lua. Kids learn coding in Lua. Even Python isn't that difficult compared to C#.
Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.
Unreal seems to have the most features and the steepest learning curve.
Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains.
Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many features as the other two and the commitment to GDscript seems... odd.
If I were picking a game engine today, it'd be between Unreal and Godot, but I'm not sure I'd feel great about either choice.
not much odd about it. 3d game engines are a large endeavor, somewhere between making a Large desktop application and making a full blown OS. I'd say the largest ones are comparable to making a web browser engine or even a full blown IDE suite.
There's also some slight snide in that there is no truly "good" game engine. Just ones that teams put up with enough to get across the finish line. The sheer scale of the engines and the nature of them being developer suites means running into edge cases is inevitable.
There are several mature 3D solutions out there, but the ones mentioned have the 3 largest communities and are strongly supported. But to throw out a few others
- Open3dEngine (O3D3), and fork off Lumberyard, which is a fork off CryEngine, is probably the biggest off-the-shelf competitor to UE when it comes to delivering AAA level games.
- Stride is an engine mentioned often in discussions, and it has a similar feel to Unity. But it simply isn't as mature as Godot and lacks some platform support like Mac
- UPBGE is the spiritual successor to the defunct Blender Game Engine, with a similar pitch: create your game without ever leaving your modeling suite.
-Finally, while not a fully featured game engine, I do want to give some note to Ogre3D. It's one of the oldest and most battle-tested graphics libraries out there, is MIT open sources, and is there for the kinds of developers who rolled their own engine/framework and simply used Unity as a rendering backend. Ogre doesn't include physics nor input (nor an editor), but it's really good at throwing your hand rolled game logic and giving it something visual. I could make similar other recommendations for stuff like Raylib and BGFX, but Ogre still being supported after over 20 years is admirable.
There aren't tons of choices, but there are choices out there if you are willing to get your hands dirty.
I'm a fan of Love but I have to admit the amount of Lua I wrote for just my prototypes did start to get a little scary.
I might have a play with raylib.
I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but they're proprietary and not available to license.
Unreal isn't good just because of the graphics. It has loads of tools built in, and that's where most of the value is in my opinion.
This video will give you an idea: https://www.youtube.com/watch?v=k2IP5DYQ0-0
As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.
That would be Joachim Ante, who is no longer CTO. He's "on sabbatical" and hasn't contributed any posts to the forums for over a year. (He used to be quite active on Unity's forums.) The entire leadership of the ECS/DOTS team has resigned.
And of course the moment he silently stepped out, Unity rolls all this BS out in less than 6 months. Joe wasn't just champion of the tech, he was likely one of the last of the old guard up top keeping things focused on the actual product instead of how to extract infinite monies.
Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
EDIT: It was in May.
Unity has their fair share of bolted on methods with a "NonAlloc" suffix. Seems obvious to prioritize raycasts / intersection / collision code to receive this treatment.
I've noticed a few lower lift things I'd like to submit PR's for, just to see how/if I can help.
Nothing stop you from modifying the engine code, but the problem lies in the binding layer, not the engine perormance (as you see in the blog, the raw engine performance for a raycast is about the same as Unity). That's a bit trickier to fix without intimate knowledge of such bindings, and you'll likely break a lot of GDScripting support (so by extension, c# scripting) in the process.
[0] https://crates.io/crates/netcorehost
*edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.
discussed here https://news.ycombinator.com/item?id=37598985
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.
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.
[1] https://programming-language-benchmarks.vercel.app/rust-vs-c...
I think Unity was like 3MB with C#
Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem.
To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?
I ended up sticking to GDScript in the end, but the typing system is very basic and the code can get very messy quickly. Plus, as far as I could tell, there is a race condition between signals and the process function, but I need to debug that more thoroughly to be sure.
From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do.
The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.
> The main difference between the .NET collections and the Godot collections is that the .NET collections are implemented in C# while the Godot collections are implemented in C++ and the Godot C# API is a wrapper over it, this is an important distinction since it means every operation on a Godot collection requires marshaling which can be expensive especially inside a loop.
> Due to the performance implications, using Godot collections is only recommended when absolutely necessary (such as interacting with the Godot API). Godot only understands its own collection types, so it's required to use them when talking to the engine.
TL;DR is that they know this & working on it
So on the one hand, yeah, 4.0 lacks polish, and I certainly have felt some strong feelings working with GDExtension... but I also believe there was a reason for that, and I believe the team when they say they're working on improvements now
That said, I'm still enjoying Godot, the only fun part in the past week.
This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?
I know it's not the same thing at all but it's as close as you're going to get.
I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there.
I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.
Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever."
The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.
Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features).
Another post in this thread said the C++/native interface was not great and difficult to work with. And C++ even in the best of times is not my favorite thing to work in.
Either way, I don't think either is ready for prime time as its still early development.
https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
1. the engine isn't stable and has breaking updates (why does that sound familiar...)
2. ECS is hard to learn and Bevy is too strict with ECS.
It's hard in the same way OOP is hard, I guess. But it's just that: a paradigm. It's harder to google because ECS is a specific paradigm for applications that want to follow data oriented design. If you don't care about that, then you lose all that benefit and google-ability for not much gain.
I guess that's just the state of FOSS game engines right now. People basically just want Unity/Unreal without the copporate overlords. But while oppressive, they also did fund the engineers to make those solutions so attractive to begin with. You'll inevitably get your hands dirty if you go of those smooth UE/Unity roads. Especially if you're choosing an up and coming language like Rust on top of all things.
Haven't tried it in a project yet myself
> However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch.
If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.
This is wonderful criticism! It's thoughtful and well-researched. Hell, even I'm inspired to finally dive into Godot's internals, which I've yet to do despite following the project for several years. I hope this inspires even more contribution and constructive criticism.
They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
That's more the problem of Reddit's code being a pile of bull dung. Someone high-level in there decided to ditch the "old" API for the "redesign" in favor of GraphQL and as everyone who has ever worked with GraphQL is likely to have discovered, GraphQL is a hell in itself.
And because whoever was moronic enough to call that decision doesn't want to admit they have fucked up and Reddit can't/doesn't want to afford maintaining two distinct APIs, they decided to rather shut down the old, working and performant API.
Reddit is being killed by corporate bullshit.
There's no point comparing year 30+ of Javascript to year ~10 of Godot. Remember that year 10 of JS was the time when Flash reigned supreme.
>They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
I agree and am glad that we're finally putting a halt to bandaging up the leaky pipes known as JS and releasing stuff like WebASM. Fortuantely, Godot is nowhere near as heavily bandaged and has easier access to change.
I'm glad to see that tools can exist in only one of 2 states, massive world wide adoption and support by big corporate, or a couple of devs screwing around. I wonder if it is possible for a tool to transcend this limitation?
If only there was a way for multiple people to use a tool, push for it, enhance it and for it's adoption to grow and spread to large pieces of the community eventually gaining corporate support. But nah, things like that don't happen. After all if there is one thing I've learned a scripting/game/animation engine that is easy enough to use and is flexible is something no one really needs anyone, a product like that would probably disappear in a FLASH, after all.
Javascript is fast since it is such a simple language that is easy to optimize, more complex runtimes wont see nearly the same amount of gain from optimization efforts.
There's just been no demand to make Python crazy fast, not to the scale where even Google will throw their engineers at it. Python's use cases aren't in real-time applications so that level of performance concern is simply not needed for many. And those that do will use anything else on the backend, from C to Go, maybe even Javascript.
Also, have you heard of JavaOS? https://en.m.wikipedia.org/wiki/JavaOS
Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
It reminds me of the linux debate:
- A: I hate Windows telemetry
- B: Then switch to linux. It's as good
- A: But it doesn't have a good video editor.
- B: You should develop your own video editor and share it with the community
- A: Ughh... I just want to edit my videos...
I use linux and love it, but there are users who need Windows or Unity.
But with so many eyes on Godot now, I can only see it getting better.
>I'm making a top down 2D game and Godot's too slow to handle my character controllers at 120fps without a lot of hacks. In Unity they run in 2ms. It's not just The Last of Us that this matters to.
>The controller gets used for NPCs too, so I can have quite a few of them on screen at once. It's got quite a complicated substepped movement and collision response system which does lots of ray and shape casts. A typical frame may end up around 500.
Even if its not efficient for their specific game, a few hundred raycasts should not be taking nearly a millisecond to perform. No wonder there's so much work to do to get Godot to be 3D ready.
>Mixing fast and slow APIs as discussed above would leave us with headaches for decades
Meh. Unity has allocating and "NonAlloc" methods, even on the raycast API in question here. It's a really minor issue.
Sounds like Godot will need more time to bake before its perfect but we already knew that.
