If you're interested in the story behind the game's creation, Eric Chahi (the original programmer) gave a postmortem talk at the Game Developers' Conference a year or so ago:
From the second link I found a link to the author's homepage where he talks about the history of the game in depth. I was really impressed to find out this game was a one-man creation. The screenshots of his character editor shows the depth of his genius.
Such a great read. Some highlights include (spoilers!):
- he used rotoscoping of filmed footage for the car animation and a few others.
- he set up an infinite fax loop during negotiations with interplay regarding changing the music of one of the ports.
- when he wanted to clean up some of the animation scripting during a port to a mobile phone, he booted up his amiga and did the editing on it in the BASIC scripting editor!
I do consider myself to be a decent programmer, but things like this (being able to break down other people's s/w) always puts how little I know into perspective.
Seeing the background being drawn in slow-motion has quite a wow factor. At the time I assumed they were bitmap but did not know enough for the game size to raise a flag. The whole design of this game looks so clean.
Difference is that Link386 rendering was not exactly in real time. You'd have to way for the scene to render before you made your shot. Painful back in the day.
It wasn't too action action packed, see the number of title from that era and even before that used the SCUMM system. Running in a VM was SOP for point and click games.
There was a huge jump between the 8-bit and 16-bit hardware in particular - more memory to play with, faster CPU, and better graphics hardware all at once. (Of course, not all the platforms were equal, but the general trend was evident)
So while the 8-bit games generally needed micro-optimizations and completely unportable techniques just to do basic 2d rendering in real-time, the 16-bit generation and on often had some "room to waste" for those kinds of games.
When looking at the level of optimization needed, it's not really what the platform can do so much as combination of the platform + the desired kinds of processing. So Infocom was able to do a VM right from the start because their games were text-only(and later a few static pictures) while today's AAA games still have to do near-metal optimization because they set the explicit goal of pushing the hardware near to its limits, and even so they still manage to waste a lot since the overall project scope is larger.
Working in Flash in 2011, I am able to support a complete in-game editing toolset, via a popup console that contains a Lisp-like repl. The resources are there to do such things, and the amount of code needed to implement them is small, while the benefits are massive. It's a very different ball game.
I have not looked at this program, but it is possible that this is not a matter of 'could take the hit', but of 'had to take the hit'. CPU cycles weren't the only thing that was scarce in those days, and a application-specific VM could be what made this fit on a floppy or in 640k RAM.
There used to be an open source Another World interpreter available called RAW, created by a guy called Gregory Montoir, which eventually shut down the project at the request of Eric Chahi (the creator of Another World) around the time when the game became commercially available again. The original project page is still on archive.org:
Eventually another project cropped up called New Raw, which as far as I can gather was a fork of the then deceased RAW, but it didn't go anywhere. You can still download the source, however:
I remember dusting off my floppy copy of Another World years back and running it through RAW on Linux, it ran the game pretty flawlessly, with a bunch of added features like high resolution (the game is all vectors).
I love these kind of reviews. I wish someone would do a code review for some of the Ludum Dare entries. They only have 2 days to create a game so there are rarely comments. I was scratching my head at Notch's color palette code in "Minicraft" for a while for instance.
Seeing the background being drawn remind me of the Last Ninja on C64. Each screen started with the world being laid out using 2D sprites, in slow motion.
Anyone know if this was done for effect or if it actually was as fast as it could be?
It's usually just a sign of low optimization or polish when the background needs a visible rendering process before gameplay resumes. Most 8-bit games written in BASIC did this, and at a glacial rate. In assembly games it was usually fast enough to just be a minor artifact on transitions.
Anyone know what the "binary to C++" thing mentioned at the start of the article is? A quick google search shows nothing. i know Gregory Montoir is a programmer on ScummVM but thats it.
http://www.gdcvault.com/play/1014630/Classic-Game-Postmortem...
If you're unfamiliar with the game, there's an essay/review of it here:
http://www.actionbutton.net/?p=431
(press the "fist" button at the top-right of the page to cycle through a variety of ironically ugly colour schemes until you find one you like)