Glitch

This article is a summary page for different variations of a glitches, etc. when talked about as a whole.

Bulbapedia also has an article about Glitch.

Wikipedia also has an article about Glitch.

In the context of video gaming, a glitch is largely synonymous with what would be called a bug in the context of software in general — an error in the programming of the game that causes it to produce results unintended by the developers of the game. Such unintended results may range from simple graphical weirdness, game freezes, or sequence breaking, to (specifically in Pokémon games) strange Pokémon, moves, or items that should never appear in normal gameplay. Trying to play the game "normally" with such Pokémon, moves, or items may lead to even more unexpected results.

The use of the word "glitch" is standard in the video gaming community. While the word "bug" always carries a negative connotation, many video game players see glitches in a more positive light, as extra contents in the game, and/or tools that could be exploited to achieve something otherwise difficult or impossible, such as speedrun records. Still, some glitches do have (usually) harmful effects like erasing the player's save file, although most glitches are harmless, especially if the player has enough understanding of the glitch in order to avoid the harmful effects.

In addition, the word "glitch" is generally used more broadly and loosely than "bug" would be used. For example, non-natural glitches usually do not reflect bugs that need to be fixed (instead, once their parent glitches are fixed, they cease to exist). In a sense, "glitch" reflects weirdness from the player's perspective, whereas "bug" reflects incorrectness from the programmer's perspective.

Common causes

Some glitches are caused by a simple typo in the code. For example, in Pokémon Gold, Silver and Crystal, the Love Ball boosts the catch rate for the wrong gender, which could have been fixed by changing a single "ret nz" instruction to "ret z". Such glitches are usually very minor, but this is not because a simple typo could not have a major effect (it certainly could). Instead, the reason is that such a simple glitch would be very easy to find in testing, unless its effects are so minor that it would get overlooked anyway.

More commonly, glitches are caused by an interaction between two or more pieces of code, and only manifest under rather specific circumstances, such as a special combination of in-game items or a special combination of joypad inputs. A ubiquitous theme in glitches is that one piece of code breaks an assumption made by another piece of code, causing the latter piece of code to exhibit unintended behavior. That unintended behavior can then break other assumptions made by the rest of the program, and the situation soon spirals out of control.

Some common patterns of breaking assumptions include:

• Out of range: A number is not in the range the programmer assumes it to be. This could be caused by a simple mathematical mistake, such as Wally's Zigzagoon dealing too much damage in extreme cases, enough to KO the Ralts he is supposed to catch. Too many items in the input can also cause an index variable to go out of range, for example when there are more NPCs on the screen than the game is designed to handle, or when a string does not have a proper terminating character.
  • If an out-of-range value is used in arithmetic calculations, it may result in more out-of-range values, and it may also cause arithmetic overflow or underflow. For example, the experience underflow glitch happens because the minimum level of Pokémon in Generation I is supposed to be 2, so a level 1 or 0 Pokémon would cause one of the experience formulas to underflow.
  • If an out-of-range value is used as an index into a table in the memory, it may cause a buffer overflow, where data from another memory region is read or written instead. In most cases, this results in data being interpreted as something completely different, which may lead to more glitchy behaviors. For example, the expanded item pack consists of various data stored after the normal item pack, interpreted as items and item quantities, and it also allows the player to manipulate those data by switching and tossing items, etc.
    • Specifically, if an out-of-range value is used as an index into a jump table, then the game may begin to interpret various data as code, which is fairly likely to result in arbitrary code execution (ACE). For example, most glitch items have out-of-range IDs, and that is why many of them are capable of ACE.
• Broken data redundancy: In many cases, the same piece of information is stored more than once, possibly in different formats, for easier manipulation. If this data redundancy is broken (i.e. values from different memory locations disagree with each other), unintended behaviors can happen. For example:
  • The Surf down glitch happens because the direction the player is facing is stored twice.
  • Unstable hybrid Pokémon exhibit many strange behaviors because the species of a Pokémon is stored twice.
  • Both methods of item underflow rely on the fact that the number of items in the player's bag is both stored as a number (the item count) and implied by a terminator in the item list. By desynchronizing those two values, the item count can become 0 while the actual item list still has items, enabling the player to perform either trick.
  • The 2x2 block encounter glitches arguably happen because the localizers assumed that the bottom right subtile and the bottom left subtile are equivalent for the purpose of wild encounters. (Alternatively, it is simply a weird typo that was uncaught because for the most part, those two subtiles are equivalent.)
• Unexpected interruption: Programmers often think of multiple pieces of code as a whole procedure, even when they are not immediately adjacent to each other in the program. If something happens in-between and unexpectedly changes a memory address or a register used by the procedure, then the second half of the procedure will read stale data. Such an unexpected interruption can be caused by:
  • A well-timed joypad input, such as in the usual (long-range trainer) method of the trainer escape glitch.
  • A random event, such as in the death-warp method of the trainer escape glitch.
  • The player saving and resetting. For example, the Safari Zone exit glitch happens because the map script of the Safari Zone entrance makes use of a temporary variable that does not survive saving and resetting.
  • A hardware interrupt, such as in the Professor Oak's lab music glitch.
  • A piece of code added later in development. A clear example is the Substitute drain move not missing glitch. Note that stale registers are usually caused by this scenario, because in the other scenarios, either the interrupted procedure should know not to rely on registers, or (for a hardware interrupt) the interrupting procedure should know to save their values.

This list is not intended to be comprehensive. As an example of a broken assumption that does not clearly fall into any of the above categories, the Walk on water through Surf glitch happens because the programmer implicitly assumed that the Start menu does not cover any of the tiles adjacent to the player, which is valid in the Japanese versions, but not in the Western versions where the Start menu is wider.

External inputs

A special case is when the programmer directly make assumptions on external inputs. This is almost always a bad practice, because while data generated by the program itself may be guaranteed to follow some specifications as long as the logic of the program is sound, no such guarantee can be made for data supplied from the outside, so such assumptions almost always lead to glitches. Still, one assumption often made by games is that D-pad input combinations like Up+Down or Left+Right is impossible, which is valid for most types of unmodified original controllers, but possibly not for custom controllers.

As for Pokémon, in the early generations, the game assumes that data received through a link cable are always well-formed, performing nearly no error check on them, so international trades involving Japanese games are possible with glitchy results, and glitches can also spread from one copy of the game to another, even resulting in remote code execution. One excuse not to do error checks on link data is that rather complicated error checks would be needed to guarantee that they are completely well-formed and will not cause any glitches. For example, despite Generation II games trying to check Pokémon from other games so as to not accept "abnormal Pokémon", the reverse Time Capsule exploit is still possible.

A further special case is when the player hard resets the game at an unexpected time. Pokémon games usually ask the player not to reset while saving the game, since corruption of the SRAM is the only way that a hard reset may cause glitches (other RAM sections and registers are wiped upon reset anyway). A hard reset forcefully stops the execution of the program, so it is impossible to "check" for it in a traditional sense, but a proper protocol should be able to stop a hard reset from leaving the game in an inconsistent state. Instead, both Generation I and Generation II games use checksums to ensure the integrity of the save file, but the checksum is relatively weak and is subject to collision. Furthermore, flaws in the saving process cause save corruption glitches in both generations, the SRAM glitch for Generation I and the (bad) cloning glitch for Generation II, both of which can happen without a (relatively unlikely) checksum collision.

Natural glitches and non-natural glitches

Some glitches are considered "non-natural glitches" because they can only be performed from an already glitched game state. In order to reach such a glitched game state, another glitch would need to be performed first, which would be known as the "parent glitch" of the other glitch. Conversely, glitches that do not require a parent glitch are called "natural glitches".

Natural glitches are always notable because they indicate logic errors in the underlying game program, i.e., software bugs. On the other hand, non-natural glitches reflect a "garbage in, garbage out" scenario that is not necessarily due to any underlying errors in that part of the program. For example, the double Blue glitch happens because the programmer assumed that the player must earn the Boulder Badge before earning the Earth Badge. This is a very reasonable assumption: The player escaping from Pewter City without beating Brock is not supposed to happen, and if it does, then the programmer has bigger things to worry about.

The concept of "non-natural glitches" is not always clear. It could be argued that, the behaviors under a glitched game state are all undefined, with none more "unintended" than the others. As such, it can be difficult to differentiate non-natural glitches from "logical consequences" of other glitches. For example, depositing a glitch Pokémon in the Day Care results in a glitch Pokémon in the Day Care, which is definitely an unintended game state, but no one would call that a "non-natural glitch" in and of itself. On the other hand, some behaviors are surprising and unintuitive even considering the fact that the game was already in a glitched state. In the double Blue glitch example, since the player is able to play the game largely normally without the Boulder Badge, they probably would not expect anything out of the ordinary on Route 22, let alone a game freeze. Complicating the matter is the fact that "surprising and unintuitive" depends on the player's understanding of the parent glitch. A player accessing the expanded item pack for the first time may be surprised that there are so many glitch items, or that manipulating them would affect other aspects of the game, but for an experienced glitch researcher, that is just how the expanded item pack works.

Another difficulty in separating natural and non-natural glitches is that glitch procedures usually consist of many steps, and it can be hard to separate the "setup", the "actual glitch", and the "consequences". For example, performing what is known as the "dry underflow glitch" usually involves the following many steps:

• Use a variant of the trainer escape glitch to encounter MissingNo. or 'M (00).
• The "seen" Pokédex flag of MissingNo. or 'M (00) causes item duplication, resulting in an item stack with quantity larger than 100. Repeat this once to get a x255 item stack.
• Do the item stack duplication glitch by tossing items above the x255 item stack, which desynchronizes the item count with the terminator of the item list.
• When the item count is 1, decrease the item count to 0 by swapping the first two items to combine those two stacks. (This is of course impossible if there is actually only one item according to the item list terminator.)
• Without quitting the item menu, decrease the item count to -1 (i.e. 255) by swapping the first two items again. (If the item count was not decreased to 0 by swapping, then the player would not be able to scroll onto the second item at all.)
• The player can now scroll beyond the item list and access the expanded item pack.

If one conglomerate all those steps into a single procedure, then it would seem that that procedure should be a "natural glitch". Of course, it is more intuitive to regard the first two steps as part of the setup, and the last step as the consequence, but trying to identify the roles of the middle steps can feel like splitting hair.

Exploiting glitches

Some glitches give the player an obvious and immediate in-game advantage. For example, after the player performs the Pewter Gym skip glitch, they can immediately proceed to the rest of the game without worrying about beating Brock, and possibly return to beat Brock with Pokémon that could only be caught in later areas. Other glitches may initially seem less useful, such as left-facing shore tiles giving wild encounters from a previous area, until the player realizes that it means they can encounter Safari Zone Pokémon and catch them like other wild encounters, or that the relevant memory area can be overwritten by in-game events like the old man.

A complete procedure to exploit a glitch in a useful way is known as a glitch technique, or a "trick". A glitch technique can consist of one or more of the following:

• Doing extra setup in order to make the glitch do exactly what the player wants, like talking to the old man before surfing on left-facing shore tiles.
• For glitches with a persistent effect, performing extra steps to make use of the resulting glitched game state. For example, the Celadon looping map trick allows the player to get almost any normal or glitch item from an expanded item pack.
• As a special case, doing something extra in the middle of a glitch, like encountering a Pokémon with the correct special stat between the two parts of the trainer escape glitch (possibly using the Ditto trick).
• Multiple different glitches chained in a specific way, such as the dry underflow sequence mentioned above.

Again, it can be difficult, and is usually unnecessary, to distinguish between those cases. However, it can be beneficial to understand what are the essential steps of a glitch, and what are the extra steps a specific glitch technique calls for.

In speedruns

In speedruns, obviously speed is the main objective, which means that runners would perform any glitch that would save time, even if performing the glitch is arguably more difficult than playing the game normally, and thus it would not be helpful to casual players. In addition, people would design complex glitch procedures that exist for the sole purpose of satisfying the criteria of "beating the game".

Usually, for games with helpful glitches, there will be a "glitchless" speedrun category where it is not allowed to make use of glitches. Conversely, categories where glitches are allowed are called "glitched" categories. There are multiple reasons for a glitchless category:

• Some players may not view beating a game by exploiting glitches as legitimate.
• Other players may not want to learn to perform glitches, but still want to have a category where they can compete.
• In some cases, the optimal glitched route becomes so luck-dependent that it becomes unfun to compete on.
• In many cases, allowing glitches will just change the speedrun completely by skipping over a lot of intended gameplay, making the glitched and glitchless categories equally interesting in different ways.

By convention, categories like "any%" without specification are glitched categories by default (assuming that helpful glitches exist). There may also be categories that only disallow specific kinds of glitches. For Pokémon games, two kinds of glitches that are commonly banned in otherwise glitched runs are save corruption glitches (which can skip over the only bit of intended gameplay at the beginning of glitched runs) and arbitrary code execution glitches (which can trivialize otherwise interesting goals).

Despite the name, some "glitchless" categories actually still allow certain glitches to happen in the gameplay. One reason is that some glitches, such as the Generation I miss, do not need any special setups and are practically impossible to avoid during normal gameplay. Another reason is that it may be difficult to classify whether the game behavior exploited is actually a glitch (see below).

Controversy

It can be sometimes controversial whether a given game behavior should be regarded as a glitch. As mentioned above, many behaviors under a glitched game state can be viewed either as a non-natural glitch, or as a logical consequence of previous glitches. However, even for natural glitches the line is not that clear.

By definition, a glitch produces results unintended by the developers, but it could be difficult to infer developer intentions. For example, the Focus Energy glitch is usually thought of a glitch that causes Focus Energy to lower the critical hit rate from normal. However, another theory is that the an error in the program causes the critical hit rate after Focus Energy to be swapped with the normal critical hit rate, which would mean that the "normal" critical hit rate is in fact glitched to be higher than intended. There is not enough evidence to tell which one the "intended" normal critical hit rate is.

Furthermore, it is generally understood that intended mechanics leading to unintended exploits does not count as glitches. Many speedrun strategies are likely not how the developers envisioned the game to be played, such as intentionally going to low HP to shorten sound effects (i.e. red bar manipulation), or using X Accuracy and X Speed with one-hit KO moves to sweep opposing teams, but they are logically consistent with the intended mechanics of the game, so most people would not consider them glitches. On the other end of the spectrum, something like the trainer escape glitch also stems from the "intended mechanics" of engaging trainers, but clearly leads to glitchy results. The big ambiguity is where "game mechanics" end and where "gameplay strategies" begin.

Two examples right in the middle of the spectrum is the Bike Shop instant text glitch and using a Poké Doll on the ghost Marowak. The instant text itself is an intended mechanic, but it being preserved outside of the Bike Shop is unintended, and gives rise to some unintuitive strategic considerations in speedruns. Skipping wild battles with a Poké Doll is of course intended, but in this specific case it leads to what is arguably a sequence break. Currently in the speedrunning community, both exploits are allowed in the "any% glitchless" category, but there exists another category named "any% glitchless (classic)" where both are not allowed.

As a verb

The verb "to glitch" is usually used either intransitively meaning "to be affected by a glitch" ("my Pokémon glitched out"), or transitively meaning "to perform a glitch with an effect on something" ("I glitched my party").

Empirical glitching refers to the practise of exploiting glitches through observation (as the word empirical refers to the senses). Hard analytical glitching can be understood as the practise of analysing the game at the assembly or source code level. Empirical glitching alone can lead to false conclusions (such as the case with sensitive glitches or arbitrary code execution), so it is valuable to practise both.

As an adjective

"Glitch" can also be used as an adjective to describe some in-game object that is not intended to appear in the game, but is created through a glitch. Examples include glitch Pokémon, glitch moves, glitch items, glitch encounter systems, etc. Sometimes a glitch object (especially a glitch Pokémon) would be simply referred to as a "glitch"; however, this usage of the noun "glitch" is discouraged because it can be confusing in many cases.

There are two other adjective forms of "glitch", "glitched" and "glitchy", but their meanings are subtly different.

• "Glitched" describes a game state or an in-game object affected by a glitch. The difference is that while a glitch object (like the glitch Pokémon 'M (00)) is something that fundamentally should not exist, a glitched object (like a glitched Kangaskhan created through evolving said 'M (00)) is just somewhat different from its normal counterpart (a normal Kangaskhan).
• "Glitchy" is sometimes used interchangeably with "glitched", but it puts more focus on the superficial weirdness of said object. "I knew my Pokémon was glitched, but I did not realize it had such a glitchy nickname."

See also

• Exploit
• Glitch technique