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).

There really aren't. You need:

- Fast to compile

- Fast to run

- 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.

Well, there is luajit at least (the GC isn't very performant, but people who care about this sidestep it). Maybe Chez or Gambit scheme as well.

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

NaughtyDog was able to do amazing things with their in house lisp GOAL[1]. I expect SPJ's work to be in a similar vein.

[1]: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

FWIW Blueprint is basically a scripting language, except instead of having you type something like "vector Foo = bar.GetPosition()" it has you create a "variable reference" block, a "variable assignment" block, a "GetPosition" block, a "reference to bar" block and then connect all of those blocks using "wires" alongside a wire that specifies execution flow.

But for all intents and purposes it is a scripting language - the blocks are even converted into an AST-like intermediate representation that is then either converted to a bytecode VM or is used to generate C++ (though the BP-to-C++ conversion generates very weird code since BP allows -conceptually- multiple things to run in parallel).

But the Blueprint "front end" can be replaced with another (text based) scripting language that generated the same IR and the rest would work the same. While i haven't seen UE3's source code so i can't be 100% certain, i'd bet that the IR and VM have their roots in UnrealScript - and chances are Verse is also targeting the same IR.

You are of course right, I should have phrased it in a different way.

Verse doesn't sound like it has to be a scripting language though, it sounds more like it's a high level simulation oriented language. Scripting languages nowadays have all the same constructs as typed languages, they just lack types. I would expect Verse to be a whole different kind of language, rather than just C++ without types.

You can see how it looks like on these screenshots, https://twitter.com/saji8k/status/1339709691564179464

Afaik it's not known yet whether verse is compiled or not.