24 ms·

There are a surprising numbers of .NET game engines. Ranging from Unity, over Gadot to things like this one here. .NET is nowadays a very different beast that

by oaiey 4y ago

There are a surprising numbers of .NET game engines. Ranging from Unity, over Gadot to things like this one here. .NET is nowadays a very different beast that the .NET Framework. Maui is not the relevant factor. The modernization of the runtime, portability and the language itself changed it lot. Give it another try. You will be surprised. But do not start with Maui :)

flohofwoe 4y ago
C# is only one of several scripting options in Godot: https://docs.godotengine.org/en/stable/tutorials/scripting/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/i... And both Unity and Godot only use C# on the surface, under the hood it's mostly C++ (although apparently in Unity this has started and parts are being rewritten in their low level C# dialect using the Burst compiler).
- whizzter 4y ago
  IIRC the lowlevel stuff isn't exclusive to Unity's Burst compiler but rather enabled by the Span<T>/Memory<T>+stack-allocs introduced in the C# language (they might've used it more aggressivly though but shouldn't be anything stopping as aggressive compilation with the mainline corert-tool).
- szundi 4y ago
  Enough to have gc pauses though
- jayd16 4y ago
  To be honest, what difference does it make? The scripting tier needs to perform well enough too.
whizzter 4y ago
.NET Framework itself wasn't that bad apart from all the tying to weird Windows functions(good when writing enterprise stuff, horrible for everything else by tying to Windows) and reliance on IIS for web (with it's engineering focused on multi-tenant hosting being a PITA for devs doing the actual web dev). Imho the main improvements lately for gamedevs are greater portability, Span<T>/Memory<T>'s (access and manage memory more freely), stack-allocs (enabled by the former) and vector math intrinsics (Add to it that C# code was never as reliant on GC perfection as Java by being more pragmatic and with support for proper generics saving a ton of memory allocs).
- KronisLV 4y ago
  > .NET Framework itself wasn't that bad apart from all the tying to weird Windows functions(good when writing enterprise stuff, horrible for everything else by tying to Windows) and reliance on IIS for web (with it's engineering focused on multi-tenant hosting being a PITA for devs doing the actual web dev). Personally, I feel like .NET Core and embracing cross-platform was exactly what the ecosystem needed. Albeit not quite 1:1 with the older versions of the framework (the Mono project tried that approach, with mixed results), things like Kestrel instead of IIS didn't feel like a high cost to pay. Plus, I think that the C# language itself is reasonably nice. It's a bit curious how C# seems to be more popular in gamedev than Java, both of the languages and runtimes not being that different from one another. For whatever reason projects like jMonkeyEngine or LWJGL don't get the same popularity as Unity or even Godot.
  - orthoxerox 4y ago
    > It's a bit curious how C# seems to be more popular in gamedev than Java, both of the languages and runtimes not being that different from one another I think we can thank Miguel de Icaza for that. Mono/Xamarin allowed Unity to run on smartphones and turned it into a textbook disruptive innovation.
  - jayd16 4y ago
    C# has structs (and pointers if you really need them) and now Span<T>. C# is just a better fit than Java.
    - KronisLV 4y ago
      > C# is just a better fit than Java. I'm not sure I follow: having access to lower level functionality is good, of course, but I don't think that's quite the deciding factor for the majority of folks, who want to knock together a game. Number crunching will be relevant for a limited subset of game projects out there, otherwise Lua wouldn't have seen widespread usage, or maybe something like GDScript wouldn't have been created in the first place. In regards to Span<T>, wasn't it added relatively recently? That seems to be the case, from what I can tell: https://learn.microsoft.com/en-us/dotnet/api/system.span-1?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.span-1?v... Applies to Product Versions .NET Core 2.1, Core 2.2, Core 3.0, Core 3.1, 5, 6, 7 .NET Standard 2.1 That seems to be confirmed by this: https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/ https://devblogs.microsoft.com/dotnet/announcing-net-standar... Span<T>. In .NET Core 2.1 we’ve added Span<T> which is an array-like type that allows representing managed and unmanaged memory in a uniform way and supports slicing without copying. And yet, C# and .NET (or Mono) were already used by popular engines like Unity all the way back in 2005, so surely there's more at play here! Maybe what held Java back were social reasons, like concerns around licensing, or how easy it would be to integrate JDK or package it back in the day and so on.
Narishma 4y ago
Unity and Godot are not C# engines like this one. They are C++ engines with C# scripting.
- oaiey 4y ago
  You are right. But even the "scripting" part of Unity is very much optimized for performance.
- pjmlp 4y ago
  Not true for Unity, since HPC# and Burst they have been slowly replacing C++ with C#. They are ones of the main contributors to low level improvements in .NET and C# since version 7, alongside the team's own learnings in Midori and .NET Native.

by oaiey 4y ago

flohofwoe 4y ago

C# is only one of several scripting options in Godot: https://docs.godotengine.org/en/stable/tutorials/scripting/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/i... And both Unity and Godot only use C# on the surface, under the hood it's mostly C++ (although apparently in Unity this has started and parts are being rewritten in their low level C# dialect using the Burst compiler).

whizzter 4y ago
IIRC the lowlevel stuff isn't exclusive to Unity's Burst compiler but rather enabled by the Span<T>/Memory<T>+stack-allocs introduced in the C# language (they might've used it more aggressivly though but shouldn't be anything stopping as aggressive compilation with the mainline corert-tool).
szundi 4y ago
Enough to have gc pauses though
jayd16 4y ago
To be honest, what difference does it make? The scripting tier needs to perform well enough too.

whizzter 4y ago

.NET Framework itself wasn't that bad apart from all the tying to weird Windows functions(good when writing enterprise stuff, horrible for everything else by tying to Windows) and reliance on IIS for web (with it's engineering focused on multi-tenant hosting being a PITA for devs doing the actual web dev). Imho the main improvements lately for gamedevs are greater portability, Span<T>/Memory<T>'s (access and manage memory more freely), stack-allocs (enabled by the former) and vector math intrinsics (Add to it that C# code was never as reliant on GC perfection as Java by being more pragmatic and with support for proper generics saving a ton of memory allocs).

KronisLV 4y ago
> .NET Framework itself wasn't that bad apart from all the tying to weird Windows functions(good when writing enterprise stuff, horrible for everything else by tying to Windows) and reliance on IIS for web (with it's engineering focused on multi-tenant hosting being a PITA for devs doing the actual web dev). Personally, I feel like .NET Core and embracing cross-platform was exactly what the ecosystem needed. Albeit not quite 1:1 with the older versions of the framework (the Mono project tried that approach, with mixed results), things like Kestrel instead of IIS didn't feel like a high cost to pay. Plus, I think that the C# language itself is reasonably nice. It's a bit curious how C# seems to be more popular in gamedev than Java, both of the languages and runtimes not being that different from one another. For whatever reason projects like jMonkeyEngine or LWJGL don't get the same popularity as Unity or even Godot.
- orthoxerox 4y ago
  > It's a bit curious how C# seems to be more popular in gamedev than Java, both of the languages and runtimes not being that different from one another I think we can thank Miguel de Icaza for that. Mono/Xamarin allowed Unity to run on smartphones and turned it into a textbook disruptive innovation.
- jayd16 4y ago
  C# has structs (and pointers if you really need them) and now Span<T>. C# is just a better fit than Java.
  - KronisLV 4y ago
    > C# is just a better fit than Java. I'm not sure I follow: having access to lower level functionality is good, of course, but I don't think that's quite the deciding factor for the majority of folks, who want to knock together a game. Number crunching will be relevant for a limited subset of game projects out there, otherwise Lua wouldn't have seen widespread usage, or maybe something like GDScript wouldn't have been created in the first place. In regards to Span<T>, wasn't it added relatively recently? That seems to be the case, from what I can tell: https://learn.microsoft.com/en-us/dotnet/api/system.span-1?view=net-7.0 https://learn.microsoft.com/en-us/dotnet/api/system.span-1?v... Applies to Product Versions .NET Core 2.1, Core 2.2, Core 3.0, Core 3.1, 5, 6, 7 .NET Standard 2.1 That seems to be confirmed by this: https://devblogs.microsoft.com/dotnet/announcing-net-standard-2-1/ https://devblogs.microsoft.com/dotnet/announcing-net-standar... Span<T>. In .NET Core 2.1 we’ve added Span<T> which is an array-like type that allows representing managed and unmanaged memory in a uniform way and supports slicing without copying. And yet, C# and .NET (or Mono) were already used by popular engines like Unity all the way back in 2005, so surely there's more at play here! Maybe what held Java back were social reasons, like concerns around licensing, or how easy it would be to integrate JDK or package it back in the day and so on.

Narishma 4y ago

Unity and Godot are not C# engines like this one. They are C++ engines with C# scripting.

oaiey 4y ago
You are right. But even the "scripting" part of Unity is very much optimized for performance.
pjmlp 4y ago
Not true for Unity, since HPC# and Burst they have been slowly replacing C++ with C#. They are ones of the main contributors to low level improvements in .NET and C# since version 7, alongside the team's own learnings in Midori and .NET Native.