Metroid Source Code Expanded • Hacker News Board

Re: Metroid Source Code Expanded

#51

Post by 5hoom » Fri, Oct 14, 2011, 11:06 PM UTC

checoivan wrote: post #34

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

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

Re: Metroid Source Code Expanded

#52

Post by bonch » Fri, Oct 14, 2011, 11:13 PM UTC

kia wrote: post #4

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

I don't know, it's hard to determine what is considered "hard." Sure, you were writing in assembler, but you were also writing directly to simpler hardware, and the games were much, much simpler.

Re: Metroid Source Code Expanded

#53

Post by bonch » Fri, Oct 14, 2011, 11:17 PM UTC

mrcharles wrote: post #7

joezydeco wrote: post #5

Earlier quoted context omitted.

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.

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.

SNES games were coded in assembly too.

Re: Metroid Source Code Expanded

#54

Post by MostAwesomeDude » Fri, Oct 14, 2011, 11:31 PM UTC

5hoom wrote: post #49

MostAwesomeDude wrote: post #21

Earlier quoted context omitted.

I'd just like to point out that Minecraft's code is absolutely horrible from an algorithmic standpoint. On performance/speed and code quality metrics, Minecraft is a statistical fluke.

Yet by any other conceivable metric it is a huge success. I love good code & elegant design, but it doesen't beat having a successful product out there. Remember, shipping is a feature ;)

60FPS is also a feature. Not crashing when sent invalid input on the wire is a feature. Being able to support more than 100 concurrent connections without requiring a monstrous top-of-the-line server is a feature. These are all missing from Minecraft.

Remember, usability is a feature. >:3

Re: Metroid Source Code Expanded

#55

Post by joezydeco » Sat, Oct 15, 2011, 12:53 AM UTC

jamesgeck0 wrote: post #14

Kurtz79 wrote: post #10

Earlier quoted context omitted.

Gamedev is simpler today than it was by then, but games (we are talking about AAA titles, as Metroid was at the time) have escalated in complexity by several orders of magnitudes. 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.

Not as rivals to those games, perhaps. But Minecraft and Angry Birds show that it's easier than ever for a single person/small team to create and sell an extremely successful game.

Easier than ever, when you stand on the shoulders of giants:

http://m.techcrunch.com/2011/02/28/creator-of-angry-birds-ph...

Re: Metroid Source Code Expanded

#56

Post by [deleted] » Sat, Oct 15, 2011, 2:15 AM UTC

[deleted]

Re: Metroid Source Code Expanded

#57

Post by EvilTrout » Sat, Oct 15, 2011, 5:03 AM UTC

mrcharles wrote: post #28

mithaler wrote: post #25

Earlier quoted context omitted.

Was this actually written in assembly by its original developers? I'm not familiar with the history--I get the sense the code explained here was originally disassembled from a ROM, and then systematically analyzed to gain an understanding of how it worked.[0] If so, couldn't it have been written in C or somesuch? Not that that wouldn't make this presentation here an impressive feat. [0] http://www.metroid-database.co…

The N64 was the first nintendo platform to support a C compiler out of the box. 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.

The PS1 was released before the N64 and supported C compilation. In fact, in the early days Sony didn't want people to use much ASM because they were worried about backwards compatibility on future systems. The PS1 port of Doom suffered from a lack of assembly optimization.

Re: Metroid Source Code Expanded

#58

Post by resnamen » Sat, Oct 15, 2011, 6:13 AM UTC

EvilTrout wrote: post #57

mrcharles wrote: post #28

Earlier quoted context omitted.

The N64 was the first nintendo platform to support a C compiler out of the box. 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.

The PS1 was released before the N64 and supported C compilation. In fact, in the early days Sony didn't want people to use much ASM because they were worried about backwards compatibility on future systems. The PS1 port of Doom suffered from a lack of assembly optimization.

Gran Turismo and Metal Gear Solid were written in C. Ken Kutaragi used them as examples of what could be done with efficient programming techniques and good use of Sony's performance profiling tools. (citation needed: one of my old gaming mags that's probably been recycled three times over by now)

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!

Re: Metroid Source Code Expanded

#59

Post by resnamen » Sat, Oct 15, 2011, 6:17 AM UTC

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.

Re: Metroid Source Code Expanded

#60

Post by jbermudes » Sat, Oct 15, 2011, 10:13 AM UTC

Impossible wrote: post #33

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 i…

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