Hi all,
I have opened up a C# support for Defold Discussion in Github. Any Suggestions are welcome.https://github.com/defold/defold/issues/8063
1 Like
I think they have DefoldSharp in a GitHub. But it doesn’t go beyond C#7.
Here’s the address:
I would like to see something with types in defold too, but does c# really fit defold?
- C# runtime would be bigger than the whole defold engine. Maybe even 2 or 4 times bigger. So you cannot apply it to all platform.
- Defold doesn’t trying to be OOP. And implementing game logic in OOP is not a good idea at all. It’s suit for implementing service parts of the game, but any game logic become an antipattern hell or too slow to run.
- The case with implementing a transpiler is really a bad idea. Because it would be just a huge overhead and a bunch of uncorrect behaviour on top of lua. I tried this path some years ago with one of my game and https://github.com/yanghuan/CSharp.lua. Strange feelings, it’s basically means that you do not control the code you run.
I agree that popular language/technology can attract more people, but still want to mention several things.
- Programers don’t casually walk around github and start writing code on every engine that support they language. There must be some motivation besides the language to choose an engine.
- Having another language don’t really make defold less accessible. Is’t not a situation when you build a stairs for a weelchair. Lua is accesible for any developer, and closure only for choosen ones.
Just some side stuff from my head about different parts of community having their own view of defold and features:
- Some time ago there was an disscussion in telegram that visual scripting can attrack more people to defold and defold team must implement it (no link sorry).
- There is an old issue on github about having flutter somewere in defold.
- One more issue of reimplementing current editor in different language.
7 Likes
This is definitely a reason for us to not implement and maintain a C# runtime. The size of the Defold engine is one of the unique selling points. Bloating it with a C# runtime would remove that benefit.
Yes, it will be slower for sure. Someone shared the Defold bunnymark rewritten using Haxe and the transpiled Lua code was indeed slower. Not noticeable in a toy project with a small amount of code running each frame, but when you started to scale the project it definitely became noticeable.
Yes yes yes. So much this. The programming language is obviously a factor to take into account, but it cannot be the deciding factor if a game engine should be used or not. Perhaps for a hobbyist, but not for a professional studio. We have quite a few examples these last few weeks of professional game dev studios evaluating other engines than Unity, with Defold being one of the engines they are looking into. The fact that a studio has invested time in Unity and C# will hurt when moving to a new engine, but a lot of knowledge will be transferrable to a new engine and a new language.
11 Likes
Disclaimer:
Just a hobbyist here who played around with Defold and Godot for a very limited time, so don’t take me too seriously. So here’s my outsider view. 
I agree that there would be some appeal to having C# supported as a scripting language because it’s more popular in gamedev than Lua. But for my limited OOP brain, the main appeal would be being able to work in a more fully featured, multi paradigm language. I’ll dare to say a workflow that allows full scripting support in C++17 could be just as appealing as C#. Maybe even more, there are very few engines/libraries that allow scripting games in modern C++.
I see Defold as an engine that has some similarities to Godot, but seems way more stable, and that’s its strongest selling point. Then again, for my OOP brain, using Lua which is not typed and has 1-based indices is a huge turn off. And I suspect this could be the case for many people programmers.
C# as pointed out by maintainers doesn’t seem to be the way to go. But I definitely see value in supporting scripting games in a typed, multi paradigm language (if any would fit Defold ofc).
3 Likes
You should not limit yourself to thinking in OOP, a functional thinking approach is far stronger. Lua is not an OOP language, this is a very good thing. How code is written is much more important than the language it is written in. A programmer should be able to use what ever language fits the situation. Lua is a great fit here as it is specifically designed to be an extension/embedding language. It is not Python, another good thing for the purpose, for example as minimal as practicable ( a C compiler is the only dependency). Haxe, C#, I can’t see the point of adding an extra layer of complication, and more stuff to go wrong; any programmer will be able to use Lua very easily, just don’t write messy code. 0 or 1 is no big deal, easy to understand. Defold has C++ for extensions, nothing else is needed. The Lua and Defold devs both try to minimise the code bases which is most excellent, many people struggle to understand the merits.
5 Likes
My 2 cents. LUA is very very simple to pick up if you have any coding skills at all. Where as C# is a bit more complex and I’m not sure some of the main benefits of C# would even work well in Defold.
If anything, I’d rather see python picked up instead of C# (and I’m mainly a C# dev). But even then that is overkill. LUA is fine. I’d rather they spend the time making actual improvements to the engine and improving the documentation so a beginner can pick it up easier.
1 Like
Yes. Python is a great general all purpose language. It would not be as fast here and it would probably require a special cut down version, and how would it be maintained and updated, people would start asking for the latest version or with this or that in it because of what ever reason and so off go the goal posts running down the road.
3 Likes
Python is also easier to be bind with C++ code.
I’m OOP first dev, who, with pleasure, dig into functional and dynamic languages after work 
In case of Defold - offering more C++ solutions (alongside Lua as a base) might be a good direction? Right now it is possible, like @sergey.lerg presented here, but the native extension code must be run from Lua anyway and the process of building it is more complex and, if simplified, maybe would a viable option together with Lua? I don’t know though good ideas for making it better and simplified - adding “C++ script” components? Promoting building C++ on own machine?
2 Likes
I just want to point out that although we do use C++, it is only for a few features. All the code is very C-like. And we don’t want to start doing OOP in the engine, or expose that as api’s to the users.
As for using C/C++, it isn’t really scripting anymore, but just regular plugins, and the turnaround times for building would be quite annoying. And we wouldn’t want the users to have to install SDK’s locally to compile for their desktop platform (we don’t want to increase the Defold editor size either).
But, if it’s “regular” programming, then sure, we’ve said that we will expand our C++ sdk with more functions to be able to program things you could normally do in a lua script.
We haven’t started planning for that though.
10 Likes
C# would be a nice option for desktop oriented games. Not good for mobile or web.
Instead of C++ it would make more sense to adopt something else. Some lightweight language with a focus on performance like Zig, V or Jai. That’s actually my goal with my C++ plugin, I use it only as a proof of concept with my game, to prove that it’s possible to make an entire full-featured game using native code.
3 Likes
Yeah! C# is the standart for gamedev!