31–40 of 64 posts
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.
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.
Earlier quoted context omitted.
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.
Do you have a link to this? Sounds really interesting!
The doc in question is All.log++. There's a lot of really cool information spread across that site, though.
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 :)
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.
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…
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…
Earlier quoted context omitted.
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.
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.
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.
It would be hard to make Crysis in 8-bit assembly, but it's not especially hard to make an NES game in 8-bit assembly. In many ways, it is much easier than modern game development: - 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…
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 r…
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...
Yes, it's a loving rendition of Halo on the 2600 platform! You can even play it now online: