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.
Metroid Source Code Expanded
11–20 of 64 posts
Re: Metroid Source Code Expanded
#12Earlier 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.
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?
Re: Metroid Source Code Expanded
#13It 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.
I'd have to respectfully disagree. I've written 100% asm games on the Amiga all the way up to PS2 games in C++ and the amiga game was a lot easier to write and debug.
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.
Re: Metroid Source Code Expanded
#14It 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.
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.
Re: Metroid Source Code Expanded
#15Earlier quoted context omitted.
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.
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?
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.
Re: Metroid Source Code Expanded
#16It 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.
I'd have to respectfully disagree. I've written 100% asm games on the Amiga all the way up to PS2 games in C++ and the amiga game was a lot easier to write and debug. 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.
Debugging I'm with you, but the actual time to create simple parts of the game? Going to have to disagree with your disagreement. It's like two lines of code nowadays to move a sprite around on screen and draw it, because you don't have to write your blit function yourself.
Re: Metroid Source Code Expanded
#17It 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.
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.
What were the development cycles for those later arcade games? How long did it take to build Mortal Kombat and how many people did they have working on it?
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"
Re: Metroid Source Code Expanded
#18Earlier quoted context omitted.
I'd have to respectfully disagree. I've written 100% asm games on the Amiga all the way up to PS2 games in C++ and the amiga game was a lot easier to write and debug. 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.
Debugging I'm with you, but the actual time to create simple parts of the game? Going to have to disagree with your disagreement. It's like two lines of code nowadays to move a sprite around on screen and draw it, because you don't have to write your blit function yourself.
You didn't have to write blit functions yourself on the NES either, it had hardware (PPU) that would handle blitting of sprites for you. There were a lot of restrictions that you'd have to work around, but actually displaying something on screen didn't take that much code.
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 :)).
Re: Metroid Source Code Expanded
#19If 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)
Re: Metroid Source Code Expanded
#20Earlier 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.
> 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.
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.