Anonymous user
Glitch: Difference between revisions
Added an analysis of common causes of glitches
(→As an adjective: Fix typo) |
(Added an analysis of common causes of glitches) |
||
Line 8:
In addition, the word "glitch" is generally used more broadly and loosely than "bug" would be used. For example, [[#Naturalness|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 {{GSC}}, [[Catch rate glitches (Generation II)#Love Ball|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 defeating Ralts oversight|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 [[Professor Oak's lab tilemap corruption glitch|there are more NPCs on the screen than the game is designed to handle]], or when [[Super Glitch (Generation I)|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 item]]s 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 [[Trainer escape glitch#Death-warp|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.<ref>For example, there could be a variable in the SRAM that normally has the value 0. When saving the game, the game changes that variable to 1, then writes the main save, then changes that variable back to 0, and then writes the backup save. At least one save file will be valid after a hard reset, and the value of the variable will indicate which one.</ref> 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 clone glitch|bad]]) [[Pokémon_cloning_(Generation_II)|cloning glitch]] for Generation II, both of which can happen without a (relatively unlikely) checksum collision.
<references />
{{Anchor|Naturalness}}
| |||