11 ms·

What's new in C# for Godot 4.0

151 points by __natty__ 4y ago

wnzl 4y ago
„ 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.
- andix 4y ago
  Unity is still using Mono? The CoreCLR should easily perform twice as good as Mono in many cases.
  - wnzl 4y ago
    Yes and no, Unity uses its own fork of Mono. When .NET evolved it keeps on using the forked mono and apparently CoreCLR is one of their priorities accordingly to blogpost here https://blog.unity.com/engine-platform/unity-and-net-whats-next https://blog.unity.com/engine-platform/unity-and-net-whats-n...
  - codetrotter 4y ago
    > Unity is still using Mono? https://docs.unity3d.com/Manual/Mono.html https://docs.unity3d.com/Manual/Mono.html Seems so. In fact, not just Mono but their own fork of Mono.
  - 0xDEF 4y ago
    They use their own heavily optimized Mono runtime that is .Net Standard 2.1 compliant and supports all C# 8 and many C# 9 features. As a C#/.Net developer I'm satisfied with the C# and .Net support in Unity. The pain points are elsewhere. https://docs.unity3d.com/Manual/dotnetProfileSupport.html https://docs.unity3d.com/Manual/dotnetProfileSupport.html https://docs.unity3d.com/Manual/CSharpCompiler.html https://docs.unity3d.com/Manual/CSharpCompiler.html
    - glenneroo 4y ago
      > 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.
    - Rohansi 4y ago
      As a developer on one of larger Unity games - yes, there are paint points elsewhere. There are many pain points. The poor performance of Mono/IL2CPP is a significant one for us. We have a different game built on .NET (Core) and performance is significantly better. 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.
      - Mikushi 4y ago
        Out of curiosity what engine are you using that leverages .NET (core) ? Stride?
        Rohansi 4y ago
        It's an engine written in C++ (not Unreal) that we've added C# scripting to. So it's in the same kind of situation as Unity where their engine calls from C# land need to be marshaled into calls to native code and back, which of course has overhead.
  - konsuko 4y ago
    They have to use Mono. New .NET Core Runtime does not yet support all platforms that Mono used to support, and won't for a while.
    - jackmott42 4y ago
      You can use mono for targets that need it and .NET 6 for those that don't
      - Kwpolska 4y ago
        Keeping two implementations side by side would be expensive to maintain and not a good user experience: you start writing nice, "modern" .NET6 code and then need to rewrite things to run on top of .NET4-ish (and the older BCL and C#). And I think .NET6 supports mobile now?
        kevingadd 4y ago
        Mono was largely folded into CoreCLR a couple releases ago and part of that infrastructure is used to support some targets like mobile and WebAssembly. [disclosure: I work on Mono at Microsoft.]
        deleted 4y ago
        [deleted]
        jackmott42 4y ago
        Yet Godot manages it, with a volunteer team and a better overall user experience.
  - Thaxll 4y ago
    CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.
    - andix 4y ago
      What are the specific requirements for games? C++ is also not built for games. It’s built for anything, including games.
      - mastax 4y ago
        Consistent low latency, perhaps.
        deleted 4y ago
        [deleted]
        andix 4y ago
        I don't see a lot of options how you should optimize that, besides using allocation free code. .NET (Core) did a lot of work into this direction for Kestrel HTTP server already (Span, ref structs). It's still a managed platform with a garbage collector, but I don't think games have such low-latency requirements, that can't be handled with the standard garbage collector. A few milliseconds are usually fine for games, even with 120Hz the time between two frames is still 8ms. And garbage collection can be suspended during critical phases.
    - jackmott42 4y ago
      This is not correct, as can be readily proven to yourself by measuring.
    - gcl09 4y ago
      Sorry but that makes no sense. Here are quotes from the C#/.NET group director at unity about how the migration to CoreCLR should bring a large perf boost: "One thing that should help in the future is the migration to CoreCLR that should provide a great boost in terms of performance."[1] "What we have seen, outside of Unity, is that performance with CoreCLR compared to Mono should range from 2x to 10x faster." [2] [1] https://forum.unity.com/threads/performance-optimizations-for-gameobjects.1403782/#post-8829403 https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-coreclr-vs-mono-vs-il2cpp.1403353/#post-8828794 https://forum.unity.com/threads/expected-performance-of-new-...
- sovietmudkipz 4y ago
  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 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.
  - jackmott 4y ago
    [dead]
  - Karliss 4y ago
    Mono and coreCLR are two alternative implementations for .Net runtime. Just like Firefox and Chrome are two implementations for various web formats, or CPython and PyPy for python language and many other examples. 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.
- pjmlp 4y ago
  Unity has a full toolchain with AOT compilation for many more platforms than Godot supports, plus HPC#, DOTS, rendering jobs and pluggable rendering pipelines.
Quarrelsome 4y ago
Does this impact the required code? I remember checking out the samples and much preferring the syntax of the native script given the C# is full of GetNode<Button>().op() as opposed to Button.op() in the native.
- andix 4y ago
  I don’t know about Gondot, but with C# source generators it should be easy to generate a typesafe and clean way to access
- vintagedave 4y ago
  According to the article, yes: > 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.
superchroma 4y ago
"The main change for C# support is that we moved away from the Mono SDK and we now use the .NET SDK to embed the .NET runtime" And .NET 6. Terrific work. Unity still isn't taking industry seriously so it's terrific to see viable alternatives.
- andrewstuart 4y ago
  >>> Unity still isn't taking industry seriously What does this mean?
  - superchroma 4y ago
    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. Unity marches on with little to no interest in enterprise development and quality processes, which is a shame.
    - DR0D4 4y ago
      Maybe I'm misunderstanding what you're looking to do, but you don't need to ship tests? Just use assembly definition files (asmdef)
    - Deukhoofd 4y ago
      Unity has supported multiple csproj solutions since 2017, through asmdef.
  - lozenge 4y ago
    They laid off 300 developers including some of the most experienced ones.
    - pjmlp 4y ago
andrewstuart 4y ago
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.
- chii 4y ago
  i'm glad javascript isn't the scripting language chosen, as C# is very much superior, and would run faster!
- krapp 4y ago
  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 WASM.) Gamedev isn't (necessarily) tied to the browser, so why not use a better language to start with? That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.
  - beezlewax 4y ago
    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
  - eropple 4y ago
    > so why not use a better language to start with? 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.)
sovietmudkipz 4y ago
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.
- Applejinx 4y ago
  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?
- zubspace 4y ago
  I have written a few games in Godot, which also work in the browser for Ludum Dare. [1] Works great, 2D and 3D, with small differences, but I can only speak for GDscript. I'm not sure if C# exports are working. 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. [1] https://ldjam.com/users/zubspace/games https://ldjam.com/users/zubspace/games
- konsuko 4y ago
  It has been excellent, best browser game engine imo - however as of Godot 4, the web export is completely broken, unfortunately. Godot with C# straight up has no web export and no mobile export atm, just desktop.
  - capableweb 4y ago
KronisLV 4y ago
I started learning Godot 3 a while back, however Godot 4 seems very promising, especially because of the built in LOD support, which feels ahead of even what Unity provides (since these would be automatically generated, a bit like in Unreal): https://docs.godotengine.org/en/latest/tutorials/3d/mesh_lod.html https://docs.godotengine.org/en/latest/tutorials/3d/mesh_lod... 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-plugin-from-gdscript-to-c 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.
debacle 4y ago
Really impressive changes here. Godot's C# support has been one of its weaknesses compared to Unity.
sylware 4y ago
[elf/linux] vulkan and guidelines/build container to workaround (modules/version)&(symbol/version)s based aggressive planned obsolescence from glibc libs and the static libstdc++ (-static-libstdc++).
swalsh 4y ago
Godot is increasingly becoming really interesting to me. It seems to be working its way towards the engine for developers who design (as opposed to other engines which seem to be for designers who develop).

151 points by __natty__ 4y ago

wnzl 4y ago

„ 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.

andix 4y ago
Unity is still using Mono? The CoreCLR should easily perform twice as good as Mono in many cases.
- wnzl 4y ago
  Yes and no, Unity uses its own fork of Mono. When .NET evolved it keeps on using the forked mono and apparently CoreCLR is one of their priorities accordingly to blogpost here https://blog.unity.com/engine-platform/unity-and-net-whats-next https://blog.unity.com/engine-platform/unity-and-net-whats-n...
- codetrotter 4y ago
  > Unity is still using Mono? https://docs.unity3d.com/Manual/Mono.html https://docs.unity3d.com/Manual/Mono.html Seems so. In fact, not just Mono but their own fork of Mono.
- 0xDEF 4y ago
  They use their own heavily optimized Mono runtime that is .Net Standard 2.1 compliant and supports all C# 8 and many C# 9 features. As a C#/.Net developer I'm satisfied with the C# and .Net support in Unity. The pain points are elsewhere. https://docs.unity3d.com/Manual/dotnetProfileSupport.html https://docs.unity3d.com/Manual/dotnetProfileSupport.html https://docs.unity3d.com/Manual/CSharpCompiler.html https://docs.unity3d.com/Manual/CSharpCompiler.html
  - glenneroo 4y ago
    > 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.
  - Rohansi 4y ago
    As a developer on one of larger Unity games - yes, there are paint points elsewhere. There are many pain points. The poor performance of Mono/IL2CPP is a significant one for us. We have a different game built on .NET (Core) and performance is significantly better. 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.
    - Mikushi 4y ago
      Out of curiosity what engine are you using that leverages .NET (core) ? Stride?
      - Rohansi 4y ago
        It's an engine written in C++ (not Unreal) that we've added C# scripting to. So it's in the same kind of situation as Unity where their engine calls from C# land need to be marshaled into calls to native code and back, which of course has overhead.
- konsuko 4y ago
  They have to use Mono. New .NET Core Runtime does not yet support all platforms that Mono used to support, and won't for a while.
  - jackmott42 4y ago
    You can use mono for targets that need it and .NET 6 for those that don't
    - Kwpolska 4y ago
      Keeping two implementations side by side would be expensive to maintain and not a good user experience: you start writing nice, "modern" .NET6 code and then need to rewrite things to run on top of .NET4-ish (and the older BCL and C#). And I think .NET6 supports mobile now?
      - kevingadd 4y ago
        Mono was largely folded into CoreCLR a couple releases ago and part of that infrastructure is used to support some targets like mobile and WebAssembly. [disclosure: I work on Mono at Microsoft.]
      - deleted 4y ago
        [deleted]
      - jackmott42 4y ago
        Yet Godot manages it, with a volunteer team and a better overall user experience.
- Thaxll 4y ago
  CoreCLR is not built for game, the fork from Unity is so there is little chance that CoreCLR is faster.
  - andix 4y ago
    What are the specific requirements for games? C++ is also not built for games. It’s built for anything, including games.
    - mastax 4y ago
      Consistent low latency, perhaps.
      - deleted 4y ago
        [deleted]
      - andix 4y ago
        I don't see a lot of options how you should optimize that, besides using allocation free code. .NET (Core) did a lot of work into this direction for Kestrel HTTP server already (Span, ref structs). It's still a managed platform with a garbage collector, but I don't think games have such low-latency requirements, that can't be handled with the standard garbage collector. A few milliseconds are usually fine for games, even with 120Hz the time between two frames is still 8ms. And garbage collection can be suspended during critical phases.
  - jackmott42 4y ago
    This is not correct, as can be readily proven to yourself by measuring.
  - gcl09 4y ago
    Sorry but that makes no sense. Here are quotes from the C#/.NET group director at unity about how the migration to CoreCLR should bring a large perf boost: "One thing that should help in the future is the migration to CoreCLR that should provide a great boost in terms of performance."[1] "What we have seen, outside of Unity, is that performance with CoreCLR compared to Mono should range from 2x to 10x faster." [2] [1] https://forum.unity.com/threads/performance-optimizations-for-gameobjects.1403782/#post-8829403 https://forum.unity.com/threads/performance-optimizations-fo... [2] https://forum.unity.com/threads/expected-performance-of-new-coreclr-vs-mono-vs-il2cpp.1403353/#post-8828794 https://forum.unity.com/threads/expected-performance-of-new-...
sovietmudkipz 4y ago
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 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.
- jackmott 4y ago
  [dead]
- Karliss 4y ago
  Mono and coreCLR are two alternative implementations for .Net runtime. Just like Firefox and Chrome are two implementations for various web formats, or CPython and PyPy for python language and many other examples. 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.
pjmlp 4y ago
Unity has a full toolchain with AOT compilation for many more platforms than Godot supports, plus HPC#, DOTS, rendering jobs and pluggable rendering pipelines.

Quarrelsome 4y ago

Does this impact the required code? I remember checking out the samples and much preferring the syntax of the native script given the C# is full of GetNode<Button>().op() as opposed to Button.op() in the native.

andix 4y ago
I don’t know about Gondot, but with C# source generators it should be easy to generate a typesafe and clean way to access
vintagedave 4y ago
According to the article, yes: > 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.

superchroma 4y ago

"The main change for C# support is that we moved away from the Mono SDK and we now use the .NET SDK to embed the .NET runtime" And .NET 6. Terrific work. Unity still isn't taking industry seriously so it's terrific to see viable alternatives.

andrewstuart 4y ago
>>> Unity still isn't taking industry seriously What does this mean?
- superchroma 4y ago
  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. Unity marches on with little to no interest in enterprise development and quality processes, which is a shame.
  - DR0D4 4y ago
    Maybe I'm misunderstanding what you're looking to do, but you don't need to ship tests? Just use assembly definition files (asmdef)
  - Deukhoofd 4y ago
    Unity has supported multiple csproj solutions since 2017, through asmdef.
- lozenge 4y ago
  They laid off 300 developers including some of the most experienced ones.
  - pjmlp 4y ago

andrewstuart 4y ago

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.

chii 4y ago
i'm glad javascript isn't the scripting language chosen, as C# is very much superior, and would run faster!
krapp 4y ago
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 WASM.) Gamedev isn't (necessarily) tied to the browser, so why not use a better language to start with? That said, there are forks of Godot that support JS/TS but I don't know how up to date or ready they are.
- beezlewax 4y ago
  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
- eropple 4y ago
  > so why not use a better language to start with? 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.)

sovietmudkipz 4y ago

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.

Applejinx 4y ago
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?
zubspace 4y ago
I have written a few games in Godot, which also work in the browser for Ludum Dare. [1] Works great, 2D and 3D, with small differences, but I can only speak for GDscript. I'm not sure if C# exports are working. 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. [1] https://ldjam.com/users/zubspace/games https://ldjam.com/users/zubspace/games
konsuko 4y ago
It has been excellent, best browser game engine imo - however as of Godot 4, the web export is completely broken, unfortunately. Godot with C# straight up has no web export and no mobile export atm, just desktop.
- capableweb 4y ago

KronisLV 4y ago

I started learning Godot 3 a while back, however Godot 4 seems very promising, especially because of the built in LOD support, which feels ahead of even what Unity provides (since these would be automatically generated, a bit like in Unreal): https://docs.godotengine.org/en/latest/tutorials/3d/mesh_lod.html https://docs.godotengine.org/en/latest/tutorials/3d/mesh_lod... 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-plugin-from-gdscript-to-c 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.

debacle 4y ago

Really impressive changes here. Godot's C# support has been one of its weaknesses compared to Unity.

sylware 4y ago

[elf/linux] vulkan and guidelines/build container to workaround (modules/version)&(symbol/version)s based aggressive planned obsolescence from glibc libs and the static libstdc++ (-static-libstdc++).

swalsh 4y ago

Godot is increasingly becoming really interesting to me. It seems to be working its way towards the engine for developers who design (as opposed to other engines which seem to be for designers who develop).