Tag: coding

Chipwits Remake Released

Some time ago on Game Developer I did an interview with the creator of the classic Mac, Apple II and C64 programming game Chipwits, who were working on a modernized version. Well their efforts have been released to the public now: Chipwits 1.0 is now out on Steam!

You devise programs using a graphic interface to get a robot character through a maze-like grid world to do various things. The original Chipwits was written for the original Mac, in Forth, with ports for different machines of the time. The new game has a nice tutorial as well as new scenarios, in addition to the scenarios that came with the original game.

The thing I like about Chipwits is, it isn’t always about solving specific puzzles. Many of the maps are open-ended. The robots have a limited amount of fuel, which translates into machine cycles to run your programs. Additional fuel can be replenished by objects found in their exploration, as well as objects worth score, but the objects are frequently randomly placed. These scenarios aren’t about tailoring a program to a specific placement objects, but devising a more generalized exploration routine that can adapt to a variety of placements. There are online leaderboards so you can see how your coding skill compares with that of other players.

Chipwits usually goes for $15, but for launch is currently 10% off on Steam. (Disclaimer: I interviewed the Chipwits people for Game Developer previously, and did a little beta testing, but I bought my own copy of the game for these screenshots. They deserve the money!)

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)

The Issues With NES Teenage Mutant Ninja Turtles

The title refers to the original NES TMNT, not the arcade version or the NES game based on it. This is the version that Konami released under their Ultra label. It sold well (real well!) but is widely considered an inferior game for a number of reasons. Those reasons are the subject of these three videos, from Youtube channel Displaced Gamers. I recommend them, even if I think every place they say gamer it would be more proper to say player.

The first video:

In a long and difficult game, one of the hardest sections comes relatively early. The only swimming section in the entire game, players must maneuver their supposedly-aquatic surrogates through a difficult course that has imprecise movement, water currents, high damage, instant kill hazards, a strict time limit, and, as the video shows, buggy implementation. Many players in the NES era gave up at this point, which is rather a shame considering it’s only at the end of level two. This video examines the code and demonstrates why it’s so challenging, and how it could be made fairer.

The second video:

TMNT has notoriously floaty jumps, a low frame rate, and a fairly weird implementation of gravity. Any platform game that allows players to adjust their jump height according to how long the hold down the jump button is fudging its physics behind the scenes, but TMNT does it rather poorly.

The third video:

Displaced Gamers examines additional problems with the game’s timing, particular with that of its input reading and attack animation. Like the other two videos, they suggest code changes (sometimes in the form of Game Genie codes) that fix the problem, if you happen to have a fondness for 6502 assembly. (I do!)

If you’d like to try NES Teenage Mutant Turtles, it’s included in the “Cowabunga Collection” that was released for Switch, Xbox X/S and Playstations 4 and 5. Fortunately, it also includes twelve much more playable titles.