Isn't it the case that the approach of using a VM to do games goes way back .. in the early 80's it was a common mechanism in games dev, and the tradition has endured such that VM's are often pushed hard, technology-horizon wise, by the game devs.
One of the reasons Lua is all over the place, is its VM code is very well written and easy to integrate in a code-base.
There is still room for VM's to solve a lot of the current platform-war problems.
”the approach of using a VM to do games goes way back .. in the early 80's it was a common mechanism in games dev”
One reason that was done is that it made porting games between CPU architectures (OSes weren’t that much of an issue, as games ran on bare metal) easier.
Zork had one in 1979 (https://en.wikipedia.org/wiki/Z-machine). I think that ended when games became truly interactive, as opposed to command-based, because, when that happened, performance became a bottleneck.
Another reason could have been is that it made programming easier, as 8-bit CPUs are so weak that running a virtual machine for the convenience of having such luxuries as 16-bit arithmetic sometimes made sense even then (e.g. https://en.wikipedia.org/wiki/SWEET16)
And of course, there is Forth, the ultimate “give me a VM that is tailored to this specific program” language (every word you define can be seen as a new instruction for your virtual machine)
> I think that ended when games became truly interactive, as opposed to command-based, because, when that happened, performance became a bottleneck.
Counterexample: the recently posted article series about Another World - a VM-based game released in 1991 that was very interactive and graphics-heavy.
One of the reasons Lua is all over the place, is its VM code is very well written and easy to integrate in a code-base.
There is still room for VM's to solve a lot of the current platform-war problems.