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.

[Ace-Dragon]

Eye776; GDscript is only unusable for more than simple games if you decide to ignore the other features (such as using nodes and callbacks where possible) instead of sticking exclusively to functions like _get_overlappingbodies()

The reason why is that said callbacks and use of nodes is far faster than trying to do everything with one large script and very few nodes. The tree gets larger, but it's a non-issue with Godot's scene instancing system.

For instance, objects that need a constant rate of rotation can just use an animation for that instead of setting the rotation manually using GDscript, stuff that relies on timing can use timer nodes and so on. I think one immediate (and straightforward) way to allow for faster games would be more node types to choose from (each with their own callbacks and connections).

[Zylann]

Code files just get too long

Do you mean scripts like this? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd Do you think C# can prevent this to happen? Personally I don't. Actually it makes it easier to refactor and detect errors earlier in these long scripts because of the tooling (yeah, when people mean C#, they often mean VS implicitely) and static typing, although node path errors would be undetectable until the game runs. But apart from that, good design and use of nodes can simplify scripts a lot.

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.

These can be added in the future if you ask for it, althought you can use an external editor without problem (https://atom.io/packages/lang-gdscript), Godot even has auto-completion services.

If you actually make a HUGE game, this is likely you'll want to extend Godot using C++. Actually, I find this a bit daunting currently because of the engine-rebuild process, but there are reasons for it.

There is no class-scene relationship awareness

What do you mean? You know you can put a script on the root of a scene, right? Also C# editors cannot guess what's in the scene where they are used, while GDScript can.

Also, given GDScript's nature there are no function references and no templating.

There is funcref and signal if you look for something similar to lambdas and events, and templating is not a thing because the language is dynamic. Dynamic languages often prefer to use duck typing instead of interfaces and generics. Also, composition over inheritance plays very well if you want re-usable things.

GDScript also lacks a lot of basic features of procedural languages

I agree a little bit. Some of them have been requested but I don't remember the issues, you'll have to search. For example I would like to see a for that can iterate on something else than integer ranges and containers (float?), so I use while. That's indeed a bit annoying but nothing too serious.

[ghost]

Do you mean scripts like this? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

I have to say that even if the file is long, I've seen much worse and it's still pretty readable despite the code being fairly procedural. Now I finally get why a simple syntax is better for GDScript: it's the best for average game logic, which is mostly ifs and function calls.

I would like to see anybody argue that the same file written in C# is easier to read or write, or offers any practical advantages other than performance (which is worse than C++'s anyway). I think C# would be an overkill for this kind of scripting, which is more complicated than the scripting that goes in some professional 2D games.

I agree a little bit. Some of them have been requested but I don't remember the issues, you'll have to search. For example I would like to see a for that can iterate on something else than integer ranges and containers (float?), so I use while. That's indeed a bit annoying but nothing too serious.

Could you go a bit more in depth on the for part and some examples of what you are referring to in pseudo-GDScript?

[Zylann]

@paper-pauper the things GDScript lack are not related to C#, but for example for i in range(-PI, PI) doesn't works in GDScript, as well as for i=0, i < size and stuff, ++i. I also would like to write ternary instead of having to write a three-lines-if. But as I said, there are issues in the tracker already for it and it's not going to stop me using GDScript :p

But even if you all your scripts are 200 lines max and relatively well designed, if you have thousands of them in your game, you'll have trouble maintaining and refactoring that code base: and this is not that much because of the language, but because of tools: A big part of C# popularity is because Visual Studio is a hell of a good IDE for it. I'm pretty sure if Godot integrates suited tools (goto definition, reliable class/function/member renaming, find all references etc), working on huge GDScript codebases will be made a lot easier. More generally speaking, this is what I'd like to see in Godot, how can it scale well for BIG games, because so far I didn't see any (including my own projects).

[akien-mga]

for i in range(-PI, PI)

That makes my head spin on its axis until it reaches a division by zero and starts destroying entropy. I hope no language implements such an unpredictable statement. What does it do? Iterate over integers between -PI and PI (i.e. -3, -2, ..., 2, 3), or between multiples of PI (i.e. -PI and 0), or does it iterate over floats wich some voodoo default step like 0.176 or ln(2) that some language programmer found most appropriate?

[Zylann]

@akien-mga oops sorry. I should have added a step argument indeed xD but it still doesn't works. Here is the issue I made for it https://github.com/godotengine/godot/issues/4164

[vnen]

I agree that what Godot misses is tooling. The major problem is the duck-typing nature of GDScript, which makes it harder to know what is what and thus makes it difficult to do some actions like "find references" or "go to definition".

It's planned to add type hints to GDScript, but since this will be optional, I'm not sure how much can be improved. It'll certainly do a great deal to code completion and may ease the work on better tooling.

[ghost]

@vnen An EMACS mode for GDScript in (M)ELPA would already be a step in the right direction, in my book :)

[eye776]

Oh yeah almost forgot about these two issues which, funny enough, actually slowed me down in practice:

• Arguments are not part of a function's signature. That means you can't override functions. In practice having a function doFoo(a,b,c,d) and function doFoo(a,b) in the same class will result in failure to compile. I ended up renaming them to doFoo4(a,b,c,d) and doFoo2(a,b) and refactoring a bunch of script files.
• Since there is no support for enumerations, all flags and return codes are, by necessity, ints so you have to guess them and many are still undocumented right now.

PS: Obviously the functions weren't literally named doFoo. ;)

EDIT: @Ace-Dragon: Other engines have taught me that complex Built-in nodes/components/etc. can and will change, breaking the game in the process. That's why other than basic trigger callbacks (collisions, values, timers) I prefer to avoid relying too much on them. I'm also not a very big fan of the signal-slot paradigm so I tend to avoid it if possible. Then again I also prefer threads to coroutines, call me a luddite :)

@Zylann: ~1200 LOC?... pffft No, I'm talking about the real deal... 20k+ LOC per file. An RPG developer that uses Unity, which shall remain unnamed (no i don't work for them), routinely has classes with 25k+ loc. Then again they make all their functions static and use C# as if it were C. :fearful:

Sorry for the off-topic.

[ghost]

@eye776 I can't think of any dynamic language which allows overriding (it can be faked with default arguments in some cases), but it would be a good idea to have it in GDScript.

And game-breaking changes to the engine can be easily detected and reverted in a libre program like Godot, so they should not be a worry.

[vnen]

@eye776 I also never seen dynamic languages with function overriding. GDScript has default parameters, so that can be used instead.

Also, who is the crazy one doing 20K+ LOC in a single file? The problem here lies not on the tool... In the whole Godot source there's not a single file I could find with 10K LOC.

What I agree is giving C++ a little more love. But for the uses you cited earlier I agree only with AI. And also procedural generation, to cite one more. Now if you are remaking the engine physics, rendering, etc. then I say you're not even using Godot anymore, you just did a fork. If you can't rely on the builtin types, what do you need the engine for?

Of course, GDScript is not perfect (no language is). It's also not carved in stone. Enumerations, switch/case and ternary operations are some likely additions in the future (there are already open issues about those). Just because it doesn't have something right now, it doesn't mean it'll never have.

Finally, "doubts" do not really help. What we need is benchmarks and use cases. There are quite complex games written in GDScript already, so I don't see what's really missing.

[Zylann]

@vnen just for fun: godot/drivers/gles2/rasterizer_gles2.cpp is 11K LOC :p (it's the largest I found, but it's a rare exception).

[eye776]

@vnen

If you can't rely on the builtin types, what do you need the engine for? Well, as a quality cross-platform context for starters. But that doesn't mean I'll write my own sprite or model classes.

Godot did burn me once back in March (v 2.0.1). I was messing about with a 3rd person camera & character and tried to use Godot's own physics for movement (drag and forces) and got it to work. The next minor version (v 2.0.2) update basically broke the character's speed (2-3x faster) for the exact same values. Figured out it was better to just keep it Kinematic and do my own "physics".

Also, unrelated to Godot, I got burned many times relying on automated stuff like XCode's storyboards. I kinda stopped being wooed by the shiny and praying whatever code gets autogenerated by the IDE behind my back doesn't mess with mine.

Anyway, I'm really, really sorry for derailing the thread.

[ghost]

@eye776 Did you check the commit diff from 2.0.1 to 2.0.2 to see what broke your game? It could have been a bug and reporting it could benefit the whole community.

[Marqin]

Mono or CoreCLR? And why?

Mono:

• MIT licensed
• stable
• possibility of being abandoned
• good documentation

CoreCLR:

• MIT licensed
• still not 1.0 ( curretnly it's RC2 )
• small
• poor documentation

[reduz]

We are using Mono because it deploys to mobile and web. I think here is zero chance of it being abandoned because it's much more portable. My hunch is that both codebases will eventually merge.

On Thu, Aug 4, 2016 at 1:45 PM, Hubert Jarosz notifications@github.com wrote:

Mono or CoreCLR? And why?

Mono:

• MIT licensed
• stable
• possibility of being abandoned
• good documentation

CoreCLR:

• MIT licensed
• still not 1.0 ( curretnly it's RC2 )
• small
• poor documentation

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/5081#issuecomment-237611905, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R .

[neikeq]

In addition of what @reduz mentioned above, the API is encapsulated so it is not too hard to change to CoreCLR later if needed.

CoreCLR: still not 1.0 ( curretnly it's RC2 )

It reached 1.0 stable on 14 Jun.

Mono: possibility of being abandoned

Based on what?

Mono: good documentation

ahahah

[Marqin]

Based on what?

Why Microsoft would develop three stacks of .NET? It's not good resource-wise. (.NET Framework, Mono, .NET Core)

ahahah

I've checked both docs about C++/C# interop (what we need for godot) and it's quite ok documented in Mono. In coreCLR I had to dig trough some of their code and ask devs for help to get my app working.

[neikeq]

The reference guide has too many functions undocumented, broken links...

[DavidKarlas]

In theory I'm bias here... But I hope my arguments are objective...

• I'm not seeing any decline in Mono development: https://github.com/mono/mono/graphs/contributors
• Development for Mono on Windows was never as strong as it is today(kinda proof(without linking tons of commits) https://github.com/mono/mono/pull/3231 Miguel saying "since we now have real maintainers") Making previous point even more clear
• Embedding API in Mono is battle tested(not just Unity there are many other private users)
• Mono TODAY runs on PS4, Android, Windows, iOS BITCODE(years of work went into this), AppleTV and many more platforms...

So imho, if you want to deliver this in near(less than 3 years) future and on most gaming platforms... Go with Mono.

[migueldeicaza]

Hello,

Some comments:

• In addition to the platforms listed by David Karlas we are also adding WebAssembly, XboxOne, UWP and Win64 native support.
• The sample that is being shared could be done also with either virtual methods (faster dispatch) or could be done with C# events.
• C# has historically been at the front of many language innovations, drawing good ideas from any place. It has popularized and brought to the mass market many ideas from language research and that we now take for granted, things like iterators, non-erased generics, lambdas, async-programming, properties, platform invocation, but is one of the languages that are most actively developed in public. For example, the upcoming version is adding a slew of new features, including my favorite pattern matching.
• In general, Unity does not showcase modern C# as they are using an older runtime. This will hopefully change soon. That said, current Mono supports all of the new C# features, among those "async" programming which is ideal for game code, as you can write it linearly, and the compiler automatically rewrites your code as a state machine - like coroutines or the advanced version of "yield" as used in Unity.
• Synchronization contexts means that you can write async code that executes within a specific context. For example, you might have game-bound execution, or IO-bound execution, or main vs background thread bound execution, it is all part of the system.
• While deploying, you have a choice of JIT compilation, or static compilation (AOT) with or without LLVM, so you pretty much get as fast as C++ can, modulo the fact that C# does arrays bounds checks (that said, if you use native buffers, you get your performance back, at the expense of safety)
• Over the past few years, given Mono's strong focus on mobile, Mono's GC has been tuned not for servers, but for interactive workloads. Our new GC is generational with small nurseries that can be collected very quickly and do not require scanning the whole heap.

As for why Microsoft is developing multiple CLRs (we have three: CoreCLR for JIT workloads; CoreRT family, for static compilation in UWP; Mono for mobile workloads) it is because they all server slightly different purposes. The internals are converging where possible, for example, Mono has now replaced about 60% of the core code with code that is shared directly with the rest of .NET. It is just a matter to find out which workload is better suited for you.

You can start with one VM today, and switch to another one in the future. Currently Mono has a larger API surface, works on mobile, has been optimized for interactive workloads and supports more architectures (like ARM64).

The good news is that swapping one VM for another, or supporting both is a couple of days worth of work, so you are not locking yourselves into one specific implementation.

[kubecz3k]

@migueldeicaza Welcome! Awesome that you decided to participate in our discussion and that you are interested in Godot :+1: Hope you will stay with us for a while :)

[Ziflin]

Thanks for the nice breakdown @migueldeicaza! I have two quick questions for you or other Mono developers.

1) What is the current setup for debugging embedded Mono on Windows with Visual Studio? Unity has their plugin, but I haven't been able to find anything but plugins that connect to Linux/OSX machines.

2) What is the recommended way to handle runtime-recompiling (compiling, unloading and reloading say an assembly for gameplay or tool plugins in the editor)? C# (very) unfortunately does not expose an Assembly.Unload() method and dealing with AppDomains and cross AppDomain issues seems to be overly annoying for this situation.

[Marqin]

For reference, not only Unity uses Mono - https://github.com/xamarin/urho (C#/Mono bindings for Urho3D engine) - that one is on MIT license, so we can easly lookup their solution.

[Zoodinger]

My two cents:

C# is far superior for game programming than other similar-level languages in that it supports custom value types. This is an extremely important feature for performance, which Java (and JVM in general) literally has no alternative to it.

You get:

• Stack-allocated math types, which support mathematical operations and temporary objects without any heap allocations.
• Optimized, cache-friendly continuous collections.
• Generics using value types (including primitive types)

On top of that, C# has other features that make your life easier. I see no merit of using Java in place of C# when C# simply beats Java at pretty much everything that matters in game programming.

[CharlesWoodhill]

Hi all, i havent read all of above (simply too much :) ) but i had some hollydays so i made a prototype module for godot that acts as msDotNetHost, so i may provide some findings ive gone through, maybe they helpful. sorrowly my hollydays ended and ive to code for money again :), but it is/was fun :)

current state is: o) the module extends the Node Class to expose the node events to netCode (init, tree_entered, ready, process, fixedprocess....)), o) "net host/wrapper module" done (using Microsoft dotNet host mecanism) its encapsulated in a dynamic library, so a switch to Mono should be easy later on o) dotNet methods are bound and called (init, tree_entered, ready, process, fixedprocess....) o) node class is wrapped and bound to netAssembly (manual written code for prototyping) o) calls to godot (from netCode) are working through a self written binding mechanism (from dll into godot-exe ) so the exe dont need to export functions. o) due to the use of msDotNet its bound to windows for the near future..

my roadmap for including .Net would be:

1. module for Godot using microsoft .Net hosting mechanism (done)
2. wrappin godotClasses (my current state: writing a wrapper generator, that parses godot c++ code, parsing is done, generation ongoing)
3. get the project out of prototype state (complete the edges, test it...)
4. write the Mono hosting mechanism, to get rid of windows bonds
5. somehow enable Visual Studio to debug mono, to get rid of xamarin/monodev ( like unity vs-plugin )
6. have fun hundreds of new godot .net developers :)

some questions:

1. i wonder if i coud reuse the binding mechanism used for gdscript. but id dont have time to evaluate all of it, is ther some good tut or some highlvl hints out there for me?

2. currently i generate a wrapper that wraps all godot-methods into functions so they can be called via dll-boundary and c++/netCode boundary easily. (self written binding mechanism for netCode) i dont want to change godot code (exept my module code) to stay compatible. also static, nonstatic, virtual nonvirtual made me cry, thats why i chose this way. any better solution to this?

some additional thoughts:

Microsoft .Net vs Mono:

i think it doesnt matter if u use mono or msDotNet, because in most cases dotNet code runs unchanged on both. The only effort to support both is writing a "host" for each of em (its the smallest part of a "GodotDotNet"). I chose msDotNet for prototyping. well, mono supports many plattforms msDotNet only windows, so why support/use msDotNet? The answer: productivity, debugging

msDotNet: Especially when writing/prototyping the DotNetModule i need/want FAST compiling and debugthrough, means ur debugger should jump into netCode from c++ and vice versa. i choose VisualStudio, because it can debug both. BUT only if u use msDotNet. Doing so u change a piece of netCode, hit run and in 1sek! its compiled and running!!! including the possibility to debug into godot. (if u dont have changed something in godot, then u have to wait the usually 30sek to 1min...damn u slow scons! :) )

Mono: Mono must be the final target there is no discussion about that (plattform independence), but: if one uses mono, u have a big problem when i comes to debugging: mono has its own debugging mechanism! for me its a big hit to productivty, because unless u write a monodebug-plugin for visualstudio (unity did this) u cannot debug mono hosted netcode in visual studio and debug into c++ code (there are hack solutions but ...). I tried so set up a Mono based solution, but i ended in using both in parallel, VisualStudio (for c++) and xamarin/monodev (netcode).

Conclusion: prototype state: msDotNet lateron: mono, for users not intrested in to debug into godot/c++ and platform independence after that: create a vs-plugin to debug mono

c# vs java: the answer is clear c#! java is for scritpkids! (oh what do c++ coder think about c# devs :) ) no this was a joke :) i dont understand the discussion... when the .net system is implemented u can use every language that supports dotNet including both languages plus more. this is not the case if java system is supported...

@Ziflin: question 1: did that search too... only monoRemotedebugger is the (not) solution atm :( my recommendation is, as stated above: use microsofts dotNet hosting for prototyping then at some later point switch to mono. alternative: start xamarin in its hacked mode, let it listen to localhost, set the breakpoints, then start ur project in vs. ive tested it, it works, but... for me its no solution! i want a "hit run and debug in 1 second"- mecanism and this with 1 click! i dont have much time in my spare time, so productivity is my main target.

question2: dont know mono that well yet, but i think u have to to that in c++, implement mono hosting, manage it from "outside" in c++.

[Marqin]

@CharlesWoodhill official C#-bindings are already WIP and can be seen here https://github.com/neikeq/GodotSharp/

[CharlesWoodhill]

cool tnx, then i know how i spend some of my next hollydays ;)

[RameshRavone]

Hi, I just came upon godotSharp but this its droped.

[Marqin]

this its droped.

Official version I've heard on IRC was something like:

@neikeq doesn't like to push unfinished code, so he works on his local branch

[RameshRavone]

Well that good to know, I was about to do my own module but guess I might as well for Godot 2.2 or 3.0

[Marqin]

There will be no 2.2 release, Godot devs moved all 2.2 features to 3.0.

[ghost]

This is my first time commenting. I came over from Unity and the move to GDscript has been a dream. I picked up the language in less than a day. I love how well the language is implemented into the engine and my productivity has jumped considerably.

My main concern is that with added C# support GDscript will be left behind or see less development after a flood of Unity developers. C# is a fine language but not my personal favorite

Also I'm concerned to see Godot trying to be more like another engine instead of standing on its own. Unity is a fabulous success story but not the best engine I've ever used. It's bloated and buggy. Once it deleted my entire project without confirmation. Dealing with bugs and things not working like they should was a constant struggle. I can't count how many times I had to completely rebuild a scene I was working on because things weren't working right. I once copied and pasted all the content from an old buggy scene into a new scene to have it suddenly work despite both scenes being identical. I lost weeks hunting physics bugs that would magically appear and magically disappear.

I really like that Godot is lean and simple to understand. Working with Godot has been like using a well tuned musical instrument. After almost a year of working in it I just know how to do anything I need to do, even if I haven't done it before. I just hope the influx of Unity users won't steer the direction of the engine more towards Unity. If I wanted Unity then I'd be using Unity.

[neikeq]

@zaywolfe Your concern have been expressed a few times by other users. You have nothing to worry about. GDScript will continue to be the main language in Godot.

[fivemoreminix]

I don't like GDScript. I understand that was modeled after Python, but I feel very puny. C++ or Java included (out of the box) would be a great idea in my opinion. I personally feel disgusted using GDScript in development, to the point of questioning whether to leave Godot and come back again when a new (or alternative) language had been implemented. Sorry, but if you'd like the hard facts from a programmer, you got them.

Also, I'd like to mention that sometimes I even use Godot for some simple software prototyping. Thus, a deeply-integrated programming language would possibly open up doors for software devolopment within the engine. That would truly be a Unity killer. (If, of course, Java or C++ was chosen)

Thanks loyal developers for your hard work, I look up to you all, and I look forward to the future updated releases!

[Marqin]

@VenHayz I don't know if you read Godot documentation, but you can already write your games in C++, since the first version of Godot - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

[nictaylr]

what about using the microsoft .net core? it is cross platform and performance focused, as well as also it is open source and is develop actively

[RebelliousX]

@RUSshy goodbye then, it is your loss, godot is awesome, GDScript is great, if you are a real programmer, it will take you literally two hours to know more than enough to start any project. Real programmers must master many languages, you can stick to your java/C# and be a "random" guy passing by as a hobbyist for ever. I am not trying to be rude, just stating facts. If you don't like something about this engine, then contribute with some code, it is free unlike most other engines.

[hubbyist]

God of Marketing favors C#. :laughing:

[Warlaan]

@RUSshy Are you kidding me? I (and several others) wrote literally pages of explanations about the benefits of GDscript over C# and you think you could solve the discussion with one short paragraph without reading anything that was said before?

"Don't be close minded" - great idea, how about you start by being open minded about GDscript? "your new knowledge won't be applicable elsewhere" - that's simply false. You won't be able to compensate for a lack of knowledge by copy-pasting code you didn't understand. "you won't be able to find tons of libraries" - learn the difference between a scripting language and a backend language. Or - crazy idea - read what I wrote about it.

Seriously, the audacity of some people...

[Zylann]

It has been said several times in various places that a C# integration module is in the works. It goes as fast as the amount of time people have to do it. The only way to make it faster is to contribute to that integration :)

@Warlaan about the second point: if you wrote loads of code in C# before, you can't reuse it unless you port all of it. You also don't need to understand the code of a library to be able to use it. The point is, if you need something that was in C# before (a single file or a set of libraries, potentially closed source), you need to either port all of it, embed a C# runtime or find a C implementation. That's not impossible, but time-consuming. That doesn't mean Godot can't use loads of existing libs though... C/C++ has tons of them too.

[neikeq]

This risks to become a flame war. The log is so long that people will repeat the same questions or topic instead of reading it. There is not much technical stuff remaining to discuss either.

The future of Godot in terms of scripting is pretty clear already:

• GDScript will stay as the main language and there are plans or ideas to optimize it (but this is not the right place to discuss that).
• From 3.0, C# will be supported as a scripting alternative. We will provide separate binaries to avoid forcing the extra size caused by the mono runtime on people that won't use it.
• DLScript is also on the work. It will allow people to use shared libraries for scripting. These libraries can be written in any language that supports c linkage and shared libraries (expect languages like Rust and D). It's not clear yet if it will be ready for 3.0 though (unless I'm outdated).
• Don't forget there will be Visual Scripting in 3.0 too!

If someone plans to contribute something else, this won't be the right place to discuss that either.

I think this issue can and should be closed.

[akien-mga]

Agreed.

[nictaylr]

Could please provide link to C# integration source codes?

[akien-mga]

https://github.com/neikeq/GodotSharp

[nictaylr]

How functional GodotSharp Integration? Is ready to use for testing? Can be used with source build from godot master?

[karroffel]

@nictaylr It's not building with master currently. If you want to test it you need to use 2.2-legacy. It's working with that version very well

[neikeq]

I'm working to have it ready for a 3.0 alpha on April.

[fivemoreminix]

Random idea, but after thinking deeply into C++ with Godot, I thought of something possibly better. The D language. It falls under an arguably "low-level" language quota, with interfacing to C and (some) C++ support. It has classes, and is very modern. While it sounds scary, it looks much like GDScript, and I could see it being used to power very big projects. It's powerful enough to compete with C and C++ (gcc/g++) with a compiler called GDC. (DMC can also be used to compile, but GDC compiles directly to gcc) see more about GDC here

Anyways, just a quick suggestion or maybe for ideas.

[karroffel]

@VenHayz I'm working on a module that enables the use of shared libraries for scripts. I already put in some effort to make C++ easier to use with it. You can use D to create those libraries as well. If you're interested in making D bindings hit me up on IRC or Discord.