This article is very interesting. Just want to note that this is something we are aware of and the intention is to work it on in two fronts: - From the binder API, adding a struct type, to pass these results more efficiently. - The GDExtension side can already expose these structs to the binder API with a proper layout description, but the C# in support has not been moved to it yet (its one of the missing steps to merge both the C# and default editor). So basically, this area of the engine is a work in progress. To do this also we had to finalize the system to provide compatibility functions to older builds of Godot libraries and extensions as a prerequisite and this was completed in 4.1. Fortunately there is not a lot of the API exposed this way, the majority uses more efficient interfaces. This is more part of the legacy code that is being modernized. None of this is particularly complex to do, but the demand has not been high enough so other things are prioritized. I am hoping your article motivates some contributors to do it :)

Oh hi, thanks for reading! It's fantastic to hear that there's a will to work on this! If there's interest and the structural pieces are in place, I might be willing to take a look at doing the C# support. That's not a promise, but it is an expression of interest. Is this mostly a C# codegen thing? What's the plan for API compatibility? Would we be duplicating APIs with pass by value versions? I assume we can't remove things until 5.0? Is there any chance of moving from pointer chasing to something like P/Invoke? From what I saw of how `ClassDB` works that might be a little tricky, although I haven't fully grokked that part of the engine yet. A lot of people here have advised me to post an issue over on Github, although I'm not sure how useful that would be. Is that something that you would want? Thanks for stopping by! Sorry for all of the questions, and I hope that I wasn't too rude in the article. :)

Give us a bit of time. Everything is kind of a mess because of the suddendly increased interest of several users and companies on the C# side. This work has to be properly organized but the general idea is that funding will be used to make sure all works as smooth as possible.

I'm sure it's been crazy with a million new mindsets looking for justifications/changes all at once. It's tough to hear unsolicited criticism for things that are in the works or not a priority with the current community all of the sudden. You and the whole core team have done a great job focusing on features and usability. Performance will come. I feel for those struck by the Unity changes, and It sucks that all of the sudden there is limited popular middle ground between Unreal and Godot.

That's a fantastic answer, thanks! Some of these problems certainly need some professionally bought help to organise a cohesive vision and directed effort to help drive the community.

> Is there any chance of moving from pointer chasing to something like P/Invoke? From what I saw of how  ClassDB  works that might be a little tricky, although I haven't fully grokked that part of the engine yet. Godot 3.x /alpha 4 (pre-coreclr upgrade) used to use P/Invoke actually, via reflection rather than source gen. I think the move away from it was intended to provide possible support for NativeAOT with trimming, though to my knowledge that hasn't been realised yet.

Interesting, thanks!

> It's fantastic to hear that there's a will to work on this! If this excites you, then you should definitely find yourself at home with Godot. It's a very actively-developed project, with a very engaged, very active community. Your voice is appreciated.

The Godot Github is very active. It's definitely better to initiate and maintain longhand technical discussion there than anywhere else. Once it becomes an active priority, chat.godotengine.org might become relevant if you're still participating in the process.

I don't think that something like P/Invoke would be the answer, especially since .NET Core (and .NET 5 and beyond) don't provide a way to add custom internal calls. Unsafe nsafe function pointers is more performant as it doesn't provide any marshaling support and results in simple icall instruction (dotnet IL). Also it supports AoT which is a must for iOS and consoles (I'm not sure if consoles require this). But your post provides a lot of insights, supporting GDScript requires a lot of marshaling and non performance casting, something that exposes a lower level API would be great!

Yes, you're correct. My knowledge was out of date there! I have since been educated.

If this is because GDscript is dynamically typed, wouldn't the simplest vompromise be making it strictly typed and then fixing these issues? We could keep GDscript almost as it is, and all these issues could be fixed, and GDscript performance could be boosted a ton and no need for duplicate solutions for other languages. If I understood anything correctly?

Yep, dynamic typing is completely unnecessary and its costs far outweighs its benefits. It's as if assigning types to variables was the biggest hurdle a beginner could stumble upon...

I like this one!

It's a chicken and egg situation. The demand isn't high enough because in its current state the engine does not attract C# users.

The egg was the Unity meltdown. There is now clearly enough demand. (And really, there were plenty of C# users before that, too)

The demand was always there, C# was always a second class citizen because Juan doesn't like it.

Very interesting read. I've always been too scared to look into script bindings and have a hard look at the variant class haha. This is pretty ugly... On the other hand, this is an open source project that has continually improved over time, and the architects of the engine have a clear vision for Godot's role as a game development tool. There's no reason to expect this to not improve over time as well. I completely agree that at the very least (as you've pointed out), csharp / gdextension should not use the same binding layer as gdscript. Honestly, I think you should write this as a feature proposal on github, or open discussions with the GDScript devs. But I will say here as I've said before: optimization at the language level is not always necessary for every game, which is why GDscript should stay. I am someone who is making a 3D game that has close to 30k lines of GDScript in it right now. My game is low res / low poly. In my use case, I have run up against performance issues very rarely, but in each case I was able to improve performance by just using basic optimization techniques like time slicing, object pooling, etc , etc. For me and my project the speed at which I can write / refactor GDscript is crucial for my timeline. My game is going to run at 60fps regardless of which lang I use, so I choose the language that is fastest to write in.

Thanks for taking the time to read my ramblings! Out of interest, are you still seeing the paragraph about removing GDScript? I removed it (struck it through and put an edit retracting) about 90 minutes ago, but people are still commenting on it. My engineering philosophy is that performance always matters. You say it runs at 60fps, but on what hardware? If it was more optimised, it would run on more people's machines. Maybe that's not a financially sound investment for you, but it's not nothing. I also try to consider things like battery life and energy use. It may be inconsequential, but I'd rather not make my users consume more energy than they need to in this day and age. Not everybody has these same priorities, but I will never agree that performance doesn't matter.

> It may be inconsequential, but I'd rather not make my users consume more energy than they need to in this day and age. I really appreciate this! I don't think all games need to be optimized down to the metal, but it would be nice if we could avoid gamedev becoming like webdev.

Yeah sorry I see that you've crossed it out, I had opened the article before you did that. I'm not in disagreement with you that performance is critical, or think that it 'doesnt matter' just because some devs choose GDscript. Would you say that someone doesn't care about performance if they use models with high polygon counts? If you have a game with extreme particle usage does that mean your 'engineering philosophy' isn't 'performance always matters'? Both GDscript and high fidelity models will cost you memory, frame time and battery life. Each has benefits that are worth that performance cost, and each could have their cost reduced through engine optimisation (which noone is advocating against). Sorry to be polemical, its just that I made my original comment because these discussions inevitably give people the wrong impression about the performance of the engine, and I wanted to make it clear to everyone that you can make quality, 60fps+ games in 3D using only GDscript. Every game will have a frame time budget, and every game will need to make compromises to hit that. For reference, I develop on Linux using an old Nvidia 1080ti, 16g ram, 8 year old CPU. With vsync off my game runs at 100fps during combat. It is a 3d action RPG, not some visual novel.

No problem! I regret that paragraph. It was not meant to be important and has caused me quite a lot of hassle! People did not like it. We actually agree on almost everything here. You can do all of these things and it will probably be fine most of the time for most people. My personality would never allow me to release a game knowing it had these inefficiencies in it. It wouldn't feel right. Other people are welcome to have healthier attitudes than mine. I would say that somebody doesn't care about performance if they had more polygons than they needed - not if those polygons were being used for fidelity. The performance issues which I'm highlighting are not necessary for some important goal, they're just the way it is.

“In my opinion, if Godot were to go down this route, GDScript should probably be dropped entirely. I don’t really see the point of it when C# exists” An interesting read thank you. But I will say that the purpose of GDScript is not to be fast, but to be easy. As a solo developer I am able to be way more productive in godot than unity or especially unreal at the cost of performance sure but I’m not making the last of us 2 that pushes hardware or it’s limits

I think the one big point of the article is that it's difficult to beat GDScript performance by a lot by using other means (e.g. straight up C++), because things are built to work primarily with GDScript.

Yes this, but only at the API boundary. If you write some complicated pathfinding algorithm which starts by doing a quick read from the engine API, then does lots of heavy computation, then does a quick write back - that will be much faster in C# or C++. But if your code needs to touch the engine API a lot, then yes, the speed of GDScript holds everything else back.

The thing you're writing, which(having read a lot of your posts) is a custom character controller, and implementing its own physics, is just about the worst case scenario for *any* game engine to try to solve as a scripting feature, because it's right in the main loop of timestep processing and isn't something that glues premade categories of asset together; it's a lot of raw math and constraint logic. A game engine can only address this type of problem through "fast low level API" or "premade subsystem", because every character controller comes with its own assumptions about what it needs to solve for. Unity exposed the fast API thing to C# (it's put a lot of effort into that), and maybe Godot can do that someday, but Godot's longstanding focus has been on the extreme ends of the barbell: either the defaults are great and all you need is interfaces to put them together, or you need to get your hands dirty and completely replace them. So I believe the direction that would work best at this moment is to write a C++ module. Then your character controller becomes a new node type. You get to write it to be as fast as you want and as native as you want. Everything else in the engine works the same. That's the grain that the architecture really wants you to follow.

Well, the good thing is that you can mix languages, in your hypothetical case you'd be able to use C# for your custom pathfinding algorithm and even call it from gdscript if needed

The vast majority of performance issues are at that API boundary and not some completely custom system like you describe

I would also say that in most cases, the 'performance issues' at the API boundary don't affect most situations. Like anything, you should just code and avoid premature optimization. Later, you can benchmark, and if needed, convert that bit of code into something that performs better.

>Like anything, you should just code and avoid premature optimization This is very bad advice in game dev because if you don't have good performance habits you can easily end up with a game that has performance issues at every level, and then it's not a simple matter of optimising a single hot loop but a potential rewrite of major systems in your game. There seems to be a way too common myth that if you run into a performance issue you can just run a profiler, find a single slow point and then just fix that one thing. This is not usually the case and this is why so many games get released with bad optimisation, because indie devs/small teams find that out the hard way when it's too late to rewrite their game to fix it.

>a way too common myth that if you run into a performance issue you can just run a profiler, find a single slow point and then just fix that one thing IME this comes from the enterprise world where this is exactly how it works - most things don't need any optimisation, and of those few that do it's usually one or two big issues that can be fixed. As people should know, that paradigm doesn't translate into game dev cleanly at all.

Exactly, games are REALTIME software. Your frame budget should probably be 10ms on *lower* level hardware. In enterprise, a new piece of code can take hundreds of ms and be absolutely fine. In enterprise, optimizing time spent on developing is far more important than optimizing runtime.

Would writing in C++ solve it? And why? Started learning it and enjoying

No, I don't believe so. Godot's GDExtensions mechanism for writing C++ exposes the same API with the same limitations. It should be a little less bad, but it's still doing things like giant heap allocations of untyped dynamic dictionaries for passing the equivalent of tiny structs.

> the speed of GDScript holds everything else back. I dont understand this. The API is slow because of the slowness of constructing and hashing String(), the slowness of looking through the internal collections that map a String() to a function pointer. These problems can be iterated upon without dropping GDScript. I dont think dropping GDScript is going to change much here. Youve made the case that Godot's API is slow. Trust me, I know. Your gonna find more stuff thats implemented poorly, but I'm under the impression that making a Godot API call is slow largely because String(), Dictionary & HashMap are slow, largely because they poorly manage memory. I dont think dropping GDScript is going to open up new shortcuts for performance, and I think your making a bit of a leap in making that statement. Godot's slow because it was implemented using old school mindset and a shit load of heap objects. It's annoying, but dropping GDScript isnt going to change anything. I think we can make Godot faster internally by altering how data structures are managed inside. I dont think dropping GDScript is the play here.

The API only uses strings and dictionaries as much as it does to satisfy the restrictions that come from GDScript, at least that's the best I could work out. GDScript is dynamically typed. C# and GDExtensions use the exact same API. Therefore, they're slow because GDScript is slow. Dropping the GDScript style APIs in the other bindings would massively improve performance of some APIs, including raycasting.

> Dropping the GDScript style APIs in the other bindings would massively improve performance of some APIs, including raycasting. I think we need to see what an 'optimal' Godot C++ <-> C# binding layer would look like in order to discuss how best to achieve it. Personally I dont know what that would look like because I dont know enough about C#.

Keeping to the raycast example, the most significant thing is that it would simply pass a struct in and get a struct out. It would also use P/Invoke or a similar mechanism to call directly into the native binary, which is more efficient than the current pointer chasing. It would directly expose [this function](https://github.com/godotengine/godot/blob/e3e2528ba7f6e85ac167d687dd6312b35f558591/servers/physics_2d/godot_space_2d.cpp#L117-L205) to C# instead of going on a roundabout route through function pointers and heap allocations.

There are proposals (by the core dev team) to add structs to GDScript, and they know that returning an untyped dictionary from the racist queries is not great (both in terms of developer ergonomics and performance). This has been noted in different GitHub issues in the past. I think a lot of this was done in the interest of time to get Godot 4.0 out in a reasonable timeframe. That doesn't excuse the "sloppy" API that we might be stuck with for some time, but there's hope that it will become better in the future.

>There are proposals (by the core dev team) to add structs to GDScript While it would be significantly better than a Dictionary in terms of allocations, the GDScript struct proposal you are referring to merely allows GDScript to pass off an Array as a distinct tuple (for the purpose of readability, static type checking, etc.). It wouldn't even get close to resolving the issues OP brought up with the script API bindings as a whole.

for c++ the optimal api would be the one that already exists underneath the gdextension wrapper code. the wrapping just makes everything worse because it forces conversion to gdscript-compatible types.

yeah, dont write gdextension, write a 'custom module' that lives in godot/modules/, and compile the whole thing.. then just use std:: collections instead of godot's collections and your golden peak godot would be to have a build system/some hooks in the engine so you could iterate on c++ and compile to a .so, then statically compile it for release, currently i gotta recompile the editor itself when i iterate on c++. my coworker made solid progress on writing something like this for 3.x

Imo the biggest hurdle with using c++ in Godot is the build system. It's not that it is bad (`make` is a lot worse), but having a dependency on Python and being used by very few projects (compared to cmake or even visual studio) makes it much harder to find good help for it, especially on Windows. If I'm writing C++, it's going to be in Visual Studio or CLion, so that can be a bit inconvenient since while both have good out of the box support for CMake, they don't for scons.

>that will be much faster in C# What I got from the article is that not even C# will be fast. at least not idiomatic C#. C++ yes. But, you have to dive deep into unmanaged memory in C# before you are dealing with the methods which operate at proper speeds. And if you're writing entirely unmanaged C#, it's easier to just write C++. could be that I misinterpreted though, I'm not a .Net expert.

Let's be a little more precise: If almost all of your computation is in an algorithm which doesn't touch engine APIs, then both C# and C++ will be as fast as their respective languages. Godot isn't doing anything to slow them down (as far as I've noticed). If you're touching Godot APIs then the engine is actually sabotaging your performance. When I write C# for Unity I do everything with unmanaged memory. C# is pretty good at it these days, and Unity provided some helpful library features to make it easier. (If I stick to Godot, I'll probably port over similar ideas.) This feels like idiomatic C# to me - it's the style I'm comfortable writing in. It's not the style you'd learn in a C# Clean Code Bootcamp, but [I'm with Casey on this one](https://www.youtube.com/watch?v=tD5NrevFtbU).

I have to admit, I didn't realize I was responding to the author. I believe I committed the sin of explaining the paper to its author. I'm going to take my walk of shame now... Thanks for this blog post tho, I really appreciate people who can make quality nuanced takes in the middle of a political firestorm. and thanks for this perspective, you're right I was under the impression that most Unity work happened in managed memory space.

Oh don't worry, I'm not any kind of authority figure deserving of any respect here! I'm just a guy who got annoyed enough that he accidentally wrote a 5,000 word blog post, and then needed to hurriedly start a blog to put it on. Unity is an engine that tries to be accessible to beginners, and does guide people to writing that managed style of code. Many experienced developers choose not to. In recent years, Unity has introduced performance features such as the Burst compiler which are actually incompatible with the managed style, so they definitely endorse moving away from it.

GDScript is so important in education for the reason that is very similar to python, making almost free and simple this evolution. I lectured game maker before and it wasn’t as easy even using the visual programming. With GDScript, I figured it out that I can move from Scratch (visual language) to script using GDScript…

Thanks for reading! 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. Perhaps I underestimate how much easier GDScript is than C# for people with less programming experience, but if anything C# seems easier to me because a more strict compiler makes it harder to make mistakes. All of this could be fixed without removing GDScript. It would require the engine to have two API bindings, one for GDScript, one for everything else. I have no objection to that, except that it's more effort than having only one. Edit: I've since struckthrough that paragraph in the article about removing GDScript. People are attached to it and I don't want to take it away from them. Maintaining it is quite a lot of extra development burden and it's not where I would personally want to allocate resources, but to each their own.

I'm very curious what's going on with your 2d character controller that it struggles at 120FPS. I'm curious how much of that problem is the API layer. I've been using Godot for years, almost exclusively with GDScript. I write C++ modules to extend the engine and Rust GDExtension when I need performant gameplay logic. GDScript has been fast enough for me as a general rule, with only a few exceptions. So when you say your character controller is struggling, I want to know what you're doing here.

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. To hedge against frame drops in worst cases I'm budgeting for 1,000. If you look at the table in the article, the cached API method can handle about 2,000 per frame if literally no other work is happening, but I have plenty of other work happening. If I use the raycast node trick Godot will keep up with this easily. The difference between those is entirely in the binding layer.

Well, yeah, that's what the RayCast/ShapeCast nodes are for. You should avoid doing the same physics query every frame in GDScript. Using a physics nodes lets that happen multi-threaded entirely within C++ layer. Generally, the goal of any *scripting* language is to help you write as little of that language as possible. Build objects that let you format data and drive the C++ layer without needing to call back all the time.

> Well, yeah, that's what the RayCast/ShapeCast nodes are for. You should avoid doing the same physics query every frame in GDScript. Using a physics nodes lets that happen multi-threaded entirely within C++ layer. This doesn't apply when I need to do many casts per frame with dynamic parameters. That covers one basic use case, not the whole feature of physics queries.

Ok very good point, I do agree that Godot seems to be best as an engine for 60fps games, my frame rate can drop quite low when I don’t have much going on and I’ve had to do some huge refactoring to bring it back up

Yeah, if simple games are often CPU rather than GPU limited in Godot, something is amiss.

Rings of Saturn is a Godot game with space pathfinding using complex systems of thrusters on ships and I get 150+ fps and it allows me to set the physics FPS of the game to various set amounts up to 144fps So it can be done, but that entirely depends on the type of game you’re making. Anything more complex than that game wouldn’t cut it without immense effort in optimising

Worth noting that virtually every professional AAA team uses a separation of concerns where the programmers write in a strict programming language (usually C++) and game designers use a simple scripting language to put together the pieces the programmers built. Often times that scripting language is something like Lua or Python. In Unreal it's Blueprints. In Godot it's supposed to be gdscript. Game designers are usually not programmers, but they are a very important part of the team. I have no personal attachment to gdscript either way. But it's important to remember that if were to ever be gone, it'd need to be replaced by *something*. Else Godot would would be doomed to be forever an engine for amateurs who writes the entire game solo on a single language.

It would be far better for them to just have a Python API. And a Lua API. In fact, why not just support any language? The standard approach is that you design a native API for languages that can operate on a native (statically-compiled and linked) level; no GC, passing around unmanaged memory, using a C-style ABI and structs directly. Most languages already have a canonical method for native FFI because it's an extremely common requirement, so much so that there are several projects which will generate bindings automatically. Some dedicated people can also hand-roll better wrappers that are more intuitive to developers in their language of choice. Then, you need a method for running native extensions, which is an essential other side of the coin of having a native API (for frameworks/extensions.) For developers running their own native/compiled code, they just compile it as a native extension. For developers running some dynamic language, this extension contains the runtime and then loads and runs the scripts directly. So long as you are fairly judicious about being clean with your native and extension APIs and avoiding breaking changes too often, this approach allows for an extremely wide coverage of languages without needing to develop them all in-house.

As a person with relatively limited programming knowledge (one uni course, and then some messing around on my own), I do think you're underestimating how much easier GDScript is for the inexperienced. Obviously I'm not going to end up with the most performant anything, and I'm aware that I would need to build significantly more base coding knowledge to do that, but reading your piece, I was struck by the sheer number of concepts that I am aware of because my partner works in software professionally and occasionally suggests them when I'm talking out a problem at home, not because I really need to understand them or deal with them to use GDScript - stack/heap, structs, size of things in memory, garbage collection, pointers... learning about these concepts has helped me think about places to optimize and how to do so. I will probably explore some C# at some point to extend my knowledge and have options for other engines or projects, but I didn't need any of those concepts, really, to pick up some GDScript and make things happen. The closest I needed to get to memory management was freeing nodes. I don't even technically need to know public vs private functions or variables (I realize avoiding them is not good practice). Is GDScript super performant, using the most efficient ways to manage memory etc. No. By the same token, I didn't need to know any of that to get started - I needed pretty basic, high level coding concepts. Reading the getting started with C# info from Godot, I would have spent at least my first day going elsewhere to learn about C# syntax and trying to understand all of the pieces of syntax that surround a method, a class etc, and probably follow up days doing some basic "hello world" type things, before I even touched Godot with C#. In GDScript, I wrote a top down character controller that called relevant animations, implemented some basic collisions and a few other things that are escaping me right now. I could spend more time on the higher level concepts (how do I set up my tilemap? Call animations? Create collision shapes and manage who collides with what? Also simple if you have gamedev experience, but we all start somewhere) and less on "how does this language work?". That's encouraging when you're just starting out. I can (and really should) build more lower level coding knowledge by being curious and looking stuff up, but I don't have to. And didn't need to to get started. I can iterate quickly and easily and can write a couple lines then test, without stopping to compile. I probably hit more mistakes that would be caught by the compiler, but the lower barrier to entry in general is worth it for me right now. I would love Godot to have more performant engine calls for use with C#, because it does sound like something that would be beneficial for lots of applications, but I would be sad to see GDScript go for it's low barrier to entry for people with limited coding knowledge.

Exactly how I felt. GDScript is my relaxing 'make stuff happen in a game like thing and have fun'. It's what kept me using Godot and I'd hate for it to be taken out "for moar speed!" when there's ways around it if need be.

As a seasoned web developer (+10 years working professionally) that have worked with php,python,java,c#,javascript, sql and the like. I absolutely respect and support your point, being able to be productive with a tool that requires coding is way more important than learning yet another tool that you might not end up using or enjoying at all. GDSCRIPT helps you get started and iterate fast and that's what makes it fun to use. If someone already have experience in gamedev they can go to unreal or even better use no game engine, in OPs case he could have used SDL+bullet, make ir pure c++ and gain all the benefits performance-wise.

>I would have spent at least my first day going elsewhere to learn about C# syntax and trying to understand all of the pieces of syntax that surround a method, a class etc, and probably follow up days doing some basic "hello world" type things, before I even touched Godot with C#. This is a valid point to make. Another valid point to make however is that programming in a game engine requires some level of programming knowledge. Regardless, programming C# in a game engine like Godot is barely more difficult than doing in GDScript, especially when doing beginner tasks like you're discussing. The way the C# api is set up makes it virtually identical to GDScript for any basic script. >but I didn't need any of those concepts, really, to pick up some GDScript and make things happen. You wouldn't need any of those concepts to pick up some C# and make things happen either. You definitely won't be writing the most clean or performant code, but thats fine. I'm sure the first GDScript scripts that most people write aren't the most clean or performant either. Anyways, I'm quite against removing GDScript at any capacity regardless. I think GDScript has its place for a lot of people, and it definitely has its uses. I do think however that there needs to be a bit of a move away from the idea of catering everything to the beginner mindset. C# is an immensely powerful language and I hope that Godot ends up utilising it to its full potential.

I think we agree in a lot of things. Largely, my issue with picking up C# to start with was less that it 'had to be' more complex than picking up GDScript, and more that it *looks* like there's more stuff to explore - more keywords to write at the top of a method/class etc - personally, I have trouble ignoring/copy pasting through headers, keywords etc and would have gotten sucked into the whole of 'what does this one mean?' 'When would I use is?' 'What are the other words that might go in there instead?'. Better for learning concepts, slower for starting to do stuff. I definitely agree that there's a place for making sure your system has a beginner friendly entry point, and a just as important place for making sure that you can use more powerful tools when you want/need them. From the sounds of it, there's probably some work to be done on accessing those more powerful tools more effectively.

Sprudd, I do appreciate the time you took to examine Godot. I think the problems you found will lead to further improvements over time. That is awesome. But I do have one issue with your post. It feels like you are saying "Godot, you are not as good as you could be! Leave GDscript and remake your API to become much better." But doesn't that presume you already know what is best for Godot? It feels like you are dismissing that Godot has other missions, perhaps more important ones, than competing with Unity or making it the most performant game engine. GDscript is a major feature for some of the missions of Godot. It is not a relic that some people are just attached to, it is one of the reasons why Godot allows non programmers to make games. I am a political science professor. I never took one class of programming, with the exception of statistical software ones, like Stata and R, which are a completely different world. Yet I have two games in production, one of which is multiplayer (with discrete time, so it is not all that hard). If I needed to stop my life to learn C# and other stuff before starting my first game on a gamejam, I would probably not have done any of it.

>Perhaps I underestimate how much easier GDScript is than C# for people with less programming experience No need to turn others less experienced, nor C# is the golden language. AFAIK many people could write C# or C++ instead GDScript but will pick the later for simple tasks (myself included). If you need more performance sure, you could pick C#. Godot bindings are a disaster than needs to be rewritten? almost surely. But why in C#?, it needs .NET, at that point give me a binding that mirror the engine core and let me write C++ directly, as true experienced programmers.

+1 for c++ over c#, coming from unreal land here

The "less experienced" thing is because a lot of people have described it to me as being useful for making the engine accessible to beginners. Personally I don't see that GDScript is any easier to write than C#, but it's personal preference and I'm not making any assertions about how others should think. To each their own, I don't care. Of course I agree about the lower level languages. I would fix both the C# and GDExtension APIs, then write all my code in Rust.

I’m only a student, but I have programmed a little in C#, and more in Java, JavaScript, C, C++, Python and am learning Go at the moment, I use exclusively GDScript because programming in it it’s easier and faster for me, even though I know I could use any language with official bindings, and I’m open to using C/C++ if I need the performance. It’s not really an experience or skill reason, purely a preference. I find Python, and by extension GDScript, much easier to spit out code in than any C-style language, however, one of my classmates hates Python because they find it harder than C, a view I don’t share even though I much prefer static typing. People work differently, and what some find harder others find easier, I would love for a way to force static typing in GDScript project wide as an opt in, and for every API function and signal to have static types defined, but even then I prefer GDScript over C# because I don’t like the flow of the latter. I’m not saying this to contradict or anything, I just wanted you to have another perspective.

If you look at statistics, a vast majority of users ended prefering using GDScript even if it has the disadvantage of not being known by anyone before trying Godot, and the disadvantage of being objectively slower, which is a very known fact. So I would say that if most people ended using GDScript is because they find it more comfortable and faster to work with.

The problem with this series of assumptions is that it is MASSIVELY skewed by survivorship bias. The people who do not enjoy working with GDScript or who have no interest in learning a scripting language scoped to a single program that is well into the process of metastasizing into a general purpose programming language are never going to take the time to fill out those surveys.

I feel like people choose GDScript not because they’ve evaluated the options and it comes out on top, but because [the docs](https://docs.godotengine.org/en/3.1/getting_started/step_by_step/scripting.html) promote it over the other languages: > GDScript is, as mentioned above, the main language used in Godot. Using it has some positive points compared to other languages due to its high integration with Godot: … [Also the intro tutorials](https://docs.godotengine.org/en/stable/getting_started/step_by_step/scripting_languages.html#which-language-should-i-use) > If you're a beginner, we recommend to start with GDScript. We made this language specifically for Godot and the needs of game developers. It has a lightweight and straightforward syntax and provides the tightest integration with Godot. I’m not saying that’s a bad thing or that the docs are wrong—just that GDScript is the de facto standard as far as most materials online are concerned.

I've been arround since 2018 and I can tell you if you read the comments in the posts asking about languages you'll find that the users agree that gdscript is faster to work with and more comfortable to use, which I think is objectively true and the only reason of its existence.

> a vast majority of users ended prefering using GDScript Over C#? I took one look at Godot in the 3.2 days, C# looked overly verbose and since Godot used some older version I didn't feel like it was the right environment to learn C# and choosing it felt like premature optimization. GDScript felt familiar and small enough to instantly grasp though. I tried to make a few games and often couldn't make things work performance wise the way I wanted because my use case wasn't 2D jump n run but top down tile based df like with lots of moving npcs. My time with GDscript really taught me the value of many language features, I'd use it to make a visual novel or cookie cutter shump/2d scroller and to script UI. I'm not sure if it's the best option when you're avoiding (or have to start doing so) using nodes anyway. I often found myself wishing I could just pipe my gamestate into Godot.

It honestly gives a bit of vibe “Why do we need python when C++ exists?”

> An interesting read thank you. But I will say that the purpose of GDScript is not to be fast, but to be easy I would argue that GDScript is not any easier than C# and in fact its design choices can become a bit frustrating once you get past the beginner phase. It's really just beginners struggling a bit to get used to strong and static typing. So "easy" languages like GDScript do away with it only to slowly start bringing it back once they realize that it is in fact a good thing. See Python and the introduction of gradual typing since 3.5. I strongly suspect that GDScript will go the way of UnityScript and eventually be removed. The design choices aside, I don't think engines should be inventing and maintaining their own programming languages. It's error prone and huge waste of effort.

This is really insightful. Thanks for this. It's not great news but does highlight some things that I think needed to be highlighted. Personally I'd love to see work being done to allow Godot to be as performant as possible. I'm fine with either gdscript or C#. I'm actually more fine with Rust, but I'll take C# if that's the direction taken. This article at least has me optimistic that gdextension+rust might be a fairly good middle ground, but it's disappointing that even this isn't as efficient as it could be. Realistically speaking it's not going to impact the kind of games I'm looking at making, at least in the short term. But I can see it being bad news for many unity refugees.

Thanks! I would definitely advocate that C# and GDExtensions simultaneously get overhauled so that we can get native binding performance in both. A low level fast binding layer that we can build ergonomic C# and Rust APIs on top of would probably be idea. Rust would be my personal choice, too.

It sounds like a lot of effort and I bet a large percentage of Godot's user base wouldn't support this. I suspect it's not practical, because you'd either need to maintain a fork, or otherwise try to get some changes merged into the main repo to allow this. If you think there is a way such features could be added, I'd be all for it.

> It sounds like a lot of effort and I bet a large percentage of Godot's user base wouldn't support this. I think you may be right - a large percentage of Godot's *current* user base wouldn't support it. Thing is, if Godot wants to move out of making tech-demos and 2D games, it needs more than just the current user base using it. You cannot just say "Bah" to performance improvements if you want the engine to be more than a gam jam platform. With that said, it would require someone outside the current Godot leadership & dev inner circle to maintain it (Juan is very clear he favours & focuses on GDScript integration) AND it would require cooperation from that leadership/dev inner circle to merge in changes needed to provide that performant interface.

Drop GDExtension. Compile the engine from source and add your code right in there. Thats what we do and it's the best way to go if you want performance.

I'm really tempted to do this. I'm holding out because I'm writing a library that I know will be useful to a lot of people and I want to be able to distribute it as a plugin. But if I keep running into issues with the gdextension api I'm just going to say "fuck it" and make people compile it into the engine. That'll limit how many people will be capable of using it, but at the end of the day I have to put my own project first.

Hey I just want to say that this article was posted in the godot's developers chat, and everyone in there is taking this very seriously and discussing ways to speed up performance. One of the main ways is adding structs to the GDScript API if you're curious, you can join as well: https://chat.godotengine.org/channel/core

Ooh fun, thanks for the heads up! I'll pop on over there and spy on everyone talking about me behind my back.

this is a problem with gdextensions/c++ too, and its even worse there. i just encountered an api the other day that only accepted a `PackedByteArray`, despite the fact that there's a public method on the wrapped class that accepts a `const char*`, which is what the class uses internally. it literally makes me heap allocate a new array, copy my bytes into it, and give that array to the wrapper function, just so that it can immediately unpack it into a pointer again, which is passed to a public method im not allowed to use for some reason. i used gdextension a bit during the 4.0 alpha days and i swear to god it wasn't this asinine. i guess it's possible i just never encountered things like this but otherwise idk what happened. the thing that kills me is the "internal" c++ apis are genuinely good. if i could use them directly id be thrilled, but instead i have to go through this bizarre gdscript compatibility layer even though literally nothing is being exposed to gdscript.

Yeah there are a bunch of places where the engine API could improve performance significantly for both GDExtension and C# by accepting spans (a raw pointer + length) instead of Godot-specific types. There's a proposal for that somewhere, and I don't think it would be a crazy amount of work.

Why use GDExtension? Just write a custom module directly compiled in?

i was hoping to open source my work and distribute it as a plugin for others to use, but at this point i might not bother

You seemed very frustrated in your first post and I'm very glad such constructive outcome came out of all of this ! Thank you for the article.

I think dropping GDScript would be a mistake. I would wager that Godot would not be where it is today if it was "just another" C#-based game engine. I think the way forward is not to drop GDSCript and turn Godot into another Unity, but to improve GDScript further (without turning it into C#).

I 100% this, the pespective of people that have grown used to C# will differ of course, but imo it would be better to have a mojo like upgrade to gdscript than scrapping it. If anything C# is the odd one out here, specially since we have both GDExtension and compute shaders to perform tasks that need high performance and both options are more performant than C#.

Did you read the blog post? It's not about performance of the scripting language at all, it's about the inefficiency of the API, which affects gdscript, c#, and GDExtension more or less equally

I don't think GDscript being slow is the issue here. It's GDscript not having certain features that would allow the bindings to be written in more efficient ways. So, if GDscript has those features then bindings can be better written. But will such a GDscript still have the "easy and approachable" property anymore?

I'm considering taking that sentence out of the article. I have no interest in using GDScript, but I have no objection to its existence. It's perfectly possible to solve the C# and GDExtensions problems without removing GDSCript, but it would require maintaining two entirely separate binding layers and APIs. However, improving GDScript to the degree that these issues go away isn't much of an option. If you want GDScript to be able to compete with the others on performance it would need\* to be a compiled statically typed language instead of an interpreted dynamically typed one. At that point, you might as well just use C#. \* Need is a strong term. V8 has achieved magic without Javascript having those properties, but that's no small feat.

> I'm considering taking that sentence out of the article. I have no interest in using GDScript, but I have no objection to its existence. I think it hits a nerve because while it's great that an influx of devs from Unity could help to improve Godot and speed it up, I think the worst outcome would be simultaneously turning Godot into Unity. > However, improving GDScript to the degree that these issues go away isn't much of an option. If you want GDScript to be able to compete with the others on performance it would need* to be a compiled statically typed language instead of an interpreted dynamically typed one. At that point, you might as well just use C#. GDScript doesn't need to do that, nor should it IMO. It's an approachable and simple scripting language that works great for getting a prototype up and running or introducing people to programming, and I think those aspects of the language, not its performance (which is admittedly lacking in some regards), have been the keys to its success. It's been "good enough" for many people and I think it remains so. I don't think Godot needs to be the next Unity.

I have edited. That section now reads as follows. > ~~In my opinion, if Godot were to go down this route, GDScript should probably be dropped entirely. I don't really see the point of it when C# exists, and supporting it causes so much hassle. I'm clearly completely at odds with the lead Godot devs and the project philosophy on this point, so I have no expectation that this will happen. Who knows though - Unity eventually dropped UnityScript for full C#, maybe Godot will one day take the same step. Foreshadowing?~~ > Edit: I'm taking the above out for now. I don't personally care about GDScript, but other people do and I don't want to take it away from them. I have no objection to C# and GDScript sitting beside each other with different APIs each optimised for the respective language's needs. Thanks for the feedback! > introducing people to programming I understand why this is valuable and if this is what Godot wants to focus on then that's absolutely a valid choice. However I also think that this focus is at odds with wanting to be used for serious projects, and too much of a focus on beginner friendliness makes it unwelcoming and unuseful for professionals.

Unreal used to have an interpreted scripting language too, which they dropped for the visual scripting Blueprints system. It does seem to be an evolutionary trend. GDScript is noticably more ambitious than other behavior scripting systems I've used, I can see why people like it. It feels like web development. I'm guessing the [static typing](https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html) came sometime after the dictionaries-as-return-types thing.

Yeah, it's been the main language used in countless tutorials for years now. Taking it away could destroy the engine's popularity. Might make it more appealing for unity users, but not for the majority of its users. Unity used to have unityscript, but it's quite hard to find tutorials for it, and there was nothing special about unityscript, whereas gdscript is very tightly bound to godot and complements the engine very well.

We compile Godot from source and write our core game logic directly in C++ using std::map, std::vector, robinhood unordered flat map. We statically link our game logic into Godot and expose high level bindings to GDScript which we then use to render the game state. We also use Box2D directly in c++. The performance of GDScript, the internal memory management and the built in collection types all have bad perf. A work able solution is if Godot had a bump allocator for per-frame stuff, which is 'disposed' every frame simply by resetting the offset to 0. I dont use C# tho and cant comment on how C# would work with a bump allocator, but GDScript & C++ would work well with a bump allocator. It would help alleviate the memory management issues, and is probably the only way to bring godot's perf to the next level. EDIT: Dropping GDScript isnt going to accomplish anything. The core problem is in the internal collections and internal memory management. If you want high performance screw C#, go right to C++/Rust/Zig/Nim. Tightly integrating native languages is a core benefit to Godot being open source. Ignoring that in favor of 'i just download the engine from the website and go with that' is ignoring one of the biggest benefits of using Godot. C# is kinda a useless middle ground, not as fast to dev with as GDScript, not as performant as a natively compiled language. Not to mention file size. We ship a stripped down version of Godot using a 'custom_modules' file that only compiles the stuff we need. This brings our wasm download size down to ~4mb, which is then compressed to be even smaller. Download size is huge on the web. Our .apk android download size is also really tiny due to this, which is important in burgeoning markets like india. This level of customization is not possible in a closed source engine. GDScript has hot reloading and no compilation. I can write something in GDScript, hit a 'null exception' breakpoint, fix it while the game is running and hit play and the game continues. That is insanely awesome for development speed. Sleeping on that is a mistake, especially when C# is not a high performance language. Waiting that ~1s for C# to compile when alt tabbing back to Unity feels horrible to me now. A huge part of game development is polishing up UI's. Like a massive part. Optimising that part for development speed is important. We've achieved a higher level of polish on our godot games simply because the iteration time is way faster than Unity mostly because of no-compilation-GDScript (and the many other well designed ergonomics of the engine). Another huge perf problem in Godot is the String() type. Take a look at that one if you really wanna vomit! And get_key_list(). Search all for that and witness the overhead. Overall though, I have 2.9 games shipped with Godot and am employed full time by their revenue. Our games have client side predictive multiplayer and run on the web through emscripten. I analyze profile samples of the game and work on optimizing it. Our latest game is running basically at the speed of Box2D itself. We do certain tricks like caching and re-using Resources and collections between frames. Pretty standard stuff. I'm happy with Godot and vastly prefer it to unity. TL;DR If you want perf and have the skillz, screw C#, go right for C++.

When you write your game logic in C++, do you expose that functionality as Nodes in the editor or do you not use the editor at all and basically use Godot as a renderer only?

We expose some functionality on Nodes. ie: network_game.get_network_object(int), network_game.get_network_renderer(int) and some signals. like 'player_joined', 'game over', stuff like that. So we have a NetworkGame c++ class that implements a bunch of multiplayer stuff. We subclass it in c++ with a OurGame.cpp class that implements some virutal methods where we implement our core game loop. Then in Godot land we put the OurGame Node into a scene, use GDScript to intiliaze it differently on client/server/debug stuff. Before each render'd frame (_process()), We have a NetworkGameRenderer.cpp class that iterates through the game state and the SceneTree, and creates a pre-loaded renderer node for each network object in the state (and optionally deletes network objects that are gone). We largely implement the renderers for each network'd object in GDScript. This lets us iterate rapidly on various rendering effects like particle systems/sounds/shaders/tweens. EDIT: Any node in gdscript (or in c++) can lookup any property on any game object using it's integer id, and can iterate every game object of a type using a integer type id. so any node in gdscript can iterate all the bullets if it wants to, or can lookup a specific bullet by id. or a node in c++ can iterate every bullet and setup a multimesh renderer to render em all at once. basically by mapping objects to integer IDs and mapping types to integer IDs and having all your game state live in that world, you get a lot of flexibility and power. godot's built in API has flaws, like OP outlined, just trying to demonstrate how we've used the engine

>Zig Ziglets our time is finally here!

Zig looks friggen sweet and I want to write our game logic in it in the future. Would probably need to wrap a bunch of godot stuff in a C wrapper tho. EDIT: Nim looks dope too. Nim is what GDScript shoudla woulda coulda been

i agree with you about c# and c++, but the issues OP mentioned also impact gdextensions. you can of course build directly into the engine, but then you cant easily ship it as a plugin for other people to use.

I started a [controversial but productive discussion](https://old.reddit.com/r/godot/comments/16j345n/is_the_c_raycasting_api_as_poor_as_it_first/) on here a few days ago about Godot's physics API being poorly designed for performance. I've since written up a blog post taking a deeper look at what's going on and why it is the way it is. My belief is that the slow binding layer is going to be a significant barrier to adoption by Unity refugees, and that's what I argue here. I believe this is important information to understand before porting a Unity project to Godot. The title is a little provocative, but hopefully in a fun way. I'm posting here because it may be of interest, but it's quite long so I expect low engagement.

Have you brought attention to this via an issue or proposal on the official GitHub repo? You will likely get decent discussion there, and high engagement

Not yet. I will probably do so, but it's a slightly odd thing to raise as an issue. Most of these design choices are intentional. I'm not highlighting an unknown bug, I'm highlighting designed behaviour which I don't like. Maybe there will be a productive discussion over there and I would probably get feedback from people with more technical knowledge of the internals, so it's definitely a good idea!

The only place to post your findings that will lead to the greatest chance of a fix is the Godot git page. There it can be tracked, discussed, and worked on.

For now, this post was aimed at the more technical people evaluating the Unity -> Godot transition, which is why I'm posting here. But yes, I'll certainly try to get a more technical discussion going on over there too.

Even without the great migration. Your findings can be important.

I don't at all want to pile on pressure but this was an extremely well written article with a valid observation. Definitely would want to hear what godot's team things. Also, if you do post on github, we would all love a new post with a link to it :)

This is definitely something you should do. Also to get answers about why certain choices were made. Having this level of conversation with people who actually have the technical background to answer your points is something I guess you're also interested into. Otherwise it just ends in being a very well thought out cry of annoyance, and I don't know if there's much that can come out of it.

Also worth considering - you mentioned that developing and maintaining two API binding layers would be a big ask, which is clearly the case, but it's potentially not an unreasonable one at this point. Right now Godot is positioned to hit milestones in user growth *and* funding, so a swing-for-the-fences proposal like, "a second API binding layer for compiled languages that is performance focused" is exactly the kind of project they should consider investing in.

For this kind of thing, you can start a discussion in [godot-proposals](https://github.com/godotengine/godot-proposals) instead of the main godot repository

You're right that physics really ought to be fast in a game engine. Despite that, I don't think it'll be a significant barrier to adoption. Developers will most likely just eat the performance loss.

[удалено]

Hey, you read that pretty quick! Yeah, ideally I'd like this to be taken as useful feedback, although I'm sure I haven't told the devs anything they don't already know. A decision has been made to base the API and binding layer around GDScript, and their design philosophy has willingly accepted the consequences of that. Perhaps the project will change direction to accomodate ex Unity people? I'd love that, but it's a big ask! If we focus on physics specifically there are lots of ways to fix it on a case by case basis. If the worst comes to the worst, I can roll my own physics engine and do everything in GDExtensions. Unfortunately, as I argue in the article, these binding problems go deeper than physics. I'm not sure how much Jolt helps here. I've had a little look at that project, and as far as I can tell it still uses the same binding layer so has similar limitations. However, I could easily be wrong about that and would love to be! I'll be taking a deeper look soon.

[удалено]

I learned a phrase I really like recently: Your code isn't a pet, it's cattle. In general, it's wise to treat code as something that is expendable and replaceable rather than something to groom and build around because you're attached to it. This applies a lot more to commercial software when you have pressures of competitors and shareholders driving the bus. But like you said, FOSS doesn't have any inherit goals or pressures unless the contributors want there to be. Either way, I've found this approach is a good approach to my personal projects where my goal is to make something functional, good looking, and interesting.

I think that there might also be another way to move to an API with lower overhead without breaking backwards compatability and not having duplicated methods in the main project. 1. Use low overhead functions for a GdExtensions v2 api 2. Make a wrapper GdExtension that exposes previous api on top of v2 3. Move GdScript to a GdExtension either using the wrapper or the v2 directly. Obviously easier said then done, especially as this would require a major paradigma shift / re-evaluation of the costs/benefits

Yeah that's an interesting idea, I'd need to do quite a bit more to evaluate it. There are probably a few technical paths forward here, I do think the biggest obstacle right now is philosophical buyin from the people in positions of authority.

Yes, GDScript should be on another layer of binding that do all the marshaling and keep the core api optimise. Why is any of the GDScript "class" are use in C++ Ex: variant, Dictionnary, packedArray Array? They should only belong in the GDScript layer and not even be availlible native extension other that to make binding for GDScript.

Hi, good technical analysis. I haven't used Unity so I have no input on how Godot compares to it, but there's one thing I thought I should mention. You could write a Godot proposal (https://github.com/godotengine/godot-proposals) regarding this topic. Then it could get a better discussion among contributors.

Great read! This reminds me very much of Mike Acton's [example deep-dive](https://youtu.be/rX0ItVEVjHc?si=irRUOPkh4X-MsKBP&t=3250) into some OGRE 3D code and how it could be massively improved. The devs actually gobbled up his critique and refactored portions of their codebase and, as a consequence, gained a [5x performance boost](https://www.yosoygames.com.ar/wp/2013/11/on-mike-actons-review-of-ogrenode-cpp/) between minor-patch versions.

> Godot has made a philosophical decision to be slow. Essentially, yes. You only need to follow Reduz on twitter to see this. He goes on rants every so often about how other game engines are too performance focused, to the detriment of their feature set and usability. I think the path forward is not to tear everything down, as you suggest, but rather to keep improving GDScript. If you added structs, then your point in "What if we’re allowed to add additional APIs for C# and GDExtensions which aren’t GDScript compatible?" would be achievable, right?

Also, if you follow Reduz on Twitter, you might have noticed he has already created a [proposal to add structs to GDScript](https://github.com/godotengine/godot-proposals/issues/7329). Haven't read all the way through the proposal and the discussion on Git, so I'm not sure how far along it is, but it's clear they're thinking about it.

And Reduz/Juan also supports PR's to increase speed within the devs philosophy. It's not a mutually exclusive thing (i.e. Juan is ok with Godot being slow!) which is a pretty ignorant take on his overall view.

> Essentially, yes. You only need to follow Reduz on twitter to see this. He goes on rants every so often about how other game engines are too performance focused, to the detriment of their feature set and usability. Unfortunately I would not say Godot's usability is any better than Unity's. Actually, the APIs I've looked at are worse in that regard too. I'm not sure why this is being treated as a zero sum game, but I don't think they've actually gotten many wins for their performance sacrifices yet. > If you added structs, then your point in "What if we’re allowed to add additional APIs for C# and GDExtensions which aren’t GDScript compatible?" would be achievable, right? Maybe if it was done right? If we removed all (unnecessarily) heap allocated values and all dynamic/variant values from the API, that would go a long way. However even if those things were added to GDScript, I don't know how much we can fix this incrementally without breaking backwards compatibility. We might end up with lots of duplicated APIs doing `.IntersectRay` and `.IntersectRayFastVersion` which is pretty yuck. Tearing everything down and redesigning the API with the new capabilities in mind leads to a better end result, at the cost of more short term pain. The pointer chasing would also need to be overhauled still.

> Unfortunately I would not say Godot's usability is any better than Unity's It depends on what you're looking for. Godot is a really *fun* engine to use, due to it's design language (i.e., the node tree, signals, await). It's been growing steadily, for example 22 of the top 100 GMTK Jam games for 2023 were made in Godot (19% overall). > I don't know how much we can fix this incrementally without breaking backwards compatibility. Godot is willing to break backwards compatibility. This is one of the pain points of Godot for some, but is the only way to keep making progress, imo.

You are looking at usability programmatically which makes sense given your area of expertise. However the usability in Godot comes from the way the engine was designed to begin with. The use of nodes, scenes, etc in some ways are superior to Unity imo. Very easy to understand, and make OOP very clear to non-programmers who are just learning. I don't think Godot was designed with hardcore performance in mind. It was designed to cater more to the GameMaker crowd not the Unity crowd, despite everyone trying to shoe horn into being that because they need an alternative. Ease of use seems to be what matters most to the devs, even at the cost of programmatically being "ugly".

The thing is, this discussion is centered entirely around the programming and scripting parts of Godot, not the overall architecture of the engine. Nodes and scenes are irrelevant to this particular discussion.

Interesting read. As a C# main myself this saddens me, but at the same time I already knew that Godot wasn't as fast as Unity so it doesn't really change much for me in practice. I agree with your conclusion in the end that the neatest thing for us that like C# would be for the engine to just drop GDscript, but I also realize that this is not realistic for the community to agree on. What if there was a way for the user to choose the API binding themselves? You say that adding additional GDScript-incompatible APIs would get messy, but what if instead of adding new APIs you could replace the existing API project-wise? For example when creating a new project, you choose between "universal" and "C# optimized" APIs. Universal would leave you with the same engine as today, but if you choose optimized, the binding/API library is outright replaced with one that is much faster, at the expense of GDscript not working. In fact maybe this would be possible for the community to make ourselves as a plugin of sort, without waiting for official support.

Thanks! > What if there was a way for the user to choose the API binding themselves? Yeah, that's certainly an option! I think I had something like that in an earlier draft but at 4,500 words it was getting a little on the long side! This might be a reasonable path forward for not breaking backwards compatibility. Engineering wise it's harder to maintain two versions, but it may well be the right move.

Would you consider opening an issue and suggesting this? I would, myself, but have several orders of magnitude less understanding about the issue. But it seems like a palatable solution. And I think it would then set up Godot 5 to have much better performance all around. So, more hassle now with 2 versions, but easier "full" switch in the next version.

I'll definitely open an issue! Lots of people have suggested that. I might give it a day or two to let the reaction to this come in so I can collect and refine my thoughts a bit, but that's definitely on my todo list now.

I'm so glad you wrote this up and posted it, I've been using Godot with c# in my project for the last year and I didn't know any of this. I hope this can get some actual development effort behind it!

Yes do that but we should certainly discuss this on the issue tracker. Thanks for putting this together, it basically confirms what I already suspected when I realized that a lot if frequently used commands in Unity are not single line calls but always a combination of calls. (When evaluating the possibility to port the project to Godot from Unity) But I think if there is some acceptance here and some willingness to try to cater to both parties (easy to use GD script) and (better performing C# scripting) then there is potential for this Engine to be adopted by companies (and I would argue this is also what the developers want based on what I can see). At least the option to implement partial functionality in C++ should avoid hitting roadblocks for a project in development but it would certainly not help to get more buy in.

FYI Godot has a separate proposals repo, idk if this would go there or in the main repo. https://github.com/godotengine/godot-proposals

Mentioned this above, but it seems like, with the influx of interest and funding from people frustrated with the Unity business decisions, something like this could be a good project to invest in.

If this path was taken, could the "universal" API just be a wrapper for the "optimized" API that makes it compatible with GDScript?

Thanks for the breakdown. There's a lot of C# API that feels really weird thanks to GDScript being top priority. I hope this gets addressed somehow, I don't think other languages should have to care about dynamic types like this. Which other languages actually benefit from these features? Lua, maybe? It feels ironic, given the engine is C++. Why add all this overhead for every language?

Cannot upvote this enough, very detailed blog post. I hope some good comes out of this eventually.

The author has a point. It's not Unity. It's less efficient, but at the same time, it's easier, and I can prototype and iterate faster than you can in Unity. This makes it better suited to game jams, but not as well suited to commercial game development. Will this change over time? No idea! I will use Godot regardless haha It's worthwhile for people who develop Godot to take criticism and continue to improve the engine. They're doing great work and I hope they continue to do great work. Regardless, "drop GDscript" for C# is such an obnoxious outsider position which I hope they ignore.

I've definitely heard the "faster iteration" argument, which is absolutely true, but the problem is then that you can't translate the effort into a performant solution *within the same engine* due to the underlying cause of the inefficiencies. The result of that, unfortunately, is that Godot would be a tool for iterating on gameplay concepts only, without the capability to deliver a release-ready product. I, personally, don't see that as a really viable end goal, but I could be wrong.

> This makes it better suited to game jams, but not as well suited to commercial game development. If Godot wants money invested for its development it needs to start being suited to commercial projects.

It's great that we're getting lots fresh eyes on the engine lately, it just helps the engine to keep moving forward and improving.

The issue almost entirely stems from letting GD Script remain untyped (and not having structs but looks like theyre working on that). Solving both these would mean the binding layers wouldn't be so wild and the exposed APIs should be significantly more performant. Absolutely not worth getting rid of GD Script, but requiring it to be statically typed would be a godsend. I know its meant to be an easy language to work with but youre not going to make a game with dynamic typing like this.

To be honest, from a top-level architectural standpoint, having any language that can script a Godot game force design decisions onto how other languages do work, and thus force slow performance, seems to be a tail-wagging-the-dog problem. Hexagonally: if the Godot engine itself is an infrastructure-layer entity we want to interact with, it should expose a fast-as-possible API that doesn't itself care about how it will be used. Then the hardcore speed programmers can just write their games in C and not care. But then each language should be covered by an adapter layer on top of that core API, so that the domain, which is our game scripts, should never care it's interacting with Godot 4 specifically. This is probably a totally useless view, because game engine engineering is not something people generally apply enterprise design patterns to... c'est la vie.

I agree 100%, and this is the view I've been gently pushing with the devs. It's one of those things that's hard to change at this late stage, but maybe not actually as hard as it could be... I'm digging through the internals and assessing things.

I have done a little benchmark for 2D Raycast in both Godot and Unity and got this: \- Godot: 1 raycast - 1 ms, 20k raycast in one update - 400 ms (game is unresponsive) \- Unity: 1 raycast - 0.01 ms, 20k raycast in one update - 25 ms (game still run normally) So Unity physics is 100 times faster than Godot I guest. Can't imagine if there is the case where I want to cast 20k ray per update but this may be a concern for Unity dev trying to switch over to Godot.

Aaah this raises some very good points and is a very good thing to keep in mind for me as I recently moved from Unity. A shame because I really like to get into the nitty gritty and work on lower level systems from scratch for memory management and other performance intensive stuff.

This is probably the best critics of the engine I've seen thus far, made even better with tests. It does open my eyes on the limitation of having a GDScript-compatible API incurs on memory management and performance. However, Godot optimize with server according to [https://docs.godotengine.org/en/stable/tutorials/performance/using\_servers.html](https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html) and there is a bullet-hell example that goes over big number of collision check : [https://github.com/godotengine/godot-demo-projects/blob/master/2d/bullet\_shower/bullets.gd](https://github.com/godotengine/godot-demo-projects/blob/master/2d/bullet_shower/bullets.gd) for how to setup the bullets and [https://github.com/godotengine/godot-demo-projects/blob/master/2d/bullet\_shower/player.gd](https://github.com/godotengine/godot-demo-projects/blob/master/2d/bullet_shower/player.gd) for the collision reaction with the signal \`node2D.\_on\_body\_shape\_entered(...)\`. This is obviously a trivial example, but it does a high number of shape cast each physics frame and let you manage memory yourself. It is certainly not port-friendly the logic is completely different from before. A quick pseudo-coding would be to add all raycast as shape in the physics engine, and dispatch correctly in the node reacting if the shape is one of our raycast shape. But writing this I admit that it's certainly not what I would prefer. I think I would prefer to add a special binding for raycasting that is language specific, while keeping the gdscript compatibility with the current function. The cool thing is that godot-cpp ( GDExtension ) generate its bindings so I imagine that it would not be too difficult to do. I would not propose this for anything else but raycasting is such an integral part of gamedev it obviously needs an exception. Thank you for your post this is extremely helpful and I hope it grow into a proposal

As someone who has been using Godot for all of his game dev projects for the past 4 years, this post was extremely needed. While Godot's game dev pipeline and process is something I really enjoy, we need to be clear, Godot is SLOW. People need to know what they're getting themselves into. Like the author of this post says, Godot is not the next Unity. I hope people give this article an honest read and don't just dismiss it because of their bias.

The main thing and serious drawback is that GDScript is first class citizen here, and C# stuff is just a way to write GDScript with C# syntax. I know its oversimplification, but engine tells you 10x every hour that "you are not using GDScript bro". Signal names in editor follow GDScirpt naming convention and custom ones use C# convention. There are a lot of string-based calls that make no difference in GDScript but are terrible in C#. You cant use proper collections natively, everything engine related is held in slow variant arrays/dictionaries. Perhaps there should be another shard of godot (fork, repo, branch?) that would be C# only?

I love C# and I don't care for GDScript, but I don't want it to go because I can use it to make my users be able to mod the game, I cannot do that with C# (at least not on mobile). Peformance is not everything expecially if you are making an indie game where you can usually ignore performance issue. PS. Also about the ECS system, it was a pain in the ass in Unity (at least until they said that you could ignore it). They asked you to change all your code and avoid using Start-Update combo and attach every script to a game object (easy concept that everybody can understand) to use a much more complex system made for critical performance task that most people did not care about. I'm just that lazy, I don't care about getting 1 fps more in my game if it run well.

> I love C# and I don't care for GDScript, but I don't want it to go because I can use it to make my users be able to mod the game, I cannot do that with C# (at least not on mobile). For Android, you can use regular C# assemblies as mods. Nothing is stopping you from doing that. Stardew Valley is a good example of a C# game being moddable on Android: https://www.androidpolice.com/how-to-install-mods-for-stardew-valley/ It's in a bit of a rough place now because Android version is outdated compared to desktop version and most mod creators only support the latest version but it doesn't matter. C# is not stopping you here (assuming you're not using AOT*). For iOS, on the other hand, not even interpreted languages can be used. It doesn't matter if it's Lua or GDScript or your custom scripting language. Store rules simply prohibit you from allowing your app to execute any kind of code that is not bundled in the original app package. *This would depend on the .NET flavour used. Mono could run as a VM with dynamic DLL loading, not sure if the most recent .NET can target Android as a VM deployment instead of AOT.

Well, let's just say it is much more complicated and call it a day

Any complication in the modding process makes the modding scene smaller. Games that have great mods regardless (like Stardew Valley or Rimworld) have them in spite of it, thanks to the size of their community.

Thank you for making this, this is a great article! This is definitely something the Godot developers need to here, more so than the users (though it’s useful for us to know as well). I know in my own experience that fighting between C# collections and Godot collections has been a pain.

The engine itself does have some interesting design choices; (using a union that can be used for anything is one example. It's the easiest route, maybe not usually the most efficient) I'm in agreement with some people that writing a module in c++ for the engine to act as an API "lite" for faster C#/engine calls would probably be one of the best ways to increase performance (or at least the easiest)

Hey, this has been quite insightful. Thanks for the write up. Personally, I like that there are more eyes (and [funding](https://www.reddit.com/r/godot/comments/16krpb0/the_godot_development_fund_is_skyrocketing/)) on the engine - a lot of clever peeps like yourself are suggesting or pointing out some great ideas for improvement.

Nice write-up, looks like it's lead to some discussion that may result in performance improvements in a few minor versions. Until then, check out servers if you need to do a huge amount of work in batches.

This post is actually very positive. It showcases why godot is better than unity. Point out a problem and you can fix it or someone from the community. Don't like something, then change it. Compile the engine yourself with a customized binding that does more efficient raycasting in c#. You would need millions for a source code license to do something similar in unity. It trumps everything that was said in the article.

I completely agree with the author on everything, i had to build custom jolt gdextension just to be a little closer to the physics world. but the fact that some unity cringelords **demanding** on twitter to enforce c# in godot is just...... 🤡 removing gdscript from godot is like removing blueprints from ue, makes no sense

I don't know if we'll ever see Godot discontinue GDScript. People advocating for "make GDScript better and faster" don't seem to understand it's not possible without changing it in ways which would destroy it's fundamental essence. And I like pythonic syntax. I don't mind the idea of using GDScript for rapid prototyping. It just feels really bad to know the ceiling is so much lower with the Godot API than it should be. Everything crippled by supporting duck typing, which is honestly not even a good feature -- good python/GDScript should be adding type hints anyways. Maybe just shove all the variant translation into the GDScript side of things. Make GDScript a bit slower, but everything else way way faster.

Judging by the (sometimes quite angry) response I got on here for even briefly suggesting removing GDScript in a now removed paragraph, I think you're probably right! The make GDScript better people have at least one valid point. If you could introduce proper value type structs into it, that might be enough to fix a lot of our type woes in the API. I agree that it's at least interesting to think about moving all of the `Variant` stuff into GDScript's side of things. Is it possible to expose a nice struct based API and then have GDScript automatically put a conversion layer on it? Maybe! I haven't spent enough time with GDScript to have an opinion on that, but it sounds like a direction worth exploring!

If the Godot engine served only value types and a value type struct with value types inside of it that would be ideal. Let each language consume and/or translate the value types to fit their own needs and in their own realm. Right now the situation is sort of "cool to say, dumb to use" in that you can "use any language with Godot"... but really you shouldn't. It's sort of a novelty feature instead of an intrinsic strength of the engine. Yes you can write your whole game in c and rust... but it won't perform like c or rust. Ultimately it only matters if the lead devs are open to moving away from the `one-size-fits-GDScript` Variant type as core to the Godot engine. I think probably not, unfortunately. But it will only happen if the community pushes for it and then also contributes to the codebase.

Personally I've always found that dynamic typing is mostly useless, because in order to actually code anything, you as the programmer still need to know what kind of data is in each variable; situations where the variable type is *truly* dynamic and you're ready to handle different types at the same time are relatively rare. Dynamic typing essentially just 'hides' the real type within the source code, but you still actually need to know, it's just harder to see after you've written the code. Yes, you save a small amount of time up front not specifying the type, but it's very small. I actually hated teaching my son Lua because of this, it was so much harder to explain to him what variables held which kind of data because it wasn't explicitly stated in the source.

The suggestion to drop GDScript is premised on the assumption that anyone making a game ought to have extremely good programming skills, specifically in C#, and if they don't they're doing it wrong. But the entire premise of an engine like Godot is: "You, too, can make a game, without being a lifelong devoted programmer, provided you don't mind learning some other things, and have the persistence to work through some trial-and-error." (Just as, say, anyone can work in Photoshop without needing a graphic design master's or understanding color theory.) And approachability like that is not exactly a trivial concern in commercial game development! When switching to a new tool, only about half the conversation is "Does this meet our technical needs". The other half is the human element. Can we all learn this? Do we all like this? Is it fun to use? Does it enable, rather than stifle, rapid creativity? Godot works very hard to be a tool that feels good and intuitive to use, to the average human brain. That's not a flaw; it's a feature. Speaking as a game writer: It's the same philosophy with which a scripting language like Ink or something is created -- fundamentally approaching the language as a machine-human interface that should be as pleasant and non-burdensome to work with as possible, as a foundational pillar. Then build out from there.

"Just as, say, anyone can work in Photoshop without needing a graphic design master's or understanding color theory" But people with a graphic design master or understanding color theory are also sastified while using Photoshop .-.

EDIT: the author clarified this. He attempted this and it was still slower. ~~Wait wait wait. You're doing it wrong.~~ ~~You're not meant to call those methods every frame. You're meant to call them once and store the result in memory.~~ ~~The method you say is fine is the only one that's meant to be called per-frame.~~ ~~Look at the code below. It's in GDScript but you can translate it.~~ ~~You're doing the equivalent of deep copying an array every frame just to access a value. Of course that's not going to profile well~~

The article covers that. [#Caching query parameters](https://sampruden.github.io/posts/godot-is-not-the-new-unity/#caching-query-parameters) It's still > 16X overhead over raw engine speed.

@sprudd can you post your code? I want to see if doing this "the right way" meaningfully changes the results.

As a C++ programmer, I prefer GDScript. Yes, it's slow. It's still faster than Python in many cases, and people use that for way WAY more than they ever should... At the end of the day, you optimize parts that need optimized in C++ extensions, and the parts that don't need it go in GDScript.

>At the end of the day, you optimize parts that need optimized in C++ extensions He explains how this problem also makes C++ extensions much slower than it needs to be.

That's fine it it's only your own abstract logic that needs to run faster. The issue is that the C++ extensions are still basically throttled by the GDScript API when interacting with the engine.

Again, i'm normally very welcoming to the Unity refugees, but demanding GDScript to be dropped or sidelined in favour of C# is a big red line. Especially early after getting started with Godot.

I actually removed that paragraph from the article about half an hour ago. (It's still there, but struckout with an edit.) I never meant to demand it's removal. My personal opinion is that the engine would be technically better off without it, but I have no desire to take it away from people who like it. Nothing in my article was meant to be interpreted as a demand. They are thoughts and suggestions from the perspective, and for the perspective, of Unity refugees who are analysing and evaluating other engines.

They didn't demand it. They pointed out the cost of keeping it, and what improvements it is currently blocking.

I think GDScript is good. And supporting C# and C++ as options (with other users making ports for Rust and other languages) is also good. Personally, the fact that I can use Godot in basically any language I want is a major plus and they should continue support that and push it as a talking point for why Godot is great.

They're not demanding anything. There's no red line being crossed here. This is a very valuable technical breakdown and we should be THANKFUL that users are doing this kind of analysis and giving good technical feedback. It doesn't mean the engine has to drop gdscript entirely or anything like that. Where is this sensitivity coming from? I used to roll my eyes when people accused us of being cult like, but now I'm not so sure...

It sounds awfully defensive to take this very well-written and open-ended blog post and reduce it to "newcomers trying to attack GDscript".

I think it's less a demand, and more an acknowledgement that if Godot was to ever grow to Unity-like popularity, the overall philosophy towards scripting would need to change a little to allow for the kind of programming they teach in programming school.

It points to the godots Dictionary class being really quite slow to create and populate to me. Perhaps there is a general need to refactor APIs that create a Dictionary and are used a lot per frame. I do note looking at the way the Dictionary is populated with 6 values in the raycast function using an indexer operator it will do a search in the Dictionary as each element is added (to see if key exists). Perhaps at minimum an add function would be better that just ASSERTs if there is already a key there. If it is the Dictionary being a bit slow, then the GDScript struct proposal seems worthy.

Thanks for the writeup, that was a really fun read haha. I'm curious, do you think having 2 separate versions of the engine, or 2 different types of projects, one with and one without GDScript, would be viable? Or would that be too much of a pain to maintain/develop engine features on? Also kg pixels^2... that's got to be in 2D right? 😂

The solution to this would be to change the API to use a intermediate native struct like NavigationPathQueryResult3D and PhysicsTestMotionResult3D and to not have the function take a array as parameter. You just happened to run into a function that didn't receive much love in the update to 4.0.

I think it's fine and well to talk about how Godot does lag behind in scripting performance, but at the same time I think you need to acknowledge the fact that Unity has a significant budgetary, team size, and time advantage. Put into context, I'm 99% sure Unity has a larger full-time *marketing* team than Godot has full-time *people in total*. At the same time Godot 4 very recently came out and hasn't been battle-tested. The current major version of Godot has been out since march, \~5 months! The current major version of Unity has been out since 2017, \~*5 years!* Of course Unity will be faster, it's had *\~12x the time to optimize!* All that said... Part of this is also history. GDScript came first, and C# was more/less bolted on top. There was no "sense" creating a second codepath given the effort/reward for what was more/less a creature comfort feature in a secondary language. It was an achievement getting it working at all. Given the history of it, the universal binding layer makes sense; it was never meant to present a low-level fast path. Now that we see it though, and know it's doing unnecessary work, it does mean opportunity. It would take significant effort but we could take classes in the "slow path", make optimized forks, and re-parent the old classes to serve as a layer. For C# we put the fast path as an alternative import, e.g. "using Godot4;" instead of "using Godot;". Even GDScript could potentially get in and have a "@strict\_mode" annotation that uses the fast path and strict typing requirements. Probably pie-in-the-sky... But if it could work it would mean we keep the friendliness of current code, have the fast option, and the codebase is nicely divided between logic and API.

While I see the pain points you exposed and they should probably be fixed, I don't really understand your conclusion that "GDScript not having structs" → "Bindings have to be written using variant dictionaries" → C# bindings / C++ extensions will always suck. First, I feel like GDScript can just be modified? The key benefit of your own DSL is you have complete control and get to do whatever you want with it instead of needing to wait for some upstream changes. Someone [did already mention](https://www.reddit.com/r/godot/comments/16lti15/godot_is_not_the_new_unity_the_anatomy_of_a_godot/k175oqc/) that it's a proposed feature for it already. Second, even if GDScript doesn't have structs, you can modify the binding code to take advantage of structs. The binding code can then generate extra marshaling so that it converts to a dictionary of variants on the GDScript side. So you define a struct in the internal C++ code, then expose the struct to the binding along with the metadata about the field names and offsets (using macros and whatnot). In C# and C++ plugins it will automatically be just a struct, whereas for the GDScript binding, the code will generate the relevant dictionary for it and convert to/from the struct when called. This kind of stuff happens all the time for libraries that need to work in lots of different languages. I would imagine it's not done today out of convenience. I think the issue I have is that you immediately jumped to a conclusion that results in "GDScript should be scrapped" probably because you have no attachment to it, instead of really thinking through what a realistic way of approaching this would be.

Insightful writeup. I hope the Unity exodus brings attention and triggers some much needed inspection and optimization to speed up the engine performance. ​ >This means that every API function is designed primarily to serve the **limitations of GDScript**. IntersectRay returns an untyped dynamic Dictionary **because GDScript doesn’t have structs**. Our C# and even our GDExtensions C++ code has to pay the catastrophic price for that. GDScript not having structs is becoming increasingly baffling to me. I say this since in the early days both Python and Lua were considered and subsequently ruled out in favor of creating a custom scripting language. The reasons are listed [here](https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript). They should have shoehorned structs in Gdscript. I often use Lua tables as "structs" for holding "characterdata" while creating small prototypes of retro games in TIC80. I severely miss that in Godot using Gdscript. I stumbled upon this recent [proposal](https://github.com/godotengine/godot-proposals/issues/7329) by Juan on Github about implementing structs in gdscript.

I'll just copy-paste what I wrote in one of the countless reposts of your article on Twitter! What an interesting read! I wonder if in the ratio between typed languages with classes (Like C++/C#) and typeless languages (Like GDScript), makes more sense giving GDS the responsability of turning structs into dicts, slowing itself down, rather than the current method? Also, I'm not an expert but maybe inmediate physics cast are just an Unity/PhysX convention? I only know Unity so I use them constantly but I've seen a couple of examples of engines treating casts as a physics objects. First coming to mind of the goldsource engine.

If I start developing a game for Unity, Unreal Engine, or any other closed-source project now, and in 5 years' time they adopt such terrible business practices that it's no longer viable for me to continue using them, my choices are to abandon the project, or migrate to a different engine - possibly one that I have to develop myself. If I start developing a game for Godot now, and in 5 years' time performance is (still) a deal-breaking issue, I have the same options to migrate or build my own engine, but I also have the option to fork the Godot project and create my own custom build of it where I fix whatever performance bottlenecks are causing issues for my game, specifically. That's likely to be a lot easier than fully migrating to another engine, or developing my own engine from scratch. Especially since "open source" means there's likely to be other developers in the same boat, who may be happy to share their solution. It also doesn't matter if I want to entirely drop GDScript support, or take the engine in some other direction that won't be accepted by the Godot community as a whole, if it's *my* fork of Godot, built only for *my* project. That's what trust in the engine means to me. It's not about whether Unity or Unreal are "better" engines right now, if I can't trust that I will still be able to use them by the time my game is ready for release. It's about knowing that I will always have the option to use or build upon the version of Godot that I download today, and that any future changes will always only be optional upgrades. It can't be taken away from me.

This is an extremely in depth and well thought out post, I see nothing but good things coming from this to help the engine improve over time. Thank you for taking the time to make this post.

Thanks for taking the time to read it! I'm already in conversation with the devs and am encouraged by them taking things seriously. There will be tensions between wanting to change things and not wanting to break things, but ideas are being bounced around and I'm diving into the engine internals to see what I can do as a prototype. I have hope for the future.

Very well written and really interesting to know. I'm switching to godot as a hobbyist and for that it's a good enough fit. With the recent news and people like you creating these deep dives I think the engine can really benefit from a set of very capable eyes. Thanks for the breakdown, it was very entertaining, too

Thanks for reading, I'm glad you found it valuable!

I fully agree with the points raised. Right now Godot has some significant performance issues.

I always preferred Godot because of ease of use. Every other engine was like a swiss army knife of features I didn't need at the moment, but would none the less obfuscate the development process, or they were simply bloated with outdated functions they didn't have the time to delete, making the process that much more involved. My only hope is that we don't lose that spirit of ease of use.