[TillE]

It's not clear to me whether .NET 6 (and therefore C# support) is going to make 4.0 freeze. It's really just been one guy working on the dotnet6 branch, which is unfortunate.

I'm really excited for many features of Godot 4, and GDScript is perfectly adequate for UI glue code and stuff, but to write a serious game you really want C#.

[nemothekid]

>but to write a serious game you really want C#

I haven't followed game development in a long time, but has the industry moved to C#? I thought C# was limited to Unity and everyone else was still using C++?

[katamaritaco]

You're correct, the industry has not moved to C#. Not even close.

The biggest player that uses it is Unity, but even they have their own special fork of Mono to get it to play nice.

Full Disclosure: I work for a Microsoft/Xbox Studio.

[jbluepolarbear]

Unity uses their own AOT compiler IL2CPP that translates C# code to C++. Mono is an option in builds, but most projects are using IL2CPP nowadays and have been moving to .Net core. Although C++ is king, C# has quickly caught up to be a close 2nd. Unity is used to make 50% of all mobile, pc, and consoles games (according to Unity https://unity.com/our-company).

[Mikeb85]

> but to write a serious game you really want C#.

This is ridiculous. You absolutely can write a full game with GDScript or GDScript and C++. Keep in mind Godot has first class support for C++.

In fact, I'd argue C++ is far better than a bolted on C#...

[TheAceOfHearts]

I don't have experience with GDScript, so please forgive the ignorant question.

Does GDScript have good debugging, linting, and profiling tools?

I'm not a game developer, but I'd love to hear your perspective on some of the criticisms I've encountered on the topic of scripting languages for game development.

One of the main criticisms I've heard of using scripting languages for game development is that they tend to be lacking when it comes to tooling.

The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.

[cardanome]

> Does GDScript have good debugging, linting, and profiling tools?

Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.)

> The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.

GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.)

Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.

C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust).

Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)

[meibo]

> Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.

Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .NET 6 or 7 are faster than ever, while Unity is stuck on an old version of Mono, too.

It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

[cardanome]

Did I say, you can't make games in C#? Why do you feel the need to defend C#? You are arguing against a straw man.

It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about.

> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

[meibo]

> So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

I have, which makes me feel confident in stating that it's a language that didn't have to exist, doesn't have a healthy ecosystem backing it, which pulls focus from the actual good (or to be good) bits of Godot, which there are a lot of, and in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors.

[Mikeb85]

> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

??? You can do everything in Godot in C++...

And GDScript isn't exactly a 'weird' language, it's downright ordinary in terms of semantics and features. The feature is that it's part of the engine and maps directly to C++ methods in the game engine...

[handsaway]

GDScript is fine and I use it but it's a stretch to compare its type system to TypeScript. GDScript doesn't have generics let alone conditional types, string template types, variadic tuple types, etc. TS is significantly more sound as well if you turn on a lot of the strictness options.

[throwaway675309]

Between XNA, monogame, Unity, etc. there a metric f###-ton of games written using the C# language.

[Mikeb85]

I mean, GDScript doesn't exist outside of the Godot engine. Debugging for it is the same as debugging a Godot game. All GDScript functions are C++ methods. Also, there are type hints if you want.

If you're going to be doing a very large, ambitious game, odds are you'll also be creating your own C++ methods and thus debugging using C++ tools and the game engine tools...

[drmidnight]

GDScript 2.0 has had some major performance improvements. While C# will still be faster, I find GDScript in Godot 4 to be viable now for things it wasn't in Godot 3.

I still rely on GDNative for really performance critical systems though.

[benjaminjackman]

Sounds like Godot 4 is replacing GDNative with GDExtension. Just wondering if you have tried it out and have any thoughts. Is it a smoother experience / about the same etc.

[drmidnight]

I have only briefly looked at it. All in all it looks very similar to GDNative, albeit a little cleaner. It will be nice to finally be able to expand functionality without recompiling the engine.

Right now I rely on nim bindings for GDNative so it might be awhile before I make the change over, unless I decide to port my code to C++ or update the bindings myself.

[opyate]

> but to write a serious game you really want C#.

I asked someone on Twitter about this the other day [0], and I'm genuinely curious: what is it about C# that makes game development serious?

0. https://twitter.com/LegatXyotic/status/1552219744723402756

[Waterluvian]

I won’t use the word “serious” but my limited personal experience is that C# feels like the right balance between flexibility and performance.

Rust is a joy to write in but I personally find that it asks a lot from you when you just want to ship a game that doesn’t need to be safety rated.

C++ is a great choice but it’s C++ and I’m just not good enough to enjoy a language with fewer guardrails. It also has similar verbosity issues to Rust and (likely because I’m a noob) eats up a lot of my time chasing dumb bugs rather than making a game.

I do most of my game dev in TypeScript because it’s a wonderful language and web is a great platform to easily ship toy games (my specialty). But it just isn’t fast enough for anything major.

[stu2b50]

I find it hard to imagine whatever glue language you choose for an engine like Godot would really matter that much. All you’re implementing is the business logic. Even the slowest language can run through basic business logic in the blink of an eye relative to the heavy duty that the Godot systems are doing.

Eve Online runs on *python*, for instance. So does Blender. For a glue language, I am highly doubtful that the .net is that much faster than v8 or any other runtime to make a difference.

[dbrueck]

Agreed - our company's app isn't a game but is built on top of UE4, and nearly all of our code is in Python and it's never the bottleneck, not by a mile.

[jayd16]

So you think all the talk about performance tuning in games is just made up, or what?

What ends up happening is you write scripts for lower compile times and ease of use. Then if something is too slow you rewrite it in native. The speed of the scripting tier lets you write less in native. Its not irrelevant at all.

[krapp]

Most of it is, because most of it is cargo-culting by amateurs who just believe what they read on SO and forums and who have never actually written anything non-trivial, much less shipped a game.

[jayd16]

Are you saying they misunderstand what they're cargo-culting or are you saying amateur game scripts run fast enough? To cargo-cult it needs to be relevant somewhere, so either way it shows the blanket statement is false, no?

[opyate]

Exactly. The Godot components are very performant, and the glue code doesn't get in the way. And Godot 4 is getting compute shaders, IIRC.

[tokumei]

I've built a few custom engines over the past decode, also shipped a few games. I've lately been working with Bevy in Rust, and I really absolutely love it. It's the perfect framework (for me). Bevy gets out of the way enough where I don't feel like I have to fight with it, which is what always annoyed me with actual game engines. Plus, I love working with Rust.

[tmp_anon_22]

> isn’t fast enough for anything major.

I think it could be fast enough if portability to different platforms wasn't such a high priority for game studios these days. Nobody wants to write typescript and then pay $50M for someone to port it for Switch or whatever.

[jayd16]

Well you could always go with C++ but C# has a solid balance of high level features, good libraries, good tooling, a feature full (if not slick) threading mode, performance features when you need them and good interoperability with native code.

Its not always fun or sexy to rewrite a reference type to a value type to get around your GC but you _can_ do that in C#. Its a have your cake and eat it sort of language.

[Mavvie]

Can you elaborate on that? Do you mean rewriting existing classes as structs so they go on the stack?

[jayd16]

Yes, just an example of one of the many performance minded complications that C# brings to the table. You can even use raw pointers if you want to.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

[steeleduncan]

gdscript is dynamically typed. If you have the large arrays of structs common in gamedev, then all data members are boxed, significantly increasing memory usage compared to something like C#.

[unsafecast]

C# objects are boxed too.

[jbluepolarbear]

Boxing is taking a Value Type (struct, int, enum, etc) and converting it to an Object. So Objects aren’t boxed.

[unsafecast]

Apparently we have different definitions of boxing. To me, and I've always used it (and seen it used) like this, a boxed value is a value that's stored on the heap and passed as a pointer. Maybe C# has a different definition?

[steeleduncan]

No, from the C# docs[1] - Boxing is the process of converting a value type to the type object or to any interface type implemented by this value type

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

[jbluepolarbear]

That’s correct, but not what you said. You said objects are boxed. Values are boxed to create a reference by wrapping it in an object, objects are already reference types so there’s no boxing.

[Cloudef]

Probably not serious, just that it's the language used in unity

[fezfight]

Does Godot's implenetation of C#/.net include the .net temeletry?

https://github.com/dotnet/sdk/issues/14556

[Kwpolska]

The telemetry isn’t in C#/.NET proper, it’s in the `dotnet` CLI utility.

[somehnacct3757]

Former professional game dev getting into Godot recently for fun and maybe for hire.

What are the limitations of gdscript you allude to? Let's say I want to render an infinite scrolling hex grid. Why would c# excel or gdscript struggle?

[marcosdumay]

GDscript is a bit slow. It's not an issue if you use it to keep track of a reasonable amount of in-game data and control the objects to render. But it becomes an issue if you decide to write game intelligence in it, or keep track of a lot of things.

It also doesn't have an all integrated top of the market IDE, only the Godot IDE. (Although I don't think you gain anything from using a 3rd party IDE in a Godot game. Even less something like Visual Studio.)

[_aavaa_]

The Wiki page says it already supports C#. As completely on the outside, what is missing?

[nodja]

It doesn't support .NET6 specifically which is what parent is asking. According to the github issue it seems that the plan is that .NET6 support will be merged after godot 4 is fully released and stabilized.

[sfteus]

Godot ~3.2+ has support for a slightly older version of C# via Mono, I think it's the equivalent of .NET 4.8.

IIRC (and this could be wrong / have changed since I last looked into it) the idea was to re-work this in Godot 4 to provide more like bindings, so that users could opt to use Mono, .NET 6, CoreCLR, NativeAOT, or whatever version they preferred.