Tag: strider

More on the Terribleness of NES Strider’s Programming

A while ago Displaced Gamers, as part of their great Behind The Code series, did a video about how awful NES Strider’s sprite updating was. Arcade Strider was huge hit and outright masterpiece, a great arcade platformer released right before fighting games took over game rooms around the world, but NES Strider was a wretched thing, full of big ideas but with code woefully unable to live up to them. Imagine a puppy trying to do your taxes. It might put up an adorable effort, but it’s just not going to get the job done.

We linked to their last video examining its malformed construction. Well, Strider is the well of crap that keeps on gushing, and so Displaced Gamers has another video on the subject of the flaws in its programming, this time about its player physics. Walking into walls causes Strider Hiryu to shudder in place; jumping beneath a low ceiling causes him to bump his head repeatedly as his jump continues even though there’s no room to ascent; and his infamous “triangle” wall jump is so wonky that it literally requires a frame-perfect input to pull off, and not even the right frame. You have to jump the frame before you contact the wall!

Here is the new video, which explicates the entire cruddy system. It goes into exquisite/excruciating detail, including tracing the code and examining Hiryu’s X and Y coordinates on a frame-by-frame basis. It’s the kind of deep geekery that I just know you love/hate! Enjoy/despair!

The Physics Nightmare and Bizarre Jumping of Strider (NES) – Behind The Code (19 minutes)

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)