So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#.
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.
I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.
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.
> community might dislike a performance-friendly change which will break the parity in favour of C#.
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.
GDScript is in a much better place than most scripting languages because the compiler actually has quite a lot of static type information. If they invest in unboxing optimisations and a JIT, it can definitely become competitive with C#.
I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.
When I first encountered Unity it was because there were performance problems on a Japanese only version of Bejeweled built with it and they needed someone to fix it. It was a classic: creating huge numbers of new objects for particle effects hammering the gc, and the fill rate of the then cutting edge device GPUs not being a match for their screen resolutions.
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.
I started evaluating Defold this past weekend and I have been very impressed.
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.
>and if you want to make immersive 3D just bite the bullet and move to Unreal
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
What advantage do you think defold has over godot for 2d (apart from currently seemingly being more polished)? Theres lots of people complaining in this thread that GDscript is not serious enough as an engine language, but Godot at least has a decent c++ api. Defold only seems to support Lua (although you can extend the engine with other languages afaik).
I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project.
Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
> but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big,
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.
I too found it a bit cumbersome past a certain code size. A lot of games don't necessarily need a lot of raw or complex code to run though, so the 1st class benefits of GDScript start to shine, like the native debugger, autocomplete, Godot-specific accessor syntactic sugar.
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.
They're commited to GDScript because it's a great scripting language. I started with Godot expecting to switch to C# pretty fast because I'm already familiar with C#, but I was pleasantly surprised with GDSCript. And I'm a programmer with more than 10 years of experience. For people who are still learning it must feel like the difference between trying to learn to ride a bycicle vs learning to fly a boeing 777.
One thing that stands out as odd to me is the small selection of really "good" game engines.
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.
>One thing that stands out as odd to me is the small selection of really "good" game engines.
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.
It really depends on what your game/team needs. If you're trying to make a match-3 then Unreal is maybe not the best choice. If you're trying for competitive cutting edge graphics in an engine that is mostly done so you can actually focus on the graphics, then Unreal is top of list.
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.
I think that which game engine will be "good" depend on manyu things including what kind of game, what computer system, FOSS, licensing, other features, etc.
This dictionary stuff is truly bizarre. I have been playing around with GDExtension and Rust - specifically the meshing interface. This dictionary stuff shows up there. Not only couldn't I figure out why (the GDScript angle makes sense in hindsight), but it also makes the API virtually impossible to discover: you have to resort to reading things up in the documentation.
As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.
>Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018.
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.
He wasn't just active on forums, he was actively developing on Unity itself, in the weeds with all the other engineers. He arguably got a bit too involved at times, but it was very admirable for a "executive" who could retire on the interest of his shares in Unity to still take so much care in the product. I can't say that about many 10+ year old company founders, let alone ones that went public.
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.
I didn't read anything that indicated a hard block to creating new methods that bypass the binding layer? All the layers are open source.
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.
I hear the recommended approach is to write your own module in the engine level code. But that means you need to compile the engine everytime you change your module. Possible, but you are losing a lot of iteration unless you are experienced in rolling in your own physics.
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.
Never underestimate the power of open source game developers. If we could do it with XNA, we’ll do it with Unity. If we have to tear the place down and rebuild it on a rust il-compliant vm instead of mono, we damn sure will [0]
*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.
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.
So, what I'm gathering is if you're bothered by the Unity (either a developer, publisher, gamer) developments, and wish Godot was a better alternative than it is, contributing to the project (by donating either time or money) is probably necessary to get there.
It's a lot clunkier than Unreal. You'll have to build a .so/.dll using scons or cmake (good luck finding a CMakeLists.txt that actually works) and you have to register all types manually. You will also not be able to work around the issues with the APIs mentioned in the article around dictionaries AFAIK. There is no header tool and no autogenerated code for your classes. Oh, and reloading the DLL on Windows requires an editor restart. Plus I haven't found a good way to debug load failures either apart from starting the editor from a console window.
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.
TBH if i was making a game using Godot i'd just be modifying the engine itself to add any "heavy" functionality (the nodes system would most likely help here) and expose custom high level APIs to GDScript. IMO scripting languages should be used to script the behavior of a game: i.e. tell the engine what to do, not how to do it (which should be written in native code).
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.
Bridging collection types between languages is never easy. Apple only manage it because they control the compiler and runtime on both sides, and that still comes with performance pitfalls. Allowing both to exist and telling people when to use one or the other is not only easier to implement, it has more predictable performance and gives the user more control.
I might throw in a bit of gossip here - many who were following the development of GD 4 last year (myself included as I was using it :) ) thought it was kind of rushed out in time for GDC 2023 in March. And immediately after GDC, Godot 4.1 followed (and now rc's for 4.2), with lots of fixes.
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
The biggest problem for me in moving to Godot is the editor tooling. I find the @tool and EditorPlugin workflow to be very finicky. Editor restarts were needed to refresh/correct changes from @tool scripts. And a lot of what I needed to do in the scene view (context-free) required hacky solutions. Not to mention, they changed a lot of related APIs in Godot 4, most of what I google are still from Godot 3 and don't work in Godot 4 (no backward compatibility).
That said, I'm still enjoying Godot, the only fun part in the past week.
It's made great progress in this regard since 3.x, and it's an an extremely powerful system, but dealing with some @tool intricacies can very quickly make you waste days trying to figure out what's going on. My greatest annoyance regrettably lies in one of Godot's most convenient features, custom resources, that are so extremely tedious to use with @export from the editor in any meaningful, useful way that I've personally given up on it for the time being, their lifecycles even avoiding _init() cross well beyond the bug behavior territory and GDscript permits no alternative approaches code-wise that aren't absolute monstrosities of jerryrigged variadic functions (not supported except for a few API calls resembling them) jumping one into another or endless walls of parameters you get lost into.
> That’s right, our raycast is returning an untyped dictionary.
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?
Curious if anyone here has tried Bevy (Rust game engine).
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.
I looked into this, but it seems most gamedev communities I asked, say Bevy isnt great, and everyone seems to be recommending Fyrox instead. No clue if it actually is, just parroting what I have been told.
Either way, I don't think either is ready for prime time as its still early development.
I've been following Bevy for a while and it looks incredibly well-thought out. One of my favorite YouTubers (https://www.youtube.com/@Tantandev) often does Bevy projects and doesn't gloss over the code and goes to explain why Rust is a great choice for the ECS that Bevy provides.
Bevy came up on /r/rust_gamedev a little while back. The general sentiment seemed fairly negative, with comments that you either do things Bevy's way or the highway.
When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution.
> 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.
It's for this reason that I appreciate this article, even though it has a (playful, well-intentioned) negative tone toward Godot which is a project I donate to.
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.
JavaScript is fast because it is used by every person every day, so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone. Godot is a game engine supported by a community (not big companies).
They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
Solving some of those performance problems can also require a massive amount of engineering resources and investment, though. For example the way browsers (generally) overcame interop overhead was by self-hosting almost everything in JavaScript or making things into JIT intrinsics. That's a tall order for something like Godot with two languages.
Python is still slow today. I've worked with performance sensitive python at Google, there is no way to make it fast no matter what tool you use except to rewrite it in a lower level language.
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.
This matches up with what I've heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it's got some significant issues that would make that difficult to unfeasible for many people.
Nobody suggested that Godot was on par with Unity. The hope is that resources get diverted away from Unity towards Godot so that it can develop into a top-notch game engine. It's time to stop waiting and start working on Godot.
Yes, I was under the impression that Unity was also slow and people who use it don't particularly care because it's still fast enough for their purposes.
But with so many eyes on Godot now, I can only see it getting better.
neonsunset|2 years ago
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.
dandellion|2 years ago
Rapzid|2 years ago
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.
badsectoracula|2 years ago
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.
Dudester230602|2 years ago
TazeTSchnitzel|2 years ago
xmonkee|2 years ago
shmerl|2 years ago
fidotron|2 years ago
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.
fayten|2 years ago
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.
johnnyanmac|2 years ago
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
Fraterkes|2 years ago
droptablemain|2 years ago
Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
gustavus|2 years ago
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.
headcanon|2 years ago
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.
dandellion|2 years ago
Lucasoato|2 years ago
rybosworld|2 years ago
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.
johnnyanmac|2 years ago
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.
jay_kyburz|2 years ago
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.
jayd16|2 years ago
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.
zzo38computer|2 years ago
zamalek|2 years ago
As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.
Rapzid|2 years ago
RobKohr|2 years ago
timmytokyo|2 years ago
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.
johnnyanmac|2 years ago
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.
pests|2 years ago
Recently because of the drama or unrelated? That’s sad to hear as I was very excited on that effort.
MrLeap|2 years ago
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.
johnnyanmac|2 years ago
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.
reactordev|2 years ago
[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.
homarp|2 years ago
discussed here https://news.ycombinator.com/item?id=37598985
tacotacotaco|2 years ago
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#.
johnnyanmac|2 years ago
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.
Waterluvian|2 years ago
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?
amitmathew|2 years ago
Hamcha|2 years ago
Scalene2|2 years ago
zerr|2 years ago
janosdebugs|2 years ago
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.
badsectoracula|2 years ago
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.
Dudester230602|2 years ago
https://learn.unity.com/tutorial/lists-and-dictionaries
worble|2 years ago
> 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.
TazeTSchnitzel|2 years ago
generichuman|2 years ago
TL;DR is that they know this & working on it
lainga|2 years ago
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
CreepGin|2 years ago
That said, I'm still enjoying Godot, the only fun part in the past week.
0x_rs|2 years ago
bakugo|2 years ago
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?
Narishma|2 years ago
jay_kyburz|2 years ago
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.
wkat4242|2 years ago
TheMagicHorsey|2 years ago
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.
Daegalus|2 years ago
Either way, I don't think either is ready for prime time as its still early development.
matthewfcarlson|2 years ago
MegaDeKay|2 years ago
https://www.reddit.com/r/rust_gamedev/comments/13wteyb/is_be...
Narishma|2 years ago
unknown|2 years ago
[deleted]
KMcPheeters|2 years ago
Haven't tried it in a project yet myself
gustavus|2 years ago
> 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.
mdbauman|2 years ago
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.
AndriyKunitsyn|2 years ago
They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
kevingadd|2 years ago
Jensson|2 years ago
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.
guideamigo_com|2 years ago
unknown|2 years ago
[deleted]
karaterobot|2 years ago
CodeCompost|2 years ago
unknown|2 years ago
[deleted]
robertlagrant|2 years ago
panzagl|2 years ago
CobrastanJorji|2 years ago
xg15|2 years ago
unknown|2 years ago
[deleted]
anothernewdude|2 years ago
hiccuphippo|2 years ago
But with so many eyes on Godot now, I can only see it getting better.
spookie|2 years ago
bowsamic|2 years ago
unknown|2 years ago
[deleted]
jayd16|2 years ago
>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.
unknown|2 years ago
[deleted]
Madmallard|2 years ago
[deleted]