It’s a bit old, but Chaz on Youtube has a great video explaining some weird facts about Earthbound, including mysterious crashes, when the game registers the effects of statuses like Sunstroke, and why there’s a small number of places in the game where you can find an early enemy, the Mole Playing Rough, in regions where you usually find much stronger enemies. It’s ten minutes long:
Here’s the gist:
Earthbound maintains a flag that the video calls the Overworld Status Supression Flag. If this flag is on then your characters can’t get a number of statuses like Sunstroke, or take environmental damage. If this flag is on, though, and your party loses to a scripted (not random) battle, then a bug is triggered that’s popularly called the Game Over Glitch: the battle loss cutscene music plays, but the screen turns black and nothing appears to work. In fact, the game has not crashed: entering the Town Map screen, or feeling around for and entering a door, will display graphics again, although glitched out. The Game Over Glitch is best known for happening if the player loses to one of the Shattered Man fights in the Museum after the game has been won: during the ending, the Overworld Status Supression Flag is set on permanently, so getting into any scripted fight and losing will result in the glitch happening.
As it turns out, random encounters disable the flag. So there is a hard-to-avoid Mole Playing Rough at the entrances to areas with environmental damage, to make sure the flag is turned off. But the mole is just hard to avoid, not impossible, so if you can avoid it, and all other random enemies of course, and then reach a place with a scripted fight, then lose to it, the glitch will still happen.
Here is a very short video from Seedy, only a minute long, explaining an interesting bug in The Legend of Zelda: Ocarina of Time.
OoT handles fiery environments without the Red Tunic, and being held underwater by wearing Iron Boots without the Blue Tunic, in an unusual away. You might expect them to return Link to the last safe place he had been, like when falling into a void, or else maybe kill him instantly, or at least cause periodic damage. Instead, for whatever reason, the designers chose a unique way to implement the danger Link is in.
While in hot places or stuck underwater without the proper tunic, the game starts a timer, with time relative to the amount of health that Link has. If Link leaves the area or puts on the right tunic before time runs out, the timer goes away and Link takes no damage regardless of how much time was left on it. However, if the timer expires before Link reaches safety, he just dies instantly, “getting a game over” in the clumsy parlance of video games. You’d think it’d be better just to inflict some damage on Link every few seconds, but that’s not how they chose to do it.
Link gets eight seconds on the clock for every full heart he has. Fractions of a heart grant proportional time. While the game only displays health in quarter-hearts, Ocarina of Time actually tracks hearts in 16ths (each full heart is effectively 16 hit points), and each 8th of a heart grants Link one second on the timer.
So, what happens if Link has exactly 1/16th of a heart? The display rounds up, so it looks like Link has a quarter of a heart left, but he’s considerably closer to kicking the bucket than that. He has less health than what’s needed to get a one-second timer. How does the game cope with that?
It does it by just not starting a timer at all! If Link is almost dead, paradoxically, he becomes immune to fire and drowning timers. He’s still in great danger, for any attack on him in this state will kill him immediately, but it makes tunic-less challenge runs a bit more interesting.
Arcade Galaga has an interesting bug that’s been known of for a long time, that can be taken advantage of to cause the enemies to stop firing. The inner workings of the bug are explained on its page on the website Computer Archeology, but here it is in brief: on the first level, if you leave the bugs at the far left or right sides of the formation alive and wait long enough, 10 to 15 minutes, just surviving their attacks, then eventually the enemies will stop firing all together, and will never fire again for the rest of the game.
Why does this happen? Galaga reserves eight hardware sprites for the shots of the enemy bugs. Galaga’s graphics hardware has no way to disable the displaying of a sprite, so if something isn’t supposed to be visible it’s kept off screen, at horizontal coordinate zero. A shot sprite at that coordinate is never updated, and never moves. This is in addition to the game’s internal records of which shots are in use. When a bug wants to fire a shot, the game looks at which shots are available, and if one isn’t in use, it puts it at the proper place, and sets its velocity (X and Y deltas). From then until it leaves the screen, it’ll be updated every frame. When it is detected as having gone off-screen, it’ll be marked as out of play, and its X coordinate will be set to 0. Shots at X=0 are never updated.
The problem is, it’s possible for bugs to fire shots while they are at X position 0. This happens most commonly when bugs at the far left and right extremes of the board attack. The shot is marked as in-use, but it’ll never be updated, and so it’ll never be cleaned up and set back to be available for firing. When all eight possible shots are in this limbo, the bugs can’t fire any more. The machine resets the shots at the end of a game, so the problem won’t affect subsequent plays.
Ben Golden Diamond performed the trick in a Youtube video, and he manages to get it to happen in around seven minutes. He doesn’t explain the precise criteria for doing the trick, but his description will still work, it just has unnecessary steps. It will work on any level, but it’s easiest to do on the first. In the video, sometimes the bugs fire wraparound shots from off-screen. That’s a good indication that the bugs are sometimes firing from the 0 coordinate.
Keep in mind, performing the trick on purpose will disqualify a score for world records. The scoreboard on a local Galaga machine probably won’t care, though.
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.
The Legend of Zelda: Breath of the Wild is a gigantic game, and where content proliferates, so too do bugs. Many of these bugs are highly entertaining (my favorite is the bullet time bounce), but there are some that are just head-scratching, leaving one to wonder why does this happen? That the occur pulls back the curtain on the many technically complex things a big game like BotW does behind the scenes to realize its world, for, every step of a process that a system must go through is one more opportunity for something to go wrong.
Youtuber Jasper has made a 35 minute video about why, if Link stands in a specific spot in BotW, inside the broken corner of a stone wall, the cel shading usually applied to his model goes away, and he appears with normal light shading. In the way of Youtubers, the explanation is contained within a 35-minute discursive video that goes into the history of game lighting, why some older 3D games have graphics that have aged well while others don’t, the basics of cel shading, and still other topics. Here is that video, embedded:
The whole video is pretty interesting, and if you have the time and interest you should watch the whole thing. However, in the event that this is all tl;dw, allow me to summarize.
Because Breath of the Wild is both a huge game and has a dynamic world, baking lighting in into textures would consume way too much storage and memory, so lighting has to be done dynamically.
As an optimization measure, the more complex steps of cel shading are deferred to later in each frame’s rendering. The main rendering is done, then the cel shading is applied afterward, when the visibility of the area has been determined, so this effort-expensive process is only done for visible pixels.
One of the deferred steps of rendering marks which of nine different kinds of material will be applied to each pixel. Terrain in BotW is not cel shaded, while characters link Link are, so they have different types of material that determine whether that shading is applied to them.
In the location where Link’s cel shading disappears, there is a decal applied to the crumbling bridge that erroneously extends over the corner, and overwrites Link’s character material type with the terrain material, causing the cel shading not to be applied to him.
It’s December 31st and our offices are empty for the end of the year. We’re kind of slacking off, so let me link to something out intrepid and gelatinous news reporter linked before. It’s a really great longform article from PC Gamer and is worth a look if you didn’t see it then.
Someone’s looking grumpy!
In summary:
For a long long while, there have been ultrarare mounts in World of Warcraft. Most items, a 1% drop rate is as rare as they go, but a few mounts are generated much more rarely than that. People have spent years grinding for a specific mount and never gotten it. It was dropped by a world boss called “The Sha of Anger.” (Hey, I didn’t name it.)
One such ultrarare item is The Reins of the Heavenly Onyx Cloud Serpent, which allows the very lucky acquirer to summon a nifty glowing black-and-white flying dragon to ride. So popular, and rare, are these items that when they go up on auction they regularly go for the maximum supported price: 9,999,999 Gold.
Players had long rued the immensely high odds of acquiring this item, and others, but had put up with it because Blizzard was the kind of company to justrule things like that to happen, and what you gonna do? Go to City of Heroes?
Early in the item’s existence, however, players noticed that the item wasn’t just generating hardly ever, but in fact, entirely never. A bug in the game meant no one had gotten it. It was just so rare that everyone assumed they just hadn’t seen it yet. Oops!
Much more recently, however, due to another bug, the item became much more common to players of a certain race. The players who had discovered this faced conundrum: be responsible and report the bug to Blizzard, or hoard the knowledge to prevent Blizzard from knowing about it, keeping it off of forums as long as they could, which resulted in the greater player base not realizing it was possible, in order to allow the precious loophole to persist for as long as possible.
If this kind of thing is fascinating to you, and if it isn’t then I wonder why you’re reading this blog, it’s one of the best pieces of game reporting I’ve seen lately.
The Final Fantasy series is loaded with bugs throughout. A full recounting would be much more than a longpost’s worth, but here is a quick description of one specific example, from Final Fantasy IV (originally II in the US, but most people now will probably think of it by the Japanese numbering anyway).
The door to the pub is push-type, potentially causing Problems. Image from mynockx’s guide on GameFAQs.
Some RPGs, instead of coding area transitions all as a sequence of doors and destinations, instead use a form of stack to record where the player was when they entered the door. “Stack” here is a term from computer science, a data structure consisting of a region of memory and a pointed within it. Data can be “pushed” onto the stack, which means putting some number of bytes onto it and advancing the stack pointed by that number. Stacks can “grow” either up or down, meaning when the pointer advances, it’ll go in that direction. When the data is needed again, it’s read off the top of the stack, then the pointer is pulled back to its original position.
So how the door stack works is, when a player enters a location, say enters a town from the overworld, their location before entering is “pushed” onto the stack and they are then moved into the town’s entrance. When they exit the town, their old location is “pulled” from the stack, leaving it empty. (Actually, the data is still there, but because the stack pointer has been decremented, it’ll be overwritten the next time the player enters an area.)
Why use a stack? Well mostly it’s a convenience thing for the programmers. A door’s location can either be “into” an area, or “out of” it. “In” doors have to know where they’re going, but “out” doors just have to know they’re going outside. But it helps in one particular instance; if a game has a spell or item like “Exit,” “Outside,” or “Warp,” it can work simply by pulling every location off the stack until it gets to the last one. This means the programmers don’t have to have every location “know” where a given area is on the World Map. Just rewind the door stack until you get to the last location on it, that must be it.
Well there’s a subtle bug in some locations in Final Fantasy IV where some transitions that push when they should pull. One such transition is the one to the pub in the Dwarven Castle. When you enter the pub, the way in is pushed onto the stack; when you exit, instead of pulling that location off, the way out is pushed onto the stack.
There’s only so much memory reserved in a stack, which for old games is usually implemented as a single page (256 bytes) of memory. The pointer into it is thus one byte long, and so if the stack fills up, it wraps around. If you find such a door, and go through it enough times, you can cause it to overflow on purpose, with unexpected results.
This can be taken advantage of in Final Fantasy IV by overflowing the stack, then going through a pull-door, which causes the game state to be read from unexpected memory. Speedrunners (you just knew they’d be involved) use this to flip rapidly to the end of the game. Most players will never notice this very subtle bug, since when you return to the world map the game knows enough to completely clear the stack.
Something I’ve noticed about the 8- and 16-bit Final Fantasy games is, if there is a potential for an obscure bug somewhere, there is almost certainly going to be an example of that bug somewhere in that code. A lot of these bugs are only visible to a player with obsessive observation or repetition. This results in spells with unexpected effects, stats with no function, features that don’t operate, and item duplication bugs. Truly, it was an age before unit testing.
There was an error in the data prep in many NES games that caused them to reverse the bit order of samples. Or more accurately, the games encoded the samples correctly, but the flaw is in the NES sound hardware.
Another game this affects is the unlicensed Tengen NES game KLAX. In the arcade KLAX had very little music, but the NES version has excellent music that relies heavily on sampled instruments. There’s a fixed patch for that game on romhacking.net, too!
The wonderful podcast Keep Nintendo Weird (Podchaser – YouTube), which spotlights a lot of awesome and unusual games made for Nintendo systems, recently covered a doozy: Space Station Silicon Valley! One of a pair of games made for the Nintendo 64 by DMA Design before they became known as Rockstar North, SSSV is a clever and charming action puzzle game where you’re a microchip that can take control of robot animals in a rogue space station.
It’s notable for its trademark humor, its inventive gameplay, and a weird bug that, as I discovered personally soon after its release, actually makes it impossible to finish! While the main story can be completed, one of the optional trophies hidden in the levels won’t collect when you come into contact with it, and it was a couple of generations before software patches could be distributed after a game went live, so there is just no way to 100% the game without hacking either it or your save file somehow. Oops!
