After all, our development consoles (which the PC debugger connected to) worked just as well on a cartridge from the store as on the code we uploaded to it. So if you were impressed by an effect in a game like Ranger-X, you just plugged it in and explored it in the debugger for a while. You'd end up with a new technique and (quite possibly) a snippet of code you could try out on your project. Happened all the time.
Now, I don't think anyone really undertook an effort such as this to lovingly decompile a game with comments on this level, but there were decompilers too. I was always suspicious that our studio's highly sophisticated platformer engine was based on lots of, uh, best practices. If you know what I mean. But that wasn't a big deal.
It's interesting because when I later heard about the tech behind the Halo engine, I realized I'd never seen their architecture before — because things had moved on and gentlemen of game development didn't decompile each other's games. They licensed their engines instead. If this had been the cartridge age, lots of people would have totally lifted their approach.
By the way, the talk I heard, a detailed overview of how the Halo 2 engine works, is available at the page below. Yeah, it's from seven years ago but it was a ten-year-old engine already. Good code design lasts. If you like game guts, this page is a little-known treasure.
That's how much RAM there was. That's 128 bytes. The entire in-memory program state was one eighth of a kilobyte. Then imagine everything else was limited like this. It's hard to understand how challenging it was to get a coherent game out of this thing.
Someone who was really inspired by "Racing the Beam" to try 2600 programming recently was Xbox daddy Ed Fries. Here's him talking about what he made:
Yes, it's a loving rendition of Halo on the 2600 platform! You can even play it now online:
Gamedev these days is so easy in comparison.
- There is no hardware abstraction layer. There is one hardware target, you know exactly how it works, and you can use/abuse it any way you like. And all the hardware is designed together for the sole purpose of making games.
- There is no I/O. All your code and data is just mapped into memory from a ROM pack. You have to swap memory banks in and out, but you can layout the banks explicitly. You typically do one level per bank and just swap banks to change levels.
- There is no memory management. RAM is all yours. You just layout your dynamic data explicitly, or let the assembler do it, or some combination of the two.
- There are no data types or undefined language behavior. Just n-bit registers and instructions. Need to use 12.4 fixed point math? Or pack a flag in the high bit of a pointer? No problem, just write some assembler macros.
Of course, in exchange for control, you have to give up some power. Maximum 16k of code, can only write to video memory between rescans, no divide instruction.. that kind of thing. But better the devil you know. It's a lot more fun solving "how can I do this with what I have?" than "what the hell is going on?"
-You think you know how it works. But lots of little hardware quirks will still bite you in the ass.
-This means that all your data has to fit in your code space, so you either trim code or you trim data.
-Generally you wouldn't do dynamic data at all, ever, so instead you were stuck constantly balancing and tweaking constant arrays of data and balancing them against everything else in the world. Do I allow 3 entries for explosion effects? Or 5? Am I willing to have one less enemy on screen for those extra effects?
-There's also often very few registers and an extremely limited stack.
I mean, I'm not saying you are wrong, and from certain angles sure it's easier to write in 8 bit assembler vs modern day high level languages. But there's also things to consider that happen above the language. What happens when there's a bug in some code and you have to hand it to a programmer who isn't familiar with that code? What happens when two subroutines are too far away from each other to jump? What happens when you get graphic corruption bugs and don't have the modern conveniences of data breakpoints and other tools?
Modern games hardware is SO much more complicated, modern games are SO much more complicated.
Where I would agree is that writing game on the Amiga in C++ would be easier but that's not game dev these days.
This also indulges the fallacy that the hard part of game development is writing low level graphics routines. That can be difficult to learn but once you know it its relatively straight forward. People don't judge your game on the quality of your sprite drawing functions (unless they're extremely buggy :)).
Today is simply impossible for a single person/small team to create a rival to Call of Duty 4 or Fallout 3, while back then it was relatively simple for someone with the skills and talent to emerge.
More so, they prove (again) that the technology arms race in today's video games is utterly retarded. It's also the reason many indie games tend to be so good and refreshing - they can't make a hitech ultra-HD game, so they focus on what really matters: gameplay and design.
I love good code & elegant design, but it doesen't beat having a successful product out there.
Remember, shipping is a feature ;)
Remember, usability is a feature. >:3
Everything that came out of Williams/Midway for example (From Defender all the way to Mortal Kombat, NBA Jam, Crusin', basically everything not on PC-based hardware) were all completely done in assembly. Wrap your noggin around that one.
And...weren't some of the most popular SNES games ports of popular arcade titles?
Yes! Street Fighter II (and sequels). The Mortal Kombat series. These were HUGE when they arrived on the SNES. I still remember how amazing it was when SF2 came out.
I should've looked at Wikipedia first, it answered part of my question.
"The first Mortal Kombat game was 4 guys, literally, one programmer, myself (Boon), two graphics guys (Tobias and Vogel), and a sound guy (Forden) was the entire team, literally"
Many teams would carry a core "operating system" (really a library of system routines/process scheduler/IO/audits) from game to game and build off of that. That left more time to write the game mechanics and choreography.
The team switched from digitized actors to motion capture technology (the quote is incorrectly referring to Midway as Acclaim): "To make the characters in video games more realistic, actors are being recruited to serve as models. Acclaim, the video-game company that made Mortal Kombat, has created a special 'motion capture studio' for this purpose. A martial-arts expert with as many as 100 electronic sensors taped to his body sends precise readings to a camera as he goes through his moves—running, jumping, kicking, punching. The action is captured, digitized and synthesized into a 'naked' wire-frame model stored in a computer. Those models can then be 'dressed' with clothing, facial expressions and other characteristics by means of a computer technique called texture mapping.
There were other 2D fighting games around that time that used video capture (remember Atari Pit Fighter?) but MK avoided the sprite scaling and kept it flat.
Not that that wouldn't make this presentation here an impressive feat.
I suppose it's possible that some crazy developer wrote their own C compiler back in the day, but if that ever happened I didn't hear about it. And I was trained by people who worked for Nintendo.
It's rather interesting how Sony went from starting with a system that was considered easy to develop for, to having the most complex product on the market--twice in a row!
IMO, Legend of Zelda source would probably look similar. But by that time, Nintendo of America started support for battery based save states, so someone more experienced in NES hardware might want to compare and contrast the two codes bases to see how much Disk System code was salvageable for battery based backup purposes.
The map is super clever. The whole game map is 1Kb of memory (MetroidTilePage.txt:line 4658). A 2d array and each byte has the ID of a room sprite.
So that's why all rooms were the same :)
Thanks for that, made me smile & shake my head at the same time :)
You clearly put a lot of work into this, dude. I gotta shake your hand, let me see, uh... Dirty McDingus?
You know what, on second thought I'll just post a comment on HN. But, uh, thanks. We're cool, though. I'll just be over here.
I can appreciate how much effort has gone into this project. For years, I've been working on disassembling and commenting the Sonic 2 Master System engine (https://www.sonicretro.org/asm_svn/Sonic%202%20SMS%20Disasse...) and it's still only about 80% complete.
The doc in question is All.log++. There's a lot of really cool information spread across that site, though.
L8DDE: LDA NARPASSWORD ;
L8DE1: BNE ++ ;If invincible Samus already active, branch.
L8DE3: LDY #$0F ;
L8DE5:* LDA PasswordChar00,Y ;
L8DE8: CMP NARPASSWORDTbl,Y ;If NARPASSWORD was entered at the-->
L8DEB: BNE + ;password screen, activate invincible-->
L8DED: DEY ;Samus, else continue to process password.