7 ms·

Godot: A Collaboration with Google and the Forge

157 points by piebro 3y ago

DeathArrow 3y ago
>.NET support is provided as a dedicated engine executable. C# support is currently only available for desktop platforms in Godot 4. Use Godot 3 to run C# on Android, iOS and Web. A bummer for me. Maybe they can also work with Google and Microsoft to improve .NET support?
- HideousKojima 3y ago
  Godot re-added C# support for Android and iOS in Godot 4.2, not sure where you're reading that since it's not in the link.
  - m_t 3y ago
    It's on Godot website features page.
    - Kelteseth 3y ago
      It's outdated, see https://godotengine.org/article/godot-4-2-arrives-in-style/ https://godotengine.org/article/godot-4-2-arrives-in-style/
  - DeathArrow 3y ago
    That's great news for me. I think they should keep their website up to date.
- Triangle9349 3y ago
  I read somewhere that they will completely redo C# support as multiplatform GDExtension. Then there will be one build and all additional languages can be added as extensions. And they can be updated faster, regardless of the editor build.
- GaelFG 3y ago
  Unless you specifically need a lot of the dot net library (and in this case you can probably theoretically 'just' use a plugin for access) I would encourage you to try gdscript. I went from 5 years of unity pseudo-c# to it in about 2 weeks, and I globally just find it an equivalent if not better experience for the majority of the code base. Honestly one of my current fears is that they focus on c# integration in place of improving gdscript support (the integrated ide is not specially comfy, and static typing support still lack some feature, collection wise in particular. but nothing really awfull).
  - gwervc 3y ago
    C# is a real programming language usable outside game dev, as well as transferable to other engines or frameworks like Unity and MonoGame. GDScript is usable only in Godot.
    - kgwxd 3y ago
      Maybe if someone is learning their first language that's a semi-important choice but, if you already know a programming language, syntax doesn't really have a steep learning curve.
      - Leo_Germond 3y ago
        No disrespect but judging languages on syntax is a lot like judging a book on its cover. Chosing a language is, for the experienced programmer, a choice of ecosystem, libraries, tools, architecture, and also a matter of long term maintenance, evolution, technical debts. Gscript scores very low on all of these, especially compared to the behemoth that is C#. Only unexperienced programmers and sales people use the "it looks somewhat similar so it must be" argument.
    - core_dumped 3y ago
      While this is true most of the structure of the language is taken directly from Python, which depending on your interests might be a little more useful than learning C#. The only syntactical differences I’ve found so far are the additions of var, const, match, how the walrus operator is used, and of course all the nice godot editor specific keywords. The built-ins have almost exactly the same naming scheme, you can still use global functions like len on any collection, I could go on… I would argue that someone who starts programming on gdscript today would be able to transition into Python with little to no overhead.
- Culonavirus 3y ago
  Learn C++, use UE5++ for rendering, all problems solved (and those that are not solved are solvable). People use all kinds of garbage like C# and Blueprint to do their scripting (and more) and then they're wondering how is it possible that the performance of their game is hot garbage. Bring back higher barriers to entry in game programming!
  - DeathArrow 3y ago
    I know C++. I prefer using C#, though. And I am not working as a game developer anymore, so I prefer a lighter game engine when doing small projects.
kramerger 3y ago
This collaboration ia about optimising the engine for Vulkan on Android. Very nice of Google to support Godot this way. Looking forward to a new wave of Android games with great performance and minimal battery drain.
- senectus1 3y ago
  would this help vulkan on linux at all do you think?
  - sylware 3y ago
    First elf/linux vulkan3D AAA games are from 2017-2019. The problem with the desktop/laptop linux (I am excluding the deck), is msft monopoly on desktop/laptop default installation. It is a circular dependency to break: windows gets the games because it is mass installed by default, and windows is mass installed by default because it gets the games. Breaking that circular dependency means a saner alternative to windows to invoke the ultra-hardcore regulation which would be required. Problem, massive and mainstream elf/linux distros out there are no less-worse than windows, and are mostly hostile to binary distributions which are games (ABI stability is stellar better on windows than on elf/linux). You need to dicipline glibc/gcc devs first (easy out-of-the-box backward ABI support in the toolchain and not that symbol per symbol version handling pain with the binutils gas .symver directive), and make more "common" software package statically link friendly or "app internal packaging friendly" (collisions of app internal shared lib symbols with system symbols). That has been the case for 10+years and it is still so much accute with so much nothing pertinent being done, I start to think about conspiracies: I am questioning for who those glibc/gcc devs are actually rolling for...
    - nicce 3y ago
      We have quite a lot of disk space these days on computers, so we can just use functional/declarative package managers to use dependencies in any format we like, having multiple versions of the same dependencies simultaneously, if needed. Steam/Epic/et all. could just host own package registry for games, and there is no conflict with major Linux distributions about binary distribution. On that case developers can bundle their games as they want, and end-users just use the package manager. If you look how Steam works under the hood in Linux, it also manages dependencies for each game separately instead of using system libraries in the most cases.
alentred 3y ago
My heart skipped a beat when I read the headline, in a scare of this being a way of saying that Godot no more because of, you know, "collaboration" with Google. Turns out these are in fact good news. I have to admit that I apparently have some trust issues here.
ozarker 3y ago
The Forge helped Bethesda out on Starfield’s rendering. I find this a little worrying considering how badly that game performs with mediocre graphics

157 points by piebro 3y ago

>.NET support is provided as a dedicated engine executable. C# support is currently only available for desktop platforms in Godot 4. Use Godot 3 to run C# on Android, iOS and Web. A bummer for me. Maybe they can also work with Google and Microsoft to improve .NET support?

HideousKojima 3y ago
Godot re-added C# support for Android and iOS in Godot 4.2, not sure where you're reading that since it's not in the link.
- m_t 3y ago
  It's on Godot website features page.
  - Kelteseth 3y ago
    It's outdated, see https://godotengine.org/article/godot-4-2-arrives-in-style/ https://godotengine.org/article/godot-4-2-arrives-in-style/
- DeathArrow 3y ago
  That's great news for me. I think they should keep their website up to date.
Triangle9349 3y ago
I read somewhere that they will completely redo C# support as multiplatform GDExtension. Then there will be one build and all additional languages can be added as extensions. And they can be updated faster, regardless of the editor build.
GaelFG 3y ago
Unless you specifically need a lot of the dot net library (and in this case you can probably theoretically 'just' use a plugin for access) I would encourage you to try gdscript. I went from 5 years of unity pseudo-c# to it in about 2 weeks, and I globally just find it an equivalent if not better experience for the majority of the code base. Honestly one of my current fears is that they focus on c# integration in place of improving gdscript support (the integrated ide is not specially comfy, and static typing support still lack some feature, collection wise in particular. but nothing really awfull).
- gwervc 3y ago
  C# is a real programming language usable outside game dev, as well as transferable to other engines or frameworks like Unity and MonoGame. GDScript is usable only in Godot.
  - kgwxd 3y ago
    Maybe if someone is learning their first language that's a semi-important choice but, if you already know a programming language, syntax doesn't really have a steep learning curve.
    - Leo_Germond 3y ago
      No disrespect but judging languages on syntax is a lot like judging a book on its cover. Chosing a language is, for the experienced programmer, a choice of ecosystem, libraries, tools, architecture, and also a matter of long term maintenance, evolution, technical debts. Gscript scores very low on all of these, especially compared to the behemoth that is C#. Only unexperienced programmers and sales people use the "it looks somewhat similar so it must be" argument.
  - core_dumped 3y ago
    While this is true most of the structure of the language is taken directly from Python, which depending on your interests might be a little more useful than learning C#. The only syntactical differences I’ve found so far are the additions of var, const, match, how the walrus operator is used, and of course all the nice godot editor specific keywords. The built-ins have almost exactly the same naming scheme, you can still use global functions like len on any collection, I could go on… I would argue that someone who starts programming on gdscript today would be able to transition into Python with little to no overhead.
Culonavirus 3y ago
Learn C++, use UE5++ for rendering, all problems solved (and those that are not solved are solvable). People use all kinds of garbage like C# and Blueprint to do their scripting (and more) and then they're wondering how is it possible that the performance of their game is hot garbage. Bring back higher barriers to entry in game programming!
- DeathArrow 3y ago
  I know C++. I prefer using C#, though. And I am not working as a game developer anymore, so I prefer a lighter game engine when doing small projects.

kramerger 3y ago

This collaboration ia about optimising the engine for Vulkan on Android. Very nice of Google to support Godot this way. Looking forward to a new wave of Android games with great performance and minimal battery drain.

senectus1 3y ago
would this help vulkan on linux at all do you think?
- sylware 3y ago
  First elf/linux vulkan3D AAA games are from 2017-2019. The problem with the desktop/laptop linux (I am excluding the deck), is msft monopoly on desktop/laptop default installation. It is a circular dependency to break: windows gets the games because it is mass installed by default, and windows is mass installed by default because it gets the games. Breaking that circular dependency means a saner alternative to windows to invoke the ultra-hardcore regulation which would be required. Problem, massive and mainstream elf/linux distros out there are no less-worse than windows, and are mostly hostile to binary distributions which are games (ABI stability is stellar better on windows than on elf/linux). You need to dicipline glibc/gcc devs first (easy out-of-the-box backward ABI support in the toolchain and not that symbol per symbol version handling pain with the binutils gas .symver directive), and make more "common" software package statically link friendly or "app internal packaging friendly" (collisions of app internal shared lib symbols with system symbols). That has been the case for 10+years and it is still so much accute with so much nothing pertinent being done, I start to think about conspiracies: I am questioning for who those glibc/gcc devs are actually rolling for...
  - nicce 3y ago
    We have quite a lot of disk space these days on computers, so we can just use functional/declarative package managers to use dependencies in any format we like, having multiple versions of the same dependencies simultaneously, if needed. Steam/Epic/et all. could just host own package registry for games, and there is no conflict with major Linux distributions about binary distribution. On that case developers can bundle their games as they want, and end-users just use the package manager. If you look how Steam works under the hood in Linux, it also manages dependencies for each game separately instead of using system libraries in the most cases.

alentred 3y ago

My heart skipped a beat when I read the headline, in a scare of this being a way of saying that Godot no more because of, you know, "collaboration" with Google. Turns out these are in fact good news. I have to admit that I apparently have some trust issues here.

ozarker 3y ago

The Forge helped Bethesda out on Starfield’s rendering. I find this a little worrying considering how badly that game performs with mediocre graphics