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.