

Metroid Source Code Expanded - rograndom
http://www.romhacking.net/documents/459/

======
zach
When I worked at Sega in the console era, I found out that every console game
was open to inspection by other developers in this way. Because they were all
in assembly, if you were ever curious about how a character moved or how a
graphics trick was done, well, you would just find out.

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.

<http://www.game-tech.com/Talks/Talks.htm>

------
Impossible
This is great stuff. When I was working on a platformer I'd read a lot of the
code for these classic games (Mario, Metroid, Sonic, Megaman, etc.) to see how
they did platforming and what the character physics tuning numbers looked
like. I've been meaning to do a series of articles that break down games,
focusing mostly on gameplay code, enemy behavior and physics. The only
comprehensive article I've found like this is the Pacman dossier
(<http://home.comcast.net/~jpittman2/pacman/pacmandossier.html>). Everything
else is random bits and pieces that can be pieced together, but would be nice
to have in one place.

~~~
jbermudes
Sonic Retro has a writeup of the physics behind Sonic 2. Check it out, it's
exactly what you're looking for and would be a good template to follow for
other games.

<http://info.sonicretro.org/Sonic_Physics_Guide>

~~~
Impossible
Yeah I've seen that and it's excellent. My idea was basically to expand on
that sort of stuff.

------
sunahsuh
If you find this interesting, I'd highly recommend "Racing the Beam" by
Montfort and Bogost, which talks about Atari development from both a technical
and a cultural perspective. It really goes into detail about some of the
landmark games that introduced new techniques to push the platform to the
edges of its capabilities (e.g. the scrolling and color-shifting "neutral
zone" in Yar's Revenge was actually created by repurposing the game's machine
code as opposed to being algorithmically generated)

~~~
zach
The first thing to know about the crazy limitations of Atari 2600 development
is this number: 128.

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:

[http://www.atariage.com/forums/topic/166916-halo-for-
the-260...](http://www.atariage.com/forums/topic/166916-halo-for-
the-2600-released-at-cge-download-the-game-here/page__p__2062848#entry2062848)

Yes, it's a loving rendition of Halo on the 2600 platform! You can even play
it now online:

<http://www.codemystics.com/halo2600/>

------
kia
For those who don't want to download: it's 1.7 MiB of assembler instructions
with comments. Looking at this you start to understand how hard game
development was in 80's (this game is from 1986).

------
mrcharles
It has always amazed me that so many quality games were made with assembly
alone, both on NES and SNES. I built small SNES games in school, and man
that's a lot of work.

Gamedev these days is so _easy_ in comparison.

~~~
joezydeco
Many _arcade_ games were done entirely in assembly.

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.

~~~
mrcharles
Yeah, but generally arcade games tend to be a lot simpler than some of the
more complex offerings on SNES, say. The systems were more powerful, but the
gameplay itself tended to be simpler, owing as much to the need to play for
quarter increments as anything. Less state to keep track of, generally, at the
very least.

~~~
joezydeco
Remember that 20 years ago, before the era of superpowerful consoles, arcade
titles usually pushed the state of the art in game mechanics and graphics.
Home consoles could benefit from longer gameplay, but that usually came from
larger game maps and way too many boss screens.

And...weren't some of the most popular SNES games ports of popular arcade
titles?

~~~
mrcharles
Sure. But graphics and basic game mechanics are actually really easy to code
in assembly -- it's crazy state and decisions that get way more difficult. I'd
bet coding up a triangle rasterizer would be significantly easier than coding
up a cutscene.

------
DLWormwood
From the looks of the comments, as well as the frequent references to
"written, but unread" memory, this appears to be a dump of the US release. The
original JP release was for the Famicom disk system, which had more
sophisticated music playback, as well as a three save slot support (similar to
Legend of Zelda) instead of passwords. These bits of vestigial code/memory
likely still exist in "dummied out" form in this US based source.

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.

------
checoivan
This is awesome. I remember playing metroid at a friend's house who had a NES,
wondering "Why do all rooms look similar?!". We spent hours drawing maps by
hand so we wouldn't get lost through levels.

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 :)

~~~
5hoom
That is a great example of a genius/cheeky hack to fit a big world into tiny
memory.

Thanks for that, made me smile & shake my head at the same time :)

------
acuozzo
If you like this, then you may also want to check out <http://nesdev.com/>.
NES programming is alive and well, I assure you.

------
zach
Man, this is an awesome contribution. ASCII art in the comments and
everything.

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.

------
mark_mcs
Reading through source code for old games is always fascinating. Any developer
worth his salt should take the time to explore this area. The tricks that the
engine programmers used to squeeze every last ounce out of the hardware are
truly inspiring.

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...](https://www.sonicretro.org/asm_svn/Sonic%202%20SMS%20Disassembly/))
and it's still only about 80% complete.

------
Sodaware
Even if you're not an assembler expert, there are a lot of detailed comments
that explain how things are done. Well worth a read if you're interested in
the real guts of classic games.

------
seagaia
I'm guessing games built upon previous ones? I'm wondering to what extent they
borrowed from previous prototypes/work. Also, I wonder what the total dev time
for the game was.

~~~
Osmose
Most definitely. There's another really good doc on Super Mario World that
compares a lot of similar chunks of code to their counterparts in the Super
Mario Bros. 3 code, which SMW was based off of.

~~~
jbrennan
Do you have a link to this? Sounds really interesting!

~~~
Osmose
[http://www.smwcentral.net/?p=list&type=documents](http://www.smwcentral.net/?p=list&type=documents)

The doc in question is All.log++. There's a lot of really cool information
spread across that site, though.

------
resnamen
I looked for JUSTIN BAILEY, couldn't find it - but I discovered NARPASSWORD!

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

~~~
daxelrod
JUSTIN BAILEY is not hardcoded; it is an emergent property of the password
system: <http://www.metroid-database.com/faq_metroid.php#metfaq35>

------
raldi
Can anyone find the part that controls whether a missile door is red, orange,
or purple?

------
robolaz
wonder how much time it took to build this

