Tag: internals

Why Is NES Strider So Janky?

There are a number of NES games that feel like they’re held together with paperclips and chewing gum. Some of them are almost endearing for their glitchiness. When it comes to janky NES games, a few that I tend to think of are those made by Micronics (who implemented Ghosts N’ Goblins, which has an awful frame rate) and Athena (where one boss has a death animation that causes it to flip through many of the sprites in the game).

A company that usually did a lot better with their internally-developed games was Capcom, makers of Mega Man, 1943, Bionic Commando, and all the Disney Afternoon games from the time, all of which have slick 60 fps update rates and smooth animation. One game they made of which that is definitely not true, however, is NES Strider.

If you’re only familiar with Strider from the beautiful arcade version, you might wonder what even NES Strider has to do with it. It’s not proper to say Famicom Strider, because Capcom never released it in their home territory, perhaps because they were too embarrassed to.

Other than the first stage being set in generally the same fictional location in Russia (even if it doesn’t look at all the same), its story has absolutely nothing to do with it. Jeremy Parish looked at it (and remarked on its glitchiness) in an episode of Metroidvania Works from a couple of weeks ago. Some people, like Kid Fenris of the self-titled blog, actually likes it, although acknowledges its many issues.

Behind the Code, one of the best game internals series on Youtube, had a look at the implementation of NES Strider. It’s an interesting 15 minutes to my taste, but if you want a tl;dr, NES Strider often doesn’t make its framerate target, and instead of slowing the game down as most games do, it plows ahead forward into the next frame, leaving the incomplete data in its update buffer to be copied into the PPU. This causes the individual hardware sprites that compose enemy characters to sometimes have only one of their coordinates updated, or even causing data remaining from previous frames to be copied over.

Why does it does this instead of just slowing the game down? Possibly the coding was so crappy that it would have caused excessive slowdown; the scene chosen as an example in the video has the problem occur when there’s only two basic enemies on the screen in the game’s first area! Not the best engine on the system there Capcom.

The Garbage Sprites in Strider (NES) (Behind the Code on Youtube, 15 minutes)

Super Mario Bros Level Glitches

The Youtube channel Retro Game Mechanics has done a series of three videos on glitches in Super Mario Bros. One involves using the NES game Tennis, which has a certain property of its code that allows you to load all kinds of funky levels in SMB.

They’re all interesting, but the one that floats my particular boat is the third, which turns into a deep dive in the compressed manner that Super Mario Bros. stores its levels in ROM, and uses to draw them during play in real time.

1. Access Glitch Worlds in Super Mario Bros. via NES Tennis (13 minutes)

2. Exploring Glitch Level Pointers In Super Mario Bros. (15 minutes)

3. Super Mario Bros. Glitch Levels Explained (30 minutes — this is the one embedded above)

Metroid Prime’s Save System

Zoid Kirsh on Twitter (while Elon Musk hasn’t completely wrecked it yet) tweeted about how Metroid Prime’s save system works. Metroid Prime save files are less than 60 bytes long! A single Gamecube memory card block is eight kilobytes, so it’s a bit overkill, but it’s still nice when a developer is frugal!

Image, of Metroid Prime’s inventory screen, from Mobygames.

The way they explain it is that the game has a number of “world layers” which determine what is spawned in each area when it’s loaded. Which layer is active when a room is loaded is determined by a single bit in the save. That, plus some basic stats like health and ammo, and the record of object scans, all take up very little memory when bit-packed.

If Metroid Prime’s save file were 59 bytes long, that would mean it had 472 bits to work with. The passwords used by the original Metroid only stored 144 bits of data!

@Play Extra: Inner Details of Pokemon Mystery Dungeon

The Pokemon Mystery Dungeon games are interesting offshoots of the mainline Mystery Dungeon titles. They make clear a stark difference between primacy and popularity: if you only care about sales, then there is no question that Pokemon Mystery Dungeon games are the main games, because their sales vastly outweigh the other games. The games in the second generation, Explorers of Time/Darkness/Sky, are the best-selling Mystery Dungeon games of all. You have to know that there’s around 30 other games, many much older than the Pokemon flavor, in fact older than Pokemon itself by three years, to know the whole story.

Yet the PMD games are still Mystery Dungeon titles, and they play very similarly. They’re graphical roguelike dungeon-crawl games, just, you, your teammates, and your opponents are not generic fantasy creatures, but Pokemon. That is, specific fantasy creatures. Trademarked ones, in fact.

Because PMD’s fairly popular, you’re more likely to find investigations into its internals than the Shiren or other Mystery Dungeon games, just from the number of people who exist in its audience with both the will and skill to investigate. Yet, those internals are close enough to the MD standard that they even provide insight into how classic Mystery Dungeon operates.

YouPotato TheZZAZGlitch’s usualy video stomping grounds in Pokemon, but they have a fondness for PMD, so they’ve made a video on how the first generation (Red/Blue Rescue Team) generates its dungeons, and what do you know, many of these floor types are also very familiar to me from my time exploring the Shiren games, and it doesn’t seem a stretch at all to presume they’re run by the same, or at least a very similar, algorithm.

And YouTuber Some Body (who has a low number of subscribers, maybe folk should send them some love?) has two videos explaining how the AI in those games works. The first is of more general (well, less niche) interest (the one above), while the second is more about covering exceptions and edge cases.

The Hidden Structure of the Overworld of Link’s Awakening

pmorinerie (on Mastodon @pmorinerie@mastodon.xyz) has been working on a full disassembly of the fourth Legend of Zelda game, Link’s Awakening on the Game Boy, and has a series of articles they’ve written about interesting technical aspects they’ve found.

One of their discoveries is of a hidden structure to the overworld of that game. Their discussion of this is fascinating, and should be referred to if you have an interest in such things. I will give a broad summary here.

The Game Boy was not given much VRAM for storing graphics. To avoid bus conflicts, the CPU that runs the system only has access to VRAM, to store new background tile information, either during VBLANK, a specific time each frame when the PPU circuitry isn’t accessing memory, or by blanking the screen entirely, which is only really feasible during major transitions, like through a door or into a hole. So, the system is limited in how quickly it can store new tiles during play.

Link’s Awakening stores two kinds of tiles in its VRAM. Most of them are from a set that’s used throughout the overworld, but a small number are overwritten, used for different purposes as Link explores the landscape. The overworld is separated into 2×2 blocks, and each can have its own set of these customized tiles.

There is a problem with this setup, however. When Link changes screens, like in the original Legend of Zelda and A Link to the Past, the screen transition scrolls smoothly between the areas. During the scroll, briefly, it’s possible for elements from two different screens to be displayed at once. How does the program handle situations where the custom tiles have two different definitions between screens?

The answer is that the overworld is cleverly designed so that there aren’t adjacent screens with walkable passages between them that use different sets of custom tiles. There are screens in the game that only use tiles from the main overworld set, and all of the places with passages between the screens with custom tiles have one of them, as a kind of memory airlock, to prevent glitches during transitions. It’s pretty clever.

If this is interesting to you, I encourage you to read the whole article, especially for the exceptional cases where the system breaks down and they had to find other ways to keep the screen from glitching.