"Another World" (game) Code Review(fabiensanglard.net)
fabiensanglard.net
"Another World" (game) Code Review
http://fabiensanglard.net/anotherWorld_code_review/index.php
23 comments
Thanks for posting these!
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.
http://www.anotherworld.fr/anotherworld_uk/another_world.htm
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!
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.
http://www.anotherworld.fr/anotherworld_uk/another_world.htm
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.
If anyone is interested, here is some gameplay footage... http://www.youtube.com/watch?v=Zgkf6wooDmw
If anyone is interested, here is some gameplay footage... http://www.youtube.com/watch?v=Zgkf6wooDmw
I was pretty surprised to see it used it's own vm when I was rummaging through Gil Megidish's port to JavaScript - http://www.megidish.net/awjs/
There are a few huge base64 encoded data files, and the rest is just the bytecode, and converting the drawing functions to canvas.
I was surprised that "back in the day" you could take the hit of a vm - I always thought you had to get as close to the metal as possible!
There are a few huge base64 encoded data files, and the rest is just the bytecode, and converting the drawing functions to canvas.
I was surprised that "back in the day" you could take the hit of a vm - I always thought you had to get as close to the metal as possible!
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.
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.
Another interesting case is Quake 3 which used a hand-written stack based VM. They don't introduce much of a performance hit when used wisely.
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.
The Links golf game rendered the same way:
http://www.youtube.com/watch?v=aSBojv19gU8
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.
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.
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:
http://web.archive.org/web/20070124142934/cyxdown.free.fr/ra...
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:
http://newraw.svn.sourceforge.net
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).
edit: corrected a link
http://web.archive.org/web/20070124142934/cyxdown.free.fr/ra...
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:
http://newraw.svn.sourceforge.net
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).
edit: corrected a link
The introduction (resource 0x1C), 3 minutes long weights only 57,510 bytes once compressed
Truly humbling - a 3 minute intro in 56kb.
Truly humbling - a 3 minute intro in 56kb.
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.
Me too with the color palette - I figured it out today though! I'll write it up on my blog after xmas.
I put up the "part one" here: http://www.mrspeaker.net/2011/12/30/colorising-sprites-in-ca...
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?
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.
I don't know for sure but maybe Hex Rays ?
http://www.hex-rays.com/products/decompiler/index.shtml
http://www.hex-rays.com/products/decompiler/index.shtml
If you find out something that works well today, I'd like to reverse a binary I created 15 years ago. Let me know!
Thanks so much. I actually went on an OOTW tech info binge a couple years ago. I wish I had found this at the time!
Is there a "Symbia OS" or the author is talking about Symbian?
[deleted]
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)