5 ms·

As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought o

As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought of returning to the pain of C++ to work with UE. Established languages generally have high-quality tools for debugging, refactoring, and more, as well as loads of libraries and code examples available, and books/tutorials/documentation. IMHO, one of Unity's best moves was to focus on C# and discontinue support for their own custom language.

Antshockey 4y ago
Godots support for C# is excellent out of the box to be honest. I've not found anything I can't do in C#. There are one or two things that are harder to find but they are few and far between
- bluescrn 4y ago
  Yet the default Godot download is a 'standard edition' without Mono support? What's the reasoning behind the two separate builds? Is it just about build/download size, or are there potential licensing issues with Mono or something?
  - galleywest200 4y ago
    After looking around the web, it seems the version that contains the .NET (mono) is about twice the size. It looks like the Godot team maintains two package versions simply to avoid bloat if you do not require that functionality.
  - lewispollard 4y ago
    Godot's system for exporting games/apps/projects as binaries is that the same codebase/build system that generates the editor binary (the Godot "tools") can be built with the "tools" parts omitted, and the resulting non-tools release binary is bundled up with your project scripts/resources as the binary API for your exported game. The general philosophy for Godot's build/compilation system is that most things are just linked statically, and features and modules can be turned on and off via build flags, so that they can be as portable as possible - indeed it's usually pretty painless and quick to export a game to a binary from the editor on most platforms because of this. With Mono there are 2 sticking points that make this a bit more difficult - first is that this non-tools binary has to bundle the Mono runtime with it to be portable, this adds a bunch of bloat, and Godot's style has always been to be as light as possible. For mobile apps for example, that extra ~40mb of stuff can be a real problem. Additionally, the development machine has to have a fairly modern dotnet SDK installed (ideally .NET 6 SDK + dotnet cli these days) as well as the app host targeting packs in order for the mono-enabled editor binary to run at all (as it contains some CLR/native interop code and nuget packages for the editor tools to copy into your project, etc that fails without these things). So the export template (the non-tools godot API binary) with Mono can't be understood by the editor tools without Mono enabled. Recently direct .NET 6 interop support has replaced the Mono integration in Godot 4, and this might in the future change the above - since it will be able to use the new AOT stuff to publish exported games in a more direct way. It's definitely a stated intention to eventually ship just one engine binary for everything, but it's still a way off happening yet, maybe in Godot 4.1 or 4.2.
cercatrova 4y ago
Bevy is in Rust, made by a former Godot contributor.
- bodge5000 4y ago
  Apparently they want to make Bevy more like Godot with a full GUI editor, rather than a framework, which for me personally is a real shame. There aren't that many really good modern game frameworks, and Bevy is the only one that uses Rust natively (Amethyst is shut down, Raylib and SDL don't count as they have bindings for literally everything, I wouldnt be suprised to find a COBOL binding for raylib). Otherwise, its fantastic and would highly recommend.
  - robotnikman 4y ago
    >I wouldnt be suprised to find a COBOL binding for raylib I was curious and found this https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Games/raylib https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Game...
mangecoeur 4y ago
I think a lot of people assume that they won't like a custom language (I did too) but the reality is when you start using GDScript it just isn't such an issue. One of the huge advantages of GDScript is how deeply in integrates with the engine and handles high level concepts, coupled with the node system you don't need to write that much code. Plus its a simple language (there's no need for 'javascript - the good parts' for gdscript). The godot approach with GDScript and C++ is very much like Python and C++ - write in the high level scripting language and build C++ components when you need more complexity and performance. The scripting language becomes the user interface of the low level parts.
indymike 4y ago
> As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought of returning to the pain of C++ to work with UE. As a professional developer, yes, I love seeing popular languages I know. When you build a product that includes a programming language, you find out maintaining and expanding the language is a herculean effort, and so I can understand from just the financial perspective why Unity switched to C#. As a Dad, what the OP was saying is right - Godot's language, while non-standard is much more approachable for a child than C++ (or most other popular general purpose languages).
bodge5000 4y ago
I wholeheartedly agree, its one of the things I like the least about Godot. That being said, I used Unity for about 8 years, 2 years ago I switched to Godot and never looked back. I think I tried Unity again once, for a few hours, then went back again. Its also worth noting that I prefer ECS as a programming style, which of course Unity uses and Godot doesn't, and yet still I'm using Godot. It really is that good of an engine. I have my issues, plenty of them even, but for the most part its a joy.
deleted 4y ago
[deleted]

Antshockey 4y ago

Godots support for C# is excellent out of the box to be honest. I've not found anything I can't do in C#. There are one or two things that are harder to find but they are few and far between

bluescrn 4y ago
Yet the default Godot download is a 'standard edition' without Mono support? What's the reasoning behind the two separate builds? Is it just about build/download size, or are there potential licensing issues with Mono or something?
- galleywest200 4y ago
  After looking around the web, it seems the version that contains the .NET (mono) is about twice the size. It looks like the Godot team maintains two package versions simply to avoid bloat if you do not require that functionality.
- lewispollard 4y ago
  Godot's system for exporting games/apps/projects as binaries is that the same codebase/build system that generates the editor binary (the Godot "tools") can be built with the "tools" parts omitted, and the resulting non-tools release binary is bundled up with your project scripts/resources as the binary API for your exported game. The general philosophy for Godot's build/compilation system is that most things are just linked statically, and features and modules can be turned on and off via build flags, so that they can be as portable as possible - indeed it's usually pretty painless and quick to export a game to a binary from the editor on most platforms because of this. With Mono there are 2 sticking points that make this a bit more difficult - first is that this non-tools binary has to bundle the Mono runtime with it to be portable, this adds a bunch of bloat, and Godot's style has always been to be as light as possible. For mobile apps for example, that extra ~40mb of stuff can be a real problem. Additionally, the development machine has to have a fairly modern dotnet SDK installed (ideally .NET 6 SDK + dotnet cli these days) as well as the app host targeting packs in order for the mono-enabled editor binary to run at all (as it contains some CLR/native interop code and nuget packages for the editor tools to copy into your project, etc that fails without these things). So the export template (the non-tools godot API binary) with Mono can't be understood by the editor tools without Mono enabled. Recently direct .NET 6 interop support has replaced the Mono integration in Godot 4, and this might in the future change the above - since it will be able to use the new AOT stuff to publish exported games in a more direct way. It's definitely a stated intention to eventually ship just one engine binary for everything, but it's still a way off happening yet, maybe in Godot 4.1 or 4.2.

cercatrova 4y ago

Bevy is in Rust, made by a former Godot contributor.

bodge5000 4y ago
Apparently they want to make Bevy more like Godot with a full GUI editor, rather than a framework, which for me personally is a real shame. There aren't that many really good modern game frameworks, and Bevy is the only one that uses Rust natively (Amethyst is shut down, Raylib and SDL don't count as they have bindings for literally everything, I wouldnt be suprised to find a COBOL binding for raylib). Otherwise, its fantastic and would highly recommend.
- robotnikman 4y ago
  >I wouldnt be suprised to find a COBOL binding for raylib I was curious and found this https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Games/raylib https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Game...

mangecoeur 4y ago

I think a lot of people assume that they won't like a custom language (I did too) but the reality is when you start using GDScript it just isn't such an issue. One of the huge advantages of GDScript is how deeply in integrates with the engine and handles high level concepts, coupled with the node system you don't need to write that much code. Plus its a simple language (there's no need for 'javascript - the good parts' for gdscript). The godot approach with GDScript and C++ is very much like Python and C++ - write in the high level scripting language and build C++ components when you need more complexity and performance. The scripting language becomes the user interface of the low level parts.

indymike 4y ago

> As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought of returning to the pain of C++ to work with UE. As a professional developer, yes, I love seeing popular languages I know. When you build a product that includes a programming language, you find out maintaining and expanding the language is a herculean effort, and so I can understand from just the financial perspective why Unity switched to C#. As a Dad, what the OP was saying is right - Godot's language, while non-standard is much more approachable for a child than C++ (or most other popular general purpose languages).

bodge5000 4y ago

I wholeheartedly agree, its one of the things I like the least about Godot. That being said, I used Unity for about 8 years, 2 years ago I switched to Godot and never looked back. I think I tried Unity again once, for a few hours, then went back again. Its also worth noting that I prefer ECS as a programming style, which of course Unity uses and Godot doesn't, and yet still I'm using Godot. It really is that good of an engine. I have my issues, plenty of them even, but for the most part its a joy.

deleted 4y ago

[deleted]