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.
8 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.
13 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).
5 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.
12 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.
4 Likes
Yeah! C# is the standart for gamedev!
I noticed that there are efforts to add C# support to the platform, and I believe this would be a mistake.
With 15 years of game development experience, primarily using Unity3D, I am searching for an engine that is lighter than Unity yet offers robust cross-platform capabilities for web, mobile, desktop, and console. Defold looks very promising in this regard and better than Godot.
While adding C# support might make adoption easier for developers like me, it risks making Defold too similar to Godot and Unity, thereby losing its unique advantage. Instead, I believe enhancing 3D capabilities in the editor would be more valuable.
For those seeking strong-typed languages, TypeScript to Lua could be an excellent option. It is familiar to many web developers and provides an easier entry point for those transitioning from Unity or Godot.
In summary, adding C# support may undermine Defold’s strengths.
While we do in fact implement C# support, it is also done with a “Defold way” in mind.
Think of C# support as an optional addon.
We’re not rewriting the engine, we’re only adding C# bindings to the already existing C/C++ sdk’s.
What you can do in C, you can then do in C++/C#(/Zig) via our dmSDK.
A key goal is still to keep the engine light. (as always)
It should relatively small effort too, as we we generate 95% of these bindings.
it risks making Defold too similar to Godot and Unity
I don’t see that as a big risk. We still have our own way of doing things, and we’ll keep our vision moving forward.
I am searching for an engine that is lighter than Unity yet offers robust cross-platform capabilities
We’re certainly light, but if you are going for C#, it will add the C# runtime to it (a few megabytes). It’s not for everyone, or all studios.
We also always keep track of our engine size:
For those seeking strong-typed languages,
We also just added Teal support for those wanting strong type checks.
7 Likes
I would love to see a tighter integration with TypeScript. The Teal extension is proof that we can now integrate languages which transpile to Lua with the build pipeline and editor. Someone motivated enough should be able to create an extension-ts repo based on extension-teal.
We don’t want to compete, and I don’t think someone will start comparing us to Godot and Unity ju because we provide C# as an opt-in language. C# will never replace C++ and Lua, but it will be available for those studios heavily invested in C#.
We’ve made many improvements to 3D capabilities over the last 12 months. And we don’t intend to stop. Our next thing for the editor, besides big improvements to editor scripting, is to improve the scene view with better navigation etc.
4 Likes
Our next thing for the editor, besides big improvements to editor scripting, is to improve the scene view with better navigation etc.
What about “snap to grid” or “snap to guides” to make building scenes easier?
Both 2D and 3D workflows would benefit from these ones…
1 Like
Yes, both of these are on the list of scene editor tasks that we will review and prioritise: Issues · defold/defold · GitHub
2 Likes
That’s awesome. Thank you!
C# is not standard to GameDev. C# is mostly used in GameDev for Unity (because it won over the JavaScript-based Boo).
I started out doing game dev on a crappy little 286 with QBasic and Microsoft Debug (where you write assembly directly into memory). Then did homeboy GameBoy dev … eventually getting a chance to work commercially on a console project. There I made my own little scripting language (2007-2009) and VM.
Anyway, … fast forward to today and what attracted me to Defold was the following:
- Small downloads.
- Performant.
- Supports Nintendo Switch without needing a third party to port (as with Godot).
- Good hot-reload support.
- Lightweight editor.
- No-brainer language choice (Lua is well-established for game development and is a versatile language that supports functional programming exceptionally well if needed).
- Will support rapid prototyping.
- Simple, minimal and well thought out (and no unnecessary cruft to learn).
I felt a little uncomfortable using an engine for my current project and was working with C++/Raylib/Lua (giving me lots of freedom to do things like render to texture so I could have some generated assets, etc). I made a little live-reload NeoVim plugin for my project and felt I was good to go (I already had a similar tilemap/tile source-like system I’d knocked up in Lua via the Raylib bindings).
I’ve decided to switch to Defold. It manages resources better and prevents me from being distracted by framework/engine stuff.
We already have Godot and Unity.
C# only became relevant for game programming because of Unity. It was C++ before (with Lua as a no-brainer scripting language).
C# isn’t popular for game development outside of Unity.
…
If the aim is popularity, continue doing what you’re doing well. Keep making great games. Keep making it easier to develop great games.
A few hit games Made in Defold will draw in more developers than adopting C# ever could.
…
I also like Defold’s message. It’s simple, straight to the point and all about the things that matter to me as a game developer.
It has evidence to back up its claims.
It has support for the things that matter.
…
It’s so easy to put the cart before the horse. Racket is doing that now with Rhombus.
The reason why things aren’t more popular isn’t always about the features.
…
NeoVim uses Lua. Vim uses VimScript. Emacs uses ELisp. VSCode uses JavaScript. JetBrains uses Java.
Out of those I’d say NeoVim is the only one where the language made the most difference (but only because it replaced the clunky VimScript with the cleaner Lua).
…
Don’t put the cart before the horse.
7 Likes
No worries. Think of our C# support as an addon. We won’t stray from our C/Lua setup.
As for ”only Unity”, the number of developers in that space is huge, and we’ve heard it quite a few times that studios/developers has passed us up due to lack of C# support. So that’s why we add this feature (addon).
5 Likes