Hi, author here. It is indeed a niche thing. But there are some use cases:
* Sandbox for code you don't fully trust (e.g. download the bytecode from a web server)
* Mods for small hobby game engines
* There are many virtual machines, but not many are so small, with strong typing and no garbage collector
* Learn about virtual machines in general, but directly have a C compiler available for the virtual machine
* Sandbox for embedded applications, e.g. plug-ins for IoT applications on microcontrollers (bounded CPU time, bounded memory area, restrict access to peripheral devices)
* There is also a historical value: learn about the Quake III engine
This is incorrect. Wikipedia specifies C’s typing discipline as “static, weak, manifest, nominal”, which isn’t great, but is at least in the right ballpark. “Strong” and “weak” are unhelpfully overloaded words.
The main advantage for Quake 3 was that the server, client and UI code could be compiled into platform-independent bytecode modules. This was mostly a boon to mod creators, who had to build only one version of their mod that would work on all Windows, Mac and Linux systems alike.
I thought I heard this was also a boon for the scenario creators and level builders working alongside the graphics engineeers.
They get something a little less hairy and volatile to work with, and execution speed isn’t that critical because you’re only making hundreds or thousands of decisions per second.
Speculation: Assuming the VM has no bugs it is sandboxed. The code run can't access the file system or freely allocate memory. Thus code from less trusted sources can be executed. (Another comment indicates that the VM has a history of bugs, so it might not be advisable, but I have no experience with it)
All of the code for the UI, server-side game logic, and client-side game logic in Quake 3 was run in the VM. It allowed code to be stored with game data, and client-side mods to be safely downloaded directly from the game server.
The link in the sibling post has most everything you'd ever want to know about it.
It might be worth mentioning that there’s a long tradition of this pattern in game design. In quite a few cases, much of the game logic is separated from the graphics engine, in a simpler language with an interpreter.
In the case of world of Warcraft, the Lua interpreter allowed for a rich ecosystem of UI (and light behavioral) addons. In some cases very popular addons features were added into the core UI in later updates.
I find that arrangement pretty compelling. In the few cases where I’ve worked on or with a team with addon support I bring this up: use the community sourced features as a popular vote for what to incorporate (just be sure to reward the author somehow).
* Sandbox for code you don't fully trust (e.g. download the bytecode from a web server)
* Mods for small hobby game engines
* There are many virtual machines, but not many are so small, with strong typing and no garbage collector
* Learn about virtual machines in general, but directly have a C compiler available for the virtual machine
* Sandbox for embedded applications, e.g. plug-ins for IoT applications on microcontrollers (bounded CPU time, bounded memory area, restrict access to peripheral devices)
* There is also a historical value: learn about the Quake III engine