I wonder what we would come up with if we (nesdev) tried to list the most "useful bugs" in a game. Can't be something intentionally put in, like the 2nd controller warp trick in Crystalis. Has to be a real bug or design flaw, like accessing the minus world in SMB1, or the "secret rooms" in Metroid. Although rather cool, neither of those are very "useful".
I already mentioned some economics cheats for
Genghis Khan here
http://nesdev.com/bbs/viewtopic.php?p=75035. Any other candidate "useful bugs"?
There's a lot of this stuff out there already on other sites, such as GameFAQs, TASVideos Game Resources, or even TV Tropes.
Dwedit wrote:
There's a lot of this stuff out there already on other sites, such as GameFAQs, TASVideos Game Resources, or even TV Tropes.
I suppose that you're right. Those sites might list bugs within individual games, but I was more after a list, like "the top ten most _useful NES game bugs_". Oh well. Its no big deal. I'm just having an odd day and this thought popped into my mind.
dwedit, are you still working on that 2-d scrolling game for the coding compo?
Um... shoot. You just wanted NES games? I totally wrote a huge list of bugs from games across all consoles.
Mushroom Jumping: Super Mario Bros.
Wallkicking: Super Mario Bros.
Skipping the Rat Race Boss (without a warp, done by abusing the camera in co-op): Battle Toads.
I know a lot of glitches, but not many that are both on NES and "useful." Will give it a little more thought, though.
Edit: And do you want just "useful" or totally game breaking and useful?
Like for instance: Battle Kid invincibility in early versions of the game. It's totally game breaking but certainly "useful" (Realizing I doubt you want homebrew glitches anyway, but it's the best example I can think of for that.) (HAHAHA. Reread topic title. So homebrew is fine. My question on game breaking or not stands.)
Edit 2: Right... Totally forgot the pause glitch in early megaman games.
Edit 3: The Kirby's Adventure UFO trick that lets you keep the UFO ability until you need to go up a ladder, rather than only for one level.
Kasumi wrote:
Edit 2: Right... Totally forgot the pause glitch in early megaman games.
Yeah, I forgot that one. That is a "useful glitch" for sure.
What do you mean by "game breaking"? Do you mean a glitch that allows a sequence break in an RPG / adventure game, or a glitch that "breaks" / crashes a game (not useful, imho, unless it corrupts your save-slot with lots of useful items to use after you reset, like in FF-IV on the SNES).
I would consider a "sequence breaking" glitch to be useful. That super-duper mega weapon that you're support to get right before the final boss... getting in early is definitely useful.
Game breaking can mean it breaks the mechanics of the game leaving no challenge or very little. Any glitch that makes you unkillable and still able to play through the game would be game breaking.
Game breaking is anything that allows an RPG to be beaten in < 5 minutes. Anything that allows you to skip basically all of the "meat" of the game is. Link's Awakening screen warping is game breaking. Anyone that knows how to do it can get the credits to roll in less than ten minutes with very little effort.
Invincibility takes NEARLY all of the intended challenge out of Battle Kid, so that's game breaking.
I'm on the fence about Super Mario 64 stuff. Beating it with 0 stars is tricky to impossible without TAS, and beating it with 16 isn't necessarily THAT bad... it's kinda like using the warp zones to skip almost the entire game in SMB, except unintended by developers.
Techniques like Wall jumping in SMB, I wouldn't consider to be game breaking. They can be used throughout the entire game, and are obviously glitches. But they could've been intentional really. "Any sufficiently advanced bug is indistinguishable from a feature." and all that. Like wavedashing in Super Smash Bros. Melee.
Skipping entire levels by pressing opposite directions at the same time in Wario Land is not, but it probably would be considered so if ALL the levels could be skipped instead of just a few.
I'm just asking if things that allow games to be beaten stupidly fast (and are available to non TAS players, otherwise their usefulness is debateable) count. (not that I even KNOW many glitches like this for NES, but I'm just wondering where you stand for this particular list.)
The Kirby UFO thing is another one that some would debate. I wouldn't consider it game breaking, but it REALLY, REALLY makes things easier and speeds things up. So that's definitely a good one for your list.
I would say that for a glitch to be "useful" a human player (and not only a TAS) would have to be able to invoke it.
Asking this question has really opened my eyes about game bugs. Many of these I never knew of, or even thought about the bug category.
My question started out as a "hey, I wonder... I'll ask my peeps on nesdev, they will have ideas" into "what should I look for when testing my game". The SMB1 "wall jump" bug sounds like a glitch in collision detection and/or general game physics. I've never seen it before, so I'm not exactly sure what it is (I'll search for it on youtube later tonight).
My own game is fairly simple in terms of game physics. But is has two nasty bugs are are more design failures than anything. I have ideas on how to correct them, I just haven't focused on them yet. I wonder how many bugs it has that I won't find until it is way too late.
There are a few of these "quirks" documented in old issues of Nintendo Power (not to mention TONS of tips/quirks which don't exist on GameFAQs; a good example is the infinite-item trick in Robowarrior, which is the most convoluted thing I've ever seen -- let me know and I can document how to do it). Thankfully I have quite the collection; MickoZ has wanted me to scan them all in, but good lord that'd take forever.
clueless wrote:
I would say that for a glitch to be "useful" a human player (and not only a TAS) would have to be able to invoke it.
Is that all? Okay.
Here's a video of SMB wall jumping:
http://www.youtube.com/watch?v=JP6uXD61LQMYour assumption is correct. Simply put, one can jump before one is ejected from a wall, but only from the very tops of tiles.
Kirby TAS featuring the UFO glitch.
http://www.youtube.com/watch?v=GdUWzc6T9dsIt requires one frame timing, but it's not only for TAS, since if you mess up Kirby games reload the enemies for you. You drop the power on the frame you get hit.
Getting the UFO from the lottery to get a "permanent" UFO earlier is trickier without TAS, but can of course still be done with consistency.
clueless wrote:
"what should I look for when testing my game".
I happen to be in LOVE with glitches, and quirks in video games. I liked them even before I was a developer, but reading about them, always gets me thinking about what assumption or oversight causes the game to break, so I can avoid such things when I develop myself.
Often people don't check what happens when certain actions are done in the same frame. Battle Kid's invincibility and Kirby's UFO glitch are caused by this.
Other times they imagine certain things are IMPOSSIBLE or unlikely. Lots of games controlled mainly with a d-pad behave strangely when opposite directions are pressed because such a thing should be impossible. Some games assume a character can never move faster than a certain speed, or be off camera. Hyper Sonic can glitch through walls very, very easily because his double jump locks scrolling, AND makes him move super quickly.
What should you look for in testing? Everything. Try as hard as you can to break the logic of EVERYTHING you write. Breaking logic is best, because really RARE cases that might slip by you or never occur for you while just playing can be caught.
Here's a list of common errors or ways to abuse a game:
http://tasvideos.org/GameResources/CommonTricks.html
Not all are necessarily glitches.
And this guy has an entire series about Sonic:
http://www.youtube.com/watch?v=XEOsmMOc_BA
When I was watching this, I was like, "Wow. I actually understand why almost all of these glitches exist." There's a video for pretty much every level.
I honestly recommend watching some TAS videos too (NES ones or for any console, it's up to you), and in addition to watching them, read the documentation for the submission. Usually they go into great detail about what glitches they're doing, and what's the underlying behavior that causes them. Perhaps that's a lot of off topic babble, though. I'll look for more that are useful so you can hopefully at least get 10 for your list.
</ranty post by obsessed glitch man>
Kasumi, this is great. This is the direction that I wanted to take this topic.
I've been a "professional" (I get paid) developer since I was 19. Testing is huge. Regression tests, code coverage tests, profiles, scaling up the size of the data sets and retesting, etc... Its good stuff. A lot of it applies to NES too. At work one of my favorite testers is actually a girl in marketing. She has a knack for finding obscure bugs in my code (black box testing). It is very good that she finds them (and documents how to reproduce them before filing them with the developers), before a customer does.
To be honest, I've not attempted to see what my game will do if given "impossible" joypad inputs. I test using a SNES controller hooked up to a USB port (retrousb adapter). I should test with a keyboard and send bad inputs too.
I've seen the TAS of Metroid. Kills Mother Brain in about 9 minutes, iirc. The only TAS video of Crystalis on youtube cuts off about 75% of the way through the game, which is a bummer, as I wanted to see what the author did in the last 25%.
I have special logic in my game to detect when my main thread takes longer than one frame to process its logic (ie, it is still running and not sleeping when the vblank NMI fires). When this happens (and its a debug build), palette #0 (normally black) increments. I should force my main loop to take longer than one frame 50% of the time (for testing purposes only) just to ensure that the game doesn't crash.
Dragon Warrior 3 had an infamous bug that corrupted your inventory, spell list, character name, EXP, and RETURN destinations. A couple of TASes used this bug. I helped disassemble and analyze this bug.
Normally, you walk around with your party, and the game checks whether you are standing on Swamp or Barrier tiles, and damages you.
The game is designed to handle different situations where your party order may be different than the arrangement of the characters. When a character is dead, they are moved to the back of the party as a ghost. For example, if the second party member is dead, the effective party member order is 0 2 3, and there are 3 living party members.
The game also maintains a small log of what tile types the characters have recently stepped on. So when your party leader steps on a tile, the next time you take a step, the list is pushed one byte forward, and the current tile moves to the front of the list.
So the normal routine reads player ID numbers from a small list, and looks at a small list to see what terrain type they are standing on, then damages them by 2 if they are standing on a swamp tile. So far, so good, no problems. It limits the number of party members checked to the number of alive party members.
This routine goes completely haywire and berserk if your party happens to contain 0 living party members, it iterates 255 times instead of 0.
When deciding whether to terminate the loop, it increments the counter, then checks if it is equal to the number of living party members. With 0 living party members, it iterates through the loop 255 times instead of 0. So it looks up the party member number from the small table with 4 values, and looks up the terrain they are standing on from another small table with 4 values. Except these index numbers are way out of bounds, it's grabbing some arbitrary number from the zero page, then another corresponding arbitrary number from the zero page to see what terrain they are standing on.
So let's make up some numbers. Let's say it's checking position #75 (in a range of 0-3). So it might read party member #27 from the party member number table, then it finds that the tile is a swamp tile. It will deal 2 damage to party member #27. So you go to the HP address in memory (071C), add 27*2 to that address, you get address 0752 which is inside the memory range for Return Destinations. Subtract 2 from the 16-bit value there. It borrows from another party member's return destination list, taking away return access to Allaihan, and grants return access to the end-game towns of Hauksness, Cantlin, Kol, and Rimuldar.
So that's great and all, but now you need a dead party walking around in order to see this bug. Normally, the game checks for a dead party whenever you take damage or become paralyzed. To stay alive, you need at least one party member who is not dead or paralyzed.
There are two bugs that can give you a dead party. One involves a situation where your party temporarily goes down to just the lead party member, like the house in Assaram where you "get your fortune told". What normally happens is that it takes the first living party member, and that becomes your party. But if your entire party is dead or paralyzed, it will always pick the first party member. There is an item in the game which will paralyze the user, it's the Dream Ruby. This item is bugged in that it does not check if your party is all alive after you use it, so you can end up with a party which is all dead or paralyzed. (It probably didn't get very heavy testing since normally the player just gives up the dream ruby soon afterwards as a quest item, and doesn't expect to be able to use it as an item.)
The other bug involves removing characters from your party at Lucia's Place in Allaihan. Normally, the game checks if removing a character would give you a dead party. But it does not check if removing a character would give you a paralyzed party. And if your party contains only paralyzed members, it breaks the check for only dead party members for some reason. So go to Lucia's Place with one living party member, one paralyzed party member, and two dead party members. Remove the living party member, and you have only paralyzed or dead party members left. Then it lets you remove the paralyzed party member. Presto, only dead party members left. You can also add other dead party members to your party if you want to. (Normally, it is very hard to see this method in action, since every time you take a step, there is a chance it will wake up paralyzed party members, so you would need to have very good luck to avoid paralyzed party members returning to normal within 30 steps.)
Moral of the story: Use >= to check array bounds against a limit if you know your size is less than 127, not ==.
Dwedit, awesome analysis. That's really cool. Very intricate.
There are four famous bugs in Dragon Quest IV:
1. Gate glitch. After opening a large gate of a castle, etc., make your character walk to the opening. Now, use the world map to view it and return to the game. The gate will be closed again, but with the character overlapping on it. Now, use the 'door' command and an extra gate will appear in front of you. Using this trick continuous you can make your party walk up unobstructed like passing though walls, etc. and enable you to access areas that you normally cannot reach (at that time at least).
2. Critical hits on bosses. If you select 'retreat' 8 times during a boss battle (if your party are strong enough to withstand the boss' attacks for 8 turns anyway) ALL attacks of your party members will turn into critical hit.
3. In the casino in Chapter 5, you can buy 838861 tokens for only 4G, so you don't actually need to play any of the casino games to earn more tokens to exchange for any useful items.
4. Invisible balloon. After getting the ship in Chapter 5, but before you actually reach the point of getting the balloon, you can travel to the upper-left corner of the world map and press A. You'll get aboard the balloon(but it's not visible on screen) that you don't have yet. Since you can travel anywhere with it this is a very powerful sequence breaking glitch.
I remember I once came across a page explaining why 2 and 3 could be done (from inspection only, not analysis of the disassembled codes, so this may not be truly accurate) and they're all overflow errors:
2. During a battle, when you select 'retreat' your party may or may not succeed in running away from the battle, but the game is designed such that your party will always succeed in running away in the fourth retreat action. This is speculated as having 2 bits in the game state assigned to a counter, which is set to 0 when a battle begins and have it incremented by 1 after each failed retreat action, so when the counter accumulates to 3 and you retreat one more time the game will let you out of the battle. However, you can NEVER retreat from a boss battle, and when you select 'retreat' for the 4th time you will fail but the counter will still be continuously incremented. This causes an overflow as it would change other bits (other than the 2 assigned to the counter) in the byte. Incidentally a certain bit corresponds to a spell effect (I think this spell could only be learnt at a very high level or something like that) that makes all the attacks critical is on the same byte, and this bit would be set when the counter rolls up to 8, which causes this very useful glitch.
3. When you buy tokens in the casino, you can enter up to a 6-digit number, but this is a bit odd as even after you have capped your gold the maximum number of tokens you can buy is much, much less than the number of provided digits (you can have at most 99999G and a token costs 10G, 200G and 20G in Chapter 2, 3 and 5 respectively, so at most you can only buy 9999 tokens at one time). As gold in the game is capped at 99999G it's actually stored as 3 bytes, or a 24-bit number. So, when you enter a very large number of tokens to buy, the game calculates how much gold you have to pay and have an overflow if the required amount of gold exceeds 24bits, and thus the required amount will roll back to 0G when it reaches 2^24 = 16,777,216G. In Chapter 5, you need 20G x 838,861 = 16,777,220G to buy 838,861 tokens and thus in reality you only need 16,777,220G - 16,777,216G = 4G for that. Obviously there are other 'magic numbers' to buy a large number of tokens for a very low cost, but it happens that 838861 is easy to remember and possibly the most economical case and so it's widely known. (As the price of tokens differ from chapter to chapter, it is possible to pull off this trick in Chapter 3, but you need other 'magic numbers'. It is not possible to do this in Chapter 2, as each token costs only 10G and buying 999999 tokens needs 9999990G, which does not exceed the 2^24 mark.
4. I think the cause of the invisible balloon glitch is pretty obvious. The game is programmed such that the balloon is always on the map, even before you actually acquire it. They just placed it initially at coordinates (0, 0) and have its sprites not displayed (or they used transparent sprites) before you get it.
I think most of these glitches were fixed in a later revision of the game but 3 was never fixed (I'm not sure), so it seems that 3 may not be a bug and can be an intentional trick (after all, you can only have 99999G max, why would the programmers let us enter a 6-digit number when buying tokens?). Also, (unfortunately) all these glitches were fixed in the US DW4 version (and any subsequent remakes, including the PS1 and NDS versions) so you cannot pull them off with the US version. AFAIK 3 was fixed in the US version merely by reducing the number of digits in the number of tokens one can purchase.
Edit: Added exact ways to make these glitches happen. Corrected some data (4 retreats -> 8 retreats) and added the invisible balloon trick.
The casino token buying glitch does NOT happen in the US version, instead, it caps the value at more 9's than your gold could possibly contain.
Rygar has a glitch that allows player to levitate, and fall to pits without losing life.
Castlevania generates a distorted game screen,if left or right button is on autofire.
There's a passage in level 6-2 in Ninja Gaiden where there's one of those cloaked guys tossing stuff at you and, you can make him glitch into nonexistence near the edge of the screen. I got into the habit of causing this to happen to get through that passageway, though I have done it a couple of times without using the glitch.
Fantastic Dizzy have 1 really useful and easy to do glitch:
Just open inventory screen when you get hit by spider/mouse.
You'll have unlimited enrgy until you get killed by some "instant killing" event.
Also I can remember "Popeye 2.Adventures in Persia" have levitating bug.
the blaster master grenade+start button glitch, too
Hold up and A on controller 2 in Megaman 3 freezes bosses and Megaman, but you can still shoot.
That's an in-game cheat, left over from debugging the game, not a glitch.
Dwedit wrote:
That's an in-game cheat, left over from debugging the game, not a glitch.
. Well, good to know I guess.
I got another Megaman related one though, does anyone know why when using the Game Genie on Megaman 1 and 2 the sound corrupts? These are the only two games I know that do that.
nothingnew wrote:
I got another Megaman related one though, does anyone know why when using the Game Genie on Megaman 1 and 2 the sound corrupts? These are the only two games I know that do that.
Back in the NES days I often used to cheat in MM2 using the GG, however, I don't think I ever noticed anything strange about the sound/music while at it. This was the PAL version, if it matters somehow.
The game genie sets some sound registers...never clears them. Nor does megaman. And it fucks up the sound bad.
do you know why the gg sets sound registers? and also, when you say megaman does not, do you mean that the code for megaman doesn't clear the sound registers habitually?
yesyesyall wrote:
do you know why the gg sets sound registers?
To make its sound effects.
Quote:
and also, when you say megaman does not, do you mean that the code for megaman doesn't clear the sound registers habitually?
The Mega Man music engine just uses the default state of the pulse waves' sweep registers, which ordinarily is no sweep.*
* Some conditions apply to the default state, such as not being able to access the lowest octave of the pulse waves.
How about a Game Genie BIOS hack that removes the sound fx?
Are there eight free bytes in the Game Genie BIOS? If so, I imagine it could be patched to disable pulse 1 and 2 sweep before it launches a game:
Code:
lda #$08
sta $4001
sta $4005
That should work. Wasn't there a disasm of the source floating around?