C# as scripting language

[ghost]

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

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

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

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

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

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

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

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

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

Any opinions?

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

[hubbyist]

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.

[Warlaan]

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.

[ghost]

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

[Warlaan]

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

[ghost]

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.

[vnen]

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.

[Ace-Dragon]

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

[RebelliousX]

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?

[ghost]

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

[alabd14313]

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: #4217
There is some issues about languages like C#: #2790

[ghost]

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.

[Warlaan]

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.

[volzhs]

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

[alabd14313]

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/](Why C++17 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...

[alabd14313]

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

[ghost]

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

[Warlaan]

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.

[reduz]

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.

[ghost]

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

[Ace-Dragon]

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.

[Warlaan]

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.

[alabd14313]

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

[RebelliousX]

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.

[avril-gh]

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 ?

[vnen]

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

[avril-gh]

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 ☺️

[ghost]

@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 Include libffi #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.

[Warlaan]

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.

[Marqin]

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

[ghost]

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

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

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

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

[neikeq]

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

[lukewilson2002]

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

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

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

[Marqin]

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

[nictaylr]

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

[RebelliousX]

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

[hubbyist]

God of Marketing favors C#. 😆

[Warlaan]

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

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

Seriously, the audacity of some people...

[Zylann]

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

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

[neikeq]

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

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

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

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

I think this issue can and should be closed.

[akien-mga]

Agreed.

[nictaylr]

Could please provide link to C# integration source codes?

[akien-mga]

https://github.com/neikeq/GodotSharp

[nictaylr]

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

[karroffel]

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

[neikeq]

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

[lukewilson2002]

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

Anyways, just a quick suggestion or maybe for ideas.

[karroffel]

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

[lukewilson2002]

@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

[karroffel]

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

[rattasak]

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

[nictaylr]

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

how can i compile godosarp from soruce for me?

[HummusSamurai]

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

[indolering]

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.

[Warlaan]

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.

[indolering]

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.

[akien-mga]

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