Just for reference, these are two books that were from the journal of Jordan Mechner written while writing Prince of Persia and Karateka. They are enjoyable reads, and I highly recommend them.
I started reading "Making of Prince of Persia" recently and it is amazingly inspiring because it captures his real thoughts as he was making it, unlike autobiographies where hindsight distorts things, no matter how real the author wants it to be. I second the recommendation.
I really enjoyed the Prince of Persia one. It's relatively lacking (though not totally) in terms of the coding side of things but there's a really good story and sense of what it took to push a complete game out of the door at the time.
I love reading Sanglard's stuff I hope he's encouraged by the comments on his site to complete this - the bulk of it so far is on details of the Apple ][ architecture. It'd be great if he decides to take apart the actual game, although even with commented assembly source, it's no trivial amount of work.
The C64 reverse engineering covers that a bit. At least regarding general data structures, as opposed to in-depth Apple II hackery (you get some C64 hackery instead, of course).
Love how most games were mainly a one man show back in the 80s. Jordan Mechner, John Carmack could be used as aliases for the games. Btw, I read a very similar article about Doom / sometime ago about the Magical Square Root Implementation In Quake III, another interesting read[1]
Carmack's famous games were not developed solo - he developed the breakthrough enabling technology that made the game possible - full-screen sidescrolling on a PC, 3D stuff, etc.
Mechner's games stand out in part because he seems to have done just about everything himself and, especially for the time all the parts are outstanding - the design, the artwork, the 'art direction', the animation, the gameplay. And then he went off and churned them out in 6502 assembly.
Another World by Eric Chahi, also reviewed by Sanglard [1] is a great example too. I love how he made all the game engine fits in only 20 KB, with the bulk of the game written in opcodes, interpreted by a VM. That made it very easy to port the game to any platform since there was only 20 KB to convert.
Very early 80's maybe, but even a couple of years in most popular games had teams working on them, though not very large ones.
A lot of musicians doing game-music for the Commodore 64, for example, were popular enough in their own right that sometimes publishers would hire them knowing their names would be sufficient to guarantee sales for otherwise mediocre titles. Some of them even perform their 80's game music live today, and there's a whole scene doing remixes of the music.
Cool. In the comments from that post, there's another article that traces that inverse square root implementation back even further - almost 20 years back at this point:
Having written a VT100 terminal emulator in 6502 assembly back in those days I remember it well. But games had to be more clever as the memory was so tight. At least in my case the only fun part was showing 80 columns of data on a 40 column screen (if the user had no 80 column video card). Today we can focus much more on just writing code instead of engaging in daily hackery.
This is a great walkthrough, and a real trip back to the good old days. I learned programming on the Apple ][ and, like many started in Basic then moved to 6502 assembly.
I am not sure how other teenagers made this awkward transition, but I did it by writing a tiny assembler in Basic. It was fairly easy because Basic had PEEK (get contents of address), POKE (set contents) and CALL (jump to address) that everyone was used to using to get anything useful done. I think I just got tired of hand assembling programs into POKE calls.
I remember getting a thin wire-bound book with a detailed disassembly (with comments!) of the ROMs and DOS as a birthday present. I think one of the thing that inspired programmers on the Apple ][ was the amazing system code that Woz had written. He set a very high bar for assembly language programmers. His code was economical, fast, smart, and tiny. He demonstrated how to squeeze the most out of limited resources.
I learned to program 6502 on the BBC Micro. It had a built-in assembler as part of its BASIC. Very useful! Assembly language instructions got written to memory according to the value of a specific variable, and there was a somewhat neat mechanism for doing 2 passes (to fix up forward references). It was quite flexible, and gave you all the power of the inbuilt BASIC - which was of course awful, though excellent by the standards of the day - for writing macros.
More programming languages should have included something like this, I think. Maybe by now we'd have runtime code generation as a common primitive, something like LuaJIT's dynasm (http://luajit.org/dynasm.html), only with GC, so you could generate custom little routines at runtime.
(As it is, what do we get? gcc-style inline assembly language. Progress? My arse.)
I see mentioned that the PC port did not go very well. I've never played PoP on my Apple ][, only the DOS port. Am I missing something by only having played the PC version?
(Maybe Color? I don't remember if it was B&W because of my VGA card or because the PC version just didn't have color.)
The PC version had color. It was my first version as well, and to me is the definitive port. I didn't like the cartoony Macintosh version that became the standard for all the 16 bit ports. The new art muted the fluid animations IMO.
[+] [-] jasonlotito|12 years ago|reply
http://www.amazon.com/Making-Prince-Persia-Journals-1985/dp/...
http://www.amazon.com/The-Making-Karateka-Journals-1982-1985...
[+] [-] kirubakaran|12 years ago|reply
[+] [-] petercooper|12 years ago|reply
[+] [-] VikingCoder|12 years ago|reply
[+] [-] wslh|12 years ago|reply
[+] [-] glurgh|12 years ago|reply
[+] [-] mhd|12 years ago|reply
http://popc64.blogspot.com
[+] [-] superasn|12 years ago|reply
[1] http://www.codemaestro.com/reviews/9
[+] [-] glurgh|12 years ago|reply
Mechner's games stand out in part because he seems to have done just about everything himself and, especially for the time all the parts are outstanding - the design, the artwork, the 'art direction', the animation, the gameplay. And then he went off and churned them out in 6502 assembly.
[+] [-] laurent123456|12 years ago|reply
[1] http://fabiensanglard.net/anotherWorld_code_review/index.php
[+] [-] vidarh|12 years ago|reply
A lot of musicians doing game-music for the Commodore 64, for example, were popular enough in their own right that sometimes publishers would hire them knowing their names would be sufficient to guarantee sales for otherwise mediocre titles. Some of them even perform their 80's game music live today, and there's a whole scene doing remixes of the music.
[+] [-] jmileham|12 years ago|reply
http://www.beyond3d.com/content/articles/8/
[+] [-] goostavos|12 years ago|reply
[+] [-] coldcode|12 years ago|reply
[+] [-] t1m|12 years ago|reply
I am not sure how other teenagers made this awkward transition, but I did it by writing a tiny assembler in Basic. It was fairly easy because Basic had PEEK (get contents of address), POKE (set contents) and CALL (jump to address) that everyone was used to using to get anything useful done. I think I just got tired of hand assembling programs into POKE calls.
I remember getting a thin wire-bound book with a detailed disassembly (with comments!) of the ROMs and DOS as a birthday present. I think one of the thing that inspired programmers on the Apple ][ was the amazing system code that Woz had written. He set a very high bar for assembly language programmers. His code was economical, fast, smart, and tiny. He demonstrated how to squeeze the most out of limited resources.
[+] [-] to3m|12 years ago|reply
More programming languages should have included something like this, I think. Maybe by now we'd have runtime code generation as a common primitive, something like LuaJIT's dynasm (http://luajit.org/dynasm.html), only with GC, so you could generate custom little routines at runtime.
(As it is, what do we get? gcc-style inline assembly language. Progress? My arse.)
[+] [-] uxp100|12 years ago|reply
(Maybe Color? I don't remember if it was B&W because of my VGA card or because the PC version just didn't have color.)
[+] [-] nsxwolf|12 years ago|reply
[+] [-] rpicard|12 years ago|reply
[+] [-] StacyC|12 years ago|reply