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++.
This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead encountered in OP) to make the transition uneventful.
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.
C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.
>if I ever need performance I'll probably just go straight for C++.
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.
> if that's my go to solution, why am I using Godot instead of Unreal?
No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).
Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.
> even a more mature C++ renderer framework like bgfx, or even Ogre3D?
IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.
>Godot & Unity have the advantage of pushing the game development to the editor instead of the code.
Indeed, but even Unity isn't known for its high performance 3D titles. It COULD viable do them, but not without a lot of work.
That was supposed to be something that DOTS would address, to take out "a lot of work" and make that performance almost be taken for granted. But... well, I don't want to go on that rant again. You can excuse some performance and optimize later, but the sounds of things from this article (with general sentiments even from diehard Godot fans that Godot isn't ready or serious 3D development) makes it sound like that optimizing will in fact exceed the content creation time.
I've seen enough of the guts to know that Godot will likely never make its own DOTS. At least, not its own Burst compiler to get around the c# issues. Likely not IL2CPP either. Fortunately, you don't need that and can get maybe 80% of the performance by simply following some data oriented principles. More than enough for all but the most lofty AAA games (think GTA6 levels of scale).
----
>Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.
that's good to hear, and I get it (Unity rushed out tons of features itself. Including DOTS). I hope I can one day contribute to that effort myself. Would make my future game dev life much easier and would be a good way to give back.
Except that is the whole point of languages like C#, being able to be productive in high level code, and not needing to write C++ when performance is called for by providing all the features for low level code, unless in very niche caches where those features still aren't enough.
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.
There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.
As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.
Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.
Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.
Maybe GDScript could just get the concept of a struct and the differences minimized over time too.
From what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices.
But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)
> 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.
It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.
I understand it. it was built a certain way to support ease of use above almost anything else.
That ease of use is important, but also may be holding back Godot's true 3d capabilities. From a cursory glance as someone wanting to work on a decent scale 3D game, I'd need to treat GDSCript as I do Unreal's Blueprints as of now: miniize use only to high level scripting and maybe UI/Shader code. That's not me saying that GDScript nor blueprints is bad, just that it gets in the way of my specific use case.
If I can help speed up the engine underneath as a whole in the process: wonderful. I don't necessarily want to disrupt GDScript for my convenience either, but like any refactor some breakage is inevitable.
For some, a few days of GDScript usage. For others, after they convert their bottlenecks into C++.
UE’s blueprints are much(!) slower than native code, but they’re still an incredible tool in the toolbox. GDScript is kind of the same; it’s covering a critical role of non-performance-sensitive glue.
That said, I’d really like to see Value Types added, as well as these sorts of heap allocations addressed in Godot 4 at some point.
It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.
If C bindings were slow because the underlying code was made to bridge with Python bindings, I would complain too, to be fair. Doesn't mean removing Python support is the perfect solution, but at some point that performance hurts everyone.
(not that that should be an issue due to python being able to directly output C code, but you understand the point).
I guess the argument is that GDScript has a different use case than Unity's C#? Seems like Unity devs know what a C# scripting engine is like and feel it covers the use case fine. To say they don't understand the use case would mean it must be different somehow. Can you go into that?
So are we fine keeping it that way and not addressing core performance issues because it's convinent for making simple 2D games?
To be honest, I'm surprised how dismissive parts of the gamedev community can be about improving performance of their game engine. That was a huge complaint from Unity and you'd think people would be interested in not repeating those mistakes with Godot.
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 can't help but think this is delusional. Microsoft has put massive effort and funding into C# and I just don't see how Godot, being much more niche, can reach that level of investment.
If they targeted the .NET VM they'd be able to make use of a lot of that investment. But they don't really need to. There's a lot of low-hanging-fruit for performance, and narrowing the gap is more important than outright parity.
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#.
You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.
There is optional static typing. If you write type declarations, the editor will not only give better code completion, but it will use type inference to find errors statically where possible, and the runtime will check for the remaining type errors. In this way it's more sophisticated than almost all other dynamically typed languages!
Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.
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).
Bluntly, getting too hung up on languages is procrastination. Lua is more than fine. (GDScript isn't actually that bad, just completely esoteric). Similarly I wouldn't get hung up on Blueprints or C++ when worrying about Unreal, partly because their C++ is so particular it's extreme.
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.
I actually agree with you about the language-stuff. I thought your parent-command was essentially making some kind of performance-based comparison between defold and godot, which is why I mentioned Lua.
Defold seems interesting, but unlike Heaps and Godot it hasn't yet been used for any game I've heard of.
(additionaly I don't really agree that Gdscript is particullary esoteric. It's basically python, with a bunch of very obvious engine-api stuff added on top. Language-wise theres very little to learn there, which is great)
> Defold seems interesting, but unlike Heaps and Godot it hasn't yet been used for any game I've heard of
Is this true really? It appears to have been bought by King (Candy Crush Saga) and used internally (see the Defold about page). So while it may be associated with mobile/casual gaming it was worthy of being purchased and used by an otherwise successful company -- at least along some metrics.
Acquiring anything usually has a period of investigation and inquiry which Defold passed.
Seems at least worthy of consideration next to Heaps and Godot.
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.
As others have mentioned, JavaScript also has had over 20 years of serious investment from the best minds in the industry to improve it. We now have V8, TypeScript and plethora of tools that make writing serious applications possible or even preferable. I seriously would take TypeScript over most languages any day.
How likely would you say the same effort is gonna go into GDScript?
>How likely would you say the same effort is gonna go into GDScript?
Hard to predict. We're still in the web 1.0 phase of Godot and dealing with questions like why we made a <blink> tag. We could get serious talent addressing the binding layers, we could simply have a few key bottlenecks addressed, or we accept GDScript as the slow path and diverge. It could also simply fade away, but many don't want that, and I'm also not too interested in deprecating something many have used to launch full games.
Personally, my goal is less about making a scripting language perform as well as c++ and more about having options to make sure people can port from GDScript to some faster binding if/when they run into performance bottlenecks. At worst, maybe a migration tool may be needed. Hard, but more doable than any of the above overhauls.
Well that's a point a lot of other people have raised and is the one I am trying to make, Godot and the associated ecosystem could become like the next generations Javascript. Companies didn't start investing an enormous amount of time and effort into improving JS because they wanted to, they did it because they adopted it and then ran into cases where they needed the performance.
My point being that a lot of the concerns are not foundational to Godot and GDScript and can be improved if there is an investment. But that investment will come with adoption, not the other way around.
Javascript only got the investment it did because it was the only language that would run in a web browser, when the web suddenly became a billion dollar business and javascript developers were a dime a dozen. Godot is able to support multiple languages. The goal should be improving and expanding language support, not repeating the necessary evil of making Javascript the One True Programming Language.
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.
It's probably not ideal for large projects, but it adds huge value for small ones, and for people who are learning, and I'd expect probably even in larger projects if combined with C++, C# or Rust. It's miles better than the joke Unity had that was called Boo. I also like it a lot better than Blueprints in Unreal while still remaining extremely simple, although I can see how Blueprints can be better for more visual people.
I concur. I believe GDScript should be split from Godot itself and support should be added for third party IDEs. It has a lot of hard-coded things specific to Godot in it and it suffers from it. The built-in code editor has a very confusing layout and its built-in code editing functions will never be as powerful as providing a language server to a dedicated IDE.
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.
GDScript not a great scripting language. It's an adequate scripting language whose only benefit is native integration with the client, and guaranteed support in perpetuity. But there is nothing about it that's better than any other scripting language. No one would choose to use GDScript as a general purpose programming language.
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#.
I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked.
It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome), it comes with a good enough debugger, its library pretty much covers what you need to make your average indie game... But what did the romans... I mean, GDScript, ever do for us?
>its library pretty much covers what you need to make your average indie game
Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue.
But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.
It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)
Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.
You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.
If you know how to code it's very easy to learn, it doesn't matter if you come from C#, C++, JavaScript, Python or something else.
There's almost no nasty surprises. Nothing like learning JavaScript and then discovering the weird behaviour of this, or using Python and discovering for the first time that the weird bug you had was because you set a dictionary as a default value for an argument.
It's got some of the syntax sugar you might expect from modern languages. Not as much as Python, but that might be for the best if they're trying to keep things simple.
Some of the syntax sugar (@onready, $, %) is specifically there to integrate with the engine and it is very very nice.
Documentation is good, integrated with the editor and the inspector.
The debugger works well (98% of the time, hopefully it'll keep improving).
It's one of the nicest languages I've learned in a long while. I think it's because it's only trying to do one job and it does it fairly well.
When I started learning it I noticed many things that were done better in other languages I've used (it's specially tempting to make comparisons with Python since it looks similar). After a few months using it almost daily to make a somewhat simple game I realised most of those things don't matter and for the purpose of making games in the engine it's pretty solid.
I can’t speak for the parent, but @onready combined with the $ operator is a delight when making a prefab.
I also very much like the way signals are declared compared to C#’s code generation.
I’m also a fan of TypeScript, so being able to do gradual typing while prototyping is a huge plus. It’s going to be a big advantage if they ever get JIT.
Everything being reference-counted, rather than fretting about GC pauses is comforting too.
Also not the parent, but: It's a very simple language. It looks like Python and behaves like TypeScript. It makes it easy for beginners to get into game development without having the visual overhead of a C++ or 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.
Unity got a stigma for delivering half baked features and dropping support for existing features without a replacement. The epitome of this was where in Netcode, where I believe they had no officially supported solution despite the engine having 2 different packages which were both half-baked, all while the DOTS variant was far from release.
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.
If you like or don't mind using Go, check out Ebiten as well. I think it's similar to Raylib in spirit, but it also supports Nintendo Switch, iOS and Xbox. IIRC it uses native graphics APIs (Metal for MacOS, DirectX for Windows) while Raylib just uses OpenGL.
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 don't think it was due to the recent drama. (Although who knows, maybe they knew what was coming.) Mike Acton and Andreas Fredriksson left back in March 2023 I think. They posted to twitter.
Not recently, but there was a steady drain of talent. The two heads of the DOTS initiative were gone by May of this year and the CTO, and the last original Founder of Unity, and arguably largest champion of DOTS, silently stepped down in April when introducing the new CTO. Johacim's official status is apparently "sabbatical" (I'm sure he owns way too much stock and other sway to be hoisted out the traditional way).
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.
> 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.
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.
I used GDExtension extensively on a previous project, and I ended up just installing the .so, launching Godot headless, and immediately exiting, as part of my build script. To catch anything that might break extension loading.
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?
It does support classes with strongly typed fields, though, which are the next best thing. It's just a poorly designed API, it's not a reflection of language limitations.
Godot has always made a point of prioritizing features and simplicity of modification over speed. In a lot of instances it does just ignore low-hanging opportunities for performance because the simple thing works and needs less code, which isn't always useful, but means it's easier to replace.
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.
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.
A lot of the consensus there seems to come down to
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.
As a Bevy dev - what platforms? We support Vulkan, DirectX12, Metal, WebGPU (with a bit more limited features), and WebGL2 and GLES 3 (with a decent amount more limited features and performance).
I double checked, and our rendering library _does_ partially supports DX11, as well as Angle, which lets you run the GLES3 backend on top of Angle on top of GLES2/DX11. They tend to be fairly buggy and incomplete, though. Arguably only usable for simple 2D games.
It is still GNM and GNMX, Playstation doesn't no Vulkan, and I am quite sure that just like with MoltenVK and DXVK, not everything can be mapped in a transparent way.
That's kinda a Sony problem. The best an Open Source project can do is build HLSL/SPIR-V IR and let you do the rest yourself. I don't really know what you're asking for besides that, it's how things have been since the PS4 launched.
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.
It feels like a breath of fresh air to me. Yes, random people, come in and start using Godot, the more eyes are on this project the better. They're articulating gripes I have had but couldn't express. It would be great if, like JS, all the attention became an impetus to make Godot really fast.
Totally agree, that's why I submitted this article. I'm personally invested in seeing Godot become successful, but this type of constructive criticism is great for the ecosystem (even though some people get very defensive). I think it's exciting that there's so much room for improvement and shining light into Godot internals is a great way to expose what needs to be done.
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.
> 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.
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.
Javascript was also once upon a time just some randomly strung together mess of code (with urban legends saying it was made in 10 days) by a not-big company. Gotta start somewhere.
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.
> 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).
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.
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.
It's possible (Unity did it to C#, a magnitude more complex a language than Python), but at the same time we are not short on choices for other languages to extend upon. Google even made a few of those languages themselves.
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.
JavaScript is very fast if you want/need it to be. Emscripten/asm.js approach is in the same category as native for example. Your simple code won't be too fast, but not all code needs to be.
Mostly because Linus won't accept anything other than C on his beloved kernel.
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.
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.
You clearly weren't on reddit. Everyone there will urge you to switch to Godot even though your game is almost finished and Godot doesn't have feature parity.
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.
Redditors couldn't even switch off Reddit during their own enshittification. I don't exactly trust their judgement in terms of knowing how to find alternatives. What is the term they use these days? Wolves eating my face?
>I use linux and love it, but there are users who need Windows or Unity.
Need is a strong word, but I will never judge someone on the tools they use (well, not on a personal level. I will judge you if you choose to make a game in Microsoft Powerpoint, you madman). But if you're going to complain about big business and then wonder why you can't find a good alternative when your complaints fall on deaf ears... well, you see why they are still in business.
I've simply shifted my mindset over the years from trying to tear down the evil, and instead build up the good. It's a much more productive way to live much of life in general.
We think that a significant advance can be made in one or more of these problems if a carefully selected group of scientists work on it together for a summer
It is probably not on par with the professional video editors and it is not very intuitive to get started, but blender has a build in video editor, that should cover most basic needs.
Otherwise sure, that misguided evangelicalism is hurting trust in open source software, when people claim it is ready, where it isn't.
I've seen comments here on HN that make me believe some people think Godot is on par with Unity, or that it will be soon. The title of the linked article also acknowledges that some people in the world at least have a misapprehension to that effect.
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.
>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.
Oh yeah, for sure. I've developed some VR demos in Godot and it seemed quite capable.
But, I was never calling this many raycasts from the CPU side of things. Never had an excuse to do so.
I'm just saying this because I really think Godot is able to produce good 3D experiences as of now. I appreciate the criticism, and of course would like it to get better.
But, I don't know, something tells me the dev could take another approach in the meantime. It seems the post started some ongoing conversations with the devs to solve this issue, so that's nice.
> I'm just saying this because I really think Godot is able to produce good 3D experiences as of now
I guess I'll see for myself next year as I work on a 3D title. But my current research doesn't make me optimistic. I am very much ready to help contribute to address these sorts of issues if/when I run into them. But I want to actually contribute, not just take my ball, fork, and redesign the engine. If I get this much friction introducing optimizations, and/or am unable to find out who/where is working on such things, I don't know what to say.
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.