I'd really like to understand glitches. How do they work? How do you discover them?
Sure, I've found my fair share by just playing a game until something weird happens. But could it be more scientific than that?
I recently watched Sleepz's Super Mario Bros. 2 vid. In the first level, he does some crazy shit to skip having to blow up the brick wall. This glitch appeared so strange to me, that I wonder how it was ever discovered.
Is it just luck? Or do you have a hunch? Do you say, "Maybe if I do this... something might happen."
A glitch is, in a way, error handling. Am I wrong about this? Maybe you have some boundary, like a wall or something, but you have something that propels you through it, like an explosion or something. Then maybe the game just continues to push your character through the wall, allowing you to skip a lot of stuff. Why does this happen, rather than a total lock-up?
Now, the game is deterministic. The better you understand the physics of the game, the better you can discover glitches. Take Mario Bros. 2 again, though. The physics were known, for the most part. But it took many many runs before this particular glitch to skip the brick wall was found. Knowing the physics may allow you to see glitch potential more easily, but what about the "hidden glitches." What steps do you go about finding them?
Hypothetically, if you had the source code, could you discover glitches more easily? You'll know, exactly, the rules the game follows, rather than having to learn them through observation. Would this aid in glitch discovery?
Your thoughts.
Games are tested, but there are certain boundary conditions that are sometimes overlooked.
From SMB2, I can't say for sure since I never tried it, but this is how it looks from my perspective. If you collide with an enemy being thrown (something rare since a thrown enemy is usually moving AWAY from you), it might fall into the floor. This is seen twice in the movie. Next, the enemy is picked up while it is under the floor. The result is that the player falls into the floor. Finally, the player climbs down the ladder (which is still working?) and since they go below the bottom boundary, the proceed to the linked area.
Stuff like this is probably found by luck most of the time. I found two glitches (?) in Mega Man X entirely by accident in my attempt to get perfect timing and look cool.
Yes, a glitch is defined as a flaw in the game's design. Some are inherently present (ie. bad collision detection in general) which can lead to exploits, like wall-jumping (SMB) or even passing straight through walls (practical uses for the High-Velocity Bum-Rush in Mario 64).
Having the source code probably isn't too useful for finding such extreme conditions. Unless there's something blatantly wrong, they'd probably go unnoticed. (ie. when the player jumps, are they partially inside a wall? Is this the kind of thing you'd notice?)
There's my little rant. All points on buggy game physics are based on attempts at rational thought after watching and/or performing these glitches myself and are not indicative of my owning source code to any of these games. Offer void where prohbitied. :)
Joined: 2/15/2005
Posts: 246
Location: Torquay, England
Now, I have never played a Mario game in my life, apart from a few times when I was at a friend's house. So I'll explain what I can think of using my experience with Sonic games instead.
In particular, the "being-pushed-through-a-solid-wall" glitch happens because you somehow get inside a wall (eg. pushed inside by an object, and the game doesn't recognise that you've been squished), and then the game will use it's collision detection to say "there's a wall to the left, so go to the right" and then doesn't bother with any other collision detection because it's not been programmed to cope with the inside-a-solid-wall situation.
One of the most obvious glitches used in the S3&K record run is the "impossible jump" at the start of HCZ1. That, I believe, is due to the game setting your being-pushed-by-a-fan status to off, and setting your being-in-the-air to on a frame later, giving you one frame's time to jump.
Also, some "glitches" are simply bad level/object design. For example, SprintGod managed to go straight through a blue tube in HCZ2. This is because whoever made the mappings for that level forgot to put enough solid blocks underneath the pipe - and the result is, the instashield cancels all detection, and by the time the collision engine starts again, Sonic is under the pipe.
As another example, in Streets of Rage 2, it's possible to hit Jet or even Vehelits using a normal combo, under certain circumstances. The collision engine in SoR2 is rather crap anyway, so it allows you to hit them for some reason.
I can outline three categories:
Extreme cases.
Situations that occur so rarely in a game that if the programmers had
programmed the game to check those special circumstances, the game would
have been bigger and slower. So they omitted the checks.
Quick and dirty programming
The game might implement a quick-and-dirty way, such as in SMB1 and SMB3:
it's no secret that Mario can occassionally end up partially inside a solid
matter, and for that purpose there's another hack: the game ejects Mario
from the wall to a certain direction. That behavior is faster to execute
(lag less likely) than a pixel-precise collision check.
Mistakes in programming
Sometimes they are mistakes, such as in Rockman 1: It's an off-by-one error
in the ceiling collision check - a very common type of programming error.
It's a process of a few aspects.
Finding something suspicious.
Anything that catches the attention: Mario's vertical movement suddenly
stopping when he bumps into a wall while jumping is a good example.
Understanding the game programming.
When you see something suspicious in the game, you need to construct
a model in your mind of how it works. In a way, this is of reverse
engineering the game. The game source code could help in this, but
it can be almost as difficult to spot things like that as by playing.
In SMB2, the ladder trick is a combination of:
- the observation that thrown enemies regain their movement differently
(or don't regain at all), depending on how the player character is hurt.
- understanding the game programming; a certain part of the monsters' program
is not run while the player character suffers in pain, and it resumes after
the player character regains control.
- observing that a monster that has been placed under the floor can be picked up
- trying what happens when that happens under a climbable thing.
Knowledge of common caveats.
The growing understanding of glitches of many games helps greatly in this.
Some caveats exist in many games. Often, they're limits mandated
by the environment: perfect collision checks need too much CPU time,
so they use less perfect collision checks ("quick and dirty programming").
Some caveats we have collected at the common tricks page.
Maybe this is kinda out there. But could you overload a variable, and have that extra information spill over to the next location in RAM, which might help you out somehow?
Yes, that'd be the sketch glitch in FF6.
But you probably wouldn't want to do this very much. You know how much the Sketch glitch screws up the game in FF6.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Sure. Take F1 ROC 2 for example, it's not easy to earn money in that game. The money is stored in 4 bytes IIRC. To the programmers anticipating anyone getting over a billion $ was unfathomable.
I went ahead and hacked the RAM so I should start off with a fortune, turns out next time I got money in the game, it overflowed and my cash was now ~$300 instead of the 4.something billion I had before.
If that happened to someone who didn't hack the game, but just kept on playing for years like a madman, I bet s/he would have been fuming.
If you find a game where it just increments every next byte when something increases, you can do what you want in the game to a certain extent.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Exactly. You can't do that in a speedrun though. One time I hacked Zelda 1 to give myself a higher ring. There are three legal ring values for the game, 00 -- no ring, 01 -- blue ring, 02 -- red ring. If, with 00, it took 1 hit from an enemy to hurt you, with the 01 ring it would take 2, and with the 02 ring, it would take 4. As you can see, it keeps doubling. But I realized that after the 08 ring, you become invincible. 2^8 is 256 though. I got hit more than 512 times without losing any life.
The reason for this is, the counter for how many times I got hit was 1 byte. It could only count up to 255. That's 11111111. To continue incrementing, 256 would look like 1 "00000000". The quoted part is where the game is looking to see how many times I've been hit. It, essentially, keeps going back to 0 and link will never get hurt.
But this glitch isn't legal because it's impossible to get a 08 ring in the game. Some counters in games you can manipulate though. Such as coins, men, score, money, etc. It's probably too unlikely to even consider, but could getting too many men in, for example, Mario somehow glitch the game in an adventageous way?
In certain Pokémon games, there are certain events that mess up the game and bring up a Pokémon carrying the "MISSINGNO" name, meaning that it's an index to the Pokémon name table to a slot with no valid Pokémon.
It has some weird consequences, including warping around the world, catching a Mew and destroying savegames.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Ramzi wrote:
Maybe this is kinda out there. But could you overload a variable, and have that extra information spill over to the next location in RAM, which might help you out somehow?
I want to see more of these glitches. :)
EDIT: in fact, do you know any movies that show off these tricks?
Joined: 2/15/2005
Posts: 246
Location: Torquay, England
Bisqwit wrote:
bobxp wrote:
What's the Missingno glitch?
In certain Pokémon games, there are certain events that mess up the game and bring up a Pokémon carrying the "MISSINGNO" name, meaning that it's an index to the Pokémon name table to a slot with no valid Pokémon.
It has some weird consequences, including warping around the world, catching a Mew and destroying savegames.
Ah, never had that happen to me but I saw it mentioned a lot on gamefaqs, so I wondered what it was (and never got around to asking until now), thanks ^_^
I thought about posting this, and decided not to. Then a couple days passed so I decided to post it. And here I am.
I was experimenting with Mario 1's lives to see what happens when I overflow it. Getting 256 lives does nothing, except restart the counter. But I found something interesting. The variable for lives is a signed integer. This means Mario could have a maximum of 127 lives. (If Mario has two men it's saved as 03. For Mario to have 127 men, the hex value for 128 is saved.) If Mario then gets one more life, it goes to -128. If you die after this, you get a game over.
A pretty strange movie to make/watch would be using that trick to get tons of men, until the counter goes negative, and then dying once and getting a game over.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Oh that's easy enough to do...
Especially in the lost levels, I can get unlimited lives right off the bat.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Why?
Why would it be a signed byte, though? If it was unsigned, a player could get 256 men before dying and getting the game over. You can't have negative men. Why did the programmers make that variables signed?
If they were planning on allowing the player to get more than 127 lives, you'd think they'd use a field 3 digits wide to display the life counter while they were at it.
Maybe it was easier to make it a signed variable and no one gave it a second thought.