Will Defold support an official alternative language like Godot does?

Questions
#1

Godot has GDscript, which is a fine language, but they offer C# too.

What language would Defold support as official alternative language to Lua?

Personally I think Swift would be good hidden choice, it has no garbage collector, very high performance, open-source and quite easy to use, maybe chance to get Apple’s donation for it (as Godot got Microsoft’s donation for C#/.NET support). While they are at it, it might pull some new iOS/Mac devs into Defold world too.

Apple also has conflict with Epic, not that Defold has conflict with UnrealEngine, but who knows… maybe when Defold finish its 3D tools.

#2

Hi @Qws!

What we’re currently working on is support for creating a game in full C++ (for some studios that are more comfortable with that). In line with that we’re also looking into supporting C#.
Both are a slightly longer task, and it’s about both restructuring some of our internals functions, to make them “cleaner”, and also make them more useful from a scripting perspective.

This api cleanup, would essentially allow you to create your own scripting layer if you wanted to.

These efforts are done to help studios with larger codebases, to migrate to Defold.

Personally, I would still use Lua, as it’s very powerful in what it does, and instead use our plugin system to add extra functionality that needs that extra computation power.

But for the OP: “What language would Defold support as official alternative language to Lua?”

In don’t think we will support another “official” language.
We will continue to support our C/C++ sdk, and our Lua bindings, and eventually they’ll be flexible enough for users to add their own scripting language on top of it. But it’s not something we strive for.
Lua language is extremely versatile and very powerful. (e.g works on all platforms, even console)

14 Likes
Does exist plan to add Rust to native extention?
#3

This is extremely interesting! :star_struck:

1 Like
#4

Would there be advantages to using c#? Since I’ve started using Lua with defold I’m in love with
it. But if there are benefits to c# I can return to my former love. Lol.

#5

I think we should focus on making our engine standardized rather than supporting a new language. Godot supports C# but its tutorials, documentation, community are just around GDscript. It makes C# developers harder to work with and also makes it x2 harder for the Godot team to manage its documentation and tools.

Lua is nice, flexible, easy to learn. Go for only Lua! Thanks!

2 Likes
#6

No, not really. Is just a different language. If you have a lot of existing C# code it would mean that you might be able to use it.

1 Like
#7

The reason why we are looking into optional C# support is the fact that studios are moving from Unity in large numbers and we want some of them to consider Defold. One might argue that these studios could learn Lua, but it is unfortunately the case that a lot of developers dont want to learn a new (untyped) language. The studio may also have invested heavily in tooling and frameworks built around C#.

2 Likes
#8

Just my 5 cents regarding C#, not C++. By the time C# support is implemented (either by community or core team) would there be many studios left that wanted to migrate from Unity to a different engine and haven’t yet by then?

#9

I’d say yes probably, but how would anyone know? :slight_smile: All we know is that there is a huge interest in c#, and I doubt all studios will migrate over night, especially if they have projects in flight

2 Likes
#10

Yes. I had multiple meetings at GDC with studios that only very recently decided to look into Unity alternatives. I’m sure there are going to be more over the next 6 to 9 months that are considering the same. My guess regarding C# is that we have something for developers to try within 3 months. @JCash knows the timeline better than me though.

4 Likes
#11

Problem with C# is that you can easily decompile the whole project with tools like DotPeek, so people’s unique games and ideas can easily be replicated and resold on stuff like Game Engine’s Addon Stores or even on game stores, course with (minor) modifcations.

Swift is a low level language, syntax sugar for Object-C, so decompiling it is basically waste of time, as the decompiled result is incomprehensible.

Also, there are already too many C# game engines, Unity, Godot are biggest but there are more. I don’t think Defold being another one isn’t going to make Defold stand out from the rest of the C# using Game Engines. I just don’t think there is demand for another C# game engine.

There is Flutter Game Engine and a Rust Game Engine both open-source, they are rapidly gaining popularity, adding new big features. Last time I checked Flutter Game Engine it was 2D only, now they have showed a 3D preview.

Even C# Mono founder says that C# is a bad language for game dev, and that he regrets advocating/developing C# at Unity.

Now the man now works on SwiftGodot:

In video he calls C# in Unity a billion dollar mistake, the biggest mistake he made in his career, because the C# architecture brings unsolvable problems for game development, even Unity doesn’t have the money to fix C# flaws for its game engine. Defold following the same footstep is a mistake, only because “maybe” some C# devs will leave Unity or Godot.

1 Like
#12

You can decompile any game. Lua is not safer to use than C#. You need to take the necessary precautions to make it harder.

5 Likes
#13

But languages like C++, Rust, Swift are harder to decompile, as they output low level machine code and thus the result is practically unreadable. The reverse engineer may not even know what language it is was originally written.

#14

If that’s your concern, you can put your business logic inside a native extension already (i.e c/c++ code), so in that case it should be fine.

And just to clarify, we are not moving away from or replacing lua, it will still be our preferred script front-end going forward. What we are doing is cleaning up and improving the underlying API, which can then be used to build bindings for any language you want (in theory). We are getting requests from left to right for various languages, we cannot cater for everyones wishes. This is the path of least resistance for us :slight_smile:

6 Likes
#15

We are not following the same steps. We are not going C# all-in, and I would say that we are not going C# at all.

What we are doing is expanding our C/C++ API to make it possible to use the other languages to write game logic.
As example of usage of such C/C++ API we are taking C# just because this is the most requested language. But we are not going to introduce it as the main Defold language or something like that.
It will be up to our community to decide and develop support for whatever they want to use. On our side, we are going to provide everything to be able to do so.

8 Likes
#16

Harder is still not a guarantee.
Getting readable C++ code from a binary is absolutely doable.
Treat the code as unsafe in that regard, once it’s downloaded on the client’s system.

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.

1 Like
#17

This is a very good point. We’re going to use the latest version with AOT compilation and we have an active ongoing conversation with the right people at Microsoft (most recently at GDC a week ago) to ensure that we are integrating C# in the best possible way.

#18

I’m pretty sure there are more c# devs compared to swift devs. Making c# a viable option will only encourage more to come to defold. Many don’t want to lose their years of skills and code base so doing this just makes defold another viable option for the many c# coders out there.

3 Likes
#19

as much as I don’t like Lua (it reminds me too much of VBA with type unsafety, 1 based arrays and the inevitable resulting bugs) I see and appreciate its potential in performance, small footprint, small runtime.

I think you are doing the best thing, keeping LUA but expanding the api to make it easier to have bindings to other languages. :+1:

1 Like
#20

Let assume there are 100 C# developers and 10 Swift developers interested in game development.

Would Defold get 100 C# developers? Honestly how many stick to Unity or Godot?

But you’ll guaranteed get the 10 Swift developers.