this post was submitted on 28 Sep 2023

39 points (97.6% liked)

Godot

5318 readers

23 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Other Communities

Rules

Posts need to be in english
Posts with explicit content must be tagged with nsfw
We do not condone harassment inside the community as well as trolling or equivalent behaviour
Do not post illegal materials or post things encouraging actions such as pirating games

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
The banner is from Godot Design

founded 1 year ago

MODERATORS

[email protected]

The Future of C# in Godot – GameFromScratch.com (gamefromscratch.com)

submitted 9 months ago by [email protected] to c/[email protected]

34 comments fedilink hide all child comments

top 34 comments

sorted by: hot top controversial new old

[–] [email protected] 3 points 9 months ago (1 children)

I'm going to say it (and eat the downvotes): Unity devs have become entitled, and kinda deserve the new Unity pricing structure.

Supporting more and more devices and functionality of c# on weirder and weirder runtimes. It is a mountain of dev work that Unity is paying for and subsidizing for your game. If there was an open source effort to make a unified c# runtime across all platforms that would be one thing, but it will always be front run by new features releasing to .NET so it will never exist.

Changing an existing agreement for pricing without any warning is gross. But something had to give eventually. I would have told you that 10 years ago.

[–] [email protected] 3 points 9 months ago* (last edited 9 months ago) (1 children)

.net 7+ is an open source unified runtime.

Unity just needed to move to .net (previously .net core) to save a tonne of work.

[–] [email protected] 2 points 9 months ago

From unity's perspective it is a bunch of wasted work. Thats the issue - they threw a billion dollars at developing their proprietary c# runtime and not recouping the cost of investment. But they can't wait around for Microsoft to make moves. And they probably don't want to open source their runtime either out of fear that a free game engine using it will make the rounds.

Godot ultimately has the right approach: offer support through universal bindings to it's underlying archetype and let devs decide what they want in their game's stack. Everyone wins.

[–] [email protected] 1 points 9 months ago (3 children)

Why are we using C# I stead of C++ for the in editor language again? Inst C++ more compatible with everything? (I know that GDMatice exists, buts that's a lot more work to use I feel)

[–] [email protected] 2 points 9 months ago (1 children)

@Smorty @mac I have been wondering this non-stop since I found out #godot uses C#!

I know the idea that C++ is the end-all-be-all is an oversimplification at best, but It's still a decision I'd like to know more about.

[–] [email protected] 1 points 9 months ago

Godot is mostly written in C++, so it's such a weird decision to switch languages like that, and expose C# instead of C++ as a game logic programming language. I suppose it was done so that Unity devs would find it more attractive. Unreal uses C++, so yeah, why?

Also brand bad, so no C# for me, only GDScript and C++ GDNative.

[–] [email protected] 1 points 9 months ago

I get the idea of having flexible options for game devs. Support for systems language for engine internals (C++), hooks for a runtime machien based language (C#), and support for a dynamic scripting language (GDScript) makes sense architecturally. C# is also strategic because XNA to Unity has pretty much cemented its status for game devs. And then GDExtension to provide an api layer for whatever other language under the sun you want to use. It is a very sensible place for Godot to be in.

[–] [email protected] 1 points 9 months ago (1 children)

The main language is GDScript rather than either of them (although the engine itself is coded in C++). C# support was added on since microsoft gave them money to do it

[–] [email protected] 1 points 9 months ago (1 children)

@mac @Smorty 😨 Well that's not good! Microsquish (still) can't be trusted! 😰

[–] [email protected] 1 points 9 months ago (1 children)

Yeah. Embrace freedom and Foss. Reject Microsoft and C#. Debian User here.

[–] [email protected] 1 points 9 months ago (1 children)

C# is foss tbf

[–] [email protected] 3 points 9 months ago

It is in a technicality But the reality is, it will always move at the pace and at the whims microsoft wants it to.

Thats not necessarily a bad thing honestly. But you can really get i to trouble making it a core dependency for something like a game engine. Unity's users didn't care that Microsoft hadn't posted the runtime to iOS, they expected their games to run on iOS. So Unity did a bunch of dev work that is now kind of a bad investment with .NET 8. This is the core of why they wanted to charge an install fee in the first place.

[–] proton_lynx -3 points 9 months ago (3 children)

What I don't like about C# has nothing to do with the language itself, which is pretty good. Is the fact that is made by Microsoft and their tooling SUCKS. I'm having to build .NET projects at work and the dotnet CLI is pure garbage. I wish we had something better instead of using C# but the gamedev industry is pretty invested on it.

[–] lordxakio 8 points 9 months ago* (last edited 9 months ago) (1 children)

Hi. I am not a game dev, but a c# one. What is it that frustrates you about the dotnet CLI?

Edit: I use C# for work, not a Microsoft employee who works on c# dev lol

[–] proton_lynx 1 points 9 months ago (2 children)

Documentation is the worst offender. I remember one time that running dotnet restore and later running another command with --no-restore flag wouldn't work, but running the last command without the --no-restore flag would. Creating a sane CI/CD pipeline for C# apps is a PITA.

[–] [email protected] 7 points 9 months ago

I've never had an issue with the dotnet CLI, including the commands you're talking about. Their documentation is a bit scattered at times but for the most part they have examples on everything and walk through most scenarios.

I'm not a Microsoft employee either, just a c# dev of 10 years.

[–] [email protected] 0 points 9 months ago* (last edited 9 months ago) (1 children)

I do a lot of work with c# CI/CD and doing what you said absolutely does work.

Most of my scripts are

dotnet restore
dotnet build --no-restore
dotnet test --no-build
dotnet publish --no-build

[–] proton_lynx 0 points 9 months ago (1 children)

It works, until it doesn't

[–] [email protected] 0 points 9 months ago* (last edited 9 months ago)

Like everything. They likely got their configurations wrong.

[–] [email protected] 3 points 9 months ago (1 children)

This is the major problem with c#. Godot project should target support of .net and mono runtime and THAT'S IT. If you want C# to run on iOS, Microsoft and Apple have to fix it. Let's not spend 1 billion dollars a year making sure whatever random iOS runtime is supported like unity did. That is the root cause of why they would like to charge I stall fees in the first place.

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago) (1 children)

.net (formally .net core) runs on all major OSs.

Mono and .net framework are super out of date and shouldn't be used anymore.

[–] [email protected] 2 points 9 months ago

Well whatever - going down the proprietary imementation route for c# the way unity did is a no go for Godot imo.

[–] [email protected] 2 points 9 months ago

Also, the dependency management, idk why but I can just shit each time I'm confronted with different .NET versions.

[+] [email protected] -11 points 9 months ago* (last edited 9 months ago) (5 children)

Or, ya know, just learn another language. It's not a big jump.

Edit: Godot 4.x is already slated to support a plethora of languages- including C#.

But even if the devs decided to not support C# for some reason: you're really going to walk away from a game engine over not being able to use C#?

[–] Lemminary 17 points 9 months ago

Of all the languages I've used over the years, C# is one of the best I've found recently. I'd rather not.

[–] [email protected] 8 points 9 months ago* (last edited 9 months ago)

Well I mean the biggest thing that would be the ultimate ideal would be anything that can maximize the ability to bring existing unity projects over to godot. IE minimal refactoring needed.

Big thing is not just getting people to start their new projects, but what about those who have spent 3+ years mastering their game, only to have the rug pulled out from under them when it was 80% of the way to release worthy.

[–] [email protected] 8 points 9 months ago (1 children)

It's a single purpose language. Learning it will bring you no benefit other than using Godot.

Learn c# and you can do basicly anything you want.

Also gdscript is kinda ugly.

[–] ObsidianBlk 5 points 9 months ago (2 children)

I disagree. Even if one is new to programming, learning GDScript still teaches one how to program. Loops, conditions, variables, functions... basically all that is programming is still part of GDScript and it would be no more difficult, once learned, to switch from GDScript to any other language as it would to switch from C#, C/C++, Python, etc. That is to say, once you understand how to program, it's nowhere near as hard to switch languages as initially learning your first one.

That said, the same could be argued when working with different engines within the same language. C# in Unity, C# in Godot, and C# in ASP.Net applications all have their idiosyncracies that might make the language feel different, even though, at it's core, it's the same language. How a library functions can have a drastic effect on how you program a language, and if you change one library for another, even in the same language, you may find you have to alter your programming style.

Additionally, languages can be ported. GDScript currently only exists in Godot, but nothing is stopping anyone from writing a python-like or nodejs-like runtime interpreter for the language that allows you to use GDScript sans-Godot.

As for how nice the language looks... that's subjective. I, honestly, find GDScript to be a very clean looking language (much like I do Python... probably unsurprisingly). C#, on the other hand, I find to be a verbose mess, seeming to take 100 lines of course to accomplish something I can do in 10 in other languages. But, again, that's subjective

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago)

Personally, I like the idea of using bindings more than using GDscript* in Godot and my preferred language outside of Godot. From what I've seen, even if not perfect it's much less likely to cause confusion having 1 workflow (+some extra context in Godot) rather than 2 (not just syntax, but also technical stuff). Also it's nice to use code that doesn't actually depend much on whatever engine/framework you happen to be using it in (particularly an imported file with procedures).

Though some of my perspective may be that I haven't really used the language that I want to (mentioned in other comment) aside from a bit of tinkering with Raylib bindings (and a bit with Godot 3.X), so (aside from switching back-and-forth making less sense) I need Godot to learn the language just as much as I need the language to use Godot, all the things that motivate me (starting points for projects) are in various stages of viability particularly with how they relate to each other. Which admittedly is not the type of situation people wanting C# are in (...maybe some are with 4.X C# limitations).

Well, that and lacking writing/ideas for actual content. For instance I coded a basic adventure book reader (CYOA-type thing) but had no desire to actually write a story (so I didn't develop it further).

*= I would not totally be against using GDscript (particularly as the language I want actually isn't too different syntax-wise) particularly as I gain more experience, but I don't think it would serve much of a benefit unless it was for a specific calculated reason. As in not my first-step or common use of time. Same with other languages, for instance something like a networking system could be done in any supported language thanks to how Godot handles languages. And that reason for a different language could just be what someone contributing to a project prefers.

[–] [email protected] 0 points 9 months ago (1 children)

seeming to take 100 lines of course to accomplish something I can do in 10 in other languages. But, again, that’s subjective

That's clearly vast exaggeration, and devalues the rest of your post.

[–] ObsidianBlk 0 points 9 months ago

So... my opinion regarding how I perceived C# and followed that statement up with it being subjective (aka, opinion), in your view, devalues the rest of my post. That's your hang up?

Cool beans

[–] [email protected] 4 points 9 months ago (1 children)

i just want enums and interfaces!!!

[–] [email protected] 2 points 9 months ago

Gdscript has enums.

[–] [email protected] 2 points 9 months ago* (last edited 9 months ago)

I mean people like what they like, also I'd say "learn another language" makes more sense for 3.X where there were a ton of good language options. C# isn't the only thing up-in-the-air due to 4.0's binding system change (that will hopefully be worth it), though C# will get priority for an obvious (and understandable) reason while other bindings will need people in the community to create new efforts for each language that still doesn't have an option.

I say that as someone waiting on Nim-lang bindings (and 1 person working on them is consistently working on it) for 4.X (the 3.X bindings were listed as production ready here). I mean unless there are other languages that also: 1. are usable outside of Godot 2. Have an easily-readable style 3. Have good performance 4. Have (optional) low-level capability/options/flexibility. (I've never actually looked at C# but I don't think I want that ecosystem/setup)

Which, from what I've seen seems unlikely as most things seem to pick a side when it comes to speed/capability or ease. Maybe there's an option with some form of compiled Python but that seems to be a technical mess to get through/decide on and even then said option wrecks its compatibility with Python Godot bindings because obviously it's not interpreted Python anymore.

Godot

Links

Other Communities

Rules

Wormhole

Credits