How were cartridge-based games programmed?

Question

I'm thinking of like the SNES, N64, Atari... even the DS today, I suppose.

SNES games did not usually take up more than 4 MB of space, and N64 games were usually 32 to 64 MB worth of data.

These days, you can barely compile a "hello world!" program without the resulting compilation generating 1.21 gigabytes!! of data. (Joking aside, files today do take up tons and tons of space compared to some of the technology back then.)

So... how did they do it?

• What did they program these games in? ASM? The entire thing in ASM?!
• How were graphics created? What technology did they have to create sprite sheets and, in some cases (like the N64), 3D models?
• How did they fit so many levels, characters, quests and items on these cartridges? I mean, Super Mario World on the SNES clocks in around 1 MB, and it has 96 exits! Ocarina of Time, Banjo-Kazooie, DK64 and a few other games take up less than 64 MB and had huge worlds, tons of content and 3D models!

Sorry if my questions seem a little out-there, I'm just amazed that a lot of great titles out there managed to fit in such a small storage space.

It's fascinating to me because even tiniest and most trivial of files and games manage to take up at least a few MB, so imagining that huge levels like those in GoldenEye 007 managed to take almost no data at all is mind-blowing.

Answer 1

It's the art and audio resources that take up space, choice of programming language was more about getting the most of out of the hardware.

Using N64 as an example, most of the 3rd party games were 8, 12, or 16Mb. The 32 & 64Mb games were mostly from Nintendo as it was so expensive to ship on carts that big for everyone else. That sounds tiny, but then so were the art assets and the final visual output. You have to remember that most N64 games rendered at 320x240 not the 1280x760 or more of today. With such a small output resolution, textures and sprites were much smaller than they are today.

Because of the tiny texture cache on the N64, most textures were 32x64 pixels with a 4/8bit palette (aka 16/256 colors). Extra color detail was often done by mixing textures and vertex colors. The Banjo games are a good example of this.

Today a single rock in an Unreal engine game will have multiple 512x512x24bpp or even 32bpp. Plus instead of just a single diffuse texture you've now got normal maps, specular masks, reflection masks, reflection cubemaps and more. So an object that used to have 4Kb of textures is now covered in several MB of data.

Old games also have a massive amount of reuse of textures. The bushes in Super Mario Bros. are the same texture as the clouds, the hills are the same as the mushrooms. Different characters are just color shifted versions of the same art resources. All of this got more usage out of each texture that was on the cart.

Audio is another big difference for modern games. Nearly everything in the old days was done with midi tracks. Now both music tracks, voice and sound effects are stored in various compressed audio formats. While certainly smaller than uncompressed data, they are still significantly bigger than their midi equivalents.

Answer 2

There are a lot of sub-topics in almost all of the questions you are asking. Optimization is a huge field all to itself and there are a lot of things to explore.

If you are interested in this sort of optimization, one of the things you might explore is the demoscene. The demoscene, and some of its related art cultures, has long retained a sense of wonder about trying to create intricate art for computers that takes up as little space as possible. Many of them will have information on how they did some or all of their "tricks".

Often there is an artful mix of common sense, although there are "tricks" and "hacks" specific to a game or genre. Often there's a bit of "luck" involved, and a team knowing the limits they are working for (perhaps continually butting heads with those limits throughout the process), knowing their available trade-offs, and be willing to make some of the necessary trade-offs and sacrifices to meet their limits.

Here are some of the things that I can think of that can help a team get a game to smaller sizes:

• Reuse What You Can: reusing the same sprites, and the variations that you can easily make from a single sprite image (such as reflections, rotations, palette shifts) will save you space. The same goes for code, music, and nearly everything else in a game.
• Compress What You Can: there are a number of compression schemes out there, and knowing which ones to use can be a huge space savings. Even sometimes simple compression schemes like run-length encoding can make a surprising difference. Not only that, but there are compression schemes (and alternative formats that aren't exactly compression) for individual file types, often with quality trade-offs. For instance, wave/CD audio files can be compressed, with some marginal loss of information, into MP3 files. Also, file formats like MIDI and sampler-based MOD are alternative formats that take up a lot less space, but encode music entirely differently and require different skills to make them sound good.
• Lose What You Don't Need: can you do it cheaper? For instance, can you still get the "personality" of a character across in fewer pixels (or polygons)? Does the placement of tiles need to be exactly defined by a designer or can they be randomly generated in your program code?
• Code Is Often Cheaper: although you made a joke about how much space a code compile typically takes now ideas (and there are reasons for why this 'platform' has increased over the years, and ways to shrink it when you absolutely need to), but generally if you can do something algorithmically/procedurally/in-code easily, that approach will also be easier to tweak and to reuse for other similar but different looking/feeling assets. Fractals are a particularly easy to see example: you could have an image of an intricate fractal that takes up a lot of space with comparison to the mathematical formula that generates it. The mathematical formula, additionally, may have parameters that can generate similar, but sometimes surprisingly different looking images.

Anyway, for such a big, loaded set of questions, hopefully some of the topics above will be good starting points for you to learn more.