What's new in C# for Godot 4.0
godotengine.org
godotengine.org
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.
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?
First and foremost: Build time for all export targets together (windows. linux and web) takes less than 10 seconds and usually just work.
Some things like GPU particles had to be replaced with CPU particles and I remember that some texture compressions were not properly supported. But other than that, it mostly works out of the box. Can only recommend.
> web export is completely broken
> Godot with C# straight up has no web export
Hmm, something is amiss here... They're already on RC5 and web export not working doesn't sound like the web platform is a focus of theirs. AFAIK, the web export being broken is not mentioned in "Known Issues" about V4 either.
I would consider that broken.
It may be outdated since the reason it no longer works is because of these C# changes, as mentioned in the article.
[1] https://docs.godotengine.org/en/stable/tutorials/export/expo...
[2] https://docs.godotengine.org/en/stable/classes/class_canvasi...
And sorry again if the answer to these questions is so obvious to some of you that the question itself sounds dumb, but I'm simply not experienced with this topic.
Depends on the nature of the game though. It works best for games that are lightweight and stateless.
And speaking of that: what are the main monetization schemes? Are browser games sold like other games? Or are they mostly ad-based like other web content?
Some of those are accepting donations, but I can't tell if they are profitable.
And there is a whole genre of multiplayer things eating things to get bigger:
But the absolute, most amazing thing ( coming from the anxiety of app 'submissions', going through 'reviews', etc ), is the ability to update/fix/hotpatch everything instantly. Like within seconds. We have a simple CI/CD workflow that builds, updates & deploys a new godot site ( with dedicated gameserver backends) within seconds. The ability to just do this however you want, whenever you want, without going through some kind of platform distribution interface is great. With the exception of WGSL being such a dumpster fire of a spec, I'm pretty bullish on web for gamedev & distribution. There's some really great stuff being built right now, see: wasm+webtransport+wgpu
Wow this is huge! Seems like Unity is lagging behind and their journey for CoreCLR just started.
The CoreCLR should easily perform twice as good as Mono in many cases.
https://docs.unity3d.com/Manual/Mono.html
Seems so. In fact, not just Mono but their own fork of Mono.
As a C#/.Net developer I'm satisfied with the C# and .Net support in Unity. The pain points are elsewhere.
Not sure if this is what you mean but one huge pain point for almost every dev is that code changes necessitate a project reload, which, even with domain reload can be extremely slow and gets worse the larger the project becomes.... which is why I'm extremely exuberant about the new hot-reload plugins which allow editing code while a project is running and changes will be patched in real time! For me it's comparable to when SSDs first came out, finally we were able to ditch slow spinning rust. I've been using it for a couple days now and I've probably already saved a few hours.
I've been using HotReload.net which is free for Unity Personal Edition but there's also an asset on the store for ~40€ but i haven't looked at it yet.
I also wouldn't call Unity's Mono 'heavily optimized' because they definitely trail behind standard Mono. Unity doesn't even support Mono's generational garbage collector but it has been the default in Mono since 2016.
And I think .NET6 supports mobile now?
[disclosure: I work on Mono at Microsoft.]
[1] https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-...
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 since unity doesn't really play well with the .net ecosystem (e.g. one installs nuget pkgs by downloading the nuget file directly from the website, renaming the file extension to "zip" to then extract the files, and then copy DLLs into an "editor" folder in your project files), I haven't had as much of an incentive.
Today I work as a cloud engineer largely focusing on infrastructure set up, and writing GO/bash code for various bits of automation. Before I worked in scala/Java, and before that node.
Note in this comment I might be slightly imprecise with the use of naming since the specification, standard library, runtime can be separate projects each with its own name. But often multiple of those parts are made by same people so it can be a bit confusing especially with the way Microsoft names them with various capitalization.
Mono started as open source implementation of .Net and means to run C# on Linux when the Microsoft implementation of .Net was fully closed source and worked only on Windows. At that point it made sense for Unity to use whatever open source implementation of .Net they had access to which was mono. Years have passed and a lot of things have changed. At some point Microsoft bought Xamarin(the company that is main contributor/maintainer for mono project).
On the other side coreCLR is latest implementation of .Net from Microsoft. Unlike earlier versions of .Net from Microsoft it is open source and compatible with Linux and macOS.
As with many languages one of the implementations (the one made by inventor in this case Microsoft) is the leader, while others are playing catch up both in terms of new language feature support and also quality and tooling. Such situation is hard to avoid because developers of one implementation are making whatever they want while being sponsored by big company. While the others are trying to implement something that's more or less compatible with leader while having much smaller budget.
In the early days mono at least had the benefits of being open source and crossplatform compatible. Now they have lost this advantage. Even worse, the main contributor of mono is owned by Microsoft so there is high chance that they will slowly kill it in favor of their own implementation. Since the coreCLR is the primary implementation made by Microsoft it will more likely have much better integration and compatiblity with all the developer tooling made by Microsoft (Visual Studio, debugger) , better compatiblity with various third party .Net libraries, better support for new language features.
[disclosure: I work on Mono at Microsoft.]
Now, Godot 3 still had a plugin for similar functionality, except for the automatic generation (so close to being on par with Unity in that regard), I even ported it over to C# in private: https://blog.kronis.dev/articles/porting-the-godot-lod-plugi...
However, while the older version might be more stable for now, such as having mobile and web export, it's also pretty clear that migrating to the newer one once it comes out will actually be a good idea, also because of the new improved 3D rendering in general.
That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.
There are game engines written in rust Bevy for example
Perhaps consider that for many programmers, TypeScript is JavaScript, and TypeScript is that better language. I've put a decent amount of thought into using TypeScript for games because it allows for a flexible, expressive data model in a way that few other languages do. The performance might be a problem for some flavors of games, but I'm interested in discrete simulations almost exclusively, where it doesn't matter at all. But TypeScript allows effectively encoding intent into data structures and into code in a really ergonomic and pleasant way, while also running on virtually every gaming platform on the planet.
(Rust, etc. are fine. If that's your bag, that's great. I'll write Rust if I need to, but I don't enjoy it, and don't seek out opportunities to write it.)
https://en.wikipedia.org/wiki/Discrete-event_simulation
In truth, I think V8 is almost certainly more than fast enough for real-time games (real-time in the gaming sense, not in the OS sense); Mono is fast enough for Unity, even, and Mono is creaky and slow, with a really poor garbage collector, on its best day. But for the stuff I'm interested in, I just don't care at all.
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 Unity programmers into C# when researching how to do certain game things. I'm sure JS Unity devs had to do the same with C# advice.
I'm happy they aligned on one language. If JS had an optional type system baked into the language, I think it would be a better choice. However; it doesn't.
Nothing is stopping you from compiling JavaScript though, browsers do it. The lack of static types makes this harder, of course.
public static Vector operator -(Vector a, Vector b)
{
Vector v = new Vector();
v.X = a.X - b.X;
v.Y = a.Y - b.Y;
return v;
}
Vector result = myVector1 - myVector2;At one point Mozilla had a prototype implementation of strongly-typed value types in JavaScript, but it fell by the wayside once WebAssembly became a thing.
var result = myvector1.sub(myvector2)
The real kicker is value type semantics. You have two options with reference types : you can either do math in-place or allocate on each operation. First option is a huge foot gun because the ownership is unclear it's super easy to share references to something and update something unintentionally. And it can be hard to track down. Second option is super taxing on GC. And the overhead of going through reference for simple 3 float tuple (and object type info, etc.) is large - but for large arrays you can sort of work around it by primitive arrays. But that's like hand rolling assembly and you're supposedly using a high level language.
C# with structs and operator overloading is an ideal high level language for gamedev - most of the time it's really ergonomic and high level, but it has the tools to get down to memory layout control without it looking like disassembled code.
- easy interop with native programs/libraries
- modern language features (pattern matching, async, and many more)
- Strongly typed
Microsoft XNA used to be a popular indie game framework that used C#. Stardew Valley, Celeste and Terraria run on XNA.
Mono used C#. Xamarin used Mono to create a cross-platform application framework that worked on mobile. Unity leveraged Xamarin to create a cross-platform game engine that worked on mobile, ending up using C#.
Thus, two generations of indie gamedevs ended up learning C# to create games. Then Unity grew a whole lot, so more and more people ended up associating C# with game engines, so as soon as Godot was released people started asking for C# support.
But C# being the language of choice doesn't really depend on specific C# features. It could've just as easily been Lua or JavaScript instead. For example, RPG Maker moved from Ruby to JavaScript when they upgraded to a new engine, again, because their new rendering engine was nw.js, and getting it to run almost anywhere was easy.
C# being possible to mostly AOT compile (some exceptions) is also an advantage over JS for scripting since JS is not particularly efficient to run in an interpreter and many deployment targets don't allow you to JIT code at runtime. Languages like Lua have much better characteristics for those targets since they have high performance interpreters and cleaner language semantics.
As engines became larger products, companies often have the resources to make something bigger for game teams. Unreal’s Blueprints, or Godot’s GDScript integrate much more tightly with the engine’s runtime.
If you're an indie dev you usually don't want to strain the hardware with extremely complex models and textures and rendering pipelines, because you don't have the money to produce or source these models and textures.
And .NET 6. Terrific work. Unity still isn't taking industry seriously so it's terrific to see viable alternatives.
What does this mean?
Unity marches on with little to no interest in enterprise development and quality processes, which is a shame.
> In the past, Godot has used reflection to communicate with the engine. This has worked great so far but it comes with some limitations. We now use source generators, which have the following benefits...
It doesn't show what the code looks like but mentions the code has a different syntax and is more performant.