Live data from Hacker News

What's new in C# for Godot 4.0

godotengine.org

21–30 of 112 posts

Re: What's new in C# for Godot 4.0

#21
post #2

„ we now use the .NET SDK to embed the .NET runtime. This means we use the CoreCLR runtime for desktop platforms” Wow this is huge! Seems like Unity is lagging behind and their journey for CoreCLR just started.

Hobbyist unity dev here. Can anyone explain the mono/coreCLR commentary in this comment thread? I recently learned that mono works kinda like an interpreted language. This makes sense I think because the internals of unity run C++ code; the C# code is just an interface into the C++ parts of the engine. I haven't done a deep dive into .net ecosystem ever. I probably should at some point. Since I only work in unity and…

[dead]

Re: What's new in C# for Godot 4.0

#22

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

JavaScript doesn't have value types or operator overloading (also applies to Java) - this makes writing vector math pretty shitty imo - and you're working with vectors all over the place in games.

Re: What's new in C# for Godot 4.0

#23
Any godot programmers here. How is godot's support of games in the browser?

4 years ago I was deciding on a game engine to use. I considered it to unreal, Unity, and godot. I want to be able to build games that can be played on the web. I have many fond memories of the Flash game days. Distributing games over the web allows me to share games with people without the friction of installers, or App Store gate keepers, which I think is super cool. At the time, only Unity supported web. I decided to go full in on Unity.

Re: What's new in C# for Godot 4.0

#24

Earlier quoted context omitted.

>>> Unity still isn't taking industry seriously What does this mean?

An easy example would be to look at moving to a multi csproj structure. The desire is to have business logic and unit tests in their own projects, for example. Unity forces you to have them jammed in the monolithic singular project with everything else. I don't want to ship tests to production, and I don't want to have to build everything just to run some tests, particularly automated tests done on a build server. Un…

Maybe I'm misunderstanding what you're looking to do, but you don't need to ship tests? Just use assembly definition files (asmdef)

Re: What's new in C# for Godot 4.0

#25
post #20

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

Not really surprising. JavaScript-the-language is missing lots of features that could be useful, like operator overloading. Or any overloading, really. Nothing is stopping you from compiling JavaScript though, browsers do it. The lack of static types makes this harder, of course.

Suppose you could use typescript and compile that?

Re: What's new in C# for Godot 4.0

#26
post #10

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

Everyone who uses javascript has to write it in a superset language that has sane types, a (poorly implemented) standard library, and other features javascript lacks, and treat it like a batch of volatile chemicals because outside of its specific niche of scripting the DOM, javascript is a terrible, unstable language at best adequate for purpose, a necessary evil because the web doesn't support anything else (barring…

Is there a use case for WASM here and rust for example to run games in the browser?

There are game engines written in rust Bevy for example

Re: What's new in C# for Godot 4.0

#27

Any godot programmers here. How is godot's support of games in the browser? 4 years ago I was deciding on a game engine to use. I considered it to unreal, Unity, and godot. I want to be able to build games that can be played on the web. I have many fond memories of the Flash game days. Distributing games over the web allows me to share games with people without the friction of installers, or App Store gate keepers, w…

That question interests me too, because I would imagine it would do quite well. Godot's failings seem to be ones of omission, as a rule, and having less built in might help in browser-based games, because there would be less to download to get started, while still allowing for the basics in many classes of game. I know it's strong on 2D.

I don't know for a fact it's lighter than say Unity, it just seems like it would be. Anyone with more direct experience here?

Re: What's new in C# for Godot 4.0

#28

Earlier quoted context omitted.

>>> Unity still isn't taking industry seriously What does this mean?

An easy example would be to look at moving to a multi csproj structure. The desire is to have business logic and unit tests in their own projects, for example. Unity forces you to have them jammed in the monolithic singular project with everything else. I don't want to ship tests to production, and I don't want to have to build everything just to run some tests, particularly automated tests done on a build server. Un…

Unity has supported multiple csproj solutions since 2017, through asmdef.

Re: What's new in C# for Godot 4.0

#29

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

C# has :

- easy interop with native programs/libraries

- modern language features (pattern matching, async, and many more)

- Strongly typed

Re: What's new in C# for Godot 4.0

#30

It’s surprising to me that javascript wasn’t chosen as the scripting language for all these gaming engines. Though I do see the benefit of C# being typed and compiled.

Unity used to have a JS interface, where one could either write their game object components in JS or C#. They deprecated the JS interface. I imagine it was too much work to support two languages? As a dev reading docs, I used to have to deconflict the parts of the docs talking about JS from C# (not difficult as an experienced dev -- I wonder how the first timers fared). I'd also have to translate advice from JS Unit…

I think it was more that Unity's "JS" was actually their own language that was just very similar to real Javascript. They were forced to support the language itself as well as the integration. It was a lot easier to just support C#, which is maintained by others.
Post reply on HN