I really do not understand game engine designers insistence on inventing a new language for their scripting needs. There are dozens of well built languages that can be used for simple scripting. Just pick one of those.
There are many engines that use existing languages, with Lua being one of the most common scripting languages used by games. However usually when an engine has its own scripting language it is because the existing languages wouldn't fit and/or the custom language can work better with the underlying engine.
For example if a game engine keeps track of asset references, scripts could be themselves assets like any textures, levels, materials, etc and have asset references as literals in the code that the script compiler understands, allowing automatic and precise extraction of asset dependencies the scripts (and the assets that refer to those scripts) can have. This is, e.g. what Blueprint does (BP is just a visual scripting language that uses a graph with a visual editor instead of parsing text to generate an AST but the same idea applies).
- Memory management that doesn't destroy frame times
- Easy to embed, ideally with a small runtime
- Can target whatever ISAs and OS's that the game runs on, like consoles.
There are not dozens of languages that fit these criteria, particularly memory management, embedding, and toolchain support for consoles when you're using a proper JIT compiler and not a bytecode interpreter.
When you are sidestepping the GC and have your object graph mostly in types built in the base language, Lua is no longer a pleasant language to use.
I think UE is a situation where writing a new language specifically for scripting it is absolutely the correct choice. The user base will be large enough to support it properly, and there are a lot of things that are a lot more ergonomic when the language will be built to support them after the base system is already built, instead of the other way around.
My guess is that existing scripting languages don't mesh well with all the parallelized staged simulation, entity content systems, and lack of tracing GC that game engines like Unreal tend to have.
I don't know much about Verse but looking at the preview I already see a type called a type called `<latent>` (async Promise?) and a `race` keyword (seems like a built-in `await Promise.all`?). I bet building these directly into the language fixes much impedance mismatch.
A similar but opposite argument could be made that every application's scripting language will necessarily be a DSL focused on that application, so might as well design a new language.
I suspect they could easily use an off the shelf language, or at least build a language that is a strict subset of one that allows for isomorphic code between that language (if targeting the subset first).
I strongly agree this is a superior approach to a custom language. Even better if the games industry standardized a single purpose fit scripting language
