[kevingadd]

Custom scripting language seems to be a common error - early on Unity emphasized a pseudo-custom scripting language (Boo) over C# and had to slowly extract it out of the product, documentation etc.

It makes sense as a risk management strategy early on in engine development, though, since integrating something like C# can be difficult and they may have been afraid that they would regret building around C# later on.

[danbolt]

Normally I'd agree with you, especially as someone that's embedded a scripting language into AAA games, but I think GDScript is the exception to the rule. Or, it's very tightly integrated with the engine's way of handling memory and it feels refreshing compared to a VM that has some bindings to native functions.

[krapp]

On the one hand, Undertale, Spelunky, Hotline Miami and other popular games have been made in GameMaker and GML is much, much worse than GDScript. At the end of the day, the player isn't going to care.

On the other hand, GDScript is not that great a language. No one would use it as a general purpose scripting language outside of Godot, it's like a more awkward wannabe Python without many of Python's useful features, and outright frustrating features like "pass" and funcref and not actually being able to type-hint signals.

To each their own, but I've never enjoyed using GDScript, which is unfortunate because the framework itself is amazing.

[bluefirebrand]

I do wonder if integrating C# is more effort than building and maintaining a language though.

But I do understand it. I just am not sure it's a good strategy for longterm growth.

[bluescrn]

Pushing people towards a non-standard scripting language is definitely not a strategy for long-term growth.

It needs a widely-known language with good performance and high quality debugging support (you can use the Visual Studio debugger with Unity C# or UE C++, for example)