Will Defold support an official alternative language like Godot does?

[Chung_Xa]

At least we can get 10+ C# devs (just for fun)

[Qws]

@Mathias_Westerdahl

Harder is still not a guarantee.
Getting readable C++ code from a binary is absolutely doable.

While it is doable, the effort to reverse engineer that will be magnitude higher…

@Mathias_Westerdahl

Also note that we will compile the C# into regular libraries, just like C++, using the AOT pipeline from dotnet. So they’ll be just as easy/hard as any other C-like language.

Then that is better than I thought… I have no problem with C#, it is my first language, made UWP apps my self (also .NET Native/AOT) and I like the performance.

But when Mono, Xamarin founder and the man who advocated C# to Unity, himself says that C# for game development is his biggest mistake in his career and that he regrets. Is kind of alarming.

[thejustinwalsh]

While it is still in the early stages and not ready for prime time, you may want to take a look at Static Hermes, a JS engine that can AOT compile to native code. It is an evolution of Hermes, an already impressive JS engine that AOT compiles to bytecode and is jitless.

This is a good talk about it here:

Static Hermes: the Next Generation of Hermes - Tzvetan Mikov | React Native EU 2023

I made an initial POC with raylib, GitHub - thejustinwalsh/sh-raylib: raylib bindings for static hermes, but this repo may have attrophied as I have not kept up with head on the static hermes branch.

And finally the community thread: How to try Static Hermes · facebook/hermes · Discussion #1137 · GitHub

Initial typescript support is there but needs a little improvement.

C# seems like a more stable and complete implementation, and the ex-unity crowd is a welcome addition for sure.

When the APIs stablize for an additional community scripting language support, I would be happy to take a crack at bringing Typescript/Javascript along for the ride. Static Hermes essentially has a zero cost FFI, and I imagine the work required to get C# working and marshalling over a C ABI would allow me to quickly implement the static hermes bindings / support.

[britzl]

@thejustinwalsh

When the APIs stablize for an additional community scripting language support, I would be happy to take a crack at bringing Typescript/Javascript along for the ride.

This is what we hope will happen too! The idea is to make it easier for others to create their own language bindings in a more integrated way.

[bob_dev]

C# sounds great to me. I would want to use it WITH Lua, is that possible? I like tools for jobs.

[britzl]

@bob_dev

I would want to use it WITH Lua, is that possible?

Yes, it will be possible to use both at one, but obviously not in the same script.

[horatiohafnaugels]

Great news about C#!

To be honest, being able to use languages like Teal or Luau woluld have fitted the bill as well for me, but C# is even better.

In fact, I came back to the forums after reading about Teal support in 1.8.1 beta…just to learn it’s only the tip of the iceberg!

My only gripe is that all this is coming a bit late, maybe? I mean, provided you had the manpower, why did you wait for Riccitiello’s false move? I’m pretty sure there were many Unity/XNA users looking at Defold with interest in the past few years, only held back by the lack of C# support.

Anyway, better late than never. Keep up the good work and let’s spread the word!

[britzl]

@horatiohafnaugels

My only gripe is that all this is coming a bit late, maybe? I mean, provided you had the manpower, why did you wait for Riccitiello’s false move? I’m pretty sure there were many Unity/XNA users looking at Defold with interest in the past few years, only held back by the lack of C# support.

Sure. You might say that about the improved 3D support as well. Or the lack of console support. Did it arrive late? Yes, probably, but it was the best we could do with the team we had at that time. Was all of the other things we worked on useless? Probably not. There are many “what ifs” but there’s little point to dwell upon decisions made in the past. The decisions made sense at the time.

[bob_dev]

Regarding Lua, I can keep using it (I am nothing if not adaptable) but if C# ends up having faster execution than Lua, then it is an actual game-changer beyond just a preference for scripting.

As you move toward 3D you will find the extra horsepower starts to make sense. 3D has always been far more computationally expensive, especially at the scripting level. More of everything is required: math, AI, queries, optimisation, etc etc

It’s very likely Lua will be the bottleneck.

[Mathias_Westerdahl]

@bob_dev

3D has always been far more computationally expensive, especially at the scripting level.

Not sure what you would expect to do here though?
In our minds, scripting is for controlling the flow of the engine, not to do large data processing.
That’s what the C++ part of our engine is for.

E.g. all our 3D loading, processing, culling and rendering is already done in C++, and Lua is helping controlling the flow of the game (loading, unloading, messages etc).

I would not expect you to do much of that 3D processing in your native code anyways, as we have most of that as part of the engine. Is there anything in particular you are looking for?

You could create models procedurally, perhaps that’s what you’re after?
You can already create buffers in C++ and pass those handles to our resource system (currently via Lua).
E.g. like a terrain system. Is that what you are talking about?

Or are you just after performance in heavy calculations (like an a path finding algorithm)?
Again, there are assets that do that, and send the result back to Lua, so that the developer can act upon it.
I don’t (yet) see Lua itself as the bottleneck.

My gut feeling, is that scripting in Lua (or Teal), will still be so much more convenient than creating your own support structures around our native sdk’s. You get a lot for free using our scripting layer. If you are using the native sdk, you’d have to write those things on top of the sdk.

[mikatuo]

Exiting news about C# with AOT! It will be definitely the most innovative C# support in game dev.
Thanks!

[britzl]

@mikatuo

It will be definitely the most innovative C# support in game dev.

Don’t get too excited It will be useful for those developers that have a lot of reusable C# library code that they don’t want to let go of, but it will not really be innovative in any way.

[mikatuo]

Yeah yeah yeah, innovative in a sense that it won’t require embedding a C# runtime. No other game engine has that?

As far as usability goes I think it would be nice to try using C# instead of C++.

[dlannan]

My two cents (also presented elsewhere). Providing capability also means providing documentation, then wider API access and so on. The problem with Unity devs and other people skilled in other engines coming to Defold means they want the same capability in the engine. Language isnt really the issue, its the platform people use to garner support to end up with a large group trying to sway opinion - this is exactly what happened with Unitys own script and JS back when they had three.

The engine and maintenance requirements for that is enormous as the engine grows. Its not so bad when things are smaller and relatively simple. Then the larger groups end up moving the dev (sure to market and business considerations) and you ended up with Unity3D with C# using Mono.

Then, and imho this is the actual problem coming down the track, if you need to support C# it is not the language that matters, its how easily Unity people can jump in and use it in the same way they are skilled with (from Unity) meaning, you will have to implement features that are more aligned with the Unity engine that is accessible in C#. This might not seem important if the focus is on Lua and C++, but managing expectations means that the engine will expand to cater for the C# additions and thus impact how the engine works for its original languages. Again if you worked back when Unity3D first started, you will recognize this problem and resulting impact.

These are slow moving group and system design issues that are 5->10yr development cycles and they are often business driven and not technical driven. I remember talking with Unity devs in the early days and they did not want to go the C# and JS route because of the runtime nightmares and engine interface nightmares. With a large body of people skilled in Unity that will influence what happens to Defold if the business and economics line up for it to do so.

For me. Im very wary of this. I work in industries where software stability is extremely important. And we have models and sims in defense that are in excess of 30 years old, written in languages like Ada. These systems dont get changed because the development cost, maintenance and security cost is far too high to do so.

I personally see Luajit as one of the most stable, flexible, performant and long term solutions that has already stood the test of many industries and thus makes an excellent choice for the businesses I work with. But, I understand the game business is very different, and so there was always a risk that Defold may have changes and mutations that might impact this potential.

The need to support multiple languages I dont believe is actually necessary. Thats my own opinion. After building systems for companys with Go, Rust and other newer languages theres is a clear over zealous need for people to use modern lang X over the sensibility of just getting the work done. Entire industries have been created for language bases alone, and they need this propagation to survive (people always forget the vast amount of languages that come and go).

I personally like how Defold is sticking with Lua and C++ - these are good long-term strategies that have already stood the test of time. No-one can claim Go, Rust, Odin, Zig etc will be around in the next 10 yrs, thus committing to them is not a good idea for an engine with a long lifespan. C#, I think is a more problematic one, and I suspect its influence will change Defold (I dont see how it wont) and this is my current concern for the work I want to keep developing.

Sorry about the rant. Its a topic that is both complicated and often for many people emotional, because they often dont look at the history or the engineering needs and just at the evangelism behind a specific languages marketing. There are ways forward with Defold atm, and for the time being it will still be my go to system to dev with.

[britzl]

@dlannan

I personally like how Defold is sticking with Lua and C++ - these are good long-term strategies that have already stood the test of time

We will not budge on this. Lua will be the main language for game logic in Defold. And the engine will be written in C-like C++. This will not change. I’d rather die on that hill than change to whatever is the latest fancy language.

This is also the reason why we do not plan to let C# anywhere near the core of the engine. We will use our low level dmSDK as the public facing API of the engine to which other compiled language can hook in. By dmSDK I mean all of the dmFoobar named C++ APIs that you find here: API reference (dmGameObject)

@dlannan

if you need to support C# it is not the language that matters, its how easily Unity people can jump in and use it in the same way they are skilled with (from Unity) meaning, you will have to implement features that are more aligned with the Unity engine that is accessible in C#. This might not seem important if the focus is on Lua and C++, but managing expectations means that the engine will expand to cater for the C# additions and thus impact how the engine works for its original languages

@JCash is making some changes to the existing dmSDK API functions so that we can expose more of our private headers and let developers write entire games using C++. It is, and it will remain, a low level API and not at all like the much more high level Lua API. It will not be very convenient to write your game entirely in C++, and if you do, you’ll likely want to add your own “high level” API on top of it.

The same goes for C#. It will not be an API which a Unity developer feels right at home with. It would be a huge undertaking and we do not wish to maintain another high level C# API next to the Lua API. It is simply not within the scope of the task of providing C# support*. BUT it doesn’t mean that someone else couldn’t do it. It could be a community driven effort to create such as high level API in an extension.

* = Remember that we are talking about low level C# support with an API that maps to the existing Defold C++ API. We have never said that we will add Unity Scripting API support.

[Mathias_Westerdahl]

@mikatuo

Yeah yeah yeah, innovative in a sense that it won’t require embedding a C# runtime. No other game engine has that?

Well, to use C#, we still need to link against the C# runtime libraries. And while I don’t have an exact number on how much they’ll “weigh in”, on macOS, they’re ca 4mb (but the result may be smaller than that, as their macOS builds have a bug).
Real question is how their size will fare on HTML5.

@dlannan

if you need to support C# it is not the language that matters, its how easily Unity people can jump in and use it in the same way they are skilled with (from Unity) meaning, you will have to implement features that are more aligned with the Unity engine that is accessible in C#.

I don’t think so. Our engine works a certain way, and that won’t change. If they do have ideas to improve things, sure, we’ll consider it, just as we do from all newcomers that have experience/workflows from elsewhere. But still, we’ll keep our own look and feel to the engine.

@dlannan

The need to support multiple languages I dont believe is actually necessary.

I think extra languages is a bit necessary, as we’ve seen studios pass on Defold due to lack of full C++ support, or C# support. If we can get a bit closer to their target, with minimal effort, then I think it’s worth a try. The goal is to attract more developers to our engine.

We’ll support a few languages. C/C++ will always be the core language, and C# is merely there for studios that have large codebases that migrate to our engine.

Keyword here is minimal effort. We will only really maintain our C/C++ sdk. The rest of the languages are bindings generated from the sdk. Otherwise the burden would escalate too quickly.

I hope this helps dampen any worries you might have that we’ll stray too far from our vision.

[bob_dev]

@britzl

I’d rather die on that hill than change to whatever is the latest fancy language.

So long as Typed Lua is a real thing and promoted front and center I see no reason why developers wouldn’t start migrating to defold.

In fact I know a developer who works on a specific top 1 app on Appstore swear blind that he’d never touch defold. But what happened is you added Teal support and he turned right round and is using defold. So Teal is a much bigger deal.