I did exactly that once, as a proof-of-concept for a console-like graphics library that I wrote (The capabilities and interface were similar to a cross between the NES and SMS graphics chips). Since it was more of a demonstration of that than a complete game, I didn't bother with enemies, block-breaking or matching the jumping exactly correctly, but you still find out all kinds of interesting things -- for example, if you look closely at sprites on an NES, you'll notice that they start to disappear as soon as they touch the left edge of the screen, because on the NES sprite coordinates couldn't be negative. On a TV you'd almost never notice this due to overscan, but you can see it in emulators.

To do it accurately would be fairly illustrative. The gravity effect during a jump isn't really complicated, but would take experimentation to get just right; or, someone has probably already annotated a dis-assembly of the game's ROM, and you could reverse-engineer the exact behavior from the assembly listing.

Anyone ever tried duplicating a game exactly as it is for learning purposes?

Yes, fiddling with the exact numbers for enemy hp, hit damage, rate of fire etc always drove me crazy.

I have done a single-stage Mario World “game” and an mIRC online Tetris game script (exactly ripped from Super Nintendo Entertainment System as far as art goes).

Both very profitable in terms of experience gained, and the Tetris clone was fully functional and very fun to boot.

It is a great way to explore game-making since you have the art assets already, know how they are to be rendered (how the animations play etc.) and you can focus on exactly what you want to explore while at the same time the art assets you use motivate you because they are from your favorite game and they look professional.
You also have a real-world example off which to base your results, so you know if something is wrong and may discover that their implementation of something was not really as simple as you had expected.


L. Spiro