I can see the benefit of typechecking the "script" code, though. The vulnerable parts are the "syscall" wrappers but they don't change all the time.
I can see the benefit of typechecking the "script" code, though. The vulnerable parts are the "syscall" wrappers but they don't change all the time.
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.
See: https://lpython.org/blog/2023/07/lpython-novel-fast-retarget...
Must admit though, things like this really make one think... what do people even want in a "scripting" language these days?
> 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.