It's cool but I wonder why would anyone want to write C# instead of Lua for the same API access ?
I mean, if C# could be native instead of translation into Lua, directly connected to Defold Engine via a C++/C# bridge, then this could be more meaningful.
And while (like a lot of open source) at some level it starts as simply a "why not?" mixed with a bit of personal interest, at some point there needs to be more to justify continued personal investment. So, I hope to give you a deeper answer, so this will be long because I think it deserves a longer answer. I'm not trying to attack your position, I think this is a question that needs to be answered fully.
I know my initial forays into this approach were simply seeing if it was possible and largely personal as I've used C# for 19 years, and over 15 of that was professionally. So that initial motivation is probably the same as that behind hxdefold and TS-Defold: a desire for a static-typed language compatibility for Defold that the author is more comfortable with. There's nothing wrong with lua! The beauty of lua and other dynamic languages is the freedom it offers without requiring really anything of the user. It's entirely possible to program a game in Defold and never really understand metatables, perhaps beyond some rote copy-paste for modules. Literally a beginner can learn everything that they need in hours to days (code-wise) and I think that cannot be stated enough.
It's just over the years I've come to value what a static-typed language brings as the project size grows. At some point, being able to track where variables are used, refactor and rename variables, group things logically, and shift as many errors to compile-time rather than having to discover the exceptions at runtime becomes more valuable to me personally. Maybe my brain just works differently, but I'm not alone in this.
And that's where we get to the more meaty stuff. My initial look to even see if this was possible was prompted by a discussion on GameFromScratch's discord, in which a number of users were discussing hobbyists and indies abandoning Unity in favor of other engines following several questionable actions on Unity's part this summer. Defold was mentioned as a possible alternative, but most users agreed that if anyone left Unity they'd probably go to Godot, given its similarities, large userbase, and support for C# (which Unity also uses). Several users chimed in that Defold's use of lua was the reason they weren't using it and had moved to other engines. Does this mean lua is bad? No, absolutely not, but it did make me wonder if C# was available, would they have stayed?
Defold obviously is a different class of engine from Unity, but how many other users bounced off Defold after looking at it and thinking it wasn't a serious option? Just like ts-defold offers a hook for users coming from javascript engines, I hope C# being offered is a hook for Unity/Godot developers. Even if it is just to give them a foothold of comfortableness to learn the lua side. To further cater to those users, DefoldSharp also has an OOP API that is being added in. You absolutely can use the regular Defold API if you wish, which should help when converting tutorials, but you don't have to. You can use more natural C# as well.
There's definitely some interest. I've had numerous people contact me to let me know they're interested, and the Defold developers have taken every opportunity to cheer me on and assist with any questions I have. Seriously, I can't thank them enough for their encouragement. Which has been quite refreshing, after reading Godot's primary development team ridicule and condescend C# users, despite them being 20% of their users.
Lastly, would something like this be better if it were directly loaded C#? Yes and no. On the one hand, there would be more direct control of performance, a better debugging experience, and so on. On the other hand, it would be immediately limited by runtimes and platform support. Right now, DefoldSharp doesn't have that issue, because it is NOT running C# and .NET, and ultimately adds zero dependencies and can integrate with other Defold extensions. It compiles down to the same API used by straight lua code. The extra OOP API I'm adding is just sugar.
And you kinda hit the nail on the head. This is a bit of a niche solution that a small subset of users might prefer. I don't want to tie up the main development team for months adding in a bridge and the runtimes, and working out the platform integrations, for something that at this point we frankly don't know will even be used much. At the end of the day, I think it's a perfect fit that this be created on the side as a community project. If there's sudden usage and overwhelming support, then that justifies the Defold development team effort and official support. But until then, their efforts are better focused on the engine and what it can do.
← Return to tool
Comments
Log in with itch.io to leave a comment.
It's cool but I wonder why would anyone want to write C# instead of Lua for the same API access ?
I mean, if C# could be native instead of translation into Lua, directly connected to Defold Engine via a C++/C# bridge, then this could be more meaningful.
Good question!
And while (like a lot of open source) at some level it starts as simply a "why not?" mixed with a bit of personal interest, at some point there needs to be more to justify continued personal investment. So, I hope to give you a deeper answer, so this will be long because I think it deserves a longer answer. I'm not trying to attack your position, I think this is a question that needs to be answered fully.
I know my initial forays into this approach were simply seeing if it was possible and largely personal as I've used C# for 19 years, and over 15 of that was professionally. So that initial motivation is probably the same as that behind hxdefold and TS-Defold: a desire for a static-typed language compatibility for Defold that the author is more comfortable with. There's nothing wrong with lua! The beauty of lua and other dynamic languages is the freedom it offers without requiring really anything of the user. It's entirely possible to program a game in Defold and never really understand metatables, perhaps beyond some rote copy-paste for modules. Literally a beginner can learn everything that they need in hours to days (code-wise) and I think that cannot be stated enough.
It's just over the years I've come to value what a static-typed language brings as the project size grows. At some point, being able to track where variables are used, refactor and rename variables, group things logically, and shift as many errors to compile-time rather than having to discover the exceptions at runtime becomes more valuable to me personally. Maybe my brain just works differently, but I'm not alone in this.
And that's where we get to the more meaty stuff. My initial look to even see if this was possible was prompted by a discussion on GameFromScratch's discord, in which a number of users were discussing hobbyists and indies abandoning Unity in favor of other engines following several questionable actions on Unity's part this summer. Defold was mentioned as a possible alternative, but most users agreed that if anyone left Unity they'd probably go to Godot, given its similarities, large userbase, and support for C# (which Unity also uses). Several users chimed in that Defold's use of lua was the reason they weren't using it and had moved to other engines. Does this mean lua is bad? No, absolutely not, but it did make me wonder if C# was available, would they have stayed?
Defold obviously is a different class of engine from Unity, but how many other users bounced off Defold after looking at it and thinking it wasn't a serious option? Just like ts-defold offers a hook for users coming from javascript engines, I hope C# being offered is a hook for Unity/Godot developers. Even if it is just to give them a foothold of comfortableness to learn the lua side. To further cater to those users, DefoldSharp also has an OOP API that is being added in. You absolutely can use the regular Defold API if you wish, which should help when converting tutorials, but you don't have to. You can use more natural C# as well.
There's definitely some interest. I've had numerous people contact me to let me know they're interested, and the Defold developers have taken every opportunity to cheer me on and assist with any questions I have. Seriously, I can't thank them enough for their encouragement. Which has been quite refreshing, after reading Godot's primary development team ridicule and condescend C# users, despite them being 20% of their users.
Lastly, would something like this be better if it were directly loaded C#? Yes and no. On the one hand, there would be more direct control of performance, a better debugging experience, and so on. On the other hand, it would be immediately limited by runtimes and platform support. Right now, DefoldSharp doesn't have that issue, because it is NOT running C# and .NET, and ultimately adds zero dependencies and can integrate with other Defold extensions. It compiles down to the same API used by straight lua code. The extra OOP API I'm adding is just sugar.
And you kinda hit the nail on the head. This is a bit of a niche solution that a small subset of users might prefer. I don't want to tie up the main development team for months adding in a bridge and the runtimes, and working out the platform integrations, for something that at this point we frankly don't know will even be used much. At the end of the day, I think it's a perfect fit that this be created on the side as a community project. If there's sudden usage and overwhelming support, then that justifies the Defold development team effort and official support. But until then, their efforts are better focused on the engine and what it can do.
Very interesting! I look forward to futher development!