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.
Karateka is different, as it's about writing a game in your spare time (really simplifying things). You realize how much time he spent writing it, how often he would be close to finishing, only to have a lot more work to do.
Thanks, I'll give it a go. I think I got the Karateka book in some bundle that was on sale recently. The only reason I didn't jump on it yet was because I'm not/wasn't familiar with the game.
I don't have the physical one, but I can't imagine what I could be missing out. If anything, you can keep reading it on your phone if you don't have your e-book with you etc.
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).
Ok, that is the craziest (in a good way) thing I've seen in some time. I'd have thought PoP had been ported to the C64 at the time - Karateka was ported just about everything. So in 2011, starting with the Apple source, disassembly dumps, graphics from a free version, looking at the PC port and god knows what else, someone ported it to the C64. Amazing.
EDIT: Oh, and apparently the Apple ][ source hadn't been found again yet, making the thing even more bonkers. Mechner's comments here:
If I remember correctly, the ported game does need a memory extension, which would've been a no-go back then. Wonder how much you would have to cripple the ported effort to fit in in there, if at all possible with the same approach...
Yep, it looks like it requires a 128KB Apple //e and up. In the comments of the blog, Mechner mentions he couldn't get anyone interested in porting it to the C64 at the time as the system was considered too old. I guess by '89, 128 KB Commodores weren't considered that interesting of a market.
The original must have needed all the memory it could get its hands on - looks like it doesn't use the Apple //'s 'double high res' modes, for instance.
Forum thread of Sanglard trying to sort the thing out, with the help of some 6502-heads is also entertaining:
Almost makes you want to combine the two actually hacker-ish posts of the last two days - the lightweight block ciphers and this and burn a weekend implementing SIMON in 6502 assembly. Almost.
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.
http://www.amazon.com/Making-Prince-Persia-Journals-1985/dp/...
http://www.amazon.com/The-Making-Karateka-Journals-1982-1985...