I don't know about the entire script. The game and game engine has tens of thousands of lines of code that is not script. But, I feel like it opens creative doors to be able to make (lets just say) a magnitude more calls into the virtual machine compared to other options. That's not to say that I am done with this research I am doing. The idea is to be able enter and leave the script as fast as possible, while also call back into the game engine as fast as possible. Once this is achieved, game logic that once had to rely on finite options can have script callbacks. Also the game will be naturally moddable from the start.

Here is an outtake from one of my game scripts: https://gist.github.com/fwsGonzo/d9116c46e5b7f8ed4743ab15f89...

While it may not look like it, flow.cpp calls back into the game engine in a surprising amount of places. It's also something that regularly gets called 10k times per simulation step if there is a cave under the water, for example.

For me right now, I feel like I have reached a sweet spot where I would no longer consider going back. Also, it's a fun project! Sometimes I am wondering if I am enjoying making the game engine more than the game. Oh well.

Might as well tack on to this that you can also choose your language. I have emulated Go, Rust and Nim pretty successfully. Enough to know that they would be a possible choice for emulation. Go is perhaps weird in that you want to avoid the C API (cgo) and just figure out the assembly instead, but that could also lock you to a Go version.

Let me just add that perhaps we can sandbox python too? LPython is on the frontpage now and if I read it right, it will compile to C and C++ when targeting AOT.

See: https://lpython.org/blog/2023/07/lpython-novel-fast-retarget...

You ought to meet and discuss your project with Arnaud Hervas, the original author of the Shake compositing software. Shake was a VFX industry compositor that used GCC C++ as the "scripting language" that non-developers wrote. It was not exposed as C, but macro modified to look simpler. Arnaud did several industry firsts, including using the GPU to render compositing layers back when all that type of work was in software. His company before Apple bought them was called Nothing Real, https://en.wikipedia.org/wiki/Nothing_Real He's a nice guy, so don't be intimidated.

Is performance really going to be a deciding factor for using this? I'd guess it depends what you really want in your "scripting" language. For me I'd want some sort of runtime with an easily readable language that can tolerate bad code, so in that case I would prefer something like lua.

Must admit though, things like this really make one think... what do people even want in a "scripting" language these days?

Probably depends how much of the game is implemented via "scripting", some games just put scripting at the edges (UI, data definition) while others do everything up from the game engine via "scripting" e.g. https://forums.unrealengine.com/t/ive-created-an-infinite-vo...

> The whole project s 100% blueprint with no C++ being used. I think this project is a great example for the power of blueprint.

And that's a post from 2016. These days you can probably create entire games via visual scripting (https://unity.com/features/unity-visual-scripting) as long as they're not too bespoke or demanding.

The example you use seems to be specifically a "because I can" project. We can't be sure (because the code isn't available, obviously), but I would highly doubt there are any AA or AAA games built entirely in the scripting engine. However, many 4X games get pretty close (Paradox series, Civilization, the Endless games, HoM&M, AoW, etc).

The limiting factor is not truly perf for visual scripting but everything around its ecosystem (diffing, architecture, spaghetti)