We presented Displaced Gamers’/Behind the Code’s video on the jankiness of kusoge disgrace Dr. Jekyll and Mr. Hyde back on Saturday. They did another video on that game, that delves into why the game’s frame rate is so inconsistent. In summary, its engine throttles its framerate in a terrible way, using long delay loops. It’s a pretty awful idea! It’s 19 1/2 minutes long. The video claims it’s even geekier than their first video on the game, but I think it’s actually slightly less technical, at least it doesn’t fill the screen with as much 6502 assembly code.
Another fact about J&H: the Japanese version had two full levels that were cut from the U.S. version, which replaced them with replays of other levels. It made a bad game even worse!
Now, because of Behind The Code, you know more about the Dr. Jekyll and Mr. Hyde game than many much better NES titles. Congratulations!
It’s 19 minutes long, and is even geekier than is usual for us, going into a disassembly of the game’s machine code in its quest to make the game marginally less awful.
While we’re on the subject, did you know that Jekyll & Hyde has a secret ending? Both endings are shown here (4 minutes):
The “bad” ending is the normal one, and shorter, but is arguably a happier conclusion to the story. To get it, all you have to do is get to the end of Stage 6 with Jekyll. That’s all.
To get the other ending, get to Stage 6 with Jekyll, then turn into Hyde and get to the end of his version of the stage. Usually, if Hyde gets as far into his level as Jekyll has gotten into his, he’s struck by lightning and dies. But in this level he’ll be allowed to reach the end of his version of the level for some reason, where there’s a boss! Beat it, and when you return to Jekyll’s world the enemies will be gone, and he’ll be free to finish the level without harassment. However, ending events will be different….
Looks like we’re on another Youtube binge, ayup ayup. This time it’s another hopeful video constructor asking us to consider the oddity of the score system in the original Mega Man (a.k.a. Rockman).
When you post as many Youtube videos as I do, it’s easy to form opinions about their style. That of “TheRetroDude,” as he styles himself, is interesting, it’s still hyper-edited in the way that so many Youtubers loathsomely adopt, but it’s not nearly as distracting as those. He keeps the volume down, as well as the number of swoopy objects tearing around the screen like a toddler newly introduced to Toblerone.
He has good points about how extraneous the game’s scoring system is too, although his misgivings could be laid against many other games. In Super Mario Bros, score is mostly a spacer before toppled turtles start giving extra lives. I think that score isn’t a bad addition to a game as long as it’s implemented thoughtfully, yet for too long it hasn’t been. Even in the NES days it was included to give players a short term goal to aim for, when they didn’t really need it.
What would a good scoring system look like, one that rewarded skill? Well–
Losing a life would reset score to that at the last passed checkpoint, eliminating point pressing from lives.
Extra lives at game end would be worth a bonus each.
Game timers are worth a small, yet substantial, award at level end, to prioritize fast play over slow.
Awards should be given for score, most typically extra lives, but others are possible too.
Replaying levels, and other means of “minting points,” earning arbitrary scores, should be ruthlessly eliminated. If the player can replay levels indefinitely then think about if your game really needs a score, and if it does, don’t allow players to earn more points from replaying them without costing them the points from that last pass.
Two games that come to mind that do scores well are:
ZANAC on the NES, being a scrolling shooter without checkpointing score is generally fair, although it is possible to warp backwards does break the no-replay rule, and
Star Fox 64, which only adds a level’s score to the player’s total at its end. SF64 is a game obviously designed around score attacks.
Where was I? Oh! Here is that video about Mega Man’s scoring system.
Sundry Sunday is our weekly feature of fun gaming culture finds and videos, from across the years and even decades.
This week’s fun video isn’t decades old, in fact it’s from just a few days ago, from AGDQ.
The NES title Gyromite, a.k.a. Robot Gyro, is a very interesting game from a design standpoint, possibly more interesting than it is to actually play (although I think its music is very catchy). It’s never been rereleased by Nintendo, for the probable reason that it relies on the accessory R.O.B. to play.
R.O.B: It’s not just that funky Smash Bros. character! (Image from Wikipedia, taken by Evan-Amos.)
R.O.B. was a motorized accessory that activated servos in its arms depending on light signals sent to it from the screen. No cords went from R.O.B. to the NES. It used photoreceptors in its “eyes” to detect the screen signals, which were ultimately caused by player input on the controller. A fairly roundabout means of control, honestly.
Only two official R.O.B. games were made, and Gyromite (Going by its Japanese name “Robot Gyro” according to the title screen) used the “gyro” accessory for play. A platform is placed in front of R.O.B., on which you place the controller for Player 2.
On the controller is a device that spins the “gyros,” colored weighted tops. By manipulating the arms with action on Player 1’s controller, making them swing around and opening and closing the claws at the right time, you can cause R.O.B. to lift the spinning gyros from their platform, then set them down on the NES controller’s buttons. In the game, this caused colored pillars to rise or fall according to the control signals.
While manipulating all of this, you also have to watch out for the action of the game itself. Gyromite is a simple platformer, but one without a jump button. The difficulty comes from having to essentially play two games at once, the platforming on screen and manipulating R.O.B. to position pillars in the right places in space and time.
R.O.B.’s motions are not simple to command either. It takes time for the arms to pivot between their destinations, time that must be accounted for in the on-screen action, and while the tops spin for quite a while they will eventually have to be collected and set back on their pedestals so they can be spun back up to full speed, or else they’ll topple over on the button. This doesn’t produce a failure state in the game. It’s just left to you to pick the top up yourself and put it back on its stand to be spun again. R.O.B. isn’t capable of such feats of dexterity.
There’s a lot more to say about R.O.B., and how it was mostly distributed as part of the Nintendo Entertainment System’s “Deluxe Set” in the U.S., the more expensive version that didn’t come with Super Mario Bros. Instead of that, let’s talk about how, due to the fact that R.O.B. is just a fancy-shmancy way to press controller buttons, that you can replace it entirely with some other mechanism, or indeed, even animal.
That’s what happened Wednesday at AGDQ, where Peanut Butter the Dog, with coaching from JSR_, left R.O.B. gathering dust in the closet as they played through Gyromite Game B.
They didn’t make it all the way without running out of lives, but they picked back up and kept going. And that doesn’t detract at all from Peanut Butter’s skills, or amazing doggy focus. They are intent on reading those hand signals and getting those tasty treats. So while they didn’t earn a world record, for “Dog playing Gyromite Game B,” their accomplishment is of definite note.
There are around four minutes of introductions at the start of the video, so if you want to jump right in to the run, begin here.
I already shown it off on Mastodon, but I’m so pleased with getting this bug on video that I’m re-reporting it here! First, though, some background.
Still the definitive resource on the design internals of Pac-Man.
I’ve been looking into the various home computer ports of Pac-Man lately. One of the better ones is the one for Famicom/NES, probably because it was made in-house at Namco, which I presume because while it’s by no means perfect, it has ghost AI that much more closely matches Jamey Pittman’s definitive Pac-Man Dossier than the others. This is a bit more important than the other ports because, due to the relative familiarity (that is to say, inexpensiveness) of NES emulation at this point, Famicom Pac-Man is often put in compilations, especially in dedicated consoles, instead of the arcade game. In point of fact, the Namco Museum Archives Vol. 1 that’s available for various consoles uses the Famicom versions of all its games, not the arcade, and Pac-Man is one of the included games. To tell the difference: if the score, fruit tally and lives are to the right of the screen, instead of above and beneath it, and Pac-Man looks a little too big to fit in a maze passage, then what you have is an inferior home conversion.
How is it different? Well:
The sound of Pac-Man eating dots is much worse, for starters, it never fails to bother me.
More substantively, the ghosts have slightly different constants in their chase routines: it’s slightly harder to fake out the Pink ghost (Speedy/Pinky), and the Orange ghost (Pokey/Clyde) gives up the chase a little more reluctantly.
The timing for scatter periods, relative the speeds of the ghosts, is a little off. Scatter periods are usually slightly longer.
The speed of the game as difficulty increases is also a little off. In the arcade, the First Apple board (Level 5) marks a noticable increase in Pac-Man’s speed, but it seems to happen around the Second Orange (Level 4) on Famicom. Yes, that’s how much of arcade Pac-Man and its port that I’ve played-it could be subjective, but maybe it’s not.
The bug that affects Pink’s and Blue’s (Bashful/Inky) AI when Pac-Man’s facing up doesn’t exist here.
When ghosts enter Scatter mode, they don’t reverse direction. This makes the game easier (one less sudden reverse to throw you off) and harder (no obvious indication that the ghosts are scattering, and one less thing to throw them off from immediate pursuit).
As the game advances in difficulty, in the arcade, on the 4th Key board (level 17), the ghosts won’t turn blue and vulnerable when you eat an Energizer, and instead will just reverse direction. And from the 6th Key (level 19) on, the ghosts will never turn blue again! NES Pac-Man instead gives them a very tiny bit of blue time, about a half-second’s worth. It never reaches a state where the ghosts become completely invulnerable.
And at last, the bug which I have confirmed. On the 10th Key board (Level 22), and every level thereafter, the ghosts will start out in an unusually long Scatter period. Their usual habit is to emerge from the box in the center of the screen and move to a corner of the screen, and circle there for a few seconds. Pink goes to the upper-left, Red (Shadow/Blinky) to the upper-right, Orange to the lower-left, and Blue to the lower-right. This period is called a “Scatter Mode” in the Pac-Man Dossier.
In most levels, presuming you don’t lose a life, the ghosts will enter Scatter Mode at exactly set three times: from the start, about 25-or-so seconds in, and about 30 or so seconds after that. These periods are usually five seconds long. There are some minor details I won’t get into-you can read the Dossier for those. These periods are lifesavers for intermediate Pac-Man players playing without patterns, as they are the only really safe ways to access the bottom passages of the board without getting trapped or wasting an Energizer.
Each Scatter Mode is only supposed to last five-to-seven seconds, but on Level 22 and after, all of the Scatter Modes last around 20 seconds. Here is the bug in action, demonstrated in Namco Museum Archives Vol. 1:
Why would this board be different from the others? In the arcade, the 9th Key (Level 21) is the maximum difficulty the game reaches. Any pattern that works on the 9th Key level will work for the rest of the game, all the way up to the kill screen on Level 256. It seems that, on the Famicom/NES version, after that level the game may not have data for the level to follow? But I haven’t looked at its code to know for sure. Maybe I should make that a future project.
Greg’s Game Room on Youtube looked at 28 games with both NES and Commodore 64 versions. It’s not by any means all of them, but a good selection. Usually its the NES version that’s better, but there are some surprising upsets, especially if the game originated on a microcomputer platform.
The Commodore games that won out are Ballblazer, Castelian, Die Hard (but the C64 version’s really different), Ghostbusters, Ghosts ‘n’ Goblins, Q*Bert and (surprisingly) Smash T.V. Decent C64 games that nevertheless lost are Blades of Steel, Commando, Donkey Kong, Mighty Bomb Jack and Super Mario Bros. (rated were both the similar Great Giana Sisters and the recent fanmade version of SMB that uses advanced scrolling tricks). Gyruss, Mario Bros. and Pac-Man were rated at a tie.
Dr. Sparkle has come through once again with the 63rd edition of Chrontendo! It’s the third we’ve linked to from Set Side B (even if, for a while, we incorrectly labeled the previous one as #68, oops).
The games covered by this one are:
Knight Move (Japan only): A puzzle game involving landing a chess knight trying to land on a target square. Apparently this got a later release on PC by Spectrum Holobyte. Wikipedia tells us that the “A. Pazhitonov” listed as the creator on the Famicom version’s title screen is Alexey Pajitnov, the creator of Tetris. I cannot speak to that fact’s veracity, but it seems plausible enough. Pajitnov later would be hired by Microsoft to make puzzle games for them around the Windows XP era.
Lamentable US cover art of The Mafat Conspiracy (image from MobyGames)
The Mafat Conspiracy: the sequel to Golgo 13! The US release does its Japanese manga source material a great disservice by not having the grim face of protagonist Duke Togo visible anywhere on the front of the box, instead using extremely generic cover art. In play, it’s very similar to a slightly more competent version of the original, just with a different scenario.
Disney Adventures in the Magic Kingdom: Another of those Capcom Disney games, a glorified minigame collection, and probably the worst of the bunch! We’re a mile away from Ducktales here. As if to confirm the player’s low expectations, trivia questions are part of the game.
Solstice: Isometric platformer of the style well-known around that time in the UK, a very difficult yet respectable exploration game, and probably the best game in this episode. I prefer its SNES sequel Equinox, programmed by the Pickford Brothers, which has a highly distinctive look.
The vibe of Solstice’s print ad is like “we’re gonna make a porno”
The Last Starfighter: This is secretly a renamed port of the Commodore 64 classic Uridium! A little of the bloom is off the rose here, if only because high speed scrolling of the kind you see here is so common on the NES, yet so difficult to accomplish on the Commie. The C64’s distinctive look was heavily influenced by that system’s limitations: it takes some serious programming effort to get the C64 to be able to scroll significant screen data in a frame, enough so that, to do it, you basically have to leave color memory unchanged, since it can’t be relocated like tile definitions can. The NES can do scrolling much more easily than the Commodore 64, and had been doing very colorful fast-scrolling games like the Super Mario series for years, yet the game kept the same nearly-monochrome look as the C64 game. That’s why Uridium got such acclaim in the UK, because scrolling games like it were unknown on the system at the time, while the NES had support for it in the hardware, so it didn’t have nearly the same impact.
Captain Skyhawk: The main things I remember about this, a game which I’ve played and beaten, is it was made by Rare, and that Dave Barry once wrote a column about how much his kid dearly wanted a copy of this game. Dr. Sparkle is pretty hard on this one too, and I think for good reason. This is clearly a game intended to be in the River Raid style, but with elevation. It could have been done as a quasi-flight sim, with targets you have to duck beneath or fly over, but in its design the elevation barely matters, and instead it’s a lot more like a standard vertical shooter. The enemies don’t even cast shadows! Helicopters or ground vehicles alike can be shot if if they were on the same plane. It would have done better if it had either gone all-in on the elevation, maybe tying it to the player’s speed, and having fewer yet smarter enemies that also had elevation; either that, or taking out the elevation completely and making it into a 2D shooter more like Zanac or Raiden. Rare at that time understood the NES hardware better than most developers, and was more than capable technically of going with either approach. But they didn’t.
Then after you have Afterburner-style dogfighting levels, then the point where most players threw down the controller in disgust, when they’re asked to align and dock with a rotating space station. It all resembles a tech demo at Rare that Milton Bradley decided to try to make a few bucks off of selling as a game.
Horrifying Palamedes box art (image from Wikipedia)
Hatris: Another game designed by Tetris creator Alexey Pajitnov, it’s also nowhere near as iconic as Tetris was, but as time has shown us, very little else is. I get the play mixed up with that of Nintendo’s Yoshi puzzle game, perhaps for good reason. Turns out there was an arcade version of this!
Palamedes: Another Tetris-ish generative piece-laying puzzle game, this one with a dice theme. And there was an arcade version of this too!
Hiryu No Ken III: 5 Nin No Ryuu Senshi: Only released in Japan. Dr. Sparkle is quick to let us know right off this isn’t the “Fist of the North Star” Ken, but the Flying Dragon: The Secret Scroll Ken. These games are a bit more simulationist (in a sense) in their depiction of martial arts than most beat ’em ups.
SD Hero Soukessen: Taose! Aku No Gundan: Also Japan-only, second in a long series of “super deformed” (basically meaning big headed, small bodied humanoid figures depicted in a cutesy kind of way) robot fighting games. The robots (and tokusatsu characters) are licensed from a variety of media, making this a massive crossover media series that could be seen as an inspiration for the hulking monstrosity that Super Smash Bros. has become. Properties that I recognized from the video are Kamen Raider, Gundam and Ultraman. This one has a fan translation patch.
Few games for the NES have been better treated by hindsight than Friday the 13th. At the time it was regarded as a terrible game with difficult play and nearly impossible to win.
But even then there were things about it that indicated that there might be a little more going on then than was first apparent. Publisher LJN was known for making terrible games, but they outsourced their work to different companies that often weren’t actually that bad, just given weird properties for video games (The Karate Kid? Jaws? T&C Surf Designs??) and approaching them with experimental gameplay. And for their part, all of LJN’s games are technically sound, and manage to hit their 60fps frame rate targets, which is much more than you can say for many other NES games, including some from big manufacturers like Capcom, like Ghosts & Goblins and 1942, both implemented by Micronics, or Strider, which as we’ve noted before is a mess.
It has come time, as we all knew it must, for Jeremy Parish to collide with Jason’s axe, and as befits the game’s redemption, his video is divided in half, first about its reception at the time, then later now that it’s appreciated a little better. Just don’t turn it off after the 8 minute mark, there’s still more than half of it to go!
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!
Wurm: Journey to the Center of the Earth is a Famicom/NES title with a lot of ambition, perhaps too much. Over on his self-named blog Kid Fenris posted a long article on it back in March. It makes it seem a lot more interesting than it otherwise would! We at Set Side B love experiments, successful or failed, and Wurm certainly was one, with shooter, side-scrolling platformer, first-person boss fights and even some visual novel elements. And protagonist lady named “Moby” is searching for her boyfriend named “Ziggy.”
Green-haired Moby wears the kind of outfit you could only find in something inspired by 80s anime.
The post mentions that designer Shouichi Yoshikawa, a.k.a. “Angela,” has an interview up at GDRI. It also mentions that Angela used to have a site devoted to their game, which while gone now has a backup on the Wayback Machine! Sadly the promised English version of the site never materialized.
Also–Kid Fenris mentions he once wrote about Wurm on GameSetWatch. My old stomping grounds!
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.
