Will godot lean toward C#?

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

MagickPanda

Just wondering if Godot will focus on C# in future major versions, and GDScript will eventually become obsolete after some years, since GDScript is still
minor language in both performance and user base compare to C# or other mainstream languages.

Just some random thoughts thou. 😃

Pixophir

C# is not free of license, MS can draw the carpet at any time, which may be improbable. And it is not equally supported over platforms, I had problems running mono on Linux, but afaik it runs smoothly now. But really, what do I need .NET stuff for ?

Yes, GDscript is slow. It is good enough for many games and use cases. Use it appropriately.

But there's C++, which, if used properly, let's C# see the rear lights ... for a short moment.

What I would really like but is probably a pipe dream: for games and simulations that are in heavy need of speed, a mechanism to compile a whole game into an executable, without any middleware in between.

Edit: looks like my info is old. See @cybereality 's post below.

Megalomaniak

Pixophir What I would really like but is probably a pipe dream: for games and simulations that are in heavy need of speed, a mechanism to compile a whole game into an executable, without any middleware in between.

You can just skip the editor almost if not completely and develop your whole game in c/c++. Remember that the editor itself is a derivative product of the core engine.

Pixophir

@Megalomaniak I know, but then I'd probably be better off with my own framework, like so many others. Though I loose some platform support. But the template approach and interpreters really cost execution time. You'll become aware just how much when really trying to brew your own stuff.

The reason why I'm dabbling with an open source game engine is that I expect it to ease my life a bit. You know, you either do a game engine, or a game, but not both :-)

Lethn

I didn't know this about C# so that was useful to find out. An extra fun fact about Microsoft and the copyright shenanigans they pull is they have even claimed ownership over standard fonts which surprised me when I researched it, just to be on the safe side I ended up grabbing an open source one because you can't trust that someone won't try something when it comes to copyright law generally.

cybereality

GDScript will likely be supported for a long time (as long as Godot is relevant). I doubt they would drop it, for the same reasons they used a custom language to begin with.

C# is open source under decent licenses (MIT, Apache), and I doubt Microsoft will try to do anything dumb with the licensing. Even if they did, current versions could still be used.

And they recently added the real .NET to Ubuntu (not the community Mono project) and this version is what Godot 4.0 uses, so if anything they are more open to Linux and open-source, not less.

Personally, I think C# is more suited to application development, I never thought it worked well as a scripting language. But it is better than Java, for sure, and similar enough to C/C++ that it's not hard to learn.

But I like to work quickly. GDScript, or Python-like languages, are much better for that. LUA is also good. I just don't feel like "real" programming languages are a good fit for gameplay scripting.

TwistedTwigleg

Last I knew, the official stance is that GDScript is not going anywhere because it offers a superior Godot development experience. That’s not to say C# is not a great programming language, but rather it is not custom tailored to Godot like GDScript. GDScript 2.0 is a big improvement under the hood and I believe, though it was over a year ago when I read this, there are plans to make it semi-compiled with JIT for speed. If/When that happens, GDScript should be as fast as JavaScript, give or take.

So, I don’t think GDScript is going to be deprecated or ignored anytime soon. 🙂

Pixophir

TwistedTwigleg GDScript is not going anywhere because it offers a superior Godot development experience.

This. It is just too good integrated into the engine. As a scripting language for Godot it is second to none. And C++ is the language when it gets deeper into the engine.

As a Linux user (not Ubuntu), I have no need for .NET. There are superior tools for development in this ecosystem, though they may need some more effort to learn and use. For games as well as systems programming, I'd rather see the upcoming Rust as an alternative. It is in the same performance ballpark as C++ and C, but avoids a whole class of possible programming errors. Though it can drive me nuts with its "You can't do it so I won't let you" attitude :-/.

I believe there are Rust bindings for Godot GDNative, and possibly the new GDExtensions.

TwistedTwigleg there are plans to make it semi-compiled

That would be cool :-)

MagickPanda

Thanks for the insights on the topic, that removes my concerns about GDS becoming obsolete as .NET language supports become fully-functionaly. 😃

Megalomaniak

While not strictly necessary perhaps I feel like adding that this doesn't mean that C# support won't continue to improve. There is no need for any 'versus'/adversarial mentality in here. GDScript is developed by people with a dedicated interest in it and C# support is developed by people with a dedicated interest in it. They don't take away from each other.

cybereality

Honestly, I think C# will improve mostly because there are new stragglers from Unity, and the fact that Microsoft ported C# to Ubuntu native means the integration is easier. So C# will likely become more popular but GDScript isn't going away.

duane

This is all strictly opinion, but I suspect that C# will supplant gdscript over time because more godot users will choose it. Ideally they should get equal support, but that doesn't often happen in software projects. The feature with more use will get more feedback and be fixed and improved more quickly. Up to now, most godot users have used gdscript, but C# is more popular in the programming community as a whole.

A lot of this depends on the health of the godot project -- how many people start using it and who is developing it -- so any prediction is mostly speculation. However, the fact that this question keeps getting asked shows that most people consider language to be a binary choice.

fire7side

Since gdscript is mostly based on python, I think new language users will probably choose it. For myself, I like low poly or low resolution games because they are easier to write, so speed isn't hyper critical. I don't mind c#, but I like python/gdscript better. I like that it's all enclosed in the download also. It's good that we have the choice, though. Maybe I would need to get the slight increase in speed, but I doubt it. It's nothing to really worry about because once you know one language, especially one that's kind of c-based, it's easy to learn another. Some people think, oh, I better just choose c#. Programming courses in college generally start out with python. Up till now, godot has made excellent improvements to the language and I think it's just going to get better and faster. Python is no.1 for programming languages in terms of popularity so there will always be places to use it. Not exactly python, but close enough so you can easily use it after a little practice.

Megalomaniak

fire7side For myself, I like low poly or low resolution games because they are easier to write, so speed isn't hyper critical.

Are you running your scripts on the GPU? I'm a bit confused how graphical fidelity relates to the scripting language and script execution speed...

Pixophir

Of course not. But it is easier to generate and manipulate low poly geometry via the scripting language than more complex things, in which case going to a C++ plugin/tool/extension/whatever would be way.

Now this could be done with C# (on a scripting level) and it might be a performance win over GDscript, but that's still worlds apart from C++, performance wise I mean and if done right(tm) on both sides, at least excluding brute force. As an example of how scripting language performance can relate to rendering speed.

It is when we start to generate all or most of the geometry on the GPU and keep it there, that CPU and GPU are more disconnected. But for that approach, Godot is just not the right choice.

And as said GDscript is better integrated into the engine, thus equally running on any platform Godot runs on, which is not the case with C#.

Edit: low poly, in my understanding: several thousand triangles.

cybereality

My understanding was that the user was making retro games, meaning the overall complexity was less (like PS1 era) not the the geometry had anything to do with the scripting language.

fire7side

cybereality Yeah, I just do simpler games. I probably shouldn't have said low poly, although low poly games run faster on older equipment so I don't have to worry about it so I guess I relate the two. I think it's mainly mathematical equations where there is a difference. Anyway, it works fine for my purposes. The low poly for me is because it takes less time to make models, and they take less storage size so I can make an online game, hopefully. I've found some free and I can easily fill in with models I make, or possibly make all the assets for a full game. I might try it later. I hardly ever actually stay on topic, but I'm pretty happy with gdscript and I did try c# for a little bit.

LeslieS

Is it a possibility that MS could/will buy there way into C# GODOT exclusivity as they did with Unity?
I like C# and I could switch to it if necessary, but I enjoy GODOT coding with GDScript.
I hope for continued development of GDScript (as well as improvements to the built in editor).

Megalomaniak

LeslieS That's a no.

cybereality

I'm not sure how much Microsoft influenced Unity. Unity was using .NET from the beginning, when they were only available on Mac.