Live data from Hacker News

"Another World" (game) Code Review

fabiensanglard.net

11–20 of 24 posts

Re: "Another World" (game) Code Review

#12

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: 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 v…

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!

Re: "Another World" (game) Code Review

#13
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.

Re: "Another World" (game) Code Review

#14

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 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.

Re: "Another World" (game) Code Review

#15
post #8

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.

Re: "Another World" (game) Code Review

#16

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.

Re: "Another World" (game) Code Review

#17

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!

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.

Re: "Another World" (game) Code Review

#18

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!

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.
Post reply on HN