C# as scripting language

[ghost]

I could not find any other issue mentioning this, so I suppose most discussion about it happened over IRC.

In #5049 we discussed some things about scripting, and some said the Godot team is considering C#.

C# is a great language with many features, but I personally think that considering Java 8 is a much better language than Java 6, has a better runtime across many platforms and a better JIT and GC than the CLR (unless things changed in the last year), Java could possibly be a better candidate.

Unity might use C#, however Godot never set out to be a Unity ripoff. Java is much more popular than C#, according to this site and job postings, and there are many game developers (especially on Android) who use Java.

Additionally, many of the features that C# offers compared to Java are not much important if the purpose is scripting, as most scripting in games is imperative and (at worst) object-oriented (and many of the advantages C# offers are related to functional programming, which Java 8 supports decently anyway). Just take a look at your average Unity script, even a more complex one like this: there's not much there that can't be done in Java straight away!

The JVM also offers a good amount of other languages - Kotlin, for examples, which has many features like nullable types, pattern matching and operator overloading. There's also Ceylon, which is in many ways a better C# (and compiles directly to JavaScript). Supporting those would not require any more work than adding a JAR dependency. Java also has a larger amount of libraries.

And if performance is the main concern and a runtime like the CLR and JVM is too heavy, those can be done away with and C++ could be used directly via LLVM, so that a JIT can be used, avoiding expensive recompilations. This solution is best kept along with GDScript, so that novices (or people who don't need extra performance) can use that instead (and avoid segfaults). The latest standard of C++ has very clean syntax, so I don't think verbosity should be a problem.

C++ is the solution I would like the best, because it would bring the fastest performance (zero overhead, can't be said for any other language), it would not need any extensive changes (as Godot can already be used from C++, and is written in C++ itself), it would have the more consistent support across platforms and it would make it possible to use Godot for very large projects (such as AAA games - there's a reason most studios use Unreal and not Unity). Additionally, keeping GDScript would let those people who don't need extra performance an easier way to write scripts than Java or C# (both very verbose languages) would be.

tl;dr: I think C++ (or worse, Java 8) makes a better choice than C# for scripting in Godot.

Any opinions?

Edit: I see the "feature proposal" tag (which is correct) but I want to make it clear that I'm not proposing C# support in Godot, I'm merely reporting and commenting on some of the things I've heard around.

[Zylann]

Type hints could close the gap preventing code completion from totally working. I once had worked on a project using Lua, and they wanted to have this too. Research led me here: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48 This is what a function parameter can become, if you dive too far in type hinting xD But I think there should be a tradeoff. Just see how TypeScript or Haxe do (they both allow mixing variants and typed). Also, type hinting is already there in Godot. It's only used in export() :)

[neikeq]

Did anyone already started to experiment a Mono module? @Zylann

Check out GodotSharp. The current state in the repository is not usable yet. In my local repo I managed to implement enough stuff (only Vector2 and Matrix32 are available as basic types) to translate the 2d/platformer demo to C#, except for enemies and bullets instancing which is done from GDScript since references are not working yet. This is an example of the player class: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

[ghost]

@Pikl

Afterthought: Is it possible to use only C++ in Godot? I honestly think I would prefer to learn C++ and use that over GDScript.

Yes, it is possible, but currently it's not that easy and/or convenient and you have to recompile Godot from scratch. Please show some support for #3936 if you are interested in C++ being a first-class citizen, so that it can be used along with GDScript (or exclusively) without much work.

[Warlaan]

@Zylann Pikl asked about changing the syntax of GDScript to resemble that of C# so it becomes easier to read for Unity developers. That's what I was commenting on. Yes, C# does have more features, which is the only reason why the keywords and characters that I removed were in there in the first place. And that's why adding them just for the sake of having GDScript code that looks like C# code is not just unnecessary, imho it's wrong, since you would be using a syntax that hints at language features that GDScript doesn't have.

@Pikl It's not about the amount of keystokes, it's about the amount of choices and the implied meaning of the additional characters. GDScript simply doesn't have some of the features that would legitimate the additional keywords. For example every variable, class and function would have to be preceded by the keyword "public", since C#'s default visibility modifier isn't public (except for namespaces - it changes based on the use case... another situation where Microsoft decided that KISS is just a band from the 80s) and since in GDScript everything is public.

So why not add C# with all of its features? As Zylann already mentioned the effect of adding C# to Godot is not that straightforward to predict. If you haven't done yet I would appreciate it if you read my long post in this thread (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). As a developer I would always have asked for more powerful languages. In my spare time I am currently looking at Kotlin just because paper-pauper mentioned it in the first post. But since I had the opportunity to look at the effect of programming languages on the outcome and the behavior of game developers I have realized how important it is to chose an adequate language rather than a powerful one. As I explained in the linked post I am certain that C# has a noticeable influence on the culture in the Unity community which sees programmers as people who

• write stuff for the asset store
• write tutorials
• fix bugs.

In my experience there isn't much of a gameplay programming culture in Unity. As soon as you run into any kind of trouble you start looking for patterns or pre-built assets to solve it. There's actually a significant number of people who pick their patterns before they even know anything about a project, and that kind of mental inflexibility affects the gameplay results.

And that's just my favorite counter-argument, there were several other good ones in the first posts. ;-)

[neikeq]

The problem with JVM is that it's too heavy. Did anyone have a look at Avian? How compatible is it with the Java world?

[ghost]

@neikeq That does not mean it has worse performance - AFAIK the JVM has better performance than the CLR, and also a Garbage Collector much better suited for game development. It's also installed on most computers, regardless if they are Windows or Mac or GNU/Linux.

It also has a larger wealth of higher quality FLOSS libraries and, regardless of what some people say, better cross-platform support.

I'd say that between the two, the JVM is clearly better for game development (but I'd avoid both it and the CLR all the same).

[Warlaan]

Avian does look interesting. I don't have experience with it, so I can't answer your question, and I am afraid that its compatibility might turn out to be as problematic as Unity's Mono version, which makes it really awkward to use third-party libraries unless you happen to find one for one of the .NET-Versions provided.

But having a light-weight Java implementation as an additional option besides GDScript & C++ for cases where you need quick turnaround times and can sacrifice code quality (like game jams or rapid prototyping of new backend ideas) would be nice.

[kubecz3k]

@neikeq Avian is made in mind to provide java-scripting for c++ projects so it's really a good candidate. It can be very small (something like 100kb if I recall correctly). Heard about some libGDX games that were using Avian to release iOS ports... jMonkey engine is using Avian on iOS as well). In general Avian comes without whole packaging that normally comes with JVM like sun/oracle classes. However I don't think it's a problem since 'original' java classes are not well suitable for games at all, this is why libraries like libGDX provides their own implementation on vectors, or data structures.. and in the end I think we would need to re-implement those classes as well. (However it's easy to embed various parts of original java classes, but the more we include the bigger Avian will become)

[neikeq]

@paper-pauper I meant heavy in size, supposing it will be bundled with the game. But as you said, it's installed on most computers, and considering the popularity of frameworks like libGDX, it could be the best option. My problem with C++ as an alternative to GDScript is that its syntax is horrible. That's a productivity killer. It's fine for engine and modules development, but I wouldn't write an entire game with it. Having said that, I am in favour of #3936 and having something like what Unreal does, but I wouldn't view it as an alternative "scripting" language.

@kubecz3k Does it support other JVM languages? e.g: Kotlin

[kubecz3k]

@neikeq yeah as far as I know it's fully compatible with java bytecode so it supports any jvm ready language (kotlin, scala, jpython and so on) I think we might ask some questions on avian google group: https://groups.google.com/forum/#!forum/avian it seems to be quite active

[Warlaan]

+1 to not viewing C++ as an alternative scripting language. As I said before it's a good thing that Godot has one language optimized for scripting and one for backend development as opposed to having one language that is kind of "meh" in both areas.

That's not to say that dynamic lib support and faster C++ development wasn't something I'd love to see.

[kubecz3k]

But to not be to over-enthusiastic about Avian, here is blog post from the main dev of libGDX in which he explain why libGDX is not using Avian for ios ports. http://www.badlogicgames.com/wordpress/?p=3925 (scrol down to Avian part) I'm not a jvm programmer/hacker (but the author is - since he was also working on RoboVm (yet another jvm that was bought and closed by Microsoft)) so I don't know how much of this would really transform to the situation in which Avian is used only as a scripting language (not powering the core engine)

[GlaDOSik]

Most of you are probably programmers with more experience than I have, but there are my 2 cents. A year ago, I would root for C#. But I learned GDScript syntax very quickly. At the end of the day, you still need to learn the API and that's probably the most time consuming thing to learn. So yeah, I don't need C#. @Warlaan pulled out a lot of good reasons against C#. Implementing C# would also take a lot of time. It would also mean more bugs. Yeah, we have a great community which contribute to the code base but we still have only one @reduz I think the time required to implement C# should be invested to features we really need. How many Godot developers are satisfied with GDScript? Yes, it could be faster, but I don't have any other problems with it. I would rather have one awesome scripting language than two not so good ones. Even Unity is lagging behind with old Mono.

What I would like to have is static typing in GDScript. Not C++ as a scripting language, not C#. Let's focus on GDScript and make it even better than it is now.

[Ziflin]

Since the engine that I lead the development on for 14 years at was mentioned in the Visual Scripting thread, I thought I'd add my 2 cents here as we were developing a new engine written completely in our own C#-like language.

We wrote our own compiler (also written in our own language after bootstrapping it in C++) that compiled to C++ (almost pure C) code that was then fed into the compilers of all the platforms we supported (XBox/PS/PC/Wii/etc). We wrote our own generational garbage collector to be able to tune its performance as needed - doing it this way meant that it was used throughout the engine which meant that it was well tested and profiled. And since we were cross compiling to C++, we could easily write C++ code in 'native' functions that could call system APIs as needed or include platform specific operations (SIMD).

I can't really imagine how frustrating it must be for Unity to have had to merge a bunch of C++ code with Mono -- which probably explains why it's lagging behind as @GlaDOSik pointed out. It certainly wasn't something any of us were interested in doing though.

Our main goal was to unify the languages used between the engine, the editor and tools, and the gameplay code into a single language. Previously, the engine and tools were entirely C++ and a visual-ish scripting language (it looked like C code at least) was used for all gameplay that was preferred by level designers, but annoyed the majority of the gameplay programmers who were writing the majority of the code. It also allowed us to tailor the language to things that we might need for gameplay development (like state machine support).

You can't please everyone though. If I had to work on or try to help someone debug a nasty mess of spaghetti blueprint/etc node-based "code", I would want to gouge my eyes out in retaliation. I would expect an artist trying to read C++ code to do the same. What you can do is waste a lot of time arguing over what the best solution is and even more trying to please everyone. At some point you just need to focus on making the most productive tools that you can for the right people - and sometimes that means a few people might have to learn something new.

"If it's not C++, it's slow" seems to often be the mantra, but I would say the majority of shipped games are written with something other than C++ for gameplay code these days. I haven't actually seen someone post performance problems specifically from GDScript, though I'd certainly be curious to hear from them what was slow.

As far as my introduction to GDScript, it went something like this:

• OMG Python-like!? That's nuts, whitespace shouldn't matter!
• Hmm, not a fan of "lower_case" style (see you can't please everyone).
• Well ok, this is actually kinda cool and well thought out.
• Yeah, this is nicely integrated with the editor, I could certainly see being very productive with this for gameplay code and some editor plugins!

It looks like a lot of effort and time has been put into GDScript, and it seems like the right tool. So I really just wanted to say kudos to those that worked on making it!

[reduz]

@Ziflin Hey! glad to meet you over here, Vicious was one of the first game engines we used professionally (though we were hired with @punto- to hack it and fix problems with it more than actually use it).

The visual scripting language was truly a nightmare, but the source code was really well done, clean and organized. After working with Torque, it was a bliss. I learned a lot working with it. Sony did a great work selling it in Latin America because everyone was using it over here a decade ago..

I think the most amazing moment I remember from working with it is accidentally stumbling into a piece of code that listed the languages, and there was a comment "Portuguese not supported"

We were really laughing hard at it and making jokes, and the game producer (who was behind us and we didn't notice him) was trembling in fear and said: "Wait what? all that is left now is translating the game to Portuguese, this is a joke right?"

But we just used Chinese for Portuguese, all worked fine and the game was shipped. Glad to know you guys are still developing it!

[SuperUserNameMan]

(quote from @Ziflin ) I haven't actually seen someone post performance problems specifically from GDScript, though I'd certainly be curious to hear from them what was slow.

I've personaly reached a CPU / Gdscript bottleneck in this project : http://godotdevelopers.org/index.php?topic=15519.0

I wrote some basic AI and basic old-school pseudo physics in GDscript to control each of the 8 cars. I did not cry loud in public about this performance issue because there was still some little rooms for optimization. But if I wanted to add more cars, I would have been forced to drop Gdscript for C++ (edit : which I would like to avoid since I don't really want to have to compile again and again).

Also, I think that I encountered the same CPU / Gdscript bottleneck last year with this other project which was using GDscript for basic AI for each bugs (animals) : http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=50893 The more I added bugs (animals), the lower were the performance.

I could share my experience on it if someone want.

[ghost]

@SuperUserNameMan Please go ahead, but I think this other ticket I opened #5049 (which speaks specifically about GDScript performance) is more suited for that.

[SuperUserNameMan]

@paper-pauper : not sure I could contribute #5049 (which is more about adding JIT, about what I could just add a thumb-up). The experience i could share is more about what kind of bottlneck i've reached, what were the specific symptoms, how I had to work around, how I optimized, and what "godot's design benefits" I had to sacrifice.

[reduz]

@SuperUserNameMan I haven't really thought much yet about implementing JIT via type inference, but for that the VM must support static typing first

[Warlaan]

I would be most interested in hearing what kind of AI code you are referring to. My preconception would be that any code that can cause performance issues when run on just 8 entities is probably not really game code and as such should be put into a C++ class anyway, that's why I am asking.

[Ziflin]

@reduz Haha, well apparently it's a small world! And yah, the visual scripting kind of grew out of control (it was really intended to just be for dealing with triggers and small bits of event logic). Vicious actually closed its doors earlier this year, but it was a lot of fun working there.

@paper-pauper I'll check out the other topic you mentioned. I didn't really mean for people to start posting performance issues in this thread.

If GDScript was to add static typing, it may be easier to just have an option to convert it directly it to C++ which would avoid extra overhead from IL->C++ transitions and keep the runtime small (no JIT compiler, etc). You could then prototype in GDScript or make mods with it, but then you could also auto-convert it to C++ for extra speed when needed for final builds.

Doing that would also keep the existing IDEs (VC++, etc. & the Godot editor) that people were used to using. We actually just used VC++ to debug our language and our compiler generated #LINE directives in the .cpp files so that you could easily step through the original code and set breakpoints. So in theory you would be able to prototype and debug with normal GDScript in the editor, but during 'GDScript->C++' enabled builds you could still use your C++ IDE/Debugger and set breakpoints/debug in the gdscript files. For us, the generated C++ files were temporarily and we only ever looked at them if there was a code generation issue.

Anyway, just a thought. The fact that you have a nice scripting language now is definitely a plus and it certainly makes doing things like user-created mods, fast prototyping, and adding new features to the language possible.

[SuperUserNameMan]

Indeed i did not understand that I was supposed to post my performance issues into this thread neither. Here was more suitable : https://github.com/SuperUserNameMan/kart-zero/issues/1

[reduz]

@Ziflin Actually what we were discussing in other issues is first, adding a minimum C API to write godot modules/scripts using plain C via a minimal API that exposes Godot's whole reflection API, this would solve a common problem we have regarding distribution of bindings to different kinds of libraries without having to recompile Godot

Examples of this are guys who want to bind steam API, ODBC, SQLite, Kinect, etc. All of which require writing modules in C++. Doing this with a C API solves the problem of dynamically linking against C++ (which is very limited due to every compiler, or compiler version having their own ABI, and the symbol size mismatch problems that might happen between Godot versions). C does not have any of those problems.

Once that works, it should be really easy to compile GDScript into C and load it at run-time when the game runs or is exported.

[Ziflin]

@reduz Ah cool. So basically you're talking about being able to write a 'plugin' DLL that can expose what it wants to GDScript? (or did I misunderstand?)

Once that works, it should be really easy to compile GDScript into C and load it at run-time when the game runs or is exported.

Does this work for someone wanting to write a dll that has say several new C++ Node-derived types in it?

It's a bit sad that the new C++ 'modules' support does seem to be enough to fix some of the issues with DLLs though.

[ghost]

Why not use an embeddable scripting language such as lua or Ruby?

[reduz]

@jersten because read the docs - http://docs.godotengine.org/en/latest/reference/gdscript.html

[reduz]

@Ziflin yeah, but you will have to use the C API via reflection (though you can ask for function pointers via reflection so it should be fast enough..). The goal would be mostly having an easy way to load DLLs that avoids the ABI problem, and also a simple way to compile GDScript to C and load it as a .so.

[ghost]

Im gonna chip in my 2 cents here for what is worth. I never coded in C# but only in Java. While I would personally prefer Java due to having used it and liked it, I actually support C# over Java. C# is what Unity game devs use so having it in would make Godot it part of this indie dev ecosystem Unity created. Also Java is not even a good choice if you want a JVM language. There are other better languages that compile to JVM.

[ghost]

I think people are missing the point anyways. C#/Java != scripting language. GDScript is sufficient; easy enough to learn, etc.

Adding a language like Java (build a JVM for what purposes?! Syntax?! Require a JVM with a specific version to function?!?) or C# (Implement mono and kludge the engine; or build your own?) would poison the engine.

If there is a problem with GDScript it should be pointed out; and then attempted to be fixed.

[ghost]

I disagree. I feel C# would attract a lot of Unity devs or devs who are familiar with C like languages providing a nice alternative to the python like GDScript. The final piece of the puzzle would be a visual scripting which would attract artists who are not used to coding. This should cover pretty much everyone. Also no matter what you code in you still need to learn Godot's classes and functions which would be same in any language.

[erodozer]

To all the people who argue C# because Unity developers know it, consider this: a lot of Unity developers don't know crap about how to program in C#. What they know is how to use the Unity API, which just so happens to have C# bindings. You bring them over to Godot, even if it's C#, they won't know what the heck they're doing anyway and will be just as lost as providing them with a different programming language.

Including any additional languages is just more overhead and more that the project has to maintain that it shouldn't have to.

[neikeq]

I was thinking a lot about this, and my main concern about supporting something like C# is that most of the people who would use it would be Unity users coming to Godot. Clearly, we would not include C# with the official templates, and I highly doubt they would build the module themselves... It could end up being a big effort to support a language which would be used just by a few.

[ghost]

I think there is a misunderstanding:

• They see GDScript and think that GDScript is on par with C#; missing the fundamental point that C# is not a scripting language.
• Because of the above fact, when someone says "Java or C#"; what they are really asking for is a rewrite of the engine into C#/Java or adding some bindings to support those languages (lol no).

Since I'm assuming the latter; debugging in C#/Java is a nightmare on multiple platforms; as both of those languages are not platform independent (inb4 there are runtimes on virtually all OS's); it turns into "Write once, debug everywhere" (this is why games written to Monogame come out on Windows first; and then eventually Linux/Mac because the devs have to debug for those platforms). This is why JVM updates break applications.

Adding support for those languages adds no value to the engine.

If the argument is "moar Unity devs"; then documentation should be made to help transition Unity devs; that layout differences, etc.

[ghost]

That is why I said in the end it doesn't matter what language you use you will still need to learn Godot API classes and all. Is not like Unity devs are gonna be insta experts cause they know C#. I guess is more of a "aura of goodness" to Godot if it supports C#. People feel like they know more and all the sudden Godot is more accessible and not so scary anymore. The no 1 negative thing about Godot from non Godot users is that it has a it's own scripting language. As a Godot user is know that BS because GDScript is a fun and simple language but to outsider it may seem uninviting. I can't speak from dev's point of view but maybe is more effort than is worth unless devs get something out of implementing C# then is worth it. In the end is lead devs decision and whatever they decide I'll roll with it. I'm sure it will be a good decision.

[ghost]

I agree with you on GDScript being a bit offputting because it's virtually an unknown language. But, after I read why Lua and Python were removed and the benefits to adding GDScript I was less concerned.

[ghost]

Another thing that might be relevant: there is another MIT-licensed engine which already supports C# and is more similar to Unity, Atomic Game Engine. I suggest that all people who desperately need something as close to Unity as possible give it a try.

[itsraineing]

I'll just add my 2 cents here. To me, the big advantage of C# is performance, while still being easier to work with than C++. GDScript, being dynamically-typed and all, is very quick to write, but is never going to be ultra fast to run (though it could be optimized quite a lot, which is planned). C++ modules are very fast, but are kind of awkward to work with; C++ isn't exactly a friendly language, and having to recompile the engine to use them isn't really optimal. To me, C# is sort of a compromise: a lot faster than GDScript, and with the proper support, a lot easier to work with than C++ modules.

All that being said, it doesn't have to be C#. Anything else that would have a similar effect would do fine, as far as I'm concerned, be it statically-typed compiled/JIT GDScript, or something else like Swift or something. C# may be the best for 'marketing purposes'; even without a similar API, devs from other engines/frameworks would probably be more comfortable with it. Modified GDScript may be easier to implement, and would probably be integrated a lot better.

[Warlaan]

I know that the thread is very long by now but please read all of the above posts before posting something on your own. The argument that C# was going to attract people and was very convenient for Unity users doesn't get any more valid if it gets mentioned a dozen times more.

See here why imho C# is great for Unity and bad for Godot, see here why imho adding C# will lead to dirty code, not just in your own projects but also in online tutorials, the upcoming asset store etc. and see here why imho the argument that people had to learn many new things when changing from C# to GDScript is invalid.

Let me add a comment on the argument that C# would bring in new people. Why do we want more people to use Godot? I totally understand that open source projects need a community that

• adds features
• fixes bugs
• creates reusable assets
• makes suggestions for new features
• finds bugs or problems with the workflow
• writes tutorials

but all of the above need people that understand and appreciate the core idea of the engine. People that add unnecessary features to a library are not helping and there has been more than one project that suffered from such features, sometimes up to the point where the project was abandoned or split up. Unity especially suffers from people who write tutorials even though they don't really understand what they are doing, which to a large part is C#'s fault.

If people are not even willing or able to learn a language as simple as GDScript then it is highly questionable whether they will take the time to fully grasp the design philosophy behind Godot before they start actively contributing to the community. ("Actively contributing" meaning anything from sending pull requests to posting their opinion about Godot on Facebook.)

Godot isn't a commercial engine. Unity has an interest to bring in as many people as they can because they are all potential customers and advertising for the engine. It would sure be nice to have a big community of users that appreciate Godot as it is, but there's no point in sacrificing some of Godot's qualities in order to cater to a larger community.

[ghost]

@Warlaan people generally don't wanna waste time and they will use whatever code snippets they find when building their projects esp in the beginning when you're learning. For beginners your points are mildly relevant because they will end up learning whatever language the code snippets they use are written in. I know this because that's how I learned looking at examples and I knew no GD Script but I learned it. The issue is not what's best or how this will impact or complicate the tutorials etc. The issue (for me) is C# more so than any other language will make Godot part of this indie dev ecosystem Unity is part of. This is not even about Unity, is about Godot.

[Warlaan]

EDIT: removed some unnecessarily harsh language ;-)

@trollworkout No offense, but you didn't really understand my point and I have a feeling that you didn't really think through what you said either.

1. Yes, people don't want to waste time. The full specifications of GDScript: a few screens. Books explaining C#: usually at least 500 pages. I have spent a few days learning GDScript and I am quite certain that it doesn't have a single feature that I don't know. I have worked both professionally and in my spare time with C# for years now (using Window Forms, WPF, XNA and Unity) and I still find code snippets that use features that I haven't fully understood. Asking for C# because it was less of a waste of time doesn't really make sense.
2. "beginners will end up learning whatever language the code snippets they use are written in" - see point 1. The notion that you could learn C# from code snippets is far from the truth. The things that you can learn that way are so basic that it's not going to take more than a few days to "learn" a different language. You said yourself that you learned GDScript that way.
3. "C# will make Godot part of this indie dev ecosystem". And what is that supposed to mean? Could you use Unity code snippets in C#-Godot? No. Could you reuse Unity assets in C#-Godot? No. Could you read Unity tutorials and apply them word for word to C#-Godot? No. So what is this "indie dev ecosystem" you are referring to?

As paper-pauper said there are lots of engines and libraries to choose from. Do you want a component system like Unity's? Look at Atomic Game Engine. Do you want to keep using C# in an engine but want to ditch the component system? Look at CryEngine / Luberyard. Do you want to keep using C# but want to ditch the engine? Look at MonoGame.

The thought that adding C# to Godot was helping beginners is faulty, since you said yourself that you learned scripting in Godot by looking at code snippets. If that's how you learn to work with an engine wouldn't you want a language that implicitly tells you how the engine works rather than one that is designed for thousands of different use cases?

[ghost]

I'll just add my 2 cents here. To me, the big advantage of C# is performance, while still being easier to work with than C++. GDScript, being dynamically-typed and all, is very quick to write, but is never going to be ultra fast to run (though it could be optimized quite a lot, which is planned). C++ modules are very fast, but are kind of awkward to work with; C++ isn't exactly a friendly language, and having to recompile the engine to use them isn't really optimal. To me, C# is sort of a compromise: a lot faster than GDScript, and with the proper support, a lot easier to work with than C++ modules.

All the issues you mentioned with C++ you mentioned are valid and could be fixed via #3936. We've discussed this many times already, but just for the sake of clarity here are the issues with GDScript that we can objectively recognize:

1. Poor support for third-party libraries
2. Poor performance

Being able to write parts in C++ easily fixes both of those. C# (or another language) would also fix those, but with an additional runtime, worse performance and cross-platform support and a lot of additional work needed (whereas Godot is already written in C++). So the rational choice is to use what's already there (C++) and make it better, and of course fix those issues with GDScript.

[phicore]

I quickly read this thread, and saw that GDScript to C was envisionned.

If this the choosen way, it would be a good thing to consider embedding the tcc C compiler in the editor to compile that generated C. It has very fast compile time, is very small and easily embedable. Maybe this would be the best way to speed things up.

[Calinou]

TCC is distributed under the GNU Lesser General Public License.

(source)

This makes it probably unsuitable for inclusion into Godot. It also doesn't seem to be maintained anymore.

[ghost]

@Warlaan I don't have to think too much. At this point we all said the same thing about 10 times already I think we pretty much know were we all stand. Other than my 2 cents and a few ideas I don't have much more to contribute since I'm not a dev and I don't know the engine inside out that well. I'll let those who know better speak. I just wanted to voice my support and that's all. Offtopic: But yea in regards to point 2. which you made a lot of fuss about that you had to edit your comment. SO you're saying you can't learn a language based on examples? I think you ASSUME people are unable to learn it unless they read 500 page manuals which C# is known for you say reason 1 to reject it. Well I am living proof that you are wrong. How do you think I learned GDScript ? With the API and demos examples and asking around questions. Mind you I had 0 Python knowledge before I started so everything about it as pretty alien. As a side note I wonder how many people buy libGDX manuals vs how many people actually google "how to do X in libGDX" probably why asset store is so badass in Unity. And with that I'm done for the time being cause I got nothing more to say .

[SuperUserNameMan]

( @Calinou : Bellard allowed a fork of TCC to become BSD or MIT. But last time i checked, the dev of the fork did not have released sourcecode. So, maybe Bellard would accept to let Godot community to relicense TCC as well ?)

[ghost]

I'm not sure TCC is as good as GCC or Clang as a compiler - their size amounts to support for a lot of architectures and for pretty optimized code generation (better performance).

What about Godot optionally depending on either GCC or Clang to compile C? They are installed on the machines of most people who would build the games anyway (so size is not really a concern), and it's the way other languages that compile to C (such as Chicken) do it. They also support C++, in case that is ever needed.

If they are made optional dependencies, those who don't have GCC or Clang installed (which is weird for a developer who's supposed to build a game for distribution, but anyway) can just use the GDScript interpreter as it is right now.

[phicore]

I suggested using TCC as a JIT for GDScripts. So the most important feature was compilation speed. And I think the results could already be much faster than the current solution.

[UnnoTed]

Most people want C / C++ for performance and Lua / Javascript for being easier and faster to write, so why not have the best of both worlds?

Nim - http://nim-lang.org/

Efficient like C, expressive like Python and flexible like Lisp

Pros:

• Compiles into C, C++, Obj-C or JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) like ( https://learnxinyminutes.com/docs/nim/ )
• GC or Manual ( http://nim-lang.org/docs/gc.html )
• Can be used somewhere else other than godot
• Cross-Platform ( windows, linux, osx, mobile )
• Helps converting C code into Nim
• Supports C libs
• Tweakable compiler
• MIT Licensed
• Open-source
• Type-safe

Cons:

• Requires a C/C++ compiler in dev's computer -> gcc, vcc, llvm_gcc, icc, clang or ucc (not really a con, in my opnion)
• Small community
• Not 1.0 yet

The Nim's TODO list is small, it is near 1.0: https://github.com/nim-lang/Nim/blob/devel/todo.txt

as paper-pauper said (about having a compiler in the dev's computer):

They are installed on the machines of most people who would build the games anyway https://github.com/godotengine/godot/issues/5081#issuecomment-227706106

https://hookrace.net/blog/what-is-special-about-nim/ https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

[Warlaan]

It's not my favorite solution, but if you must go down that road I strongly suggest you use Haxe (haxe.org) instead of Nim.

I can't comment on Haxe's license (the compiler itself is using "GPLv2+", the standard library is using MIT), but all other factors make it a superior choice imho. It is a tested platform (currently in version 3.2.1) as opposed to Nim being not even version 1.0 yet, but what to me is a lot more important the syntax is a lot closer to other well known languages. Reading the Nim examples it seems to me that the developers behind that language tried to find unusual and / or ugly solutions.

But as I mentioned it's not my favorite solution and here's why: Intermediate languages like Nim or Haxe have many "semantical dependencies". I don't mean dependencies on libraries or executables that need to be present, I mean that they relate to other languages. Now as I said before languages aren't tools anymore, they are cultures. And even if you only see them as tools they have different core domains they were built for. E.g. it totally makes sense that the command "echo" prints text to standard output when entered on standard input. It is only consequential to use the same command in a batch script. Following that logic it is understandable that PHP uses the same command. Using it in a general purpose language like Nim makes no sense, since basically all other general purpose languages have methods called something with "write" or "print" in the name. I have no idea why Nim would still use "echo" as the name for that command, but this is the kind of thing you can observe a lot with Haxe and that I would expect from Nim in the future if not already in the first release. For example the standard library of Haxe contains both a substr(int, int)-method and a substring(int, int)-method. One of the two returns the substring from the first to the second index, the other one returns the substring from the first index with the length of the second argument. The reason that both exist is that as the language can be used to replace languages of different kinds it has users that come from different platforms, and unless there's someone with a very strong hand deciding what goes into that open source library and what doesn't you'll easily end up with such a mixture of coding styles.

It's very important to pick the right tools for the right job. Languages like Haxe (or C# for that matter) try to give you one language that fits all, so more often than not you end up using "just one tool" that unfortunately happens to look like this.

[eye776]

I'd like to add my 2 cents after working with Godot for a while. What I'd like to see (and have also been looking at, with... limited success) is C++ as a first-class language in Godot. Writing the computation-heavy logic (collision solving, physics, transformations and AI) in C++ and scripting the nodes using GDScript (triggers, conditions, animations and sounds).

GDScript IS pretty easy to learn, placing Godot a bit closer to Gamemaker than Unity in that regard. But after writing 3 small games and toying around with a bunch of demos, I have to say that GDScript is lacking for anything beyond very basic games.

Code files just get too long and the code editor lacks a lot of useful features found in other IDEs such as : collapsing scopes, regions, jumping to the start/end of the current scope.

GDScript also lacks a lot of basic features of procedural languages such as: proper for loops, proper do...while loops (it support while loops), switch...case, ternary operator, enumerations. There is no class-scene relationship awareness so if it's not prebuilt it's an "external" class and has to be preloaded.

Also, given GDScript's nature there are no function references and no templating. It's nothing show-stopping but it is very annoying.