Mono seems to be MIT-licensed now, for the runtime parts. This means that we are legally able to use it. There also is CoreCLR, though I’m not sure if it can replace Mono in our case.
That said, GDScript may eventually get a static typing option, which would allow for better performance.
Other things to expect in 2.1 and 3.0 might be:
- OpenGL ES 3.0 support for dramatically improved graphics. Physically-based rendering, SSAO, real-time reflections, better shadow mapping and much more. WebGL 2.0 encompasses OpenGL ES 3.0, so it means that Godot could still run on the Web (but right now, WebGL 2.0 is not enabled by default in any browser, although that may change in the future).
- Improved networking support. Reliable UDP implementation and/or remote procedure calls; latency or packet loss simulation for local game development.
- In general, more work on the 3D part of the engine, such as better navigation in the viewport (“fly camera” like you can find in Blender).
You have not correctly understood. Personally, I don’t need “Mono”. On the contrary, I do not support “Mono” in Linux. I think it is a “foreign body” and I delete it immediately after installing Linux. I know that as do many.
A distinct advantage of the Godot - his exceptional native character for Linux. In news indicated that it is expected “C#”, for Linux it is “Mono”. I believe that the emergence of such dependence in the future - will reduce the attractiveness of the Godot for Linux users.
DimitriyPS | 2016-05-10 14:10
Love the idea of “fly camera” building in 3d is more work than it should be because of the current camera system.
SupToasty | 2016-05-10 16:59
I really want C# support !!
concept of encapsulation and static type will boost the productivity
eaglecat | 2016-05-11 05:34
I am not a principled opponent of C#, just the Godot it cross platform. In the Windows, interpreter “.net” - an inseparable part of the system. On other platforms, the interpreter is “Mono” - this is a very large and useless dependence. Programs “Mono” are regarded as not native. Often, users (e.g. Linux) prefer to remove “Mono”.
DimitriyPS | 2016-05-11 08:53
@eaglecat: If you want visibility modifiers and static typing then ask for those two features. Asking for C# because of those features is like uninstalling your virus scanner because you don’t like its icon.
Of all the languages I know C# is most overloaded with features and paradigms. No matter what you do in C# there’s always at least two different ways of doing it. This leads to less readable code which in turn leads to people posting magic code so you can “solve” your problems by copy-pasting.
I assume you are actually asking for visibility modifiers, because Godot is already better at enforcing encapsulation than Unity for example, which can easily be used in a very procedural way (which is very common in tutorials or code snippets you see on the internet).
One of the main strengths I see in Godot is the clean code base. The downloads are tiny and building it yourself is really easy.
The separation between GDScript and C++ is also very clean. If you need a more powerful language, e.g. so you can access new libraries, then it’s easy enough to write new C++ modules. If you don’t need that power you should be thankful for not having it, because if you intend to write good code every option is a decision you have to make.
Imho supporting Haxe would be a much better choice. That language has three visibility modifiers (unlike C# which has 5) and is type safe using type inference, i.e. it’s type safe but you can still use “var” in almost every place, as long as the type of the variable is recognizable at some point. But unlike C# it has a much more restricted feature set.
But the main issue I see is that it’s probably not a good idea to introduce a general purpose language as an in-editor language. GDScript is a DSL (domain specific language), and that is what makes it so powerful. For example it doesn’t support static members, which may seem weird since it supports static methods, but that facilitates multithreading because it’s much easier to tell which methods access the same nodes. I have to admit that I haven’t looked into the corresponding engine code yet, but that’s how the decision is justified, and that’s the kind of decision you can actually make with a DSL.
The result is that “the way to do it in GDScript” and “the way to do it in Godot” become the same thing. The language can facilitate the right way and make the wrong way less visible. In Unity there’s a huge difference between “the way to do it in C#” and “the way to do it in Unity”, because some things are just implemented in a way that is not really natural to C#.
Warlaan | 2016-05-17 09:03
Personally I, DBScript completely satisfied.
Before I began to study the Godot I was programming on FPC+Lazarus.
I immediately realized that to start learning the Godot - need DBScript. DBScript is not similar to Pascal, so at first I was a little afraid. But to my surprise he “succumbed” is quite easy. I don’t know all the available function and the classes topology but thanks to the documentation I am quite cope with current tasks. Sometimes asking questions here )))
Why I raised the question of C#? I really like the Godot. I was very pleased with the appearance of a full games development environment under Linux (native Linux). When I read in the news that Godot is expected to support C# - I was concerned about it. I don’t wish that the development environment Godot depended on “Mono”.
DimitriyPS | 2016-05-18 08:59
You did a great job! Thank you guys! please, unprocessed Godot in Unity: D Unity is ugly!
SpaghettiDeveloper | 2016-08-17 00:12
Regarding “real-time games” and managed languages, there is the issue of Garbage Collection.
In UNITY there is a need for “a bag of tricks” to avoid trigging garbage collection during the games.