7 ms·

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

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 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.
    - davvid 15y ago
      And...weren't some of the most popular SNES games ports of popular arcade titles? Yes! Street Fighter II (and sequels). The Mortal Kombat series. These were HUGE when they arrived on the SNES. I still remember how amazing it was when SF2 came out.
  - bonch 15y ago
    SNES games were coded in assembly too.
- asb 15y ago
  RollerCoaster Tycoon (released in 1999) is well known for being written almost entirely in x86 assembly. http://www.chrissawyergames.com/faq3.htm http://www.chrissawyergames.com/faq3.htm
- trafficlight 15y ago
  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"
  - joezydeco 15y ago
    In those days it took about a year, maybe a year and a half. Many teams would carry a core "operating system" (really a library of system routines/process scheduler/IO/audits) from game to game and build off of that. That left more time to write the game mechanics and choreography.
    - trafficlight 15y ago
      I also didn't know they did motion capture for Mortal Kombat. That's even more impressive considering they only had a team of 4.
      - davvid 15y ago
        Was it motion capture (driving a 3D model from sensors) or was it video capture (making sprites from videos). I believe it was the latter. MK's photographic realism really made it stand out in the arcade.
        trafficlight 15y ago
        You're right. Here's the relevant paragraph. The team switched from digitized actors to motion capture technology (the quote is incorrectly referring to Midway as Acclaim): "To make the characters in video games more realistic, actors are being recruited to serve as models. Acclaim, the video-game company that made Mortal Kombat, has created a special 'motion capture studio' for this purpose. A martial-arts expert with as many as 100 electronic sensors taped to his body sends precise readings to a camera as he goes through his moves—running, jumping, kicking, punching. The action is captured, digitized and synthesized into a 'naked' wire-frame model stored in a computer. Those models can then be 'dressed' with clothing, facial expressions and other characteristics by means of a computer technique called texture mapping.
Kurtz79 15y ago
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.
- jamesgeck0 15y ago
  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.
  - slowpoke 15y ago
    > 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.
    - chwahoo 15y ago
      "Utterly retarded" is far too strong a statement. The indie games of tomorrow may be built on "hitech ultra-HD" engines. The exploration of the space of games is advancing along many dimensions (including technology) and I think technology improvements will be needed for many of the great games to come.
    - Goladus 15y ago
      The technology race in video games is as utterly retarded as it is in the movie industry. There's as much room for Clerks and the Blair Witch Project as there is for Toy Story and Avatar.
  - MostAwesomeDude 15y ago
dazzawazza 15y ago
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.
- mrcharles 15y ago
  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.
  - Impossible 15y ago
    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 :)).
    - mrcharles 15y ago
      Trust me, I've been doing this a long time, I'm not pushing out fallacies. But you had to do a hell of a lot more management in NES/SNES/Asm than a simple ->Draw() call.
extension 15y ago
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 I/O. All your code and data is just mapped into memory from a ROM pack. You have to swap memory banks in and out, but you can layout the banks explicitly. You typically do one level per bank and just swap banks to change levels. - There is no memory management. RAM is all yours. You just layout your dynamic data explicitly, or let the assembler do it, or some combination of the two. - There are no data types or undefined language behavior. Just n-bit registers and instructions. Need to use 12.4 fixed point math? Or pack a flag in the high bit of a pointer? No problem, just write some assembler macros. Of course, in exchange for control, you have to give up some power. Maximum 16k of code, can only write to video memory between rescans, no divide instruction.. that kind of thing. But better the devil you know. It's a lot more fun solving "how can I do this with what I have?" than "what the hell is going on?"
- mrcharles 15y ago
  Counters: -You think you know how it works. But lots of little hardware quirks will still bite you in the ass. -This means that all your data has to fit in your code space, so you either trim code or you trim data. -Generally you wouldn't do dynamic data at all, ever, so instead you were stuck constantly balancing and tweaking constant arrays of data and balancing them against everything else in the world. Do I allow 3 entries for explosion effects? Or 5? Am I willing to have one less enemy on screen for those extra effects? -There's also often very few registers and an extremely limited stack. I mean, I'm not saying you are wrong, and from certain angles sure it's easier to write in 8 bit assembler vs modern day high level languages. But there's also things to consider that happen above the language. What happens when there's a bug in some code and you have to hand it to a programmer who isn't familiar with that code? What happens when two subroutines are too far away from each other to jump? What happens when you get graphic corruption bugs and don't have the modern conveniences of data breakpoints and other tools?
- doomlaser 15y ago
mithaler 15y ago
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.com/m1/sourcecode.php http://www.metroid-database.com/m1/sourcecode.php
- mrcharles 15y ago
  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.
  - EvilTrout 15y ago
    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.
    - resnamen 15y ago
      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!

joezydeco 15y ago

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 15y ago
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 15y ago
  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 15y ago
    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.
  - davvid 15y ago
    And...weren't some of the most popular SNES games ports of popular arcade titles? Yes! Street Fighter II (and sequels). The Mortal Kombat series. These were HUGE when they arrived on the SNES. I still remember how amazing it was when SF2 came out.
- bonch 15y ago
  SNES games were coded in assembly too.
asb 15y ago
RollerCoaster Tycoon (released in 1999) is well known for being written almost entirely in x86 assembly. http://www.chrissawyergames.com/faq3.htm http://www.chrissawyergames.com/faq3.htm
trafficlight 15y ago
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"
- joezydeco 15y ago
  In those days it took about a year, maybe a year and a half. Many teams would carry a core "operating system" (really a library of system routines/process scheduler/IO/audits) from game to game and build off of that. That left more time to write the game mechanics and choreography.
  - trafficlight 15y ago
    I also didn't know they did motion capture for Mortal Kombat. That's even more impressive considering they only had a team of 4.
    - davvid 15y ago
      Was it motion capture (driving a 3D model from sensors) or was it video capture (making sprites from videos). I believe it was the latter. MK's photographic realism really made it stand out in the arcade.
      - trafficlight 15y ago
        You're right. Here's the relevant paragraph. The team switched from digitized actors to motion capture technology (the quote is incorrectly referring to Midway as Acclaim): "To make the characters in video games more realistic, actors are being recruited to serve as models. Acclaim, the video-game company that made Mortal Kombat, has created a special 'motion capture studio' for this purpose. A martial-arts expert with as many as 100 electronic sensors taped to his body sends precise readings to a camera as he goes through his moves—running, jumping, kicking, punching. The action is captured, digitized and synthesized into a 'naked' wire-frame model stored in a computer. Those models can then be 'dressed' with clothing, facial expressions and other characteristics by means of a computer technique called texture mapping.

Kurtz79 15y ago

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.

jamesgeck0 15y ago
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.
- slowpoke 15y ago
  > 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.
  - chwahoo 15y ago
    "Utterly retarded" is far too strong a statement. The indie games of tomorrow may be built on "hitech ultra-HD" engines. The exploration of the space of games is advancing along many dimensions (including technology) and I think technology improvements will be needed for many of the great games to come.
  - Goladus 15y ago
    The technology race in video games is as utterly retarded as it is in the movie industry. There's as much room for Clerks and the Blair Witch Project as there is for Toy Story and Avatar.
- MostAwesomeDude 15y ago

dazzawazza 15y ago

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.

mrcharles 15y ago
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.
- Impossible 15y ago
  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 :)).
  - mrcharles 15y ago
    Trust me, I've been doing this a long time, I'm not pushing out fallacies. But you had to do a hell of a lot more management in NES/SNES/Asm than a simple ->Draw() call.

extension 15y ago

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 I/O. All your code and data is just mapped into memory from a ROM pack. You have to swap memory banks in and out, but you can layout the banks explicitly. You typically do one level per bank and just swap banks to change levels. - There is no memory management. RAM is all yours. You just layout your dynamic data explicitly, or let the assembler do it, or some combination of the two. - There are no data types or undefined language behavior. Just n-bit registers and instructions. Need to use 12.4 fixed point math? Or pack a flag in the high bit of a pointer? No problem, just write some assembler macros. Of course, in exchange for control, you have to give up some power. Maximum 16k of code, can only write to video memory between rescans, no divide instruction.. that kind of thing. But better the devil you know. It's a lot more fun solving "how can I do this with what I have?" than "what the hell is going on?"

mrcharles 15y ago
Counters: -You think you know how it works. But lots of little hardware quirks will still bite you in the ass. -This means that all your data has to fit in your code space, so you either trim code or you trim data. -Generally you wouldn't do dynamic data at all, ever, so instead you were stuck constantly balancing and tweaking constant arrays of data and balancing them against everything else in the world. Do I allow 3 entries for explosion effects? Or 5? Am I willing to have one less enemy on screen for those extra effects? -There's also often very few registers and an extremely limited stack. I mean, I'm not saying you are wrong, and from certain angles sure it's easier to write in 8 bit assembler vs modern day high level languages. But there's also things to consider that happen above the language. What happens when there's a bug in some code and you have to hand it to a programmer who isn't familiar with that code? What happens when two subroutines are too far away from each other to jump? What happens when you get graphic corruption bugs and don't have the modern conveniences of data breakpoints and other tools?
doomlaser 15y ago

mithaler 15y ago

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.com/m1/sourcecode.php http://www.metroid-database.com/m1/sourcecode.php

mrcharles 15y ago
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.
- EvilTrout 15y ago
  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.
  - resnamen 15y ago
    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!