Common tricks

"This is a sparring program. Similar to the programmed reality of the Matrix. It has the same basic rules – rules like gravity. What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others – can be broken." ― Morpheus, The Matrix
There are several tricks that can be used (or at least tried) in many games to improve the time. If you are making a movie, be sure to try every one of them :)
Table of contents

Collision abuses

Close approach collision abuse

Most games don't do pixel-perfect collision checks. The character's and enemies' sprites (the graphics that you see on-screen) have unusual shapes, while their "hit-boxes" are usually actually square. Games are programmed this way because it’s much easier to program "is the character's box touching the enemy’s box" than it is to program "is any pixel of the character’s graphic touching any pixel of the enemy's graphic."
In some games, the hit-boxes are actually bigger than the sprites, and you can get hit by an enemy before it seems like you should. In a lot of games, though, the opposite is true: hit-boxes are actually smaller than the sprites, so you can seemingly touch or even go partially inside enemies without getting hurt. The SMB1, SMB2, and Solomon's Key movies have many examples of this.

Fast motion collision abuse


Games don't interpolate motion between frames. This means that you are in one place on one frame, and in some other place on the next, without actually having traveled the path between them, like we do in the real world. This is how animation works.
If you are moving very fast, you can sometimes pass through objects because the game does not render a frame when you are inside the object. Combined with the close approach collision abuse mentioned above, the speed may not even need to be very high.
The example shows Gradius collision abuse. Due to the extreme speed, the ship is able to fly through narrow pieces of ground that would normally destroy the ship.

Other collision abuses

By various methods (such as pushing into corners in strange ways or getting shoved by an enemy) you may sometimes manage to get embedded into the floor, walls, or ceiling. Sometimes when this happens you just get stuck and your game is ruined, but other times it might allow you to make use of new routes that weren't possible before. For example, you might be able to gain support and jump from a wall. The SMB1 and SMB2j movies have examples of this.
In most games, collision calculations are very simple. As mentioned earlier, because motion is not interpolated, sometimes you can go through enemies or walls if you are traveling fast enough or along an odd enough trajectory. With respect to walls, most games account for this by very quickly ejecting you from the wall to prevent you from getting stuck. Sometimes, you can trick the game into ejecting you in the wrong direction, which is how walls are initially walked through in SMB1. In other games, wall ejection moves your character at high speed in one direction (usually horizontally) until the game finds a place where you can exit the wall. This is most useful when you can force the game to shoot you off at high speed along your desired path! In Mega Man and Mega Man 2, even ceilings eject you horizontally, which is why the authors of those movies often perform various antics that result in Mega Man being embedded in the ceiling.
The image on the right shows a classic example in Super Mario Bros (the famous wall glitch that allows entrance into -1)

Invulnerability abuses

Most games contain some situations where your character is immune to harm.

Event invulnerability abuse

Often, when the game has started a scripted demo that may not be interrupted, like the animation for finishing the level, your character becomes invulnerable. If you touch something lethal during this state of game, the game may very well ignore it. The Little Nemo and Gremlins 2 movies have examples of this. In many games, such as Umihara Kawase and The Wrath Of Black Manta, lethal object collision checks are ignored when entering a door. In Mega Man 2, these checks are ignored when changing weapons.

Stun invulnerability abuse

In many games, if you take damage you will flicker for a while and temporarily become invulnerable, to prevent you from immediately taking more damage. This invulnerability can often protect you from "instant death" hazards, for example, allowing you to safely walk on deadly spikes or lava for the duration of the flickering. The Mega Man 4 and Blaster Master movies have examples of this.
It may also be advantageous to use such a period of invulnerability to pass through monsters that would otherwise take longer to destroy, or to pass through other nearby monsters that would do more damage. The Goonies movie is an example of the former, while Castlevania: Circle of the Moon movie is an example of the latter.

Pause abuse

In some games, pausing has unintended effects due to programmer oversight:
It might be worthwhile to observe what other anomalies are caused by pausing in your game.

Luck manipulation

Video game consoles are computers. They do exactly what they are told, and will always give the same result when given the same input. There is nothing that is truly random. The only source of true randomness in games is you! Games are purely deterministic and depend solely on user input.
Learn to abuse this fact. You can affect anything that has an element of randomness in it, like monster movements or item drops.
Read more at Luck Manipulation.

Monster "damage boost" abuse

It is common for games to be designed so that the character can't reach certain paths or platforms, but just barely. Designers often overlook the boost monsters provide when they hit you, however. By getting hurt at the right place and the right time, you can get monsters to boost you into places you normally shouldn't be able to go. Castlevania and Ghosts'n Goblins have examples of this.

Monster damage speed boost


In some cases, taking damage from a boss flings the character at speeds faster than he is normally able to go. If planned, this can send the character in the direction desired and save time. Symphony of the Night, Super Castlevania 4, Legend of Zelda, Link's Awakening, and Kirby Superstar are examples of this.

In some cases the damage causes the character to retain that speed as long as he doesn't stop. In the video example here, Adventure Island 4, the character is able to retain a super speed boost for a strikingly long period of time.

Avoiding lag

The processing speed of old console systems is limited. They can only handle so many objects per frame. If there are too many objects on screen at one time, the game slows down, because it just can't calculate everything in one frame.
Knowing the cause of this phenomenon is important when making a TAS. Often this lag can be minimized by keeping the number of on-screen objects low, either by destroying them early, or perhaps not destroying them to prevent an overly complicated (and processor intensive) death animation from playing. Luck manipulation can be useful here, too. In some games, whether or not a monster spawns is random.
On-screen objects are not the only cause of processor use. Some actions require more calculation than others. For instance, being close to enemies, or collecting or using certain items may cause the game to lag.
Often lag can happen for unknown reasons, sometimes doing a slightly different strategy which doesn't cost time can prevent the event from occurring. In this instance a memory search might help to reduce it

Input abuses

Two or more actions at once

Try to make some input that most probably hasn't been tested, like pressing left+right or up+down at the same time, or use multiple input devices like gamepad+touchscreen simultaneously. It might have bizarre and useful consequences. See the Zelda: ALttP and Zelda 2 glitch runs for examples of this.
(Note that some emulators (such as VirtuaNES or old versions of Snes9x and FCEU) don't allow you to press right+left or up+down. The consoles themselves have no such qualms, though you usually have to press very hard on your controller to press in two opposite directions at once.)

Frame window

In some games, there are short periods when you can make valid game input while you are not supposed to do so. Catching such opportunity might either merely allow you to act earlier, or do things unintended by the developers.
TODO: Other typical examples with different outcomes.

Super speed abuses

When you act inhumanly fast, like pressing a button 30 times a second, you might be able to do things that the game developers would never have thought possible.

Alternating buttons

Often, you need to press a button to dispose of some dialog box, or to start the game, or something similar. When two buttons can be used to activate the same goal, you can press them like this: 
A, B, A, B, A, B, A, B, etc.
so that a button is effectively pressed every frame. It doesn't save actual time in the movie, but it saves time making the movie, because you don't need to test for the earliest possible frame every time. Some emulators (such as VBA and Snes9x) let you put A and B on autofire starting at different frames to automatically press this sequence of buttons, which is even less effort for you.
Sometimes a game will actually accept the next input every frame, in which case it does actually save time in the movie compared to pressing one of the two buttons as early as possible each time. Also, some games might have been designed not thinking it's possible to press buttons so fast, and strange things may happen as a result.
Be aware that hexediting may be more cumbersome if you use this technique. It may be difficult to determine the exact frame where the input affected the game.

Untested code abuse

Untested code is not always helpful. For example, in Battletoads there's one level that is impossible to complete with two players because the game testers never actually tried the level with two players. The game was published containing a serious programming error that prevents the second player from moving (and resulting in his immediate death) in the Clinger-Wingers level.

Jumping off ledges

The speed of playable characters in most games, especially platformers, is nonlinear. This is usually done in form of acceleration: the longer the character moves in a certain direction, the higher their velocity is. Similarly, the longer they fall, the faster they reach a platform underneath the starting point, so it's often preferable to jump shortly before the edge of the platform. Avoid the temptation of running off and falling normally, because often the character will have little-to-no downward velocity for a short period (unless, of course, you need it that way).
Note: Some games have drastically reduced aerial speed. For them, it's usually preferable to do very short jumps only a couple frames before reaching the ledge, or to not do any jumps at all. Be sure to study the physics of the game you're working on well, don't hesitate to use memory search to find exact values for character's speed.

Pass through obstacles at the highest speed:

Often, it won't be possible to travel at maximum velocity. This may be because you're waiting for a door to open, hydraulic obstacle to move or need to avoid a deadly fireball from below. In these instances it's often tempting to hug doors when waiting for them to open. Screech to a near halt to avoid being hit by an enemy or coming to a complete stand still.
The problem with doing this is that you'll need to spend time building up maximum speed again. In these instances it may be preferable to slow down a lot earlier and speed up again. Passing obstacles at the optimal time and speed.

Abusing erroneous assumptions

Due to limited processing power, old console games often make erroneous assumptions to reduce the number of calculations the game has to make. Sometimes these errors are just a result of programmer oversight.

Many interesting examples exist, such as:

Die


While it may seem contradictory with goal to do things as fast as possible, it does not have to be. Games commonly reset the player position when the player dies, leading to possible shortcuts. Your health often also set to a known number and you may lose items.
In games with multiple players, this can be used to change the amount of player interaction, for example dead players in an RPG will not get asked for their commands. Dead party members can also act as a form of party change, possibly affecting scripted events that depends on who is in the party.
In multi-player games, one player may be able to die to take advantage of a favorable spawning. The video example to the right demonstrates this idea in Level 5 of Super C. The two players continually die in order to spawn at the top of the screen to save time.
This can all be abused to save time. Submission doing this are marked with the category uses death to save time.

Subpixel carryover

This is extremely common in NES games (and less common on platforms such as DS and GBA). Regardless of platform it should be looked into for any game.
The subpixel value represents a fraction of a pixel. It is used to calculate how many pixels a character moves in a frame. Often at the end of a level/room, the remainder of this value is not cleared. This means the value left over will be used on the next level/room. When possible a high value should be left in a level to give the character a tiny "head start" in the next level.
Note: Subpixel variation is a common source of desyncs when copy/pasting movies. In games with subpixel carryover, the subpixel values should be aligned before copy/pasting.

Read the program

All games are programs in some form. While they are intended to only be executed by the game system, there is nothing stopping you from reading the program instead. While the program code is most likely not very easy to read, it is the exact rules that the game is made out of.
The best way of understanding the rules is to simply read them and figure out exactly what they mean. You can check exactly how the random number generator works or simply why the player character (supposedly) can not move into walls.
This is a very difficult thing to do, it is recommended that you know how to program before you attempt this. This is not normal programming, but on a lower level. You will need to actually understand the instructions that are given to the processor and not what the programmer may have written.

Read the script

Many games, especially ones with plot, have their own script engines. It commonly controls important events such as when you can go somewhere and how enemies behave.
Learn how the script engine works and examine what the game script does. It can have flaws just like the main program. But most importantly, it allows you to understand what your options are.

Don't save

Avoid saving the game, it commonly takes several seconds and is not needed in a TAS movie. Similarly, turn off auto save.

See also

GameResources/CommonTricks last edited by klmz on 12/10/2010 11:22 AM
Page History Latest diff List referrers View Source