I've only briefly played around with Godot, but how does one get type-assisted autocomplete on variables and methods? Is there a type-hinting for the IDE? Kind of broke it for me. Maybe I should've tried C#.

You have to make sure you opt into the type-safe GDScript. It's not easy. There's an IDE feature that highlights lines that are not type-safe but the default color is a hard-to-see grey. I changed it to be red ("Line Number Color" is the one for untyped lines), and then fixed all typing issues. Then, autocomplete works as does cmd+click to go to definition.

In GDScript you kind of get code completion. Kind of. 50% of the time it doesn't give anything useful.

If you use C# then you can use Visual Studio or Rider or VSCode and get that

There is optional static typing. If you write type declarations, the editor will not only give better code completion, but it will use type inference to find errors statically where possible, and the runtime will check for the remaining type errors. In this way it's more sophisticated than almost all other dynamically typed languages!

What about other bindings, like with Rust?

Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.

Sounds like something they can improve then.

The history is cyclical here it seems: https://blog.unity.com/community/unityscripts-long-ride-off-...

I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.

I think this is correct... you can even go with Rust instead of C++

This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead encountered in OP) to make the transition uneventful.

And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.

You don't need to spend big though to address the issues author highlighted.

Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.

The author of the article seems to say that even the c++ api version is a heap allocated dictionary, so you would still take the perf hit

C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.

>if I ever need performance I'll probably just go straight for C++.

if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.

> if that's my go to solution, why am I using Godot instead of Unreal?

No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).

Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

> even a more mature C++ renderer framework like bgfx, or even Ogre3D?

IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

>Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

Indeed, but even Unity isn't known for its high performance 3D titles. It COULD viable do them, but not without a lot of work.

That was supposed to be something that DOTS would address, to take out "a lot of work" and make that performance almost be taken for granted. But... well, I don't want to go on that rant again. You can excuse some performance and optimize later, but the sounds of things from this article (with general sentiments even from diehard Godot fans that Godot isn't ready or serious 3D development) makes it sound like that optimizing will in fact exceed the content creation time.

I've seen enough of the guts to know that Godot will likely never make its own DOTS. At least, not its own Burst compiler to get around the c# issues. Likely not IL2CPP either. Fortunately, you don't need that and can get maybe 80% of the performance by simply following some data oriented principles. More than enough for all but the most lofty AAA games (think GTA6 levels of scale).

----

>Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

that's good to hear, and I get it (Unity rushed out tons of features itself. Including DOTS). I hope I can one day contribute to that effort myself. Would make my future game dev life much easier and would be a good way to give back.

Except that is the whole point of languages like C#, being able to be productive in high level code, and not needing to write C++ when performance is called for by providing all the features for low level code, unless in very niche caches where those features still aren't enough.

> community might dislike a performance-friendly change which will break the parity in favour of C#.

The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use.

If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.

I guess the argument is that GDScript has a different use case than Unity's C#? Seems like Unity devs know what a C# scripting engine is like and feel it covers the use case fine. To say they don't understand the use case would mean it must be different somehow. Can you go into that?

[delayed]

C++ > C#

For some, a few days of GDScript usage. For others, after they convert their bottlenecks into C++.

UE’s blueprints are much(!) slower than native code, but they’re still an incredible tool in the toolbox. GDScript is kind of the same; it’s covering a critical role of non-performance-sensitive glue.

That said, I’d really like to see Value Types added, as well as these sorts of heap allocations addressed in Godot 4 at some point.

I would bet that it doesn't matter for 99% of scripts. By the numbers, Godot's primary use case so far has effectively just been game jams.

So are we fine keeping it that way and not addressing core performance issues because it's convinent for making simple 2D games?

To be honest, I'm surprised how dismissive parts of the gamedev community can be about improving performance of their game engine. That was a huge complaint from Unity and you'd think people would be interested in not repeating those mistakes with Godot.

"People" will always do shitty stuff. Also, "people" will get overly defensive about challenges to their status quo and world view..

That said, how prevalent is the former vs the later really?

I understand it. it was built a certain way to support ease of use above almost anything else.

That ease of use is important, but also may be holding back Godot's true 3d capabilities. From a cursory glance as someone wanting to work on a decent scale 3D game, I'd need to treat GDSCript as I do Unreal's Blueprints as of now: miniize use only to high level scripting and maybe UI/Shader code. That's not me saying that GDScript nor blueprints is bad, just that it gets in the way of my specific use case.

If I can help speed up the engine underneath as a whole in the process: wonderful. I don't necessarily want to disrupt GDScript for my convenience either, but like any refactor some breakage is inevitable.

GDScript is in a much better place than most scripting languages because the compiler actually has quite a lot of static type information. If they invest in unboxing optimisations and a JIT, it can definitely become competitive with C#.

I can't help but think this is delusional. Microsoft has put massive effort and funding into C# and I just don't see how Godot, being much more niche, can reach that level of investment.

If they targeted the .NET VM they'd be able to make use of a lot of that investment. But they don't really need to. There's a lot of low-hanging-fruit for performance, and narrowing the gap is more important than outright parity.

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... .

One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:

> As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).

It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.

Further down though somebody points out:

> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.

This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:

> C# is faster, but requires some expensive marshalling when talking to Godot.

I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".

EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.

That poll seems highly biased

How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

Yeah it's def biased towards existing users in many ways.

Not a terrible thing if you want to concentrate on their needs, but not the best questions for filtering ideas for expanding adoption (perhaps).

How many users that are happy with gdscript are taking time to read vote in a GitHub polling posted about c# issues?

Doomscrolling is a thing even in gamedev, I suppose.

There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.

As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.

Easily room for both though.

Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.

Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.

Maybe GDScript could just get the concept of a struct and the differences minimized over time too.

From what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices.

But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)