Hacker News Reader

Comment by wyldfire | Hacker News Reader

Great article. And what a great game! I bought it recently on steam and tried it. I must have had significantly more time to play games in my youth because I just could not make it terribly far (just a bit beyond the part where you find the chamber to re-energize the pistol). Still, it was a great game.

I never knew it used a VM. Sounds remarkably uncommon for games at the time.

View on HN

It wasn't that uncommon - most of popular adventure games (and probably others too, but I just happen to know about this genre) worked as VMs or interpreters (SCUMM, AGI, SCI). Helped a lot with portability, which was desirable at that time when games were being released on various platforms like IBM PC, Apple, Amiga, Atari, Commodore 64, NES...

And thanks to that we have ScummVM now.

Infocom's Z-Machine used for text adventures is another good example.

Even lots of BASICs, like Applesoft, were technically VMs with bytecode and even garbage collection. Not a retargetable VM, mind you.

I don't know about Apple's, but Microsofts BASIC was stored tokenized. I'd argue calling that "bytecode" would be stretching things a bit in that there was a direct 1-1 mapping between what was stored and the "raw" source format, because what was shown when you type "LIST" on e.g. the C64 was an expansion of the tokenized source.

Personally at least I'd expect "bytecode" to usually refer to a more complicated and usually "lossy" remapping of instructions (e.g. at the very least throwing away comments and trimming identifiers (Microsoft BASIC only looked at the first few letters of an identifier to identify a variable, but stored the rest as part of the source)).

I know that the conversation system in the Ultima Underworld games used bytecode in a stack-based VM. I've read that the original code was in Forth (or something similar) before being compiled into game-compatible bytecode.

Reply on news.ycombinator.com