Godot: C# as scripting language

Adding more features to GDscript would be better way to approach scripting in my opinion

For me, main reason to choose Godot over other game engines is simplified scripting scheme. Godot is not offering to learn a new programing language. It is offering to learn Godot and its scripting language as a combined tool for game development. This is a less intimidating approach than offering new comers to learn C++ or any other programing language for scripting.

Thanks for opening this issue, I think this is a topic where there's a big difference between the rationally best choice and what the majority will ask for.

The most important reason why more than one engine exists is because besides one-dimensional factors like performance in general purpose tasks or accessibility of the interfaces there are multi-dimensional factors like performance for specific situations (there is no obvious winner if you compare an engine optimized for 3d games and one optimized for 2d games) or usability for specific groups of users (an interface that is beginner friendly usually has to hide advanced functions).
So in order to find a place among other engines an engine has to pick a "philosophy".

Now a scripting language is an integral part of an engine, so the philosophy of the language should fit the philosophy of the engine, or at least it shouldn't contradict it.

So what is Godot's philosophy? Let's look at some facts:

• Compared to Godot every other major engine is bloated.
  Godot's download is smaller than 20MB, the whole "installation" is one executable that's less than 50MB in size. Lumberyard on the other hand has an initial download size of about 5.5GB, currently my installation folder of it is 15.3GB large. The main reason for that is Amazon's philosophy regarding dependencies. That initial download contains 10.5GB of built images of 42 dependencies, and if you have worked with Amazon web services before you know that the AWS SDK is not that different in that aspect, so it's not a matter of necessity or ability, it's a matter of choice. For example while Lumberyard includes boost and Lua, Godot contains its own versions of the most imporant STL containers and uses GDScript rather than lua, which keeps the size down, removes dependencies and makes the code a lot more readable and accessible.
• Godot's source code is very accessible.
  That starts with the choice of the build system (SCons) which uses python as a build language. Most other projects use existing build systems with proprietary build languages or write their own proprietary build system, both of which has a negative impact on the readability of the build code.
  The source code itself is also above average in that aspect. It took me about the same time to find out how to write a single Unreal Blueprint node in C++ as it took me to write the code for my first pull request to Godot. That's not to say that Unreal's C++ code was unreadable, it's simply not as clean as Godot's as it uses more macros and requires the user to understand more of Unreal's default project code than Godot.
• Godot promotes KISS and OO principles.
  In order to illustrate that let's look at some simple objects in Unity. The first concept you are confronted with in Unity is that of GameObjects with attached components. "composition over inheritance" as it is often called (I prefer Michael J. Dickheiser's formulation "Containment versus Inheritance" from "C++ for Game Developers" which doesn't sound like a war cry and promotes reflecting on the topic) is a successful pattern due to the flexibility it offers. That flexibility comes at a cost though. If everything in your game is a GameObject you can't really get a reference to "the player", because there is no player, there's just a GameObject that may or may not have a player component attached (or rather those several components that make up the player).
  The Unity developers saw the same issue, sometimes you just want to create a Button, not a GameObject with Button component. So what they did is this: they allowed you to create "a Button" through the editor interface which does actually create a GameObject with a Button component attached. In addition to that they routed the most important members of GameObject through every Component, so that now you can use a reference to a Button just like you would use a reference to a GameObject. You can ask a Button for its position, you can ask it for a list of its components - even though the Button is actually a component, not the object it is attached to.
  So now we have a mixture of the two most popular ways to describe a game world - composition based and in plain objects. But when you look at beginners' projects (and even some advanced projects) you will find that Unity also facilitates the third way to interpret a game world: procedural programming.
  In Unity every object is always part of a "scene". Unlike in Godot that term describes a top level part of the game (disclaimer: now Unity has a SceneManager that sits on top of scenes, but my point is still valid), meaning that if an enemy wants to shoot at the player it can just search it's current scene for the player and interact with it. That's the core idea of procedural programming - you have a sequence of commands that alter the state of the environment without regard for ownership. Of course technically it's still object oriented programming, but as every object can expect to be part of the same scene you are enabled to write code that behaves like global code. For example if you want to instantiate an object all you have to do is call "Instantiate(templateObject)" and a copy of the templateObject will be instantiated and added to the scene. There's no need to ask which scene to add the object to because there's always the one scene that everything is currently part of.
  So Unity promotes a mixture of composition, object oriented thinking and procedural programming.

Godot on the other hand promotes object oriented thinking as for example every single object in your game can be built as a scene of its own. Those scenes can be started by themselves, allowing you to test them, alter them by themselves etc. That in turn requires you to build those scenes in a way that does not require accessing the environment. For example if an enemy wants to interact with the player it's much more feasible to use signals to tell the underlying scene that an interaction is requested or to simply require the scene to give the enemy a reference to the player. You still can search the game scene for the player, but if you do that the enemy scene will not be able to run on its own, so that design simply doesn't fit the tools as well.

So how does this make a difference regarding the choice of scripting languages?
C# is to languages what Unity is to engines. C#'s philosophy has always been that if some feature would be nice to have it's added into the language. Just look at the list of features that were added with each version: https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Features_added_in_versions
Now you may argue that having a feature isn't something bad, right? You don't have to use it, just leave it if you don't like it. Unfortunately that's not true for a language. With the importance of the internet today languages aren't tools anymore, they are cultures. Sooner or later you will have to google for help, you will use modules or objects built by others, you will use new features built by the community into the engine, and sooner or later that will require you to use language features that you never intended to use.
Also if you are working in a team you will learn to appreciate using a language that promotes a common coding style and doesn't offer you dozens of ways to write the same code.

Now you may wonder if I mean to say that a language with less features is always better than one with more features. Of course that's not the case. Let's compare how Java solved the problem.
C# allows you to write unmanaged code. Just use the appropriate keyword and you can use it right in the same file. It also allows you to write functional code using LINQ, which reads like SQL code and behaves like functional code. In order to completely understand what one file does you may need to know quite a lot about programming paradigms.
If you are writing Java you can use functional programming as well, you just have to write it to a separate file, use a different compiler and call it "programming Clojure". If you prefer to combine object-oriented and funcitonal programming you can call it "programming Scala". The important part is that you are still writing code for the JVM that can easily interact with code from other JVM languages.
The .NET-languages have the same capability, it's just not used in the C#-philosophy. They could just as well have decided to stick to one or two programming paradigms in C# and create a new language to add new paradigms, but instead they went with "one language to conquer them all" - which is totally fine, it's great to have a language like that. You should just be aware of that philosophy and the choices you have as a programmer.

Long story short: of all the languages we have I think C# is just the worst fit for Godot. It's a natural fit for Unity, but if you have all those options then why choose a language that promotes mixing-and-matching of paradigms in an engine that promotes clean OO-principles and KISS-programming in every other one of its parts?

So if you think that C# would be a nice addition to Godot then I am NOT disagreeing with you - I am merely saying that alternatives exist that are even better, that should be evaluated first and that would be immediately forgotten once C# is implemented.

@hubbyist

Adding more features to GDscript would be better way to approach scripting in my opinion

That can happen for sure, I don't think it's incompatible with the other proposals.

For me, main reason to choose Godot over other game engines is simplified scripting scheme. Godot is not offering to learn a new programing language. It is offering to learn Godot and its scripting language as a combined tool for game development. This is a less intimidating approach than offering new comers to learn C++ or any other programing language for scripting.

But Godot can already be used from C++, so nothing would really change (provided GDScript is kept) except coding in C++ would be made easier for those who want to do so (currently writing modules requires compiling all of Godot, and it is not integrated into the workflow).

@Warlaan nice analysis. If you read my post, I too disagreed with C# being a good pick for Godot, that's why I proposed expanding the already existing C++ capabilities to make it possible to use it as a scripting language, with GDScript remaining the default language for most users.

Users should be able to write pretty much in GDScript, however it's unreasonable to think that a large game would be written in GDScript. In my opinion, there's nothing that prevents Godot from being suitable for large games except GDScript performance, because the engine is very well designed and has already pretty good performance (and Vulkan will probably make it even better).

In my opinion, performance does not appeal to most Godot users, but it could bring more professionals to Godot, which means more contributions which means a better Godot for everybody.

@paper-pauper I understood that we are on the same side. When I wrote "if you think that C# would be a nice addition" I was adressing "you, the anonymous reader", not you personally. ;-)
And yes, any new scripting language will drain attention from GDScript. I doubt that the community will take care of more than one language, sooner or later some features will be unavailable or broken from either of them maybe even up to the point that one of the languages is dropped.

I also agree that the only real issues here are C++'s compile times and GDScript's performance.
The argument that people already knew C# is just plain wrong imho. I have been working professionally with C# for about 4 years now (mainly working with C++ and SQL) and the one thing that I have learned in that time is that I will most likely never be able to say that I really know that language. After all with C# 6 and the propositions for 7 the number of features is still growing.
So when we are talking about "knowing C#" all we can actually be referring to is knowing the most basic syntax which even the worst beginner should be able to re-learn in a few days. I recently held a lecture on different game engines to a class of game designers that were exclusively using Unity before and none of them commented badly on the syntax of GDScript while in fact several who had given up on programming are now motivated again.

So yeah, a solution that speeds up GDScript and makes C++ less cumbersome to compile and use would be my favorite as well.

A lot of people who "know" C# don't use many of its features which make it different from Java. Just take a look at the myriad of Unity scripts which don't go much far than subclasses.

For this reason alone, I'm highly skeptical about the practical advantages C# would give. They are nice in many contexts, just not game development. Besides, C++1x already offers many of those things (including type inference, iterators and some basic functional tools) without any overhead.

Also, it's possible that the overhead brought by the CLR (or even the JVM) could make Godot perform _worse_, although I see some advantages in using the JVM's garbage collector (does anybody know more about Godot's memory management)?

I read on forums about people who don't use Godot because of GDScript. I think that's close-minded, because there is nothing wrong about it except the fact that it has a poor selection of libraries, which I tried to address in another ticket, #3943, by suggesting a solution which has zero overhead and cross-platform support.

Without having to implement a C++ JIT via LLVM, there is a solution which runs on native code and does not require any fiddling with Godot's sources: dynamic linking.

The first would allow native code without having to recompile Godot from scratch: you just compile it as a .so file and then add it to your load path, then use it from GDScript with no overhead (since it's all function calls).

This should be very easy to do (via libdl?) but as far as I understood it's not done because of cross-platform concerns.

Also, there's the idea of compiling GDScript to C++, much like ENIGMA does with its language. This is not easy, but obviously offers best performance.

does anybody know more about Godot's memory management?

From the docs:

If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, just simple reference counting. By default, all classes that don’t define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can’t be freed, a weakref function is provided for creating weak references.

Just to note...

A major advantage of GDscript is that it's a language that is completely under the control of Reduz and the other developers, how it works for Godot developers is not dependent on an external team and as such it can be developed in a way that's specific to the engine's design and have what users are requesting.

Another thing is that while GDscript isn't a real high performance language right now, there are likely a lot of areas where performance can be greatly improved while preserving its simplicity and dynamic typing nature.

Then there's the fact that GDscript does not require any compiling knowledge whatsoever and that you don't need anything outside of Godot's built-in editor (which makes the workflow nice and tidy, not to mention easy and fast).

Just a question, how does GDscript interpreter work internally? Parse each line at runtime like old Basic language or does it convert the whole script into a bytecode tables then run the bytecode?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

I don't think there are any serious languages that work like BASIC anymore! :)

Hi!
Here is the history of GDScript:
//////////////////////////
History
Initially, Godot was designed to support multiple scripting languages (this ability still exists today). However, only GDScript is in use right now. There is a little history behind this.

In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.

The last third party scripting language that was used for shipped games was Squirrel, but it was also dropped too. At that point, it became evident that Godot would work more optimally by using a built-in scripting language, as the following barriers were met:

• Godot embeds scripts in nodes, most languages are not designed with this in mind.
• Godot uses several built-in data types for 2D and 3D math, script languages do not provide this, and binding them is inefficient.
• Godot uses threads heavily for lifting and initializing data from the net or disk, script interpreters for common languages are not friendly to this.
• Godot already has a memory management model for resources, most script languages provide their own, which resulted in duplicate effort and bugs.
• Binding code is always messy and results in several failure points, unexpected bugs and general unmaintainability.

Finally, GDScript was written as a custom solution. The language and interpreter for it ended up being smaller than the binding code itself for Lua and Squirrel, and equally as functional. With time, having a built-in language has proven to be a huge advantage
////////////////////////

In my opinion, c++ can be best. There is some solutions like:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Even Angel script typically can be like a runtime compiled.
In scripting, I love python because I always love solutions that mix game and scientific simulations (python has many scientific libraries). So I complain! in another issue why godot has it's own physics library: https://github.com/godotengine/godot/issues/4217
There is some issues about languages like C#: https://github.com/godotengine/godot/issues/2790

Nice find, @alabd14313 - that would solve pretty much most issues, while leaving GDScript alone.

About RCCPP, it is a very good idea. I think that if Godot supported it in editor mode and then disabled it in builds, there would be maximum performance and iteration times would be pretty fast. I've heard other engines like Unreal Engine do something similar with C++, and I think it would be pretty neat if Godot allowed seamless scripting-like C++ coding.

It seems the authors know their stuff, because in this page they listed most alternatives to their approach (including the one I mentioned, the LLVM JIT).

I think this approach makes the most sense, because Godot is written in C++ (and I don't think that's ever going to change, considering that C++ will be even better in a few years), it already has a working C++ API and C++ has pretty much the maximum desirable performance with zero overhead and there would be no additional runtimes or memory managers. I hope the devs will take a look at it.

I am a bit surprised to find that this thread which afaik was started as a reaction to the proposal to add C# as a scripting language doesn't yet contain a single argument FOR C#, even after six people have expressed their opinion.
Maybe the decision to add C# isn't as premeditated as I assumed from the rumors I heard.

@Warlaan what will happen if post this URL to facebook group? :)

Please change title to something like "C++ as scripting language".
C++17 have more features:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
I admire godot developers and thanks them for their works. but I resist on Box2D/LiquidFun/Bullet libraries. In this way developers can focus on pipeline, not on components like physics. With C++ they can focus on performance, not maintaining and updating gdscript. Theoretically RCCPP can implement some new features like tool mode in a better way. May be...

@reduz mentioned some months ago that he want to implement visual scripting, something like unreal blueprints. With RCCPP the workflow between C++ (for programmers) and Visualscripting (for level designers and artists) can be implemented like:
Introduction to C++ Programming in UE4
C++ and Blueprints
So in a group, programmers can develop new blueprint classes for artists and artists use these instead of directly coding.

@Warlaan IMHO it's because a lot of the C# talk was fuelled by people who want Godot to be a Unity ripoff, but fortunately many here realize that Godot is its own thing and already ahead of Unity in many regards and it wouldn't be fair to let it become affected by the same issues.

@alabd14313 I would change the title but perhaps it's better to create a separate issue and keep this for the sake of posterity so that it can be linked when someone proposes C# (as is often the case).

I am hesitant on the visual scripting, to be honest, but if it can be implemented as a module then why not? Of course, I think having visual scripting (designers and newbies), GDScript (people who can program or are willing to learn) and C++ (programmers) would make Godot a pretty balanced program suitable for all levels of skill, but making C++ coding less cumbersome and allowing easier interfacing with third-party libraries should have a higher priority, IMHO, because it can bring in a lot of professional users (and consequently, contributors).

Imho visual scripting is nowhere near refined enough to make sense. It's great for marketing and talking beginners into programming, but from my experience the learning phase during which beginners prefer flowgraphs is very short.
For anything but the most basic sequences of calls the systems I know (Unreal, Cryengine, Fungus, Stingray) are simply not helpful. I mean this screenshot for example is from the official advertising video of the Stingray engine. Now that's what I call spaghetti code. And the official examples in the Cry engine don't look any better, even though you can tell by the amount of comment elements that a lot of effort went into making the graph readable, or rather trying to.
If you think that's not so bad let me remind you that if you saw that code in a text based language every connecting line that starts offscreen would be a variable with a (hopefully) meaningful name.

Flow graphs are somewhat helpful when it comes to shaders / materials, since intermediate results can be displayed, but even there the system suffers greatly from the fact that a short equation like
float x = (a-b)*(a+b)/(1-(a+b))
easily fills a whole screen when it's done as a graph, since every multiplication, sum or difference is a node with two inputs and an output. That's at least 10 nodes for the formula above, and if you don't want to cause a chaos of connections you'll have to duplicate the a- and b-nodes.

The flow graph systems we have today (at least the ones I know) take away the option to give values meaningful names, because instead of putting a result into an intermediate named variable you simply connect it to the next node. That makes self-documenting code almost impossible and requires you to put a lot more effort into documentation.
What those systems add is the option to place nodes wherever you want, which in my experience results in less readable code more often than not rather than one that is easier to read.

And please don't talk about flow graphs as if they weren't coding. They are just as much coding as any other programming language. They aren't typing, that's all.

Visual scripting is for designers and artists to make changes without having to learn how to code. Some artists also are able to make simple interactive games with it. It has it's target where it's definitely usefu, it's just not for programmers.

@Warlaan Well, it depends on how you define "programming". Certainly visual scripting is akin to defining algorithms, so it's not far from programming, but programming is also about other things.

There are some good implementations of visual programming, though. PureData is one and also there's GDevelop, a pretty good FLOSS game making program (a shame it isn't more popular). In short, even although I don't personally like it (for some of the reasons you mentioned), it's also true that we both can program, so to us visual programming is a slow and cumbersome to achieve comparably poor results.

Still, I agree with @reduz that some people see an appeal in it. They are not the people who would be hanging around threads like these, but they make games too. I think they could bring something to Godot.

The reason why flowgraphs work well for shader editing is that it's very visual (you have nodes that allow you to load images, select colors, ect... without typing out the filepaths and values manually). You also have absolutely no fear of making sure the syntax is correct and that functions are spelled correctly. There is also no need to figure out such complex tasks such as how to work with a matrix (it's all calculated for you).

Godot's methodology for shader editing winds up being a good approach because it cleanly separates the vertex, fragment, and light components and also gives clear guidance as to what type of data you're working with (whether it's normal information or camera information).

Now with the visual scripting, I do think it could be useful even for moderately complex things if the nodes are at a high-enough level in terms of game mechanics (they do more complex things and have several inputs) and if there are nodes that allow you to run a script or create an expression/equation (which in turn can be used to manipulate values in complex ways). The problems I've seen with other visual node systems of this type is that they try to be as close to literal programming as possible (ie. having a bunch of low-level functions as nodes as opposed to being more like a nodal version of Blender's logic bricks or GameMaker's drag & drop).

Sure, it still won't allow something as fine-grained and as advanced as what you can do with pure scripting, but it would still have a use for things such a simple object types within a game (that do not need very complex logic) or if you need to just quickly bang something out.

I agree that some people see an appeal in it, and I also agree that it's not for programmers (it's just our definitions of "programmer" that differ ;-) ), so I suggest we leave the discussion at that since it's somewhat offtopic.

Another useful feature of C++ is it's statically type. "auto" and "decltype" facilities can detect the type of an object. Editor and code completion can be easier. Instead of focusing on internal code editor, we can use another external IDE. For now I think codelite and qtcreator have a better status in code completion. Codeblocks have some troubles with c++11 kewords. Also eclipse-cdt have a good code completion. A plugin for qtcreator is a good idea (like unreal-visual studio and Unity-Monodevelop). External IDE can identified with a system path in godot settings (like /use/bin/qtcreator), no need to be compiled and packed with godot (Unlike Unity package has builtin monodevelop).
There are another tools like cppcheck and valgrind that have plugins in qtcreator.
If you want to have a preview of what is RCCPP:
demo

I would love to see a C++ based scripting language for Godot, but implementing all C++ features would be cumbersome such as template programming. There must be some limitations to this kind of script language (STL) and templates shouldn't be use. Also RTTI could cause performance issues.

I love GDscript, my only complaint about it is the pollution of variables namespace, when dealing with large scripts, variable definitions before ready() can become very messy, and prone to bugs in code due to sharing variables between functions of the same script file.

My 3 cents. (uh... it ended up 20, but let it be...)

Like @alabd14313 mentioned earlier "it is at the point where it is" because of evolution over years which leaded godot into form it is today.
No matter if nature do this or we humans, correcting things at the time of creation apears to be the best way of developing, and i must admit, thanks to this, i enjoy Godot very much as it is and where evelution brought it.

It have all the needed pieces.

Nodes which can be combined into more complex object, saved as scene, then reused again as a "simple" object in another scene which is awesome and mega flexible feature, really, limited only by user own imagination and creativity borders.

Simple to use and learn GDScript, powerful enought to control all the nodes in the way we coders are just used to do - by typing lines of code.
In addition doing it in a fast and easy way (code completion / buildin documentation / useful tooltips here and there) without need of compiling, just type, try out, adjust, and again, polishing it to perfection.

Deploying to multiple platforms with REALLY one click (not mention these deploying to android over wifi/adb, life editing, debugging, ect is just a masterpiece of art, no... Its more, its a magic!)

Additionally all these familiarities with commonly used tools like blender ect.
(import stuff and it works out of the box, everything is where and how it should be)

And finally, I admit that sometime even ultra creativity might be not enought when it comes to do something milion times in a loop and fits in 1 frame. Thats where C stuff comes in. If you know C, need it, nothing stops you from creating plugin, own custom node ect, which do exacly what desired.

It have almost everything, and in time, i believe will have it all.
(Meant, the things that today are "not implemented yet" and one have to do it 'somehow' or 'bare hands' (read: use external tool for it) eg. adjust 3D rigged something in a easy way (gota use blender)

Godot is amazing and a magic thing, perfectly perfect on its road where it go.
Needs adjustements and adding stuff here and there but thats it. - its in constant development.

Visual scripting ?
uh. It could force us coders to change way of thinking "a little" in a unusual way, plus i dont believe it can be as flexible and readable as normal code.
Imagine you coding and have simple one line like this ( abc / def ) * ghi
then the fast way, as usual (?) to save typing, you mark part of something, paste here, cut there, paste again and in 5 seconds and fiew keypresses, end up with "simple" (because you know what it do) one liner like ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
Its common, perhaps many of us do it this way in a super fast way.
Now imagine doing it Visual way...
It could take whole screen, a lot of mouse work, and it wouldnt look that readable as should.
(ofcourse, such one liners also not looks easy after a year but thats what comments are for)

What if someone have 100 such lines one under another ?
Visualy he could get a football pitch to display it. What about analysing it, changing, thats a mess and a big headache.
Ofcourse coders can do this because, its not a language used, make someone a coder, but specific way of thinking, creating algorithms, manipulating data as a small parts and as a whole.
The language no matter if its C, Python, PHP, Java or Visual scripting is only a tool to write down the thoughts.
And here, Imho, normal typing with keyboard is most fastest and readable form to write it down.
On the other side If someone cant code, do you expect him to suddenly reveal algorythmic genius and perceptivity to not get lost within own idea and Visual representation of it, considering that when we think game - we talk about something more complex than two balls bashing each other with physics.

So for whom really Visual Scripting would be ?
To make coders life harder or to limit godot to level - engine for "simple games" for beginers ?

People, there's a long discussion about Visual Scripting in #1220. Let's please not discuss the same topics again in here.

People, there's a long discussion about Visual Scripting in #1220. Let's please not discuss the same topics again in here.

Most of posts here were so long, perhaps made me lost myself while reading.
Sorry :relaxed:

@RebelliousX Even with RTTI, C++ would still have much better performance than GDScript. Although it's true that templates could be a problem.

The solution proposed by @reduz in #3936 would already make coding in C++ fairly trivial - you just do it with your editor and compiler of choice and link against Godot's API. If this is implemented, even if scripting in C++ would be nice, it wouldn't be much different than writing code in C++ and then calling it from GDScript, in terms of performance. In short, I think focusing on #3936 (which is a simple solution) would greatly improve:

• Performance (since writing parts in C++ would be extremely easy)
• Availability of third party libraries (since wrappers can be distributed more easily, but not as easily as #3943)
• Userbase and contributors (many C++ programmers would adopt Godot)

Then there could be focus on static typing in GDScript and optimizing the interpreter (via a JIT or by compiling GDScript to C++), but this can come later if writing modules is made easier.

I just want to mention a couple of points that have snuck into this discussion but weren't addressed yet:

• Some of us are talking about improving the existing system (GDScript as a scripting language, C++ as a backend language) by facilitating C++ development and increasing GDScript performance. Others are talking about using C++ (or Java / C# / ...) as a scripting language. It may seem like there's no real difference between enabling fast C++ development and making it a scripting language, but I'll gladly explain how I have experienced and observed the negative effect of powerful scripting languages on the quality of game design. And unless this becomes the topic of the discussion I'll gladly do that on the forums or somewhere else where it doesn't hijack this thread.
• @RebelliousX: When you talk about "variable namespace", "large scripts" and "sharing variables between functions" it sounds a lot like you haven't fully understood the object oriented nature of GDScript (no offense). Every GDScript file is a class, so name clashes between (member) variables should happen exactly as often as in any other object oriented language. You aren't sharing variables between scripts, you are writing several functions that can access the state of the encompassing object.

@Warlaan About the first point, I think you could post here, as it's related to the topic.

@Warlaan no offense taken. I know that GDscript is a class of its own and I know that variables are like normal member variables in C++ class, but what it seems that you missed my point entirely. You will understand it when you have a script with more than 1000 lines of code. What I want is references or pointers, instead of creating myriads of member variables, just pass them around between member functions. It is more safe that way.

I like C#, but I see pros and cons.

Pros:

• Good tooling support (let's face it, would you code in C# without Visual Studio or MonoDevelop?)
• Suited for large-scale projects
• Widely used and mature, there is tons of support threads on the internet.
• Good performance, tradeoff between C++ and scripting languages while being cross-platform
• Relatively easy to bind to C++

Cons:

• Garbage collected: large-scale game projects also need to implement allocation strategies to prevent GC kicks from happening too often, this can be nasty
• Not as integrated as GDScript (node path completion? Script member variables on nodes? Memory allocation model?)
• The runtime is heavy, and .NET framework even more. As in Unity, the standard libraries should be remapped to Godot's.
• Not the best fit for actual scripting, in a sense of getting stuff done quick and dirty. C# is more verbose and restrictive than GDScript.
• No guidelines yet regarding Godot development. The language is generic and can do a lot of things, and as Warlaan said, developers have different cultures (You could litteraly have a WPF coder trying Godot and wondering why there are no MVVM way to create GUIs :p)

Most of this also applies to Java.
Maybe I forgot other things because it's late here.

Ok, this is my experience regarding feature-rich scripting languages resp. a complete lack of a scripting language depending on your definition of "scripting language". I'll try to keep it short. ;-)

I have been working as the dean for engineering at the School4Games in Berlin, Germany for several years now. At that school we don't have a faculty for "pure" game design, but our game design course is called "game development" and includes enough programming lessons to teach game designers how to develop their own prototypes and to understand the possibilities and limits of the hardware and common software architectures.
So the students that I teach are people who sometimes have a raised interest in programming but none of whom applied to become a programmer.
Every semester they have to form teams and develop one game. Since almost all of the potential future employers of our students use Unity it has been a requirement for the first two semesters to work with that engine.

Now let's get to the point regarding the effect of scripting languages:
These students split up into two groups. One that either tries to avoid programming or has lost hope (meaning they will attend programming classes but will not ask for help if they run into trouble but silently give up) and one that dives into programming so deep that they skip right ahead to topics that usually you wouldn't be concerned with while writing game prototypes. For example one of my students from the first semester has recently published a tutorial on how to write a Singleton in C# using generics so that you can turn a Unity component class into a singleton by inheriting from the generic class from the tutorial. The interesting point is not so much that he was able to write that article, after all he of course did receive help from his teachers and there are quite a lot of resources on the topic on the internet. The interesting point is that a student who applied for a course that is focused mostly on game design rather than programming would be interested in such a specific programming topic. The code from that tutorial will never change due to changes in game design, it's a pure programming construct.
Something similar happened with a different student who used a similar class to transport information from one game scene to another. He was quite surprised when I showed him that he could do the same thing with a public static member, which shows that he was looking for complete, complicated solutions before he completely understood all the basic elements in it.

So if you skipped ahead this sums up the text so far: while it is possible to write simple code in feature-rich languages I have observed several times that people are likely to dismiss simple solutions where complicated alternatives exist.

This is not just due to prejudice. Sure, that's probably one factor. If you see that the code in tutorials, examples or other classes in your project looks complicated you may conclude that yours should look complicated too. But I think the real reason is that in programming it makes sense to try to create code that is error-proof. It is a natural desire to write code that doesn't break as soon as it's used in a different place or as soon as it receives different input. And that requires you to find out what options there are that you may have to prepare for.
I think this feeling of having to check for every eventuality is what splits up my students into those that drown in the vast number of features of C# and those who jump right in and lose focus in the language.

Zylann mentioned the phrase "quick and dirty". We often use those two terms as a phrase, but when you think about it those are actually two different factors. Whether or not it's possible to code quickly is quite measurable. Whether or not the resulting code is dirty on the other hand depends on a lot of factors, the most important one being the number of features the used language has.
For example creating a top-level node and using it as a singleton in Godot is totally fine since GDScript doesn't offer the features necessary to implement the pattern in the same way you would in languages like C#. Sure, using the autoload feature would be better since that's the first place other developers would look for singletons (and it makes the syntax a little nicer), but if a team decides to implement it that way I doubt that there would be much of an argument. Imagine on the other hand that someone implemented a singleton in Unity just by adding a public static member to a class. It's just as quick, in a way it's even the same thing (both are class instances in the most public place), but since C# does offer the option to make the constructor private, access the singleton via a property with lazy initialization etc. it's expected that you do so, otherwise the code will be perceived as very dirty if not broken.

Now the fact that game design students dive into topics like these may be a vague hint at what my point is, but I think I can illustrate it even better by talking about the situation at my first job at a large F2P MMO developer. The team I joined is one of the most experienced game developers in Germany. Their head of development has been creating his own in-house engines since 1995 and even though they had just been bought by another company they were still one of the most successful developers at the time.
By the time I joined the team they were using the third version of the in-house engine, which did not have a scripting language. They had implemented one before but in that version of the engine they reverted back to not having any scripting language since there were issues with the code quality the game designers delivered. In other words since the scripting language was too powerful the decision was made to shift the barrier between programmers and game designers to the point where game designers would only edit levels and change settings in config sheets while the programmers did all the programming - in retrospect I noticed that this is pretty much the same situation my students end up in (and it seems many professional studios working with Unity end up in).
Now why would I care? If this is happening time and again then doesn't that prove that it's a successful way to work? My answer is no, because there were issues, both technical and in game design, that could easily be explained by the fact that the communication between programmers and game designers was reduced to writing tasks in the one direction and exposing settings in the other. From the game designers' perspective the features became black boxes that could be enabled and disabled, but on that side of the team there was no one who could discuss or even prototype alternatives.
The programmers on the other hand were pushed almost naturally into a backend mentality. The "quick and dirty" KISS mentality was gone, because none of us could foretell how the features we built were going to be used. I remember vividly how once the database broke down because a game designer had implemented an easter egg hunt causing the inventories to grow a lot larger than they used to be. That was the last time I just assumed the requirements of a feature would probably stay about the same.

That's why I think that having a low-feature scripting language as a defined area for game code is extremely important and why I think that not having it has a bad effect on game design.

• Writing quick code means ignoring features turning it into "quick and dirty" code.
• The desire to write clean code splits the developers into those that don't code and those who spend more time thinking about coding and less time about the game.
• That in turn splits the whole team into one half that works on game design without knowing the code base and one that works on features without knowing how they are going to be used, leaving no one who could come up with engine features based on the game design or suggest game design based on features that could easily be implemented.

It is not possible to imagine game development today without using prebuilt libraries of classes, after all that's what makes engines with toolsets like Godot, Unity, Unreal etc. so successful. But the difference between all of these engines is where the line between programming and game design is drawn and how much of a gap is created between the two sides.
And based on my observations I think that the choice of scripting language is one of the most important factors that can create such a gap or close it.

By the way the reason why I have become so involved in Godot is that I am working on establishing it as the mandatory engine for the first semester. Just so you know that I am not just talking but also drawing my consequences. ;-)

@RebelliousX I have to admit that I still don't quite understand what you are getting at. But since you said that what you would want is references or pointers could you open up a new feature request and post a code example for your problem in there? To be honest it still sounds like your problem is one of code architecture rather than one of missing language features.

I should have added that KISS mostly benefits for small teams. Godot is so feature-packed that one developer can make a game. But as soon as a project has more developers, "quick-and-dirty" things become less likely, and are left for prototyping or temporary fixes, then rules/guidelines have to be setup. So, it really depend on who is using the engine, and for what.

Godot in general also has more constraints than we think. You cannot make "c-static-style" singletons or global variables for a reason: memory leaks and thread friendlyness. GDScript is not as featured as Python for a reason: focused on game dev tasks and performance. The scene system is also object-oriented for a reason: you can make independant "boxes" that can be tested and re-used :)

This topic is about adding a C# (or Java) module support, but I see no example code. Let's try something on the fly :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

What do you think?
This file could then be compiled as a DLL asset (or run on the fly). But speaking about this, would we need to generate a csproj like Unity?

@Warlaan thanks for sharing your experience. Correct me if I got it wrong (it was a long post), but are you saying that offering a language with fewer features is better for the sake of the programmers, so that they can focus on developing their games rather than overcoding?

If so, this is a very subtle observation. I think the Godot devs have to do what's best for their userbase - they know what's best.

And I myself today was wondering if some people here (myself included) aren't just subtly asking for Urho3D, while others are asking for GDevelop. Godot is clearly a middle-of-the-road tool between those two (but perfectly suitable for pros, more like Urho3D), and I think it should stay so, but Unity is always going to cast a shadow on it because many people here come from it.

I don't think it's fair to expect Godot to be a Unity ripoff - Godot has clearly better design and as far as I know, better performance. But some people think GDScript is not suited for "serious" development and will never be because it's a custom runtime, despite the fact that the old version of Mono that Unity uses is also in a way a "custom" runtime. And besides, when you write C# in Unity, you write code that works only in Unity for the most part and follow their design patterns, so you might as well use another language.

I think those people who want C# are wrong, but a good compromise in my opinion would be to offer:

1) Better performance (static typing, maybe a JIT)
2) Better support for third-party libraries (via FFI and easier C++ integration)

for GDScript. The rest can be done in C++, including writing modules which implement other scripting languages (which don't need to be first-party - everyone can write a C# module, if they want).

@Zylann I see no advantage in writing that code instead of the equivalent C++, honestly, and the C++ code will have better performance.

@paper-pauper the advantage of writing this code is the same as GDScript: you don't need to recompile the engine for every platform you want to export to, and... well, you get the choice of language (and performance is not the only one point, as I mentionned earlier). I agree that currently, GDScript experience is superior, and C++ is the best choice for pure performance. But, there are people that just don't want to do C++, whatever good it is.
I'm not personally interested in Godot+C#, just evaluating what happens if you add it to Godot. And it's not that straighforward :p

After reading the great book Game Scripting Mastery (you can't find many books about the subject, except the non gaming book about compilers the Red Dragon). My conclusion is that, GDscript is adequate, it is so easy to keep adding features to a scripting language that makes it lose its power. The most important thing is to implement a non bloated script language and as general as possible to make it suitable for different projects. From the same book, it says that Unreal is using C++ with LLVM.

Another idea which might be more lightweight than implementing a separate runtime: what about adapting a transpiler like TypeScript (which is very similar to C#, without the runtime) to emit GDScript instead of JavaScript? This doesn't have to be included in Godot, in fact it might be a third-party module. It would at least offer static typing (at compile time) and a number of libraries, with the same performance as GDScript (because it'd be GDScript).

I like TypeScript, but I don't see the point of adding such complication. If someone do that, they'll have to maintain it to be compatible of newer versions of TS. Also, TS is a superset of JS, so would this be able to transpile JS to GDScript? And then, we would have some people with bugs in the transpiler thinking it's a bug in the engine.

I still think a better idea is to have a static version GDScript that can resort more easily on JIT and still be closely related with the engine and with the current GDScript itself.

The point of C# is to use a established language that could be used outside of Godot too. TypeScript may fit this, but I'm not convinced that it's easier to make a TS transpiler than to embed a Mono runtime.

For me, as I said on IRC, the best option would be the ability to make dynamically linked modules. So you can work in C++ more easily and also there can be third-party modules with different languages, like one for C# and one for C++ as scripting language. It'd increase the ability of growing Godot's resources without having to bloat the main engine binary.

@vnen

For me, as I said on IRC, the best option would be the ability to make dynamically linked modules. So you can work in C++ more easily and also there can be third-party modules with different languages, like one for C# and one for C++ as scripting language. It'd increase the ability of growing Godot's resources without having to bloat the main engine binary.

Oh, I 100% agree - in fact I expressed a similar view in #3936. I was just throwing it out there since we mentioned C#'s runtime as a drawback :)

For me, that example C# module by @Zylann is lovely, I'd switch from Unity right now if that was available - it's not about the higher performance of C++ or the 'easiness' of GDScript, it's about being comfortable.

I'm still super new to Godot and I've barely had a chance to make a test game yet so you guys may not find my opinion valid, but for me GDScript is the biggest hurdle, not in how it's supposed to work with Nodes and Scenes - I understand that (and it's pretty neat!).

But for me, it's literally the syntax of GDScript that is really off-putting to say the least, not to mention the code editor is severely lacking - I'd love to use VS as I know all of the shortcuts already.
I've got years of writing C# worked into my hands and honestly I feel like a kid trying to write in GDScript.

What would be lost by allowing developers to write comfortably? I don't need the plethora that is Mono or fanciness like Linq, I just want to be comfortable while I'm writing my code.
I would settle for a C#-like syntax for GDScript, at least the option to use curly parenthesis, semi-colons and explicit types - I can't stand implicit types personally, they drive me crazy.
I think GameMaker allows for variations in syntax to accommodate different demographics.

This is of course, just my 2 cents from several hours with Godot - feel free to disagree (as I'm sure most of you will).

Also, I think I'm missing something - what is it exactly about GDScript that everybody loves so much?
I'm not trying to offend, I just don't see it yet.
I'm quite familiar with Perl so I know the power of implicit types and whatnot but there's got to be more than that, right?

@Pikl:

Also, I think I'm missing something - what is it exactly about GDScript that everybody loves so much?
I'm not trying to offend, I just don't see it yet.

The point about GDScript is not much about syntax (which is Pythonesque) but more about how integrated it is with the engine. It might sound pedantic, but syntax is the least of the concerns when moving to another system. What matters most is the API. Even if we added C# right now, you'd probably feel uncomfortable with the new paradigm, since the way you do it in Unity is not the same way you do in Godot.

Sorry, but if we added languages to attend the comfort zone of every programmer, we'd spend the eternity doing just that. While might make sense to bring Unity users with the least stress (right now we're trying to make a Godot guide for Unity users), I don't think Godot should adapt itself to work like Unity. Otherwise we'd have to do the same for users of Unreal, Urho3D, GameMaker, etc.

This is not to say C# isn't happening (it might be if it's feasible and within the interest of the engine), it's just that these arguments would apply to many other languages and engines too.

@Pikl First of all thanks for providing the first argument in favor of C#. Now let me explain why I think your opinion is invalid. ;-P

Let's have a closer look at the start of the code example by Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

As a rule of thumb every keyword and every non-keyword-character has a meaning. If it doesn't it shouldn't be there.
It starts with
using GodotEngine;
which means that this code is referring to functions imported from the "GodotEngine" package. Since every script in Godot refers to those functions and there are no other packages to import from it's pointless to add that line, so let's remove it.

Next we have
public class Spikeball : RigidBody2D {
Everything in GDScript is public so why mention it?
class Spikeball : RigidBody2D {
Every GDScript file contains a class with the same name as the script. That's not just a coding convention like in other languages, it is defined like that, so where's the point in repeating the class name?
: RigidBody2D {
Now since the : is the only meaningful "keyword" in this line let's replace it with something a little more readable.
extends RigidBody2D {
Any coder with a little bit of experience will use indentation to mark the different areas of the code. That means that the code inside the class can be identified by the surrounding braces AND by the indentation, which is why the developers of Python decided to make the indentation mandatory and get rid of the now redundant braces.
In our case indentation isn't even necessary on the class level since every script file is defined to be one class (unless you are using subclasses which are marked by indentation).
extends RigidBody2D

Next we have the export lines.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

The []-characters mark attributes that are defined in classes of the same name, which is a mechanism that doesn't exist in Godot, so it simply uses keywords instead.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

Again, everything is public:

    export float damage = 60f;
    export float rotationSpeed = 2f;

and you don't need to specify the data type.

    export var damage = 60f;
    export var rotationSpeed = 2f;

Exports are an exception because the inspector needs to know which widget to show you, so the type is really just an extra information for the export keyword.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

So the difference between this C# code

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

and this GDScript code

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

is simply that every character and keyword was removed that did not describe the options you have in Godot.
I am assuming that now it's pretty clear what people like about GDScript. You aren't forced to type in stuff that's meaningless or redundant and the syntax reflects the options you have instead of hinting at options or language features that don't exist in Godot.

Coming from a C++/C#/TorqueScript background I have to say that Godot's paradigm takes a few days to get used to but once its simplicity "clicks", you can move from idea to execution about as fast as you can type.

@vnen:

it's just that these arguments would apply to many other languages and engines too

Fair enough, I'm not holding my breath nor do I expect to be accommodated - this isn't my territory.

right now we're trying to make a Godot guide for Unity users

Maybe I could help with that? I've been using Unity for several years and know the thing quite well compared to any other engine - I'd be a good lab rat for this guide.

@Warlaan:

I am assuming that now it's pretty clear what people like about GDScript. You aren't forced to type in stuff that's meaningless or redundant and the syntax reflects the options you have instead of hinting at options or language features that don't exist in Godot.

That makes perfect sense - it goes along with Perl's ideology of reducing the amount of keystrokes needed to type a script. But really, the amount of keystrokes I would actually type for that example would be the same - I use VS's auto complete to the max and rarely have to type more than 3 characters for whatever keyword, type or variable name before I press space or open bracket to complete it. And as for the actual extra 'unneeded' characters there, I prefer having them there, that one is just a syntactic sugar preference.
Godot has autocomplete but it's slow, it takes so long that I have often typed my entire line of code before it even shows up most of the time.

So what people like about GDScript is that it's stripped down to be as minimal as possible providing the exact functionality that's available for use and nothing more, as well as reducing keystrokes.

I get that, but it does nothing to help me enjoy it any more - I'm just not comfortable typing GDScript, I can read it perfectly fine, though. I'm not struggling to learn it, I just don't like it, it seems.
Maybe a few more hours making a Space Invaders clone would help convince me - I want to like GDScript more than I do.

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

Maybe I could help with that? I've been using Unity for several years and know the thing quite well compared to any other engine - I'd be a good lab rat for this guide.

@StraToN made a post in the facebook group asking for this kind of help. Contact him (I am not sure if there is someone else working on that too).

@neikeq Thanks, done!

@Warlaan I understand your code comparison, but for me it mainly proves that C# has more features, and as such, is more verbose.

You need using because there are namespaces to avoid name collision with lots of classes (which already happens to me in my own game project).
You need public because there is a notion of encapsulation to prevent coder errors over time.
You have [SomeClass] because we can extend built-in annotations to suit different project needs and improve tooling.
As for braces... I don't see an advantage, except for defining scopes.

These features are here for a reason. Among them, I would say scalability. Would you develop a huge cross-platform 3D game with all codebase in GDScript? Well, you can. But a lot of users will prefer C++, C# or Java, because of the pros I listed (and I speak purely about the language, not the framework).

But at the same time, there is no "huge" game project I know of being developped with Godot, so not so much examples :p
Also, I see a few bad features in C# (warning: personal opinion ahead):

You can have static variables. This is wrong, so much errors come from global states/singletons. Unlike auto-load, they are not bound to any scene scope.
You can mistype a semicolon at the end of a while() of if() statement, making it useless and hard to find.
You can overcode. I agree that, when used the wrong way, C# code can become very convoluted while another simpler code would do the same. But it depends on people/experience.

Oh. I didn't mentionned preload(). This just can't make it to C#/Java, unless you rely on compiler tricks :p

Did anyone already started to experiment a Mono module?

To add my most humble opinion, as somebody who is a C# developer, to this...

I don't think there is much value in adding C# to Godot, as you would still have to learn Godot's classes to get anything done and the only thing you would really gain from adding C#, is the more familiar (to many) C style syntax and static typing.
The syntax thing is debatable, Python has the reputation of being easy to learn for beginners and since GDScript is highly similar to Python, I think the same holds true for it.
Somewhat experienced programmers shouldn't have any trouble picking up on that syntax anyway, it's consistent and has considerably less pitfalls than the more free form C style syntax.

Now static typing on the other hand can have some value, aside from helping with performance, it can also help with speed of development in some respect. Auto-completion tools just love being told what type a give function/method expects and returns but type hints alone can achieve that.
This could be added to GDScript though, no need for any additional language.

Also implementing C# probably wouldn't be all that easy and considerable amount time and effort would be spent on just getting the engine to the state it currently is in but now with C# on top or instead of GDScript.

As a closing comment, which I know some people will take the wrong way, I have this to say:

It has been my observation that some programmers that might not be as solidly footed as they should be in our craft have the tendency to cling to the stuff they do know with all force available to them.
This phenomenon appears to me to be especially widespread in the C# dev communities, though this might just be my bias.
If any of the people reading this think they might fit into that description I can only recommend to step outside this familiar box and start learning something new, it's not as daunting of a task as you might think it is and once you do have a firm grasp of that new thing, you will probably also have increased your understanding of what you already knew. It's just worth it.

I would love static types, but if that happened how would you deal with generics? Would you simply use a dynamic type in that instance or would you want to be able to use constraints? - only allow ints and bools for example.

Namespaces would be extremely welcome, I'm surprised that they don't already exist in GDScript.

The option to use braces instead of colons for methods would be lovely too, I know they're unneeded but I like having them there - it's like reading a book without any full stops, it's jarring.

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() :)

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

@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.

@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. ;-)

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?

@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).

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.

@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)

@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

@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

+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.

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)

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.

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!

@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!

(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.

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

@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.

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

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.

@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.

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

@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.

@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.

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

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

@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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

@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.

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?

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.

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.

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.

@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 .

( @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 ?)

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.

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.

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

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.

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.

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_overlapping_bodies()_

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).

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.

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?

@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).

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?

@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

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.

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

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.

@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.

@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.

@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).

@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.

@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.

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

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 [email protected]
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
.

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

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.

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

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.

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.

@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 :)

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.

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.

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.

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++.

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

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

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

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

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

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

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.

@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.

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!

@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

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

Hello just a random guy passing by

I wanted to let you know that i'm not using Godot because i don't like the script language you use

If you add Java or C#, then i'll install and use godot right after your announcement :)

@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.

God of Marketing favors C#. :laughing:

@RebelliousX Choosing Java or C# means you'll have in hand LOAD of library to use

Limiting yourself to home made script language is just useless, your new knowledge won't be applicable elsewhere, and you won't be able to find ton of libraries, or wont be able to reuse your knowledge or existing learning resources

Choice is insane nowadays don't be closed minded

@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...

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.

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.

Agreed.

Could please provide link to C# integration source codes?

https://github.com/neikeq/GodotSharp

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

@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

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

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.

@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.

@karroffel that's really cool. I have no experience with writing libraries and APIs (reference to your mention of "bindings") although, I could probably just research into it for a day and do it; I'm proudly a quick learner. I would like to get in touch with you on Discord, if you wouldn't mind? My discord: _hasCat#3941

@VenHayz I can't add you, you're not allowing others to add you. Karroffel#8409 or join the Godot server

@neikeq Is your GodotSharp repo the codebase that is being used for the C# support in Godot 3.0? Just asking because I am trying to get a rough idea of what features will be available and will poke around that codebase if so. Thanks!

i look godotsharp, is outdated ? new feature ? or is ready to use in develop build?

how can i compile godosarp from soruce for me?

@nictaylr You'll need to use the 2.2-legacy branch as a develop build.

I think I read enough to figure out if someone else mentioned this.

I personally just don't want to learn yet-another-language that I can't use anywhere else. I'm not planning on doing a lot of 3D programming, just a few things here and there.

Yes, there are plenty of counter-arguments against this but ... it's an open-source project. There is no need to hate on someone contributing a new programming language.

Imagine bringing beer to a kids party. Would you say that "there's no need to hate on someone contributing a new drink"? There's a good chance that adding C# is going to harm the development of GDscript. I know that everyone is determined to keep GDscript the primary language for Godot, but it still annoys me when it has been explained several times why adding new features has downsides and people are still asking "what's the harm?".

Also asking for C# instead of GDscript because "you don't want to learn" is a really stupid argument. Of all the languages I know in game development GDscript has the least features and C# has by far the most. If you don't want to learn you should be thankful for GDscript.

I really don't want to warm up this discussion time and again, so please if anyone wants to comment on this thread PLEASE READ IT FROM THE TOP.

Also asking for C# instead of GDscript because "you don't want to learn" is a really stupid argument.

I wouldn't mind learning C# because I might be able to use it somewhere else.

Just lock the thread, it's getting mean.

It's true that this thread has served its purpose, let's lock it.