Ubiquitous cheats are cheats that can be used in any game by applying methodologies rather than exploits that would be particular to specific games in part. The list presented on this page is thereby a search for invariants that would apply globally to all games available on the market. In many cases, the "cheating" is a misnomer and players are even expected to perform such "exploits" as part of the gameplay based on player skill and knowledge of the game. Consequently, the "ubiquitous cheats" presented on this page can be, at worst, be seen as "cheating without cheating" covering the cases where player skill blends with game exploits.

Furthermore, "exploits" that are not universally applicable, go against most game terms of service or end-user license agreements, perhaps exploits that involve direct intervention in the game runtime are purposefully out of the scope of this page. One example of "exploits" that are excluded could include direct memory manipulation by using a differentiating tool that compares the memory contents for a game between and after a parameter changes (ie: life value, number of items in inventory, etc.) and then uses a different tool in order to modify the value at runtime in order to duplicate items or increase player statistics (a very common exploit performed in the older days on consoles).

Most of these collected "exploits" will not come as a surprise for people with experience playing games but are collected for historical reasons, elaborated and verified or applicability to all games and perhaps will constitute part of an article meant to document, assess and demonstrate tricks or techniques used by computer or console games. The authors find that there is a lot of intelligence, skill and cunning used by players in games that may be of interest to a larger public and is worth documenting.

A CPU jammer software can be created that will overload the CPU with, say, computationally difficult to solve problems, thereby achieving a lag effect. The lag can then be leveraged to get through portions of games that require (too) quick reflexes.

This cheat can be achieved through hardware for handheld consoles, such as the Gameboy DMG variable oscillator mod, by simply replacing the oscillator with a half-frequency oscillator for half speed.

Perhaps the most attractive part of this ubiquitous cheat is that, depending on the task within the game, the cheat should work for massive multiplayer online games too - or rather, games that require Internet connectivity (Punkbuster) since such games allow a certain tolerance threshold before the game considers the player to have a severed connection.

One of the oldest trick in the books is to use the Save & Load feature of games that require you to pass a test before proceeding on with the main storyline. The principle is easy to comprehend: save when you win and load when you lose.

For instance, this cheat works wonder in Leisure Suit Larry 1 - The Land of Lounge Lizards when the player is supposed to obtain a certain amount of cash to continue the adventure by playing poker. DeusEx or Fallout hacking sequences can also be similarly defeated ensuring that no time is lost. Passing speech tests in RPG games can also be ensured to succeed with the same technique - even when the odds are against the player (in which case the average number of retries can even be computed).

This cheat is unbeatable unless the game forcibly autosaves after every failure of a minigame.

Most games allow changing settings such as brightness, contrast or screen gamma - the latter setting is typical of console games where the game asks you to move a slider till an image can be "barely seen". Most of the time, the darkness works to your disfavour and various game elements (such as items, or clues) will be hidden in darkness. Cranking up the gamma or manipulating the brightness can avoid a lot of trouble with finding the hidden clues.

The procedure can range from messing with basic tools such as NVidia control panel or perhaps more advanced tools such as SweetFx / Reshade to remove or enhance graphical elements.

Similarly, a lot of games sometimes have a calibration phase where the player is requested to move a slider till some image is "barely visible" - a request that can be completely disregarded and the player can just slide towards the end of the slider that makes the image entirely visible. Usually games that have such built-in calibrations will also require the player to pixel hunt down the line such that following the instructions to reduce the brightness is just a way for the player to shaft themselves.

Macros can help overcome repetitive tasks and some macros are more advanced than others - there are typical hardware solutions such as mice or keyboards with built-in macro features but more than often you will need some advanced scripting. Examples include:

• A dynamic macro repeater such as Spring.
• An autorun program by Wizardry and Steamworks written using AutoIt that helps add an autorun feature to games that require the shift key to be held down.
• Using TinyTask to perform sequential actions repetitively in order to raise in-game reputation.
• Exploiting the AvaLife Fashion Voting minigame.

Autofire can be implemented for any mechanical button - even for desktop computer keyboards by using a timer circuit such as the NE555. The obvious advantages are bypassing button mashing sequences in games or perhaps some form of auto-run in FPS games.

Cut scenes in games represent moments when the game re-arranges the scene. This implies that states that were there previously are either halted during the cut scene or entirely removed. That being said, it is sometimes possible to escape a difficult situation if the player just manages to trigger a cut scene.

For instance, Guild Wars 1 only registers a quest hand-in when an NPC is reached. Even if the NPC is on the battlefield, then the quest completes and the enemies vanish. Other examples include games where the enemies will just be suspended and not deal any damage whenever a quest NPC is being talked to.

Similarly related is saving the game that sometimes implies that the game will be halted for a few moments. Some games save whilst additionally displaying a cut scene, in which case, the game will most likely be interrupted for the duration of the cut scene.

With unbelievably few exceptions, games are rigged for the player to act with a "good" alignment. This is either because being evil is not a fully developed branch but most of the time this is because "evil" is self-destructive. One cannot be, truly evil since evil is self-defeating.

For instance, even if Dungeons & Dragons (in its computer game form) allows a player to be chaotic evil, it is still impossible for that player to be truly evil and additionally finish them game - simply killing off a story-related NPC will not allow the player to progress; otherwise, the key NPCs will have to be made invincible. Dungeons & Dragons in its pen and paper form would imply a DM that can use divine intervention in order to prevent a player from messing up the game but a computer would not anticipate, say, killing off a team member or killing off a key NPC since the decision branch would be way too large.

Examples such as Tryranny are equally sensitive - in Tyranny, "evil" might be implied by the story but not necessarily by player actions. Player decisions, may be political where some choice may lead to consequences that may be considered "evil", but the player is still restricted to doing what they are told (regardless the side).

Most of the other RPG games such as Fallout imply a "good" playthrough where the player essentially gets rewarded for being "good" and punished for being "bad". Ie: rewards are given to completing quests, not rejecting them, NPCs offer goodies and killing them off results more than often in no loot at all, etc.

Winning a game, without any other additional information, would imply a "good" playthrough as a best guess, since statistically it is the choice that most games prefer.

Some game props, particularly walls, are sometimes set to be phantom such that they do not comport themselves as a physical object in order to reduce the load on the physics engine. Usually such walls or boundaries (even other objects) are placed in "difficult to reach places" where the developers did not anticipate players to reach. However, sometimes players do manage to reach these difficult places by either:

• performing jump combinations,
• using skills or other physical objects to propel them

This usually results in the player being able to take shortcuts, for instance, by walking through walls thereby bypassing the intended geometry of a scene.

One such example is the Hobo: Tough Life wall exploit where a player can use physical props (in this case, a fence) to break through a physical wall.

Similarly, just by jumping around, phantom walls can sometimes be found allowing players to escape the geometry such as in Mario Bros where a player would break the top wall and run through the rest of the level while avoiding most challenges and obstacles:

It is difficult to label this as a cheat - it is not even sure whether the developers intentionally made this mistake, the trick was very common and it does have the trade off of not collecting anything for the rest of the level and the trick itself is so common that it was performed all the time without further thought (most game cheats websites will not mention the "trick" as a cheat).

In other cases, there is a direct link between scene architecture and well-chosen player configurations such as in Warframe where players barricade inside a room that is difficult to reach by the game AI in order to run long sessions and acquire resources that would have otherwise required a much longer gameplay time.

In role playing games players meet computer-controlled opponents in a given environment in order to do batte. One of the programming problems is how will the computer-controlled opponents pick a target and that is conventionally solved via something called the "threat tables" (computeristically, a priority queue): a table is constructed by the software ranking every player by the amount of threat they generate and the computer picks players in descending order by their threat ranking. Implicitly, since the computer controlled opponent(s) must attack a certain player that has been selected, the computer must then generate a "physicial" path to the selected player, in case the attack type is melee. In doing so, the computer-controlled opponents must traverse both the environment and will also avoid other players in order to reach a given player. The algorithm can be grossly approximated as follows:

• generate a threat table, perhaps based on attack power of all players and previous history of attacks,
• pick the top-most player,
• move to the player,
• attack the player
• loop at the first step

One common trick is to perform a "body-block": a "body-block" is usually performed by a player on the lower levels of the threat tables that moves within the environment and attempts to block the computer controlled opponent just by standing in the path of the computer-controlled opponent; the player usually uses their intuition to guess the path that the computer-controlled opponent will pick.

The effect of a "body-block", sometimes in very severe cases, is to confuse the AI so bad that the computer-controlled opponent will just never reach the player that it must attack. In doing so, the player and the computer-controlled opponent dance across the environment whilst the rest of the players in the party attack the computer-controlled opponent from afar. In case one of the players attacking the computer-controlled opponents from afar will generate sufficient threat in order to surpass the player blocking the computer-controlled opponent, the players will either change roles or the player performing the body block will attempt to generate threat back in order to maintain their position on top of the threat table.

One example of performing body-blocks can be found in:

• Star Ocean - one of the players equips an item named "Bunny Shoes", granting extra speed and is able to run around, blocking the computer-controlled opponents that will ignore the player performing the body block and turn and twist trying to generate new paths towards the players generating threat.

The technique can sometimes be combined with the environment, ie: attempting to make computer-controlled enemies end up stuck behind items in the environment such as rocks, hills, trash and others, perhaps even related to exploiting scene architecture issues where players attempt to make a computer-controlled opponent fall off some platform or ledge.

A somewhat similar and related technique is called "kiting" which involves one player generating sufficient threat in order to race a computer-controlled opponent trying to reach them. One example of "kiting" can be found in "World of Warcraft": some funny situations include an event where one player managed to drag an extremely high level boss into a starter city with low level players and just watch the ordeal unfold:

A more useful example of implicit "kiting" is performed by just two players, Incantatrix and Melchior in Scholomance, a high level 5-person dungeon using just two mages.

In this case, the "kiting" performed is implicit since the only way to survive the overwhelming amount of foes (for a 5-person dungeon, done by 2) is to oscillate between the two players and confuse the AI such that the foes will bounce back and forth from one player to the other. At 1:46m in the movie, both players hide behind a doorway that makes enemies have to recompute the path and start walking towards the doorway, the other player generates some threat and does the same, effectively exploiting the line of sight (LOS) and confusing the mobs. This is one example where the "kiting" involves the environment as well as the players.

Back at the time, a two-people party was considered impossible, especially given the party configuration since mages are cloth wearers, take lots of damage, deal in return lots of damage and thereby generate a lot of threat, have no inherent way of healing themselves via spells and are generally not designed as characters to be on the front lines.

Perhaps one of the most prominent and perhaps irreducible but not directly related examples would be the classic Pac Man exploit as explained by Retro Game Mechanics Explained (originally at https://www.youtube.com/watch?v=ataGotQ7ir8):

Although not a "body-block", nor "kiting", the Pac Man exploits are based on the limitations of old-era platforms where a developer "fix" was introduced in order to prevent a buffer overflow condition that resulted in some distinct patterns being generated by the ghosts in Pac Man. The patterns are then leveraged by the user in order to confuse the AI into either avoiding the player altogether, effectively reaching a stale-mate (or a deadlock) where the game can run indefinitely without the player losing. Or, the patterns can be used to exploit the game such that the user always wins.

Both techniques, "body-blocking" and "kiting" are not even considered "cheats", even though they exploit the underlying AI algorithm in order to gain an advantage, but they are, in fact, considered to be player tactics. In many ways, the critique would be unfounded since both techniques do require a lot of player skill - kiting or attempting to body-block high level enemies with rapidly reordering threat tables is very dangerous to a player - in the World of Warcraft example presented in the video above, "Grindpa" from the "Khadars Rage" guild kites a very high level computer-controlled enemy "Kazzak" into a starter area but the process of doing so must have been painstakingly difficult and would have required an insane amount of skill. Kazzak is considered a world-boss, of unknown level and the player must have dragged the boss across at least three distinct regions to get to Stormwind (Azeroth → Eastern Kingdoms, from Blasted Lands to Stormwind). Similarly the maneuvers performed by Incantatrix and Melchior were considered impossible given the design and constraints of the game.

A bit of a Deleuzian singularity perhaps, but…

It seems that just letting a player run randomly through the first level of Tony Hawks Pro Skater 2 - Hangar, would end up with the skater moving just along the pink lines.

With some measurements performed, it seems that it would take no more than an hour, in the worst case, for the player to reach the point of equilibrium and it seems that once the point of equilibrium is reached, the skater will just move back and forth forever along either of the two pink lines marked on the map.

After a very long while, the skater will end up face down on the floor, moving along the floor, thereby breaking the initial equilibrium and then reaching a different equilibrium; the invariant in this case is derived observationaly from the fact that the player does not seem to rise from the floor again.

As far as computing is concerned, the equilibrium(s) are most likely disrupted by micro-memory leaks implicitly created by bugs within the software (before the second equilibrium is reached, there are graphics glitches to be observed where the skater phases in and out of the sceen, occasionally dropping to the ground) and not much else could be said.

It is a difficult problem (unsolved) to determine whether the exact same initial equilibrium could be reached once memory corruption occurs although it is interesting that the exact same invariants are reached even by memory corruption - this might be explained by the actual disposition of bugs throughout the code (that are fixed or at best undiscovered, given that the code is final) that invariably corrupt particular and distinct regions of memory leading to the same re-occuring equilibrium.

The exact same type of equilibrium can be reached in other games, for instance, in the eldest most successful commercial video game named "Pong", on Atari, as illustrated by deptymaddog5:

The "cheat" consists in moving the bar to a particular geometric point on the board such that the computer AI will always lose against the player.

Patterns created by architectural constraints.

Fibers of code that can be minimally changed in order to induce changes in the program.

Albeit trivial to experienced game players, "farming" is a methodology applied by players with specifically tailored gear and frequently with the aid of particular scene architectures singularities meant to reduce the gameplay time required in order to obtain certain resources or "drops" that are granted sparingly by a game. The term "grinding" generalizes the concept of "farming" by extending the methodology to not only obtaining in-game resources but also defeating enemies in order progress through the game by acquiring in-game ranks faster and unlocking more of the game content.

There is always a push- and pull game between players and game developers where game developers try to throttle the progression of players by rewarding certain resources sparingly with the hopes of increasing the time required for players to reach the content at the end of the game when, once reached, players might lose interest in the game due to having completed everything that the game has offered.

In some ways, there is an overall interesting outcome where one can observe that the developers of a game had a certain play style in mind yet the players end up playing the game an entirely different way as intended. In some cases, one can even conclude that that there is a certain level of disconnect or, perhaps, misunderstanding between game developers and the actual way that the game is played by gamers. Unfortunately, many such cases where a disconnect appears to exist, may be due to very harsh throttling methods applied by game developers, with the intent of hampering the development of players, such that entire areas or equipment designed by the game developers ends up outright ignored by players due to high opportunity costs. Even though the phenomenon where a disconnect occurs between games being designed to be played a certain way and the actual way that a game is played is immediately apparent by, for instance, looking inside game chat and checking the activities that players form teams for, sometimes developers factor-in the disconnect or just ignore it - however, and regrettably, in doing so, entire areas created and designed by game developers may end up abandoned thereby minimizing the gains and making the investment not worthwhile.

A game named "Warframe" by Digital Extremes, for example, is sometimes mockingly labeled as "Grindframe" due to excessive amounts of gamplay time required to obtain resources or equipment. "World of Warcraft" classic, as published by Blizzard Entertainment, similarly was considered notorious by players by practicing very low probabilities for certain rare rewards - in one such case, very long ago, a player was lucky enough to receive an item considered to "legendary" and with a very low drop rate. The item was so rare that it ended up creating a singularity event in the player market being estimated to have an exorbitant in-game trade price compared of the rest of the item rewards - so bad, that the entire population of the server glorified the item so much that the item became a cornerstone for flaunting yet did not help the game nor the player that received the item at all, effectively becoming an item of worship and not much else.

Another classic example, yet more elucidating of player farming methodologies rather than game developer throttling took place in a game named "GuildWars" by NCSoft. Players chose and configured an in-game character (in game terminology, a "Monk" class character) to be invincible, the damage taken by a player being reduced to zero via a calculated choice of skills and procedure, in order to farm and item named "Ecto" that was highly valued on the in-game market. The farm procedure involved a single player traveling to a very high level area of the game and then keeping themselves alive using in-game abilities (skills) whilst dealing damage to AI enemies via skills that return the damage taken to the enemies. In very many ways, the methodology was considered skill and "GuildWars" by NCSoft was at the time of its height a skill-driven game rather than a grinding game - most obviously since just completing the game tutorial that took perhaps an hour or less would result in the player having the exact same statistics as any player with a very large gameplay time.

The terminology "Running", "Taxiing", "Ferrying" and "Carrying" have the same goal which is to lead low-level players from one part of an area in the game to a high-level or trade are within the game. The procedure, in most cases, involves an experienced player, equipped with specific or resistant gear, that forms a party with the low-level player and escorts them to the desired destination. The experienced players, for obvious anecdotal reasons, are called runners, taxis, ferries or carriers. In most cases, the low-level player does not perform any action whilst the experienced player attempts to run through very large and dangerous areas, deliberately ignoring enemies in order to reach the destination. Once the destination is reached, the experienced player leverages game design, specifically instanced areas of the game where by entering the new area, the low-level player gets teleported across the map. The term "carrying" is sometimes extended to an experienced player completing levels by themselves and without the help of the low-level player being "carried" in order to enable the low-level player to reach higher ranks within the game and thereby progress faster.

In NCSoft's "GuildWars" two such "runs" were well-known: first, the "Leon's Arch" run that involved very areas of the entire game, bringing a starting player from the starting area to Leon's arch. In doing so, the low-level player gained access to both the commercial backbone of the entire game since "Leon's Arch" was an economic trade center of the game as well as bypassing a very long story line. Second, the "Drok's run", well-known for its difficulty amongst players, involved a smaller path, yet achieved much more than just reaching a center of trade, namely a Drok's run would bypass game content spread out between different separate stories of the game.

Usually, a run is not requesting by "new" players, since obviously new players might not have had the knowledge to request the run in the first place, yet the run was commonly requested by experienced players that had just created a new game character and were just seeking to reach a center of trade, sometimes backtracking and playing the content that was skipped via the runner shortly thereafter. The runner is usually paid for their services by the player being ferried to their destination.

"Running", "Taxiing", "Ferrying" or "Carrying" are notable examples where players create additional challenges that might have been not designed by the game developer intentionally. Since they can be seen as a singularity event, where players figured the "exploit" by themselves, "Running", "Taxiing", "Ferrying" or "Carrying" is frequently seen as more difficult and challenging than the rest of the game.

Contrary to more recent games where players are distinguished by their ability to acquire resources, kill many foes or reach higher levels of the game, where completionist players are deemed to be skillful by their ability to "grind", "running" in older games were considered to be a measure of player skill: for instance, a player that was able to consistently complete Droknar's Forge runs in a timely fashion was deemed to be a very skillful player due to the overall difficulty, attention span and split second decisions that had to be made during the run, no matter their level, equipment or time spent playing the game.

Historically speaking and in an economic context, one might argue using the concept of "running" that older games that relied on player skill are being phased out since they do not directly imply profit for game developers - for instance, the very difficult "drok's run" mentioned in this section took, when performed masterfully, up to 10 minutes which is definitely not an activity to aim for when designing games whilst having profit in mind. Similarly, "running" explicitly skips game content and advances a player "artificially" thereby reducing gameplay time.

The video created by XiLaRtHtHeWiSe explains the Droknar's Forge run and demonstrates the difficulties encountered along the way, perhaps, the most notable quote being "anyone being able to perform this run could probably easily complete the entire game" reflecting the amount of skill required.

Running a game by relying entirely on server-side code would incur a lot of network costs and might even congest the network so much that the clients might end up racing each other in order to obtain their own slice of bandwidth. Even multiplayer games are designed to balance server and client-side responsibilities where a game developer decides which values are crucial and should be verified on the server side and which values can be trusted to the game client.

Memory scanning is a process though which a game client scans the memory of the game locally in order to find a value (ie: a game metric), change the found value and achieve an advantage over the game. For instance, the owned currency can be multiplied, difficulty barriers lowered or similar.

Even though memory scanning tampers indirectly via the memory with the game code itself, it is included in this section as an example that at least partially fits the "ubiquitous" term because the memory scanning technique can be applied to any game.

The following is a demonstration of using a software named "Game Guardian" in order to manipulate values in the Sims Mobile game on Android:

In general and for any game, the procedure runs as follows:

1. decide on a value that should be changed; for example, the raw value of "gold coins" in a game, say 1134.
2. attach a debugger (in this case, Game Guardian) to the game (or program),
3. halt the game execution via the debugger (in Game Guardian terminology, "freeze" the game),
4. dump the memory and scan for the value to be changed, ie: 1134; iff. multiple memory addresses reference the value, then store all memory addresses in a list ,
5. continue execution of the game till the value sought after changes or deliberately change the value; ie: 1134 changes to 1132,
6. halt the game execution via the debugger,
7. dump the memory and scan the formerly list of values while maintaining only memory addresses that contain the new value, ie: 1132,
8. repeat until the list of memory addresses contains addresses that reference only the current value,
9. modify all the values referenced by the list of addresses to a desired value

In the provided example, in the case of Sims Mobile by EA Games, the number of simoleons held by the player cannot be changed using this technique. Interestingly, by performing the operations, the currency will change on the client side but the actual value will not change such that the client and the server in this case will end up de synchronized: the game client will display a different value but purchases will not accept the new value. Values that are stored or cross-checked by the server cannot be changed.

Pedantically speaking, the procedure could be classified as a Time-of-Check-to-Time-of-Use (TOCTTOU) attack due to the desired value changing before it is registered by the game client. Unfortunately, memory scanning is not safe and can be detected deterministically by server side code: in this case, it suffices for the server to know that is the maximum amount of energy available and that the sim ended up using way more than in a timespan that can be computed given other game invariants.