Speedruns of games come in many forms. In particular, the goal choice of a run can shape it, with different runs looking very different. The restrictions and goal of a run combined are often called its "category". In this article, I try to enumerate all the commonly found aspects of a category.

When creating a speedrun, one of the major choices, even disregarding the goal, is about how much the runner is allowed to retry. At one extreme, you have "single-segment" runs, where you do the run in one sitting, no reloading of saves allowed. At the other extreme, a tool-assisted speedrun allows the use of savestates anywhere, so that a section of the run can be repeated indefinitely until the runner is satisfied with it.

A single-segment run is defined by not allowing any loading of a save file. (You can still create save files, which is important in games which have autosaves or in which saving is the only way to heal, just not do anything with them.) There's a minor exception for games that dump you at the title screen halfway through and require you to load a save to continue; such games almost invariably save the game just beforehand, and the run still counts as single-segment if you immediately reload the same save file.

A segmented run is the opposite category for unassisted runs; it allows the loading of save files, and importantly, any time spent playing the game that was subsequently thrown away by reloading a file (a "failed segment") doesn't count against the run's time (the speedrun itself is produced by editing together the footage of all the "segments" that were actually used, with a segment being the part of the run between two save points). This allows unlimited attempts at any segment of the game. Not only does this lead to a much more polished run, as mistakes can mostly be avoided via the greater number of attempts, but it allows for some tricks impossible in single-segment runs; most notably, luck manipulation, where you repeat a segment until you get good luck on it. The effectiveness of segmentation rather depends on how often the game lets you save; for games with widely spread save points the run may not be that much better than a single-segment, whereas for games which let you save anywhere, you can effectively use the saves like savestates and create something similar to a TAS. SDA (http://speeddemosarchive.com), my favourite site for unassisted speedruns, gives a half-second penalty per segment in this situation to prevent people being pressured into effectively making a TAS inefficiently.

One minor side effect of the rules for single-segment runs is that tricks/glitches that involve saving cannot be used in them. To keep the spirit of a single-segment run while allowing these glitches, the most obvious method is to allow reloading saves like in segmented runs, but count failed segments against the time. This category doesn't really have a widely-agreed-on name; SDA calls it "single segment with resets". It's also very commonly used as a segmentation category together with the use of real-time timing; this combination is known as "RTA", or "Real Time Attack".

Finally, you have tool-assisted runs, what TASvideos is about. In these, the segmentation is done via emulator savestates, and as such is invisible to the game itself; and there is no restriction on how many savestates can be made (indeed, authors are encouraged to use as many as are needed). The number of times a savestate was loaded is normally available in the metadata of a submission for a TAS (the "rerecord count"); it's rare (although not unheard of) to track the rerecord count in an unassisted run. From the game's point of view, a TAS looks either like a single-segment run, or (rarely) a single-segment-with-resets run. (Resets would be used for the same reason as in an unassisted run: to take advantage of a glitch or other technique (such as savewarping) where the save system was part of the glitch.) A TAS cannot meaningfully be a segmented run, because there is no reasonable excuse to have failed segments in the run anyway (unless they have some effect on some part of the gameplay, in which case they aren't failed segments).

TASvideos currently uses the Uses a game restart sequence category to track runs that reload save files. (The opposite, "Forgoes game restart sequences", is theoretically possible as a category but unlikely to be used; it would likely only be used in a game trivialised by savewarping, to give a sort of low-glitch category.)