SDA Knowledge Base - User contributions [en]

Making your game speedrunner-friendly

2019-06-22T06:09:34Z

Ais523: /* Capturability/streamability */ typo fix

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. (Showing the text box one character at a time is not only slower, it also forces players to choose the shortest possible name for anything they get to name, because a longer name will cause more text when it shows up in the text box.) If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run (and also makes it viable to speedrun categories such as "start with everything locked, and unlock everything").

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being a factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opaque with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

=== Further Reading / Watching ===

"[https://www.youtube.com/watch?v=VAfUTApc4oI Designing Speedruns from the Ground Up]" – Panel at SGDQ 2018.

Making your game speedrunner-friendly

2019-06-22T05:13:32Z

Ais523: /* Unlockables */ all-achievements categories

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. (Showing the text box one character at a time is not only slower, it also forces players to choose the shortest possible name for anything they get to name, because a longer name will cause more text when it shows up in the text box.) If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run (and also makes it viable to speedrun categories such as "start with everything locked, and unlock everything").

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being a factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

=== Further Reading / Watching ===

"[https://www.youtube.com/watch?v=VAfUTApc4oI Designing Speedruns from the Ground Up]" – Panel at SGDQ 2018.

Rules

2018-07-21T01:14:38Z

Ais523: /* Fundamental rules */ add section anchors to allow links directly to items within the bulleted list

This page lists the generic rules for speedrun hosting at SDA. Every run submitted to SDA will be independently [[Verification Guidelines|verified]] against these rules and to ensure that the submitted runs meet the site's quality requirements in terms of audio/video and gameplay.

==Common questions==
;What if I disagree with your rules?
[https://forum.speeddemosarchive.com/board/sda_discussion.html Discuss it] on the forum and explain why. We're always open to suggestions and welcome intelligent discussion. If enough people hate something, maybe we'll compromise. [[rule history|It's happened before.]] 

;What if I have a rule question that is not covered here?
First, use the search function in the forum and see if someone has already asked the same question. Next, if there is a game thread in one of the sub-forums, ask there and see if you get any response. If all else fail, explain the question the best you can in the [https://forum.speeddemosarchive.com/board/sda_discussion.html SDA discussion sub-forum]. Remember that there isn't necessarily an expert among the SDA staff or the forum users at your game. In order for them to be able to help you with an answer, please consider being as clear as you can possibly be when you ask (without being too wordy...). 

==Fundamental rules==
* '''Recording''': Speedruns hosted by SDA should be captured at the native framerate and dimensions (depending on region and platform). The video needs to contain only the gameplay footage and the first audio track needs to contain only the game audio (additional audio tracks can be added with audio commentary though). You can find more information about recording and processing game footage right here in the [[Recording|SDA knowledge base]]. You can also ask for help in the [https://forum.speeddemosarchive.com/board/tech_support.html tech sub-forum] if you didn't find the answer in the knowledge base.
* '''Emulators and Virtualization''': We will generally not accept speedruns recorded on unofficial emulators (ZSNES, VBA, etc.). Emulators commonly allow for recording games frame-by-frame and then playing back the input at normal speed. Emulators also give the player access by default to features not present on the original consoles, such as RAM-watch or the possibility to use, for example, keyboard as input device. Finally, many emulators have minor inaccuracies in timing and slowdown that inhibit accurate comparisons between runs. Note that an exception is made for officially sanctioned emulators such as the Game Boy Player, the Virtual Console, and the GameTap. Due to problems with many official emulators, we will place them in separate categories if the known differences make comparison with runs made on other platforms difficult. For the purpose of this rule:
: - DOSBox can be used for SDA-submissions. It has seen very widespread use for re-releases of DOS-era PC games in the past years and is frequently the only reasonable choice for playing and recording those games.
: - Virtualization software (VMWare, VirtualPC, etc.) is permitted for games that wouldn't otherwise run natively on a modern operating system.
: - Programs such as WINE that attempt to replicate the Windows system calls and structure on Unix systems are not allowed.
: - Flashcarts (such as Everdrive) are a grey area. In many cases there is no possibility to distinguish between the use of a flashcart and an original cart, in which case there is no reason not to accept them. However, if any differences would be discovered in the future, applicable runs can be expected to be removed from the site.
* '''System modification''': You are not allowed to modify your system or use extra hardware such as GameSharks and Game Genies. These devices let you alter game parameters and can give you an unfair advantage. Modchips and boot disks used for playing imports and officially released add-ons are allowed. For example, the PS2 HDD is allowed (provided the game itself has an option to install data to the HDD), while the HD Loader is not. In addition, modifications that enhance the quality of the audio-visual output of a console are allowed.
* While recording runs, interacting with the game other than through the gameplay itself is not allowed. This rule covers both passive methods (such as '''RAM-watch''') and active methods (such as '''removing or altering a game disc/cartridge/file''' while the game is running).
* '''Third-party controllers''': You must only use features that are available on any controllers that were officially bundled with the system. Thus, turbo-fire is not allowed except for systems such as the TurboGrafx-16 that come with official turbo-fire controllers. Of course, if a game itself provides a turbo-fire option, then it may be used. If the bundled controller features differ between different console releases and it's not clear which ones should be considered as default, you're welcome to open a discussion about it in the forum. If you use an unusual or non-standard input device you should be open about it (for example mentioning it in the run comments), even if it doesn't introduce any additional features. There is probably a reason why you decided not to use a standard controller in the first place. Other people trying to compare themselves with the time you have achieved have the right to know if anything was used that could be seen as a competitive edge.
* Some glitches/tricks/clips can be more reliably performed under certain game settings (such as frame rate or resolution). '''Changing game settings mid-game''' is generally acceptable as long as it's done using commands accessible through the in-game (or launch) menus. When available, exactly corresponding console commands may be used and bound to separate keys to lose less time to the graphics refresh.
* '''Codes''': Using a beneficial cheat code is not allowed: something that gives more lives, reduces damage, etc. If a code is only cosmetic, like suit-less Samus in NES Metroid, that is acceptable. A code that increases the game's difficulty, such as Donkey Kong Country 3 105%, may qualify as a separate category.
* '''Configuration files''' can be also edited for cosmetic changes. As a general rule, you can't increase a run's difficulty by this method because it's impossible to find a non-arbitrary category definition. Exceptions may exist.
* '''Impossible inputs''': Some games, such as The Legend of Zelda: A Link to the Past, show unusual behavior when one feeds them with usually impossible input, such as up+down pressed simultaneously. As such actions require worn out controllers, non-standard controllers or excessive force, they are treated as hardware modification and are thus banned as well.
* Many PC games allow you to use the in-game console to write '''scripts''' or macros to automate certain actions. There are also external input scripting programs such as AutoHotkey. These are not permitted to be used for any form of automation in PC games. You are however free to '''bind''' keys in whatever way the game allows you to do through the game's menu system or config file and it's expected that you use this to your advantage (e.g. binding of a free-spinning mouse-wheel to the jump button in Half-Life games to allow a simple way to bunny-hop).
* As a general rule, speedruns submitted to SDA are supposed to be using the game '''patch''' that allows the fastest possible completion of the game. SDA doesn't consider different patches to be a reason to create new categories, so make sure that you choose the correct one for your game. The exception is if the fastest patch has severe compatibility issues in a modern OS and cannot be, e.g., run without Windows XP, in which case the fastest compatible version can be separated as a category of its own.
* Many speedruns utilize '''glitches''' (unexpected behavior due to the game's programming), to the runner's advantage. Glitches are allowed and runs submitted to SDA are expected to fully utilize beneficial glitches and bugs in their runs to save time within the confines of the game's behavior. In extreme cases, glitches allow you to skip huge chunks of the game and that can warrant a separate category. More about that further down.
* SDA will accept hosting speedruns for many games, but not all. Here are some examples of '''games that won't be accepted''':
: - Alpha/beta versions or early access of a game
: - Shareware and demos (i.e. partial full games)
: - Romhacks
: - Game mods (defined as requiring the original game in order to play)
: - Games that can't be sped up. Examples are games that run on a fixed timer or rail shooters. A rail shooter can be an acceptable game choice if there are enough gameplay elements that allow the game to be sped up compared to a normal playthrough. Examples could be lag reduction techniques, particularly long boss fights or boost abilities.
: - Games without clearly defined start and end points.
: - Games where you play against other human players.
: - Games with ”morally questionable” content (extreme racism or adult content etc). 

==Categories==
Not all categories apply to all games and some games can even have game specific categories not mentioned here. In general, all runs must complete the game to an ending. We have divided the categories into three groups, ”segmentation”, ”completion percentage” and ”additional category tags”.

===Segmentation===
SDA accepts speedruns completed either in a single sitting, or in multiple segments recorded over a longer time period.
* Games that allow you to save your progress and continue later can be done using segments. A segmented run implies a higher level of risk-taking and a lower tolerance for mistakes. '''Use as many segments as is optimal''' to achieve the fastest final time. Also do not feel like you must use roughly the same number of segments as a run you are attempting to obsolete. However, to avoid over-segmentation in games with a 'save anywhere' feature, make sure there is a distinct purpose to every segment, e.g. luck-manipulation, clearing a difficult section etc. 
: There obviously needs to be continuity between segments in terms of inventory, experience points or whatever is applicable for the individual game. Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before. Be aware that additional caution needs to be taken in games where the RNG seeds carry over between segments. It will in practice often be difficult to determine if this results in an advantage for the player or not. Re-doing segments where the RNG seeds impact future segments in a noticeable way is therefore not allowed on SDA.
* Runs done in a single sitting are referred to as '''single segment''' (SS) runs.
* '''Single segment with resets''': You are allowed to save and resume in a single segment run as long as it is part of the same game session. This will add the with resets tag to your run.
* For some games, it makes sense to track times for '''individual levels''' (IL). Usually, this is the case if the game is separated into sections that can be individually selected and are independent of each other (for instance, no status effects or equipment carry over between levels). If there is a minor connection between levels but an obvious base state exists, ILs may be done starting from this base state (for example, the Yoshi's Island ILs all start with 0 eggs and don't permit using any of the bonus game items from the pause screen). If the game does not currently have any IL runs then all of the levels must be completed as part of the initial submission. For future improvements, each IL may be obsoleted individually.
* Some games have timed '''mini-games''' that can be competed in isolation from the rest of the game. These may qualify as additional categories for games that already have a full run. 

===Completion percentage===
Beyond this basic consideration of the type of segmentation, a run usually also falls into one of the following categories:
* '''any%''': This is the most basic goal of a speedrun: beating the game as quickly as possible. The aim is to reach an ending (or for an IL, the end of the level) as fast as you can manage to within the boundaries of the game. This may include skipping entire sections of the game, skipping key items, leaving the boundaries of the game world and abusing programming oversights left in the game. Most runs fall into this category.
* '''100%''': A lot of games, especially ones following an open-world design, have collectibles and core items that a player may or may not pick up over the course of the run. The goal of a 100% run is not only to beat the game quickly, but also to bring it to a 'full' completion in doing so. This usually involves collecting all of the collectibles and items that grant permanent status changes as well as finishing all of the quests and/or levels in the game. This category is usually easy to define for games that track the completion rate, but other games may also have 100% runs. [https://forum.speeddemosarchive.com/post/low100_definitions.html This forum topic] contains 100% definitions for a number of games. This thread is mainly for posting the rulings, not for the discussion itself. If you wish to discuss the 100% definition for a game that's not mentioned in that thread, first post in the relevant game thread (or create one if there is none for your game) and see if you can get feedback from other people who know the game.
* '''low%''': While the 100% category aims to complete a game as fully as possible, the goal of a low% run is the opposite of that: Beat the game using as few resources as possible. This is probably the least well defined of these categories and strongly depends on the specifics of each game. For games that track a completion percentage, the goal is to minimize that completion rate while still beating the game. For other games, the goal is usually to replicate that behavior, which means foregoing as many collectibles and permanent power-ups as possible. It's important to note that as a general rule, the spirit of this category is "not collecting" items, but not "not using" them! If the game gives you upgrades or powers at certain points that can't be avoided, you're expected to use these items to the full extent. As an example, think of the Megaman games. When you beat a robot master and gain their power, you should not just stick to the buster gun (unless of course that is the best weapon for a given situation). See above under ”100%” for how to discuss the definition of the category for specific games. For this category, an accepted run that manages to beat the game on a lower completion rate than a currently published run will obsolete that run even if the completion time is slower. 

===Additional category tags===
In addition, there are frequently more game-specific categories and tags that are added to a run beyond those. Not every possibility will be listed here, but some or the most frequently used are:
* '''Character used''': For games with multiple playable characters that don't just constitute a cosmetic difference, each playable character may constitute a separate category. However, for games with a large roster of characters (such as racing games), you are usually expected to just pick the fastest character instead of having individual categories for all character choices.
* '''Difficulty''' settings that will always be accepted are the fastest (usually the easiest) setting and the hardest setting. Additional settings (especially the game's default, or special challenge modes) are accepted so long as there's sufficient variation between them and the aforementioned ones. For games with no speedrun history, SDA is more relaxed with the choice of difficulty level. However, if the game starts to see more activity and the game page fills up, runs on ”in-between” difficulties can be expected to be obsoleted in favor of more competitive difficulties. For games that allow you to change the difficulty settings during the game (such as the Left 4 Dead games), you are allowed to mix and match the difficulty in order to achieve the fastest time possible. In that case the run receives a mixed difficulty tag.
* In some games, deaths can be used to save time by, for example, teleporting back to a location you've been already and must return to or to refill your character's resources, such as weapons or health. Any run with deaths will be placed in the '''with deaths''' category. This also includes the use of continues after a game over.
* Some games have tricks or glitches that allow you to skip a major part of the game. In this case there will be a '''with large-skips''' category for the game (for instance, skipping entire dungeons in Zelda games). Runs using warps that skip large parts of the game (e.g. warp zones in Super Mario Bros.) are treated the same as runs with large-skips, but will be labeled '''with warps''' instead.
* '''with uber large-skip glitches''': Some games contain glitches that go beyond skipping portions of the game and allow you to literally skip the vast majority of the game. Credit warp runs typically go into this category.
* '''Multiplayer''' runs are considered as a separate category to single player runs. The more players you have, the more things can be done at the same time, but can also mean additional lag and the worn-out term ”no chain is stronger than its weakest link” might also apply. There is in general no distinction on SDA between the number of players in a multiplayer run. Use as many players as you deem necessary at any given point during the run to achieve the fastest completion time. This rule also includes runs where one player simultaneously controls two (or more) characters in the game.
* '''New game+/DLC''' means that you use stats, equipment, characters or other game features that are not available when you start a game from scratch. DLC (Down-Loadable Content) should be self-explanatory, while new game+ refers to starting the speedrun from a saved file (usually, but not always, from a completed game file) or a state where for example unlockables have been made available. 

If you feel that a certain category would make for an interesting run, feel free to ask about it on the forum or contact an SDA admin about it. Please just keep in mind that the more arbitrary the rules are, the less likely it will be seen as a good fit for the site. 

==Timing==
Always remember that speed is the first and foremost priority; side issues such as entertainment are secondary. Someone can beat your run later simply by omitting your time waster. If you waste enough time, the verifiers will reject your run outright. Similarly, if a game lets you skip cut-scenes or advance through text quickly, then you must do so (exception being if the game has an in-game timer that doesn't run during cut-scenes – it's still preferable to skip what's skippable though). Below follows the '''general''' outline for how timing is done on SDA, including some recurring special cases. It's not possible to cover every imaginable situation though, so there will still be many games that must be treated as special cases.
* The game's '''internal timer''' will generally be used unless it is inconsistent or fails to display the time after completion.
* For games without timers, a simple real-time measure is used. There are many different types of software that can do this. Avidemux for example (be sure to use a version that allows frame count, at the time of writing, that means v2.5 or earlier).
: - '''Starting point''': when the player first gains control of the game's character, timing begins. This is defined as the frame before the character starts to move (in case that's hard to define, a reference point, such as fade-in can be used instead). If the game starts by going through menus that have an impact on the gameplay (adjusting stats or equipment) or an overworld map (or level selection screen etc), then those are defined as ”gain of control”. However, if character creation is done as an independent activity before the game starts, it's not considered as part of the run time, even when it involves defining stats, equipment or similar. Having camera control (for example Half-Life), but no means of impacting the character's movement, is not considered gain of control for the purpose of SDA-timing.
: - '''Ending point''': at the end when control is lost, even if that's long after the final battle, the timing stops. This is generally defined as the frame the character freezes on. If loss of control is hard to define for a game, a reference point, such as fade-out to credits can also be used. For RPGs, we use the frame the hit points of the final hit on the final boss shows up (unless there are gameplay elements coming after that point). Possible movement that can occur during or after the ending credits does not count (unless it involves actual gameplay elements that affect the outcome).
: - '''Loading screens''' are counted for console games, but not for PC. For segmented runs, timing for a segment stops at the first system-dependent activity. It can be the save screen (automatic saving) or when the save menu screen appears (manual saving). The starting point for a segment depends on if you actually load a game state or if you're just back at the starting menu with your progress saved. If there is a loading of the save, we will use the frame before the loading screen fade-out as starting point. This means timing might start with a cut-scene, even though there is no character control at that point. In the second case (you start a new segment from the start menu), timing will begin as soon as you activate the menu option that starts the new segment. This is generally the option that leads to a new menu with gameplay-related, and not only cosmetic, options.
* For some speedruns, the route and strategies depend on whether the in-game timer or real-time is used. In that case, both types of run can be hosted on the site side-by-side. 

==Hosting==
* Speedruns accepted on SDA will be made available both on SDA's server and on archive.org.
* For each game there can be multiple categories of runs that are posted on SDA. These generally exist independently of each other and are also improved and obsoleted independently, except for when a new run in a more restrictive category beats the time of a currently posted run or when a new run in a comparable category improves on an existing run beyond the scope of the category difference. For instance, a run on an easier difficulty that significantly improves on an existing run beyond the time saved from playing on an easier difficulty level or a run on a faster version that clearly improves on an existing run more than the version difference accounts for. Cross-category obsoletions are done on a case by case basis.
* Once a speedrun has been published on SDA, it will be hosted until it's obsoleted by another run or if there are doubts about the validity of the speedrun (for example cheating, inconsistencies in segmentation or not sticking to the category rules). The obsoleted run will still be available on archive.org, though.

Hammerfight/Mechanics

2017-12-14T06:44:24Z

Ais523: /* Level Skip/Gold Bulla */ exact value

== Level Skip/Gold Bulla ==
Level Skip/Gold Bulla
If you have enough money (the cost is 10, with bronze counting as 1, silver as 2, and gold as 8 rather than the usual 10), this happens on the third “try again” for a specific stage. You lose all your money but skip the stage. THIS MEANS THAT YOU DON'T GET THE UNLOCK FOR THE LEVEL.

== Armor Breaking ==
If you hit armor hard enough, it breaks off of the enemy.
== Dizzy ==
If your ship hits something, like a piece of something or a wall or ground or pretty much anything, you lose control of your ship for a short time. This can really screw you over. Be careful when killing an enemy as parts fly everywhere, and some parts can dizzy you.
== Slow Time ==
Time slows down and the mass of your weapon is increased. Two ways of triggering this: Hit the enemy really hard, or get overkill by knocking their weapon off of them while they are in the red. It doesn’t always happen when you do this, so I’m not sure the exact criteria needed to get this. It helps you do more damage but it can be dangerous because if you get dizzied, you can take lots more damage since your weapon is so heavy. It also slows down time for a few seconds, which may not be helpful for your run.

Making your game speedrunner-friendly

2017-03-18T21:17:28Z

Ais523: /* Cutscenes */ mention customization of player names

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. (Showing the text box one character at a time is not only slower, it also forces players to choose the shortest possible name for anything they get to name, because a longer name will cause more text when it shows up in the text box.) If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run.

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being a factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

Making your game speedrunner-friendly

2017-02-17T23:24:40Z

Ais523: /* Determinism and recording */ typo fix

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run.

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being a factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

Making your game speedrunner-friendly

2016-12-12T02:56:41Z

Ais523: /* Game flow */ typo fix

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run.

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

Making your game speedrunner-friendly

2016-12-04T06:52:35Z

Ais523: update based on feedback, and a number of typo, etc., fixes

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedrunner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or since the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightfoward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see cutscenes in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, randomness is an exception; it often serves a genuine gameplay purpose and is there to make the game more interesting. This means that when it comes to randomness (assuming it actually serves a purpose), it makes more sense to try to manage the negative impacts it has on speedrunners rather than removing it entirely; you wouldn't want to get rid of the positive aspects too.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

Bear in mind that randomness can be good for speedrunners too! Most of the reasons randomness is bad stem down to "it makes the run less about skill". This means that in situations where randomness makes a run ''more'' about skill, it's helpful rather than harmful. A good example is a random event that requires a reaction from the player, but if dealt with correctly, ''won't slow them down'' compared to the event not occurring. This sort of thing raises the skill required in the game, and isn't unfair between runs where it does and doesn't happen because a good player will be able to take it in stride, rather than necessarily losing time as a result.

=== Unlockables ===

Many games choose not to have everything available from the start. This can be to help new players ease into the game, by avoiding overwhelming them with the game's true complexity; it can be to ensure that the player is good before they have access to "expert" options; or it can be to give rewards and/or goals to aim for. If unlockables are limited to a single save file (i.e. you have to unlock them separately each time you play the game), then they aren't really an issue for speedrunning; if they turn out to be relevant to the speedrun, they'll just have to be worked into the route. Unlockables that persist between save files, though, can be a problem for speedrunners, and in more than one way (although all the problems are manageable, so this is more something that you need to be aware of rather than something that you need to avoid).

One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run.

Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep. These glitches are much easier to pull off on an N64 than on a Wii, because the N64 runs more slowly and thus is more susceptible to lag.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible. (The optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen. Although it's unrealistic to do that well, you should try not to be much more than a frame behind the optimum amount of render lag.)

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations; in general, it's best not to use floating point at all except for graphical calculations that have no impact on the game's physics), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being factor.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determining these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items. (For example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game; and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total.)

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from other speedrunning categories, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top players.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving by mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this is to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the most subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

Making your game speedrunner-friendly

2016-09-23T02:00:49Z

Ais523: new page; I've been working on this for ages; was also requested by LotBlind but only after I started work on it

Every now and then, a game developer comes to a speedrunning forum and asks for advice on how to make their game better for speedrunners. After answering several of these questions, I decided to make a compendium of advice for easy reference.

== Summary ==

The vast majority of advice here stems from one of three reasons:

*<dt>Ensure that the playing field is level, even between two players on different systems.</dt><dd>Players can compete against themselves, but they like to be able to compete with others too.</dd>
*<dt>Allow players opportunities to improve their times, both in competition and in practice.</dt><dd>If players can't find, measure and learn improvements, they'll move on.</dd>
*<dt>Give your players something to be optimizing at all times: decision-making, execution, or both.</dt><dd>Downtime causes boredom, and boring hobbies tend to be abandoned quickly.</dd>

Most of this guide is basically just an in-depth explanation of what these goals imply about specific details of a game, but the general principles are important in their own right.

== Gameplay considerations ==

=== Resetting and practice ===

Not every attempted speedrun is a world record. Speedrunners typically take huge numbers of attempts, both in practice and as serious runs, in their quest to make the fastest speedrun possible. As such, it is fairly vital that your reset cycle won't discourage players from running the game.

Towards the start of a run or practice session, any nontrivial mistake may cause a speedrunner to abandon the run and start again. (If your game is short enough – and it's often hard to predict how long your game will be, especially with the potential existence of glitches – speedrunners will be in this mode throughout their entire runs.) If this requires resetting the console, going through a bunch of menus, manufacturer logos, and the like, the speedrunner isn't going to be happy. Likewise, a reset cycle that goes through long loading screens or unskippable cutscenes is highly problematic. Ideally, a reset would take the speedrunner directly to immediately before the gameplay of the game started, such that the game would start with their next button press (dropping the runner right ''into'' the game is problematic as they need a chance to start their timer).

You also need to think about how the speedrunner gives a reset input to the game. Resetting the game is a pretty drastic thing to do if you care about your save file, so it's typically made difficult for casual players. However, speedrunners want to be able to input a reset without long waiting periods or going through several confirmation screens. As such, a reset input is normally a sequence of multiple keys, or a chord (in which multiple keys are pressed at the same time); these are relatively easy to type intentionally, but unlikely to be typed by accident. Most games use their pause input as the first key in the sequence/chord in order ensure that it's never something that a player would need to enter in the normal course of gameplay. On console games, sometimes you can use the actual physical reset button on the console (or even the power switch!) for the purpose, although you still need to make sure the game loads back up as quickly as possible after a reset, which might be difficult using typical reset button implementations; provide a reset code as well if you technically can't, or don't want to (e.g. due to needing to show a publisher's logos), avoid a forced wait after a hardware reset.

Players also aren't necessarily going to want to reset to the start of the game; it's common to want to practice sections of the game other than the start, then reset repeatedly after them (at least when you fail, and when trying to learn a difficult trick, sometimes even when you succeed). The most common way to deal with this is to have your reset command restore to the last save, but to also have some way to avoid saving (speedrunners normally omit as many saves as possible, frequently all of them, because they typically cost time; thus if saving is optional and speedrunners never save, the reset command will reset a speedrun to the start of the game without any additional logic needed). This means that players can practice a section of the game by saving before it, and then repeatedly resetting back to their save.

In games which have an autosave, this trick doesn't work, so you'll need some other method to make sections of the game easy to practice. Many games are divided into levels. In the case where the levels are mostly independent of each other, it makes sense to add a level select mode which lets players practice the levels individually (and have resetting return the player to the start of the level in this mode). Other possibilities include a debug menu / cheats to allow the player to place themself somewhere on the map. (You could also just add the possibility of turning autosaving off, something that's seen in games occasionally.)

=== Autoscrollers and frame rules ===

One of the most important factors in making a game fun to speedrun is that the speedrunner always has the possibility to do things to improve their time. A section of the game that can't be optimized is not very interesting to speedrun, as all that's required is survival (and to a player good enough to be attempting a speedrun, survival is unlikely to be difficult).

One of the largest offenders here is what's often known as an ''autoscroller''; this is an area of the game which has a fixed time limit and cannot be completed until the limit runs out. (The classic example, which inspired the name, is a section of a game in which the camera moves on a fixed schedule and you cannot move outside the camera's view, and thus are unable to complete the level until the level exit happens to become visible on-camera.) These are fairly common in games because they change up the gameplay, but very tedious in speedruns as there's nothing you can do to optimize your time. Speedrunners would thus prefer to be able to avoid all the autoscrollers in a game, if they can; as such, if you have them at all, it's best to keep them away from the fastest route through the game. (For example, you could have points in the game at which the player has a choice of levels, and ensure that autoscrollers only ever exist if there are alternative choices, and those choices are faster.) As a side note, a tool-assisted speedrun often likes to see one autoscroller because it gives the player a chance to show off what tricks and glitches are possible in the game engine (thus adding more entertainment) without having to waste time to do so. There are some speedrunners who have similar levels of showmanship, but most would prefer just to be able to get through the game quickly.

Another solution to autoscrollers is to give the player some method of influencing the time they take. An autoscroller where the camera moves at a fixed speed is uninteresting on a speedrun, but perhaps you could place elements in the level that vary the camera speed, so that a speedruner can concentrate on trying to make it move as fast as possible. Alternatively, you could make the camera move faster or slower depending on what the player is doing, thus adding another axis that needs optimization other than simple survival. The idea is to make sure that the player always has control over how fast they can go. You could also replace an autoscroller with some sort of chasing element or time limit, in which the player is penalised for going too slowly but not penalised for going too quickly; this keeps in a reasonable proportion of the autoscroller gameplay from the point of view of a casual player (especially if going quickly causes you to be chased faster and therefore is a bad idea if merely trying to survive), while avoiding the element that hurts speedrunners.

The traditional camera-based autoscroller, and "survive for X minutes" levels, are examples of the harshest possible types of autoscroller, as barring glitches, there's nothing you can do to speed them up. However, there are other gameplay elements which behave in an autoscroller-like way in practice. One of the most common involves moving platforms in platform games; if a platform is moving a long distance through a level, and using the platform is required to make progress, then the player will have to wait for the platform to reach the last point at which they require it before they can continue. In many cases, this is effectively an autoscroller. There are more ways to make this more interesting, though, than a simple camera-based autoscroller. One method is to allow the level to be completed without the use of the platform, via adding in an alternative method; speedrunners will almost certainly find something like this unless it's very well hidden, and casual players who find it will typically enjoy the challenge. The normal approach here is to chain jumps from enemy to enemy (and occasionally on structural elements of the level) in order to reach the end of the section that would normally require a moving platform. Adding more movement techniques to the game allows you to have more variety in strategies here (e.g. if your game has wall jumping, perhaps a series of walljumps would let you cross a gap that otherwise needs platforms; or perhaps your game has a power-up that gives the player more mobility and makes routes possible). Another trick is to have a moving-platform level in which falling off the platform merely damages you rather than being fatal, in which case a player can skip at least the end of the platform's motion via running off the end and tanking damage until they reach the end of a level (or possibly a save point / continue point).

On the subject of moving platforms, there's a similar problem to the autoscroller, on a smaller (but still relevant) scale. A ''frame rule'' is an element in the game's programming or level design that causes a certain point of the game to only be passable at defined intervals (e.g. only for the first second in every five, or only every 21st frame) relative to a substantially earlier point in the game (e.g. the start of the level). One of the most common examples is a platform that moves back and forth a short distance, which is on the fastest (or only) path through the level, and whose position depends on time since the start of the level or sice the start of the game; if the platform is in the wrong position when the player reaches it, they'll have to wait for it, and because this depends on the time spent so far through the level, it means that mistakes earlier in the level may not hurt a player's time (because they have to wait for the platform to arrive anyway, and going faster would just mean waiting longer). Frame rules are relatively easy to make by mistake when placing any element of the game on a timer, whether it's a platform or score countdown; to avoid a problem, the timer has to start counting only at the last moment, rather than being relevant to an earlier point in the game. In nonlinear games, they're less of a problem, as it's often possible to rearrange parts of the game in order to give a frame rule less of an impact. In linear games, though, you want to avoid them, as there's often not much a player can do but wait and as such they reduce the ability to compare players, as perfect and slightly imperfect play may well give the same time.

=== Game flow ===

Autoscrollers are time periods that you can't speed up because if you go too fast, you're forced to wait. However, there's a similar, much more common issue: time periods that you can't speed up because going at maximum speed is trivial. For example, in many games, a long empty corridor is uninteresting; the player will just move down the corridor at top speed (perhaps by holding "run" and "forwards"/"right" for 3D and 2D games respectively). Because the best strategy is trivial, the skill ceiling for this sort of section of a game is very low, and speedrunners will quickly get bored doing it (especially if the section comes early in the game and has to be negotiated after every reset). One of the biggest things speedrunners look for in a game is therefore interesting movement (unless moving from one place to another in the game is a ''very'' minor part of the game).

There's more than one way to do this, depending on the ideas behind the game and its general style. For example, you could make movement interesting on the micro-level, by (say) allowing the player to move more quickly than default by chaining special attacks than by running; this style tends to work well for platformers and games where movement is a similarly important part of the gameplay. If you go down this route, better still would be to ensure that instead of just repeating a sequence of keystrokes over and over, the best way to move depends on the details of the surroundings. Platformers that make good speedgames therefore often have very fluid movement, with a large variety of movement techniques (common examples are things like double jumps and wall jumps, although the field of interesting movement techniques is much wider than this); a common alternative or supplement is to have some sort of imprecise rapid-movement technique (such as a dash that moves in a straight line and that wastes time if stopped too early) so that strategy is needed to plan out the various locations of using the various movement techniques available.

Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightfoward way to move faster like holding a key, but some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.

Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further.

Movement isn't the only situation in which a good game flow is important, although it is probably the most common one. It's important for speedruns (and often to casual players too!) to identify any situation in the game in which the best/fastest solution is trivial to execute, and yet time-consuming. Another situation where this commonly happens is in menus, especially in RPGs which use menus for combat. The correct input is often obvious (some variation on "attack" or, more generally, "repeat what you did last turn"), and if you have to scroll through the menus to find it every turn, that's just a repeating sequence of relatively uninteresting keypresses. Often it's hard to make the input in this sort of case more interesting, so what you can do instead is to try to make the actual inputting part a minimal part of the game; for example, you could dedicate a single keypress to "repeat what you did last turn" (which is the solution to the problem that most RPGs in fact use in practice). Tutorials are another case which are typically trivial for an experienced player; you could offer an option or input to skip tutorials, or else make them interesting enough (perhaps by providing alternative, faster but more difficult, solutions) that they become interesting even for someone who's beaten the game multiple times already.

A related issue is to ensure that the game has solid controls; in particular, you want to be able to perform most actions with a minimum of inputs (unless, as in some fighting games, having complex and difficult-to-enter inputs is part of the gameplay). For example, for a PC game, hotkeys are typically favoured by speedrunners over clicking on icons or buttons on the screen, because moving a mouse to a point and clicking is fairly tedious compared to just pressing a key to perform the action directly. In general, single button presses and small chords are better for speedruns, and menus and mouse/joystick movement (except to move the character) are worse. Ideally, the controls should be customizable so that speedrunners can find a control scheme that works well for them.

Note that although interruptions to the game flow are less of a problem if infrequent, they're still a problem! Things like a splash screen at the start of a level, confirmation dialog boxes on actions, and the like, are all short and minor irritations that nonetheless make the game less fun to speedrun (and can be annoying even in casual play). Often there are other good reasons for these things to exist, so you may need to make them optional (i.e. adding a game option to turn them off), or allow them to be dismissed quickly via tapping or holding a particular input.

=== Cutscenes ===

Many games have noninteractive (or minimally interactive) sections that are typically used to expand more on the game's story. These are known as ''cutscenes'', and require very careful treatment as far as speedruns are involved.

One of the most relevant tensions here is that many casual players will only ever play through a game once or twice, whereas speedrunners may well play through the game hundreds or thousands of times (or more!). There are often good reasons to ensure that players see them in their first playthrough (typically because the information in them is required for players to be able to make any sense of the game, either in terms of gameplay or in terms of story, or both in games where the story and gameplay are heavily intertwined). Being able to see cutscenes once in a while can also be fun even for an experienced player. However, seeing them for the five hundredth time isn't so interesting for a speedrunner; and as an unskippable cutscene is basically an autoscroller that has no scope for skill, and thus badly breaks up the game flow too, it's one of the worst things you can put into a speedrun. (And having a long cutscene at the start of the game, which is fairly common, screws up the reset cycle too!)

Assuming that you want cutscenes in your game (and most game developers do), there are four main solutions. If none of the cutscenes are indispensible (common in more gameplay-driven games), you can simply make the cutscenes skippable using a keypress. (For keyboard-driven games, Esc is common. With a mouse, there's often a "skip" button that can be clicked on. Using a controller, the most commonly seen single keypress for skipping a cutscene is the pause/menu button, which has different names on different platforms.) Although a single-keypress skip is worthwhile in faster-paced games (and your casual players will likely be using it a lot too, especially if they need to reset a lot in order to pass levels and don't care to read the cutscene the second time round), slower games often put a lot more work into their cutscenes and want to reduce the chance of players skipping them accidentally (say because they want to pause a particularly long cutscene to take a break). In these games, cutscenes are normally skipped by a sequence or chord, in much the same way as reset inputs are made hard to enter by mistake.

If you want to ensure that pretty much every casual player will see your cutscenes basically no matter what, but allow speedrunners a method of avoiding them, a surprisingly commonly seen trick is to make a physical reset input to the console (or Alt-F4, the equivalent for a PC game) work as a cutscene skip (this is something that casual players basically never try, and which speedrunners often take a few months to discover even though it should be a well-known trick by this point). The simplest way to implement this is just to autosave at the start of the cutscene (although autosaves cause problems for speedrunners in other respects, all of them can be worked around via careful game design, and thus it's entirely reasonable to have autosaves in a speedrunner-friendly game). Doing a physical reset and waiting for the game to reload can be fairly slow, breaking up the game flow, so this isn't really a recommended option even though it's better than waiting through the whole cutscene. You might want to add it as a supplement to one of the other techniques, though (its main disadvantages are for single-segment runs, and TASers and segmented speedruners will have no problems with doing this sort of cutscene skip).

Another possibility that's sometimes seen is to enable cutscene skipping as described above, but only for players who have seen the cutscene before. This can't sensibly be done on a per-save-file basis (because someone on a replay will be unlikely to be using the same save file), so you'll probably have to base it either on files stored on the game cartridge or the system on which the game is stored, or by seeing if the cutscene has been viewed on any save file. This makes a good complement to the previous suggestion, because it's particularly helpful for single-segment speedrunners (who will typically have plenty of practice saves to work from), whereas it doesn't help much in a TAS (TASes need to be reproducible and thus typically can't rely on external save files). I would have recommended doing this more in the past, but it's lead to some controversy more recently, typically in games which have a "glitched newgame+" (i.e. a glitch that relies on the content of save files other than the one being used); if players are using content from one save file to speed up another, it can be hard to define exactly where the line should be.

Finally, a solution that's particularly common in games that were designed with speedrunning in mind, and which tends to keep everyone happy, is to have an option that turns cutscenes on and off (perhaps with disclaimers to discourage casual players from using it, if the cutscenes are important). If you think only speedrunners will want to skip your cutscene, you can group a cutscene skip option together with other speedrun-related options (most commonly, a visible timer, and disabling autosaves). Whether the cutscene option is separate or part of another option, it means that speedrunners don't need to bother pressing a button to skip a cutscene – the cutscenes "skip themselves" – and casual players have no risk of skipping them by mistake. It also speeds the game up more noticeably in cases where the cutscene would require a long loading time before or after it, because removing the cutscene often means that you can remove one of the loading screens near it too.

On the subject of loading screens, these are very similar to cutscenes in most respects, except added to games for a different reason, and therefore in need of different solutions. It'd be nice if players could choose to skip loading screens, but if they could, there'd be no reason to have the screen in the first place! Although loading screens are bad for speedruns for all the same reason that cutscenes are, often there's not much you can do about them (although keeping them short in length and number is going to be helpful, and trying to keep them out of the reset cycle as much as possible is also going to be helpful). In cases where a cutscene is used to hide a loading screen behind it, you probably want to make the cutscene skippable at the point when the loading has happened even though it can't be skipped earlier; this could be done either by hiding the cutscene and showing the loading screen behind once the skip input is given, or else rejecting the skip input (with some feedback, e.g. an error sound) if it's given too early. (In the latter case, you probably want some visual feedback to come up to indicate, "OK, I've finished loading, you can skip the cutscene now".) For any part of the game that needs to be loaded and that isn't critical to the game's functionality (such as detailed textures), you might want to provide an option to turn it off; speedrunners will normally accept a reduction in graphical quality if it means shorter loading times.

One thing to take care of is that although speedrunners will normally do what they can to reduce loading times and skip cutscenes as early as possible, the occasional speedrunner will want to play with better graphics or watch through a cutscene for amusement value, at least occasionally. It helps if you don't punish them time-wise for this, which basically means pausing the timer during cutscenes and loading screens (see the discussion on the timer below). It also helps to ensure that your cutscene skips give exactly the same result as the cutscenes would have if they played out, so that players are never forced to watch or skip a particular cutscene in order to get the best result in the game. You don't want your cutscenes to place the player in a different position if skipped, or to dock the player completion percentage if they don't watch to the end (both of these problems have actually happened in games in the past!).

One other thing that needs thinking about are text boxes, which are effectively miniature cutscenes. As such, you want to make them efficiently skippable, just like cutscenes should be. Typically this will be via showing the entire text box at once (rather than one character at a time), at least as an option, and allowing it to be cleared with a single keypress. If you have a ''series'' of text boxes, you want one input, typically Accept/OK, to dismiss the text box, and one keypress, typically your cutscene skip input, to dismiss the entire series of textboxes. Another good reason to show text boxes one text box rather than one character at a time is to be fair between the different language versions of your game; you're likely to need a lot more characters to express something in German than you are in Japanese, and drawing the text box character by character thus forces players to seek out specific language versions of a game to be able to get the fastest times (if the text box counts against the time) or the fastest reset cycles (even if it doesn't).

=== Randomness ===

Later on, I discuss nondeterminism and the issues that it has for speedrunners. In most cases, nondeterminism serves no gameplay function and thus can be removed (helping out speedrunners) without hurting anyone else. However, sometimes parts of a game are meant to be intentionally unpredictable/random for gameplay purposes, and thus removing the nondeterminism that's caused by randomness would miss the point. As such, it can be worthwhile trying to reduce the impact of randomness on speedruns via careful gameplay design rather than via trying to remove it entirely.

There are two main reasons why nondeterminism is bad for speedrunners. One is that it encourages trying repeatedly until the speedrunner gets the best possible result; this means that doing well on a speedrun becomes more about persistence than actual skill at the game, something that can be quite discouraging. The other is that it means that players aren't competing on an equal footing, and a player could do better or worse than another through no fault of their own. As such, if you want to include random elements in a game designed for speedrunning, you want to reduce these two factors as much as possible.

There are various reasons why you might want to use randomness in a game. One is to remove an advantage gained from having played the game before; if an event is meant to come as a surprise, or the player's meant to look up a code in-game rather than remembering it from a previous playthrough, then having the event happen at random or the code be chosen at random is a fairly common method of implementing this. When you're using randomness for this purpose, the important thing is to ensure that all possibilities are equally fast (or at least, as approximately equally fast as possible), and thus a speedrunner won't be disadvantaged by the random numbers they happen to get. For example, suppose a fairly common animation in your game has a much rarer variant, that replaces it every now and then as a surprise to amuse the player. There are two main ways to prevent this being problematic on a speedrun; either you can ensure that the two variants of the animation have the exact same length, or else you can ensure that the rare variant happens a constant number of times per playthrough (most likely once, in this example). Because speedrunners are fairly good at finding glitches, you need to be careful with things that are meant to happen once per game to ensure that they aren't skippable; in this case, you might pick a random moment in the first half of the game to display the animation, and then play it at that time or at the next opportunity if the intended time to play it was skipped, thus making it very likely that the animation will play even in the face of heavy sequence breaking. In the case of a randomized code, the time variance is the risk that the code could be guessed correctly; you can fix this either by drawing the code from a ''very'' large pool of possibilities, or else marking all codes as incorrect before the player discovers the correct code, rerandomizing the code if the correct code is entered at a time when the player shouldn't know it. (Note that you shouldn't just make the code deterministic, or speedrunners will memorize it and skip the portion of the game where they're meant to obtain it; that is, unless you ''want'' that portion of the game to be skipped on a speedrun because it's a boring tutorial or the like. Failure to randomize this sort of code has lead to entire games being trivialised in the past.)

Another reason for randomness is for the "lottery effect" / anticipation that comes with random results from a common action (such as random item drops from killing enemies). This sort of thing is fairly annoying for speedrunners because it places a large luck-based element on whether a run can be good or not; some speedrunners like that sort of run, but it's more widely despised as taking control out of the runner's hands. One possibility is to add a method of influencing the results; I don't mean this in terms of probabilities, but rather in terms of choosing the result based on something that's under the player's control (this could be anything in the game that the player can determine the results of, such as the identities of the last ten enemies they killed, the path they took through the world map, or even the note that's currently playing in the background music). Of course, you can't do this if it would badly disturb the game's balance, but this sort of trick can be fun for casual players to learn about and exploit too (learning a way to deterministically get a superweapon that would otherwise take days of grinding is a good way to rekindle your players' interest in a game that they'd otherwise grown bored of). A related solution is to change random conditions to counts (e.g. instead of getting a rare drop with a 1% chance with every enemy killed, make it so that every hundredth enemy killed drops a rare drop). With some game designs, though (especially in monetised multiplayer games) there's not much you can do about this sort of randomness without disturbing something more important.

Finally, some games use randomness as an input to procedurally generated content, as a method of keeping the game fresh. In addition to the earlier advice about keeping the various possibilities balanced when something is randomized to avoid spoilers, something that's worth considering is the idea of a "seeded run" in which the randomness is based on information input by the player at the start of the game. This has two purposes; one is so that speedrunners that dislike randomness can find a good seed and just use it forever (thus avoiding all randomness-based issues), and the other is that when two speedrunners race, they can pick a seed randomly and both use the same seed, negating a reasonable proportion of the time variation that comes from randomness (although there will still be some, because players will be rewarded for correctly guessing what content will generate and acting accordingly). In such a case, you should probably have a non-seeded mode available too (which is basically seeded mode but with the seed chosen randomly by the game rather than being specified by the player), with its own leaderboards; this preserves the random aspect of the game to casual players and that subset of speedrunners who like the game being somewhat out of their control (or who aim for good average times or long winstreaks rather than for world records).

== Technical considerations ==

=== Fixed-step physics ===

One of the worst technical issues that can occur to speedrunners is if the game runs differently for different people. When people are competing for world records, they need a level playing field.

There are two basic ways to do game physics. One possibility is to know how fast things are moving, and how long it's been since the last physics update, and use formulas of the form "distance = speed × time". If you're using realtime to determine the distance between updates, this can be very bad for speedrunning (especially on PC), as it means that using a laggy system will cause the game physics to become more approximate, possibly opening up new strategies or glitches. (As an example, it's possible to "lag through walls" in Donkey Kong 64 because the physics timestep increases in times of heavy lag, letting you move further in one timestep.) In PC games this is a real problem because some tricks may be possible for some runners and impossible for others. (On console, it's less of an issue because different peoples' consoles tend to have similar lag properties, but it's still nice to not require runners to use a specific revision of their console to be able to compete.)

The alternative method, which is much fairer when comparing speedrunners, is to have physics updates act at a fixed interval; for example, performing physics calculations 60 times per second regardless of how fast the machine is capable of running them. Note that there's no requirement to run ''graphics'' updates at the same rate as physics updates, although in practice most games choose to run them at the same rate because it makes programming easier. It's reasonable to, say, run physics updates 120 times per second and graphics updates at the framerate of the user's screen, and doing this sort of thing is recommended if you want the game to be able to render at high framerates, which is something that many players will be interested in. Obviously, you can't generally run graphics updates more slowly than the physics updates as nothing will have moved, and thus you'll get the same on-screen image as last time. The exception is if you're doing some sort of "cosmetic physics", like interpolating positions in the graphics engine, that has no game effect; this makes sense in games which have a very slow physics framerate (think Pokémon, Crypt of the Necrodancer, etc.; turn-based games and grid-based games like these benefit from doing physics calculations only at grid intersections and/or the start of turns, although oddly both of the games I mentioned actually do physics updates every video frame leading to bizarre timing-based glitches).

The length of time between physics updates is known as a ''frame'' in speedrunning. By far, the most common framerates are 60, 50, 30, and 20 frames per second. 60 is the "standard", because it was used by most games on older consoles (NES, SNES, etc.) in the US and Japan, and if someone says "frame" without context they're probably referring to 1/60 of a second. 50 was historically used in Europe, and 30 and 20 caught on when graphics advanced to the point where the consoles couldn't keep up with the higher framerates. There are good arguments in casual play for using higher values for modern games, although most speedrunners are likely to be happy with 60 (and 30 and 20 make frame-perfect tricks easier to pull off!). Some games (e.g. A Hat In Time) have customizable physics framerates, although this often leads to speedrunners selecting very slow framerates to make tricks possible or easier, and thus I wouldn't recommend it as it may well make speedruns of the game very frustrating to watch.

=== Lag ===

You should try to ensure that your game can always calculate frames "on time". Failure to do this is known as ''lag'', and although there are a few ways to handle it, none is really satisfactory. If you slow down the framerate to compensate and count in-game time in calculated frames (these are both the most common options), then lag will cause slowdown that makes tricks easier without penalising a player's time (and so intentionally lagging the system will give players an advantage). If you count ''lag frames'' (times at which a physics calculation should have happened but it was missed due to lag) as part of the in-game time, then players will gain an advantage if their computer is fast enough to avoid lag. If you take the first option here, a good solution is to disqualify runs if they have an excessive amount of lag, and have a framerate display so that the player is aware of any lag that might be occurring so that they can try to manage it; this is implemented well by the Windows Touhou games (which are highly competed but more focused on scorerunning and survival than speedrunning, and thus for which a time penalty for lag would be mostly ignored). With the second option, it's sensible to allow players to turn down the graphics settings, and to ensure that with minimum system requirements the minimum graphics settings will run without lag; in this case, you're basically putting the player in charge of eliminating their own lag and thus you want to give them the tools to do so. Note that most (but definitely not all!) games have physics simple enough that lag from physics (which can run on the CPU, if simple) is not an issue, and the main source of lag is the graphics (which runs on the GPU on most modern gaming systems). As such, another sensible solution is to ensure that the physics always runs on time and simply skip updating the screen when the rendering is running late.

Note that in addition to the issues with calculating the correct time for a run, lag spikes (i.e. varying amounts of lag) can be very frustrating to play with, as they can mess with a player who is trying to do precise inputs. It's thus helpful to give players the information they need to manage lag; for example, a framerate counter, perhaps which changes colour during times of lag. (If your physics and graphics frames are not tied to each other, and there's a chance of both physics and graphics lag, you'd need two framerate counters; but in most games, the two happen at the same time.) Many games have framerate counters as an option (and if there's room in the interface, there's no real harm in just showing the counter unconditionally).

A related concept is that of ''latency'' (known as ''input lag'' in the speedrunning community to distinguish it from late/skipped frames which are just ''lag''), the length of time between when the user presses a button on their controller/keyboard/etc., and when the effects are visible on-screen. Although annoying, as it makes precise tricks harder, this is normally mostly determined by factors other than the game, and tends to have a consistent value for any given setup, so there's not much a developer can do about it. Some tricks that you can do involve polling the controller only immediately before you use the results (this is hard on modern platforms because not all gaming libraries allow for manual polling, although it's easy if you have fewer levels of abstraction), and using as few levels of buffering in your graphics render as are possible (the optimum, which is very hard to pull off, is to render each portion of a frame only just before the screen tries to show that portion onscreen; although this is unrealistic, you should try not to be much more than a frame behind the optimum amount of render lag).

=== Determinism and recording ===

A related issue to that of a fixed framerate is the input that goes into your physics calculations. Obviously, the player's controller/keyboard input will be part of this, as they need to control their character. Likewise, the state of the game (which level's being played, where enemies are, and the like) is going to be remembered from one frame to the next. There's other input that's also potentially relevant, though; for example, a variable-step physics uses the current clock time as an input, many games use a random number generator, and it's not unheard of to accidentally depend on things like the order in which objects are stored in a dictionary (which is not going to act consistently in many programming languages), the configuration of the floating point units (this is different by default on different OS/compiler combinations!), or even the memory address at which a variable is stored.

If a computer program (such as your game) acts the same way each time given the same input, this is known in the programming community as being ''deterministic''. (In the TASing community, the phrase ''sync-stable'' is commonly used to describe the same property.) Determinism is very helpful because it ensures that control is in the hands of the player; the speedrunner can control the input they give to the game, but they can't necessarily control other aspects of the platform (and even if they can, doing so can be very controversial as it can be considered hardware modification). Having part of the game's behaviour being outside your control can be very frustrating while speedrunning (and mean that getting a good time is about persistence trying repeatedly until the things you can't control go perfectly, rather than any sort of skill).

One thing that's often overlooked is that because the state of the game is another input into the physics calculations, it needs to start in the same place each time. This means that you have to be careful to do things like zero memory before using it, so that the game state doesn't start with junk data in it. Using data left over from a previous program / from console boot is a fairly common mistake, and something that's caused noticeable problems for speedrunners in the past; for example, it causes the enemy patterns near the start of the original Metroid to be slightly faster to get past on some models of NES compared to others, and has caused TASbot to get confused in the past. A related mistake is using data left over from a previous level or part of the game later in the game, even though it's no longer relevant; this is normally called a ''storage glitch'' in the speedrunning community (and typically set up intentionally by speedrunners via finding some way to skip the code that would reset the variable). This is normally fairly harmless because it can be manipulated and thus forms part of the skill of running the game. However, the common special case of ''subpixel carryover'' (where the fractional part of the player's position, velocity, etc. isn't cleared between one room/level and the next) is rather more problematic, because normally the subpixels can't reasonably be manipulated through a whole level and there's normally no quick way to tell what they are. Subpixel carryover isn't technically randomness, but when trying to perform a subpixel-precise glitch, it feels like it; the glitch is impossible if your subpixels are wrong and there's no sensible way for an unassisted (i.e. non-TAS) speedrunner to influence whether they're wrong or not. As such, clearing position subpixels whenever the player warps/teleports/is set to a position, clearing velocity subpixels whenever the player's velocity zeroes, and the like, will make life much easier on your players when they need to do something very precise.

Another common source of nondeterminism is network inputs, for games which have online features. This shouldn't normally be a problem for speedrunners, who can just turn the online features off (or in extreme cases disconnect their computer from the Internet). However, you do want to make sure that the game functions correctly in an offline mode; ideally it should be an explicit setting in the options. It's also a good idea to try to reduce the influence that any online communication your game does over the actual gameplay, so that speedruns are fairer if it's left on (intended gameplay interactions aren't worth removing, but you don't want something like the time it takes the game to connect to a leaderboard to affect the game time; definitely not in-game time, and ideally not realtime either).

Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons. As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate randomness as a factor here.)

On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

=== Glitch tolerance ===

In the rush to get programs out of the door, something that game programmers often don't consider is how tolerant their program is to things that should be impossible. On the other hand, the whole point of glitches is to produce effects that the programmers weren't expecting, such as sequence breaks. As such, the error handling of your code is likely to be stressed heavily once routers start looking for glitches for the speedrunners to use.

One obvious issue here, and something that game developers who care about speedruns are often concerned about, is that fixing a glitch makes it unusable by speedrunners. This is sometimes considered a good reason not to fix a glitch, if casual players aren't going to be badly affected by it (if it's something that's basically impossible to pull off, it's likely to be found only by people who can handle the consequences, and likewise if the effects aren't going to destroy a casual game, it may be OK to let the casual player deal with it). However, it's likely that you'll need to fix some glitches because they lead to easily encountered crashes or the like. The simplest way to handle this is just to make old versions available to your players (either as separate downloads, or via adding a menu option to switch back to an old version of the engine; the latter choice has the added advantage that it lets people play recordings made with older versions of the game). I wouldn't recommend simply fixing the glitch with no way to obtain the old code, because that gives an advantage to players who have an older version of the game already / made speedruns before the change. (It's far from uncommon to see people on speedrunning forums trying to trade for a specific version of a game. If you allow your players to play the old versions after purchasing a new version, these people may well just buy a new copy instead, which means more money for you, and if it's a free game there's really no reason not to put the old versions up for free download as well. Ban old versions from online play if you must; speedrunners typically prefer to run with online features turned off anyway for determinism reasons.)

There's a more subtle issue that's probably more important, though, and that's how the game reacts to an impossible situation like a sequence break. The worst common reaction is to ''softlock'' the game (a game is softlocked when it's still clearly responding to the player's actions to some extent, and yet it's equally clear that making further progress in the game is impossible; examples would include trapping the player in a wall where they can look around but not move, and failing to trigger an event needed to continue the plot). Showing an error code is almost as bad, and even forcing the player to backtrack to the intended sequence is far from ideal.

Instead, there are two approaches that lead to excellent results in practice (which can be used individually, or combined). The more common one is to track every part of the gamestate individually and ensure that the code will handle all combinations. For example, if the player's intended to get super strength and super speed powers in that order, but the two powers can reasonably be used on their own, you can simply make sure the code handles the (intended to be impossible) case of super speed but not super strength like an unspoiled player would expect (and the simplest way to do this would be to use entirely separate code for the two, so that the code for one power doesn't care whether the player has any of the others). This typically involves using a bit or boolean for each pickup/enhancement that the player's intended to get and each plot event that they're intended to trigger. A big advantage of this method is that if a casual player does a sequence break by accident, the result will be what they're expecting and they may not even notice that anything is wrong. The main disadvantage is that it sometimes lets players get into areas early that they can't subsequently get out of, leading to a softlock. If you want to go down this route, one suggestion is to add a game mechanic that makes it possible to effectively suppress the fact that an item has been picked up, area has been cleared, or the like; this will basically force you to implement code to handle all possible sequence breaks. (Super Metroid is one of the clearest examples of this approach working well in practice, although there are plenty of others.)

The other possibility is to accelerate the game's sequence forward to the point at which the player appears to be; if part of the game's sequence is skipped, it'll compensate by giving the player any upgrades that were meant to happen in the skipped section. This is a natural consequence of describing the gamestate in a single number, and handling plot triggers via setting that number to a specific value. (The important thing to do here is to ensure that you tolerate the old value being unexpectedly low. Metroid Fusion disappointed a lot of speedrunners, especially those who were used to Super Metroid, because it fails to progress the plot if the current plot status is lower than expected, rather than handling the current event independently or accelerating the plot to catch up with the event.) The advantages of this method are that it saves memory and save file space (you don't need a separate variable for each possible plot trigger / item / game event), and that it makes a softlock very unlikely because it's moving the player to a state they could have reached "legitimately". (It's also rather helpful for debugging!) The major disadvantage is that casual players who stumble across a sequence break may end up rather confused as to what just happened, as skipping the plot forwards is fairly jarring. Note that games that are divided into levels that are meant to be progressed in order often end up using this technique by default, because they tend to remember only the level that the player is on rather than the set of levels that have been cleared (or if they remember both, only use the current level for plot progression purposes).

=== The timer ===

Although not strictly required (players can time runs using an external timer), pretty much every game designed for speedrunning has a timer, and thus absence of a timer will tend to lead players to conclude that your game isn't designed for speedrunners (and presence of a timer will naturally tend lead casual players to consider speedrunning your game, which is a good thing for sales if it leads to a speedrunning community growing due to all the free advertising it tends to give you).

Timing methods are divided into two main categories, realtime timing and in-game timing. Adding a timer to your game is an in-game timer pretty much by definition; and although it's possible to give it real-time-like properties if you want to, it makes more sense to take advantage of the opportunities that are only available from an in-game timer (or perhaps even to have two timers, one counting in-game time and one counting realtime). One of the main technical properties that speedrunners want from an in-game timer is that it should allow for a fair comparison between players in different circumstances (e.g. different speeds of machine, different settings for cutscenes, and the like); so it should probably be counting frames of gameplay (possibly including lag frames; see the discussion in the section about lag). By "frames of gameplay" I mean frames in which the player is making meaningful decisions about the way the game proceeds, rather than watching a cutscene, sitting at a loading screen, waiting for the credits to roll after defeating the final boss, or the like. In particular, freezing the timer during loading screens is highly important because they can vary wildly between one system and another, and (in most cases) have no useful impact on how the game plays out. Time spent with the game paused also needs to be counted if the player can usefully use the time to plan out their future moves, give orders that will take effect when the game is unpaused, or otherwise react to changing circumstances. (If the game is mostly about execution and very light on thought, stopping the timer while the game is paused makes considerably more sense; in this case, you might want a pause to hide the rest of the screen to reduce the ability to exploit pausing to buy more time to react to an event.) There are several instances in which it's debatable as to whether something is gameplay or not (e.g. menuing); this can be controversial and there's no hard rule that will always produce the right answer (nor agreement as to what the right answer is, in many cases). For what it's worth, I tend not to count time spent in menus as part of the in-game timer unless the game has a menu-driven interface and thus is in some way "about" selecting items from menus. (If you can manage it, a good solution here is to allow the menus to be navigated in parallel with the rest of the game, so there's no need to worry about how to time them; for example, when I speedrun Neverwinter Nights, I'm often menuing with the mouse while I'm running to the next area with the keyboard.)

Players may well want to create their own timer which runs on different definitions from the ones you use, and as such it's quite possible that people will want to use an automatic load time removal program with your game. As such, the game should indicate whether it's loading or not in a way that can easily be programmatically extracted. You do this via using a memory location that's fixed relative to your program's data segment, and that's immediately updated whenever the program starts or finishes loading. The way you declare this depends on the programming language you use; for example, in C or C++, you would declare the variable as <tt>static</tt> (fixed memory location) and <tt>volatile</tt> (immediately updated). Other languages may have different ways of specifying the same thing. (Typically, a variable will have a fixed location if both of the following hold: it isn't allocated using <tt>new</tt>, <tt>malloc</tt>, or a similar memory allocation function/operator, and isn't local to a function or object, but rather is global and allocated automatically; and it also has a fixed size (e.g. <tt>int</tt> is good, <tt>string</tt> is bad because strings vary in length).) It's a good idea to specify other relevant game variables like this, too, to allow auto-splitting programs to do splits at the right times; in particular, a number describing the current level or area is a good thing to place at a fixed address so that it can be easily read out of memory, as is a variable that counts the number of bosses defeated (because level/area transitions and boss kills are the most common split points). A sensible suggestion is to group all these variables together into one (fixed size and statically allocated!) structure, preceded by a few extra variables that have constant, unusual values (to make them easy to search for in memory).

There are a couple of fairly common mistakes that I should point out, that can make a timer unusable. One is that players will need to know the value of the timer at the end of the game (once they've won), a time at which the game typically doesn't respond to normal game inputs. As such, only showing the timer in-game, despite happening fairly often, is not very useful. If you want to focus attention to the timer, you can display it onscreen after the game has been won (possibly via displaying it onscreen at all times during the game so that it's onscreen at the moment the game is won, although using a separate "results screen" is also fine for the purpose). If you'd rather be more subtle about it, a common trick is to autosave when defeating the final boss, return to the title screen after the credits, and show the in-game time on the "choose a save file to load" screen (which the player will inevitably go via before they start playing again).

The other common mistake is that you need to ensure that the timer counts forwards whenever gameplay is happening, and doesn't count backwards under any circumstances. It's highly common for an in-game timer to potentially lose fractions of a second when the game is saved and reloaded (due to truncation or rounding), and moderately common for it to fail to start running again immediately after an unpause (even a frame of delay can be problematic, if it allows the player to play a frame of gameplay and pause again before the timer can restart). Either of these circumstances mean that players can get an uninteresting time of 0 via repeated save/load or pause/unpause.

Not so much an in-game time problem (as the in-game timer shouldn't be running at this point anyway), but a common time-related problem in situations such as races where real-time timing is required; the game typically shouldn't penalise someone for doing well via longer animations at the end of the level (this is commonly seen with score countdowns and celebration animations). For example, if a player scores more, don't make them wait longer for their score to be counted, or speedrunners will have to try to avoid score. (This goes double if you give players score for completing the level under a given target time; you don't want players using real-time timing to intentionally have to fail to meet the target time so that they get a shorter score countdown, cancelling out their intentional waiting. In addition to requiring perverse behaviour, it's effectively a frame rule. TASvideos.org occasionally excludes score countdowns from even real-time timing because of this problem.)

Something that game developers who are used to watching speedruns online on sites like Twitch often suggest is implementing timer splits directly into the game (because they're nearly universal in speedrun streams). The general consensus I've seen on this is that although it doesn't harm the game, it's also not seen as an advantage; speedrunners prefer to use their own external splitting programs, which tend to be much more customizable (and handle things like comparing splits to various benchmarks, saving splits, predicted time saves, and the like), and thus in-game splits would be redundant. One potential exception is in games which are separated into levels and those levels are entirely independent (i.e. what you do in earlier levels, and what state you end them in, has no influence at all on the subsequent levels). In this case, you probably want to time the levels individually (which is sort-of equivalent to splits in this context) in addition to timing the full-game run. In-game splits are also important in games like racing games in which you can expect competition for times to be at the frame or even subframe level; things like individual lap times are often competed, but determinig these times via splitting manually wouldn't be accurate enough to know whether a time was a record, and thus an automatic splitter is needed and most easily provided by the game.

=== Capturability/streamability ===

Although many players just speedrun for fun, it's highly common nowadays for players to want to take video of their speedruns; either a local recording (video capture) that they can subsequently use to review their records or show them to other people, or (increasingly common nowadays) broadcast the video online as the run is being made, to allow their fans (and anyone else interested) to watch live. These tasks can be fairly complex from the technical point of view, and making them easier is going to expand the number of people who are willing to speedrun your game.

There are two main ways to do a capturing or streaming setup; either you do the capturing and streaming on the same machine that's running the game, or a separate machine. Highly dedicated speedrunners (those who do it for a living) may well pay for a dedicated streaming machine separate from their gaming machine, and of course if you're writing a console game for a console that doesn't have streaming features, players will need to use a separate machine (typically their PC) to do capturing and streaming. For PC games, though, the majority of your audience will be streaming from the same machine that they play on, and some amount of care is needed to prevent technical issues cropping up when they do so.

In the case of PC games, one of the most important points to bear in mind is that most streaming software has a much easier time with capturing windows than it does with capturing programs that run full-screen. As such, having at least an option to run in a window is very valuable (especially because it lets the player place their timer and splits next to the game window on the screen, giving them an idea of how far they are ahead or behind their other runs). Better still is a "borderless" option, which technically runs the game in a window, but removes all the window decorations and similar things that mark it as a window (and allows it to be optionally expanded to fill the whole screen); this allows the player to have the immersion they'd get from a full screen game if they wish, but because it's technically a window as seen by the operating system, you get the streaming advantages that you'd get from play in a more traditional window. (Mostly this is only a problem on Windows, and possibly Mac OS X; gaming libraries for Linux tend to default to borderless by themselves when full screen is requested.) It may be worth downloading a streaming program (OBS is free and commonly used) and trying it on your game in a range of configurations to ensure that it works. Having a range of resolution options is also valuable for a PC game (assuming it plays identically regardless of resolution), as a speedrunner can adjust the resolution to a value that their computer can stream or record in realtime. If you do this, you probably also want a range of aspect ratios, to make it easy to produce a good stream layout (in particular, many speedrunners want to fill a typical computer screen with the game on one side and their timer/splits on the other, which means that the game needs to be squarer than the typical computer screen; providing 4:3 aspect ratios as well as widescreen is a good way to accomplish this).

When playing and capturing on the same machine, another important point to bear in mind is that the game and recording/streaming software will be competing for CPU cycles. As such, minimizing your CPU footprint, as much as reasonable, can be helpful. If your game is single-threaded and can only run on a single CPU core, or if it's not very CPU-hungry and only ''needs'' a single CPU core, it can help to lock the game to a single CPU so that the others are fully available for the runner's video capture software (this tends to have a name like "CPU affinity" in an operating system's API). Optimization for CPU usage (and with some capturing software, GPU usage) can also help here.

Regardless of whether you're sharing with the video capture software or whether the game and capture software each get a machine to themselves, one other fact that you have to bear in mind is that some videos are simply easier to capture than others. If a video is particularly difficult to capture, it'll tax the capture software more (forcing it to use more CPU and possibly lagging the game or dropping frames), and look worse in the capture compared to the game when its bitrate is reduced to create a smaller video or to stream it across a network connection with limited bandwidth (and even if the speedrunner has a very powerful Internet connection, their viewers might not, and might see a view that's substantially worse than it is in the actual game and make your game look bad). The hardest to capture videos are known colloquially as ''codec poison'', and are best avoided if you want your game to look good on camera. Typical codec poison pictures involve a relatively "busy" background with many small details (i.e. the colour changes rapidly from one part of the background to a nearby part), and a foreground that consists of many small moving objects that are distributed over the entire screen and with gaps between them that allow the background to be seen (something like confetti is absolutely terrible from a codec poison point of view, and will often cause digital TV broadcasts which normally look very good to break up badly). It's best if you can avoid this sort of situation occurring in your game. Meanwhile, the least poisonous videos tend to have large areas of solid colour or gradients, and objects which move (if they move at all) moving at a constant rate relative to the background and being opqaue with a fairly compact shape (like a square or circle). In general, codec poisoning is only really an issue nowadays when it gets particularly bad; a picture that's average in terms of how easy it is to capture will likely look fine on a broadcast, so there's not much reason to worsen your graphics purely for capturability reasons unless you have reason to think that they'll be particularly hard to capture.

== Category support ==

There's more than one way to speedrun a game. A ''category'' is a set of rules that define a goal that can be accomplished within the game; different speedruns might be in different categories, and thus achieve different times. The most commonly seen categories are "any%" (effectively, you can do anything to reach the end of the game and any route is allowed, including one that skips optional or even intended-compulsory parts of the game), and "100%" (everything in the game must be completed); incidentally, the fact that both these names end with a percent sign means that players often place percent signs at the end of random words to show that they're categories, even if the word has nothing to do with completion percentage. Having multiple viable categories increases the potential speedrunner audience for your game, as players who dislike the way that one category plays out may nonetheless enjoy competing in another. Thus, this section gives advice on how to support more categories (and to avoid ruining categories that would otherwise be viable by making category-specific mistakes).

=== 100%: completion tracking ===

The most basic speedrun requirement is simply "finish the game". However, players who want a longer run or to show off more of the game often implement some sort of "full completion" category that requires the whole game to be completed, in some sense. The main problem here is that "complete the whole game" (or "complete 100% of the game", which gave rise to the "100%" name for the category) is vague as a requirement, and defining it precisely can often lead to either flamewars where players disagree as to what should be necessary, or problems where the obvious or developer-intended definitions lead to tedious gameplay.

The first thing to note with 100% completion is that – assuming that the game's definition is good – it helps a lot if the game tracks completion percentage itself. This has most of the same considerations for displaying it to the user as the timer does (i.e. there needs to be some way to get at the completion percentage of a game after it's over, either via having it permanently visible onscreen, displaying it during the ending sequence, or showing it on the "select a save file" screen after a reset). Although a percentage is the most common format for displaying the amount of completion, the game doesn't necessarily need to use this syntax; if there's a certain number of things to do in the game and that number isn't 100, you may as well use a format like "55/80" (i.e. 55 discovered out of 80 maximum) to show completion, and if you want to keep it secret how far through the game the player is (perhaps as a method of avoiding spoilers), you can simply show completion as an absolute amount (e.g. "20 items collected") rather than as a proportion (speedrunners will quickly find out the maximum, and then define that as the full completion category).

The important followup, though, is that it's important that the game's definition of full completion actually is good! In many games, there's a class of rewards you get (exits, boss trophies, or whatever) for completing major sections of a game; and there's a separate class of rewards (often permanent upgrades or some sort of currency that's only finitely obtainable) for completing optional challenges within a section of a game. Typically, a good 100% definition will be based on one or the other of these categories. (A good rule of thumb is to choose one or the other definition based on how much work is involved compared to a normal playthrough; if your game only has four main areas then most likely a regular completion of the game completes all of them, and "full completion" would include the optional challenges too; whereas if your game has 85 levels on a nonlinear world map, many of which have minor optional secrets, and for which the reward for finding a major secret is typically access to a new hidden level, most likely the best 100% definition would be to complete every level.)

When designing a 100% definition, it's important to ensure that the run will be varied and to avoid busywork; in general, you want the points that are hit as part of the 100% definition to be things that each individually took thought for your level designers to place and are all based on different principles, as opposed to something common that was scattered around the game without much thought for the placement. For example, one commonly seen 100% definition in games that's typically bad and should be avoided would be to reward the player for encountering or defeating 1 of every enemy; you probably didn't place otherwise unseen enemies in the game specifically to serve as rewards for difficult challenges! (Perhaps your optional bosses are hidden like that, in which case "all optional bosses" would make for a better definition.) It's also worth noting that the ideal 100% definition doesn't involve completion on multiple different axes, but should ideally be described as a single number; if you have multiple types of reward for completing optional challenges, then it can be worth gathering them all into a single number via giving a reward of one type for collecting all the rewards of another. Many games also have some sort of special reward for a full completion, which can make for a trivial 100% definition in its own right and often serves as a definition of the category.

One final thing to note is that a bad 100% definition can really hold back a full-completion category, but if multiple completion percentages are given, speedrunners can choose the more appropriate one for themselves. As such, if you're at all uncertain about what would make a good completion percentage definition for your game, it's not a terrible idea to just list both possibilities. That way, players can choose whether maximising one, the other, or both makes the best speedrun. (On occasion, both will make for good speedruns in their own right; for example, some games have both "100%" and "all levels" categories. This is great, because two viable high-completion categories expands your potential speedrunner audience even more than one does.)

=== Low%: sequence flexibility ===

The opposite of a maximum completion run is a minimum completion run. These tend to show off skill in a different way from maximum completion runs; with only a minimum of upgrades and possibly skipping even upgrades the player was meant to have, a low% run tends to have incredibly difficult combat and require creative solutions to get from one place to another without the intended set of items. One preliminary note here is that low% running is basically only applicable to games which have permanent, persistent upgrades that are meant to be collected as part of normal gameplay; if this doesn't describe your game, it's probably not worth trying to shoehorn a low% category into it. If it does, though (and a number of game genres can be described like this), read on.

The trick to making a game with a good low% is to add a lot of flexibility and open-endedness into the intended sequence of your game. If there are meant to be multiple ways to get from A to B, each of which requires a different set of upgrades, then that increases the chance that a player will find some smaller set that also accomplishes the same thing. It helps to concentrate on "soft" barriers for the purpose of gating progress if you want to make this sort of flexibility possible; instead of checking to see if a player has a particular item, create a jump that they can't make without items to boost their jump height, or an enemy that's not meant to be possible to defeat with basic equipment. Likewise, if an early-game item is meant to be required to get past a particular point, make it possible with late-game items too (perhaps ones which are more powerful versions of that early-game item); this both makes backtracking less tedious, and opens up new potential possibilities for low%. It's also important to avoid accidental barriers that weren't intended to test for items (for example, you may want to avoid requiring a minimum amount of ammo to reach an area or complete a fight if all non-low% players will naturally get that amount of ammo over the course of a game, and if you have a fight that's about endurance in a game where dodging attacks is normally possible, and most players will naturally have enough HP to tank it, ensure that all the attacks actually are reasonably dodgable so that low% players have some chance to complete it on their minimal hitpoint total).

Something that's fairly controversial is whether a game should add sequence breaks intentionally for the purpose of making low% interesting. The most common opinion seems to be that it would be preferable for the sequence breaks to occur naturally as glitches rather than to be developer-intended, but that developer support for low% in games that have a suitable genre is a nonetheless a net good thing even if it's fairly crude and/or blatant. If nothing else, a developer-intended low% that brings the typical low% gameplay (of unusual techniques to get past barriers, combined with difficult combat) to a wider audience can give casual players an interesting target to aim for, even if it disppoints speedrunners.

Even if the game doesn't have sequence breaking possibilities that make low% interesting for the way it gets to parts of the map "early", low% runs are also defined by combat being particularly difficult; as health, attack capabilities, etc. are typically dependent on upgrades in this type of game, a low% player will typically have the minimum amount of health and the minimum possible attack power required to complete the game. As such, they'll likely be almost entirely reliant on dodging or shielding enemy attacks (or preventing the enemy attacking in the first place), for long periods at a time, while they try to poke the opponent to death with a pitiful weapon. In order to keep a good game flow, it's worth trying to ensure that this sort of fight is actually interesting. If your combat system is one in which commands are not difficult to give (such as the average menu-driven RPG), you need to take care that combat doesn't degenerate to choosing "Fight" a hundred times in a row; this would get boring for everyone quickly. (And in general, you'll want to make sure that there's a lot of variety in your low% runs, which in an RPG would typically be called something like a "low-level challenge run" by casual players. It's a common enough goal casually as well as for speedrunners.) If your combat system is more active, say in a platformer, dodging attacks for minutes at a time can be impressive in its own right and a very nervewracking task that many speedrunners will enjoy. Nonetheless, you might want to mix up enemy attack patterns a bit to make fights a bit less repetitive than they otherwise could be when they last ten times as long as intended.

Finally, the same notes about completion percentage tracking that were discussed for 100% apply to low% too; if the player's going for a minimum completion of the game, they need to know what their completion is. It's important to choose a completion percentage definition for which low% is interesting. Nearly always, this should be the number of permanent upgrades that have been obtained; this is likely to mesh well with the 100% definition in a platformer, but maybe less well in an RPG. You might therefore need to add the upgrade count (for an RPG, this is often but not always the player's level) as a separate entry on the results screen, save file selection screen, or whatever location you're using as a percentage tracker.

=== IL: basic equipment ===

Some games are divided into levels, or other fairly independent sections. There will normally be a fraction of your playerbase who don't care much about optimizing the whole game (like most speedrunners would), but are interested in a sort of time trial mode in which they try to optimize a single level by playing it repeatedly. A listing of the best possible time in each level (typically together with recordings of how the level looks) is known as an ''individual levels table'' (and the category is called IL for short), and (in the speedrunning context) is sometimes created collaboratively by a community to show off top-level play in their game. IL play is often considered fairly different from speedrunning, but it's close enough in spirit that many of the same considerations apply.

In order for a game to really support IL play, the most important point is that the level must always start in the same state (thus the determinism requirements discussed above apply to each specific level, rather than the game as a whole). In some games, each level is naturally entirely independent as it is, and thus nothing special needs to be done. In others, though, you'll have to give your game a separate "single level" mode (which is a good idea in any case – it can make practicing easier), and make a specific choice as to what state each level should start in. For example, in a game which has temporary upgrades that carry between levels but only last until you get hit (and which the player wouldn't be assumed to have at the start of a level), it makes sense for IL play to always start the player with no upgrades (or perhaps with a specific basic set of upgrades). Games which have ways to permanently upgrade the character are hard to support IL play with, unless the game is fairly linear (making it possible to predict the likely state of the character at the start of each level, and just setting them to that state). The general idea is that for IL support to work, there needs to be a way to start any chosen level with a consistent, basic set of equipment, most likely accessed via a separate game mode.

Individual level gameplay tends to be quite different from both casual and speedrun gameplay. Because levels are (usually) fairly short, there's a huge pressure in IL runs to optimize them as highly as possible; in games that have an IL category, an IL run is more heavily based on routing than any other category, often to the extent of calculating the position of each individual jump. As such, regardless of what genre you thought your game was in, under IL conditions your game often turns into a puzzle game (which explains why it's likely to appeal to a different subset of players than a full game run is). Due to players aiming for perfect optimization, they're likely to reset on any minor mistake (and thus you need to ensure that your IL mode has the best reset cycle possible; for example, often you can remove a loading screen if you know the player's still within the same level). The IL tendency to route out the entire level in full also means that it's ''especially'' important to remove randomness in this mode, even if there are good reasons for it in other modes; otherwise, players will just have to reset until they get the best possible random results, which is tedious and doesn't add much to the game.

It's also interesting to note the effect that this has on the game's timer. In most game modes, the timer should typically be seen from the point of the player; it's measuring the amount of time the player spends making decisions, among other things. (This is particularly relevant in games that let the player input instructions while the game is paused; the timer needs to keep running during the pause in a "regular" speedrun of the game.) However, in IL play, what players are competing on is often not really how they react to events on the level or on decisions made realtime, but instead on the plan they've made for completing the level as quickly as possible (because they'll be able to try the level over and over again with a very short reset cycle until everything goes perfectly according to their plan). As such, the timer in single level play is typically more useful if it's looking from the point of view of the game world, stopping while the game is paused.

IL play is fairly close to TAS play (perhaps the closest that can be obtained without the use of actual speedrun assistance tools). As such, it may be interesting to add standard TAS functionality to your game; this isn't a route that many game developers have gone down (although some have, with it typically seen in a debug menu), but it's likely the logical conclusion. (TAS functionality is also very useful to speedrunners more generally when they're trying to practice individual sections of a run, and for players generally when they get really deeply into studying a game; in games that include a means of accessing TAS functionality, it tends to be heavily used by top playesr.) Easily implemented assistance tools include the ability to slow down the game's framerate while leaving the physics the same (so that everything moves in slow motion); a ''frame advance'' feature that unpauses the game, plays it for exactly one frame with a certain set of inputs held, and automatically pauses it again (typically assigned to an otherwise unused button); and displaying the most relevant internal values for setting up tricks (most commonly position values) onscreen. Harder to implement is the ability to rewind to an earlier state (either with a very precise save-restore or with a way to play the game "backwards"), but this is possibly even more useful for testing tricks. TAS tools should probably be kept out of the main speedrun modes, but including them as a separate game mode (with "debug menu" the most common name) makes sense, and if you decide to add the possibility of competition among assisted runs, IL rules are the most sensible way to do it.

=== Segmented: exact saves ===

Although some games are particularly suited to IL play, most games have substantially more trouble (mostly due to some form of persistent upgrade or state that can be carried from one level to another, or due to levels being re-entered as part of normal gameplay rather than being separate and in strict sequence). However, it's nonetheless common for some of your players to want to optimize the game more heavily than they could in a single session playing straight through the game, via optimizing each individual "segment" of the game before moving onto the next. ''Segmented'' categories are those in which the player is both 1) allowed to save and restore the game, and 2) allowed to remove any time spent on attempts that were subsequently discarded by returning to an old save from their total run time. As such, in segmented play, players can try a segment repeatedly until they have something they're happy with, before moving on with the game. This is fairly similar to IL play, with the difference that players choose where the boundaries between segments are and what equipment they'll need at the start of each segment, rather than having it specified by the game; additionally, in a segmented run, it's sometimes possible to spend extra gametime on earlier segments in order to set things up to allow later segments to be faster (unlike an IL table, in which the levels have no interaction with each other and can reasonably be run in any order).

There's rarely much that needs to be done on the game design side of things to support segmented play (unless your game's save system is heavily tied into the idea behind your game, which is rare but not unheard of). However, it's fairly easy to mess things up on the technical side of things; unlike other sorts of speedrun, which typically don't care about how your save system works (because they'll be starting from a new game and probably not saving unless they have to), the save system takes centre stage in a segmented speedrun, which fundamentally relies on saving and restoring the game to make.

First, it's possible to help out segmented speedrunners via ensuring that the game timer matches the definition of timing that they're used to; timing a segmented speedrun manually can be a surprising amount of work, but they'll have to if the timer is using the wrong definition of time. If breaking up a segment costs time, it places an artificial restriction on how many segments can usefully be used for the game, thus forcing players to potentially settle for suboptimal segments (or to spend more time than they wanted trying to get an overly long segment to go perfectly, and likely giving up eventually) in order to avoid losing time to the "save penalty". This means that you'd want the timer to stop immediately when the player starts to give the command to save (otherwise the time spent in the save menu would count against the time for the run as a whole). Unfortunately, if your timer runs in menus, this isn't always possible to implement (although it can be if save points are a feature of the game world rather than a menu option, it can be if the game autosaves, and it can be if you have a "quicksave" feature; what these circumstances have in common is that they all make it possible to save the game with just a single button input, which can thus also stop the timer at the same time). However, you should at least try to keep the save penalty as small as possible. Starting the timer at the right point when ''loading'' a game is always possible, and important to get correct; it should start counting at the instant the player regains control after a load (and after all relevant loading screens, etc., have played out), and have exactly the same value that it did when the save file was created. (It's very important that you don't let the timer go "backwards" across a save, say due to rounding it to the nearest second; store the fractional part of the timer in the save file as well as hours/minutes/seconds.)

The idea behind segmented runs relies heavily on the idea that discarded segments (ones after which the player doesn't save, or at least doesn't use the resulting save file) don't count at all (they don't count against your time, and don't influence the eventual speedrun in any way). This means that you need to ensure that this is true in practice; there shouldn't be any way to influence a save file sitting safely on your disk, memory card or cartridge via your behaviour in a discarded segment. For example, you don't want a "return to save" style reset (whether it's an actual reset + loading a save, an explicit "return to save" command, or something like a Game Over that recovers via loading a save) to add any time to the timer, carry over any experience or items from the discarded segment, make the game easier to compensate for a death, or make any changes to global state that isn't tied to a save file. (Speedrunners have been known to use cheating programs to modify their saves, purely to put them back the way they were after the game insisted on changing them; this sort of thing tends to be allowed even by speedrunning sites that are otherwise heavily against cheating, as using discarded segments that don't count against time to influence gameplay is even worse.) Once a save file has been made, it needs to sit exactly as-is until loaded again, and needs to be loadable any number of times. (There are some games in which the ability to do this would violate the principles behind the gameplay. In such cases, your choices are to abandon support for segmented runs, add it as a separate game mode, or add some way to do it via file manipulation on disk rather than through the game interface.)

One particular danger for segmented runs comes in the form of autosaves. In order to make segmented runs work, you have to be able to load the old save file exactly in the state it was saved, any number of times. Autosaves have a tendency to save ''over'' the old save file, so that it's no longer there to be loaded. This is a fairly easy problem to fix if you're aware of it. The most reliable way is to add a "copy save" feature (allowing players to copy their save file to a different save slot for safekeeping, so that they still have a copy if one gets overwritten by an autosave); this also lets speedrunners work around most other problems you make with save file reproducibility (as most such problems will only modify one copy of the save). A similar option is to have separate save slots for autosaves and manual saves; overwritten autosaves don't matter in this case because players can just use a manual save for their segmented runs. Of course, you could also just add an option to turn autosaves off (which will also be useful for players when practicing via repeatedly reverting to the same save, as they won't have to worry about autosaving my mistake).

Finally, something that's a little less important than the previous points, but still worth thinking about, is how much data is preserved between a save and reload. Some games reload a game at the exact same point it was saved, whereas others forget short-term information (such as which attacks are currently in progress), or much larger details (such as the location of the player on the game world; many games place the player back into a hub area upon a reload, probably to reduce the size of a save file). Being able to change things within the game via a save and reload adds a new possibility for tricks and routing, and thus isn't necessarily bad for speedrunning, but it also reduces the number of opportunities to usefully break the game into segments, and makes practice substantially harder. In general, it's probably going to be better for speedrunners if saving and reloading preserves as much of the game state as is reasonably possible, or at the very least anything that has an influence on anything more than the next few seconds of gameplay.

=== Marathons/racing ===

Segmented play used to be the main way to create speedruns, because it provides a "higher quality run" when finished than the other speedrun categories do. However, more recently the exact opposite category has become popular, typically known as ''marathon'', ''race'' or ''no resets'' play; players start a run and then attempt to finish it as quickly as possible, working round any mistakes they make (unless they're so serious that they lose tens of minutes or make completing the game impossible) rather than resetting if something goes wrong, and the goal is typically to beat another player who's playing at the same time, or to show off the game to a wider audience. These runs are similar to single segment runs in most ways, but have a few considerations of their own.

If a marathon run goes well, it'll typically proceed identically to a single segment run. However, accidents can happen in practice, and it's important to make sure that players aren't disproportionately punished for a mistake. As an example, many games throw the player back to the previous manual save upon a game over event. In a single segment run, a game over would probably force a reset and another attempt from scratch (unless the game were very long or the player were exploiting a glitch in the game over code). In a segmented run, you're going to retry the segment (again, assuming the game over weren't intentional for some reason). However, in a marathon run, these options aren't really available. Depending on how the game is designed, there could potentially be no good options here, thus forcing speedrunners to make "safety saves" (making their demonstration take longer or making them appear to fall behind in a race, as the other player won't have stopped to save), or else go without and potentially end up in a situation where they have to give up on their attempt to show off the game. Careful game design can fix this problem, by making sure that there are limits on how much a player can fall behind in a certain length of time. For example, a game over could allow the player to restart from the start of the current level or battle. A carefully designed autosave option can also place limits on how badly things can go wrong.

Another defining aspect of races in particular is that they're almost exclusively timed using realtime, even in communities which normally use in-game time to set records. The reason here is that if two or more players are racing each other, the player with the shorter realtime will finish the race first. This means that it's helpful to design the game in such a way that realtime competition is interesting and fair, if you can, but there's often not much that you can do in this direction as a game developer.

Finally, as mentioned earlier, it helps a lot if you can somehow make randomness fair between two players playing the same game at once. A seeded mode is typically the best way to do this.

== Miscellaneous/other ==

=== Legal/copyright ===

Although players sometimes just speedrun by themselves for fun, it's very common for a speedrunner to want to post a video of their game online (as proof or so that someone else can watch), or stream it live. For a few speedrunners, this sort of activity is a significant source of income, but even for players who aren't making money from it, protecting the reputation of their Twitch or YouTube account can be important. If speedrunning a game gives the runner copyright strikes against their account, it can cause them significant trouble, often leaving them worse off than if they'd never run the game in the first place; losing the account, or losing all income from the game, can be fairly major punishments.

Because games studios or publishers tend to own the copyright for games that they develop or publish, they can control how their game is licensed and what the legal requirements on posting gameplay footage are. For speedrunning, it's incredibly helpful if you explicitly give permission to post gameplay videos online, including monetized/commercial use. That way, speedrunners can be confident that they won't get into trouble, or lose money, from running the game. (Besides, if more players are posting videos of your game, that mostly just gives you free advertising; unlike with other sorts of media, a video of a game is rarely a replacement for the game itself, and if it is, the game probably isn't too good to speedrun.)

=== Growing your community ===

There are two ways a player can get into speedrunning a particular game. Either they're a speedrunner already, and decide to learn the game as their next speedrun; or else they're a fan of the game, and decide to speedrun it as a challenge or to increase its replay value. The number of dedicated speedrunners who play multiple games is small relative to the typical audience of a game, and compared to the number of games that they'd enjoy speedrunning; competing with other games for established speedrunners is hard and so it helps if you can build up a speedrunning community of your own first. This typically means that if you want to get people into your game via speedrunning (or to keep your existing customers playing your game through speedrunning so that they end up advertising it to more players), then you need to persuade at least some of your casual players to take up speedrunning as a hobby.

The main way to do this are to make sure that getting a fast completion time is presented by the game as something that's interesting to aim for. Showing the game timer at the end of the game is one of the mos subtle ways to do this, but it still works fairly well. If you want to be more blatant, adding a separate "speedrun mode" makes it clear that the game is designed for time-based competition, and achievements for completing the game (and maybe for completing the game 100% as well) within a certain time will encourage players to try out optimizing their times to see what it's like. (Something less obvious, but still worth doing: if you're supporting low% gameplay in your game, you want an achievement for completing the game with less than a given number of upgrades. This might not look related to speedrunning, but is a good way to encourage players to develop the skills needed for routing/glitchfinding, and tends to increase the longevity of your game as a result.)

Another way you can build a speedrunning community is via leaderboards (especially if they're visible in-game, although you should also have a website for them because most in-game interfaces for leaderboards are terrible). If you make online leaderboards, they should exist for all the speedrun categories your game supports or that you can reasonably imagine players might want to compete on, in order to prevent players needing to maintain separate leaderboards elsewhere. It's also very helpful if you store recordings of the record-breaking runs; this is one of the easiest ways to reduce leaderboard hacking (especially if you do some sanity checks to ensure that the recordings look reasonable), and allows players to learn strategies that they might not have thought of and see what high-level play looks like. (Games which are almost entirely about movement, such as most racing games, sometimes also have a "ghost" option which uses a recording to give a visual guide as to whether you're ahead of or behind the current record. This isn't worth doing if the game is any more mechanically complex as it will probably be more confusing than useful.) If you can't prevent leaderboard hacking (which is infamous for making online leaderboards useless), or don't have the infrastructure to run an online leaderboard of your own, you can place a local leaderboard within the game; it doesn't fulfil all the functions an online leaderboard would, but it's still useful for many of them (and a separate local leaderboard is useful anyway so that players can keep track of how well they're doing even if it's nowhere near high-level play). Remember to ensure that runs that have more help than a typical run (e.g. seeded, cheated, using assistance tools) should be placed onto a separate leaderboard or disqualified, so that they don't outcompete games played within more traditional rules.

Neverwinter Nights/Mechanics and Glitches

2014-11-28T12:22:24Z

Ais523: /* Instant Rest */ mention a caveat with instant rest

== Game Mechanics ==

=== Timing rules ===

There are basically three sorts of action you can perform in Neverwinter Nights:
* Standard actions, like attacking and casting spells, have two lag periods, a shorter one which prevents you performing standard actions or moving, and a longer one that just prevents you performing standard actions. (Typical times for these lag periods are on the order of 2 seconds and 4 more seconds, respectively). As such, if you want to cast a lot of spells before a battle or the like, it's best to space them apart in time somewhat; the casting will happen just as fast as it would if you were standing still, but you'll be able to combine it with your movement. A good example is the divine casting trial in the Prelude; you need to cast a Cure spell, and Turn Undead (which internally implemented as a spell), and you get several seconds of running between them (which are best spent walking from the Injured Man back towards the door).
* Movement. You can move around with WASD or clicking at almost any time, apart from the short lag period after a standard action (or while entangled, paralysed, etc.). However, this will cancel any queued actions you have at the time. The reverse is not true: you can order a long move (via clicking on a distant target), then queue up other actions to perform after it completes. The cancelling-other-actions effect is sometimes useful; for instance, pressing W is the fastest way to cancel a rest (you can start giving useful orders faster after pressing W than after manually clicking on the "cancel rest" button, which is also a pretty small target). Another way to move is to give melee-only actions (like "open door" or "attack") on distant targets; this is similar to moving up to the target then performing the action, but it doesn't cancel queued actions. So on the "hit the gongs in sequence" puzzles in Chapter 3, you can get a perfect time just by clicking on all the gongs faster than the character can reach them, causing the character to run to the next gong as soon as a gong is hit.
* Conversation and changing equipment. These actions happen instantaneously, so long as you aren't in combat and don't have an action queued, and the game isn't paused. (Some equipment slots can be changed even when in combat, so long as you aren't in either lag period after a standard action). There is '''no lag''' after these actions; you can spam equipment changes and conversation items as fast as you can input them. Starting and resetting conversations (you reset a conversation via clicking on the person you're conversing with) can be done even while the game is paused; this is essential to one of the major glitches. Other similar actions cannot be performed while the game is paused, but can be pause-buffered; in order to get through a conversation quickly in in-game time, you can pause the game, select an option from the conversation, quickly hit Space twice, and repeat. This is slower in terms of the time you actually get for the run, but sometimes necessary to finish a conversation before you get attacked (forcing you into combat) or before an enemy despawns.

== Glitches ==

=== Plot item duplication ===

Works on: unpatched, Diamond

Effect: If you have the only copy in the game universe of an item flagged as "essential to the plot", gain a second copy of it (if it's unsellable, for 1gp).

How to perform: Drop your plot item (preferably near a Divining Pool; this isn't necessary to the glitch, but makes it faster to perform). Go to a Divining Pool (there's one near each Recall target point), which should now sell you a second copy of the item. Then pick up the original.

Uses: The main (and probably only) use of this glitch is to sequence-break past most of Chapters 2 and 3. You can duplicate a cultist's journal in Chapter 2 (probably the Charwood Cultist's; it's the fastest to obtain), then use both copies to immediately unlock the gate to Luskan. Chapter 3 can be broken a similar way, but the glitch is a little harder to perform because you need three Words of Power to complete the chapter; you'll have to turn in the duplicate Word of Power to Aarin (leave the original on the ground), then pick up and drop the original in order to get a second duplicate (allowing you to turn in the second duplicate and the original to complete the chapter).

You can duplicate plot items in Chapter 1, but it isn't useful; Aribeth won't accept the same reagent twice.

=== Item and experience farming in Chapter 1e ===

Works on: unpatched, Diamond

Effect: Gain multiple copies of the quest reward items from the Guardian of Helm quest in Chapter 1e (both the "good" and "evil" paths), and arbitrarily large experience.

How to perform: After completing the Guardian of Helm quest (either by completing the summoning of the demon, or banishing it and summoning the Guardian in its place), and gaining the quest rewards, resetting the conversation works and allows you to get the rewards again, but only for 3 in-game seconds. Pause-buffering the conversation will let you get the item rewards several times; the experience reward happens right at the start of the conversation, so you can just reset the conversation repeatedly to gain arbitrary experience.

Uses: The Guardian of Helm quest is less than a minute off the fastest route in Chapter 1e, and can farm you enough experience for the whole run, and enough gold (via saleable items) to at least get through Chapter 2.

Notes: The number of items you can get depends on your alignment. When using the demon (which is faster and has better item rewards), Good has less text than Neutral, which has less text than Evil; so being of a more Good alignment will allow you to farm more items in those 3 in-game seconds you have. However, being more Evil means you get more experience per click, so although you get less gold, you save time farming experience. The best of both worlds is to be Chaotic Evil for the demon (or Lawful Good for the Good route through the quest); this gives you the fastest possible experience gain rate, but also gives you a double item reward from the conversation (which is badly bugged; it shows two "Continue" options, you need to take the first).

You can farm experience faster by using two mice (say, a mouse and a touchpad), and spamming clicks with both hands.

=== Gold farming at the start of Chapter 1 ===

Works on: unpatched

Effect: Gain 100gp from conversation, an unlimited number of times.

How to perform: Ask Aribeth if she'll answer some questions, then for a reminder on how to use the Stone of Recall. Then go through the conversation naturally.

Uses: Although this is a relatively slow method of gold farming, it's available so early that it can get you through early-game purchases. In particular, it can allow you to afford henchmen and Recalls until you've defeated Meldanen.

=== Immunity exploits ===

Works on: unpatched

Effect: Damage enemies that are meant to be invulnerable.

How to perform: Use a spell whose damage type is not physical nor one of the standard elements (fire, cold, electricity, acid, sonic). Good examples include Horrid Wilting (works on all such enemies, as far as I know), and Harm (won't work in the endgame, will work elsewhere).

Uses: You can combine Harm and Negative Energy Ray to sequence-break the Creator Race Ruins in chapter 3, but the current any% route doesn't go there. Horrid Wilting can also work as a decent backup strategy for the Protectors during the final boss, but it won't oneshot them unless they make their save.

=== DetermineCombatRound breaking ===

Works on: unpatched, Diamond

Effect: An enemy is hostile to you, but does not attack you unless you actively provoke them.

How to perform: This is only possible due to mistakes in an enemy's script; "turn hostile" (i.e. reputation changes) and "enter combat AI" (DetermineCombatRound in the code) calls are separate, and sometimes the code has different triggers for one than the other. In particular, the final fight against Morag starts her combat AI loop when attacked or via conversation, and you can break the conversation via being in combat at the time, such as via bashing the door next to her at or just before the instant she tries to force conversation.

A more minor version of this glitch causes several plot enemies (e.g. Callik, Klauth) to waste their first round of combat if you initiate combat yourself via spellcasting (possibly also via other means), meaning you get two tries to land a particular spell on them before being attacked back.

Uses: You can deal with Statue and the Protectors as you wish before Morag starts fighting, making the boss fight much easier. Once that's been done, you can start the fight correctly by using any attack on Morag (ranged attacks work best as she teleports across the room after being attacked, and you can make her teleport to your position).

There are mixed reports about reproducing this glitch on Diamond; it is definitely possible to glitch Morag out, but may require a more complicated setup (one theory is that the timing is more precise and thus you have to be on the other side of the door for the glitch to work).

=== Instant Rest ===

Works on: unpatched, untested on Diamond

Effect: Get the full effect of a Rest (hitpoint gain, spell and ability refresh) in 6 seconds rather than 30. (Caveat: for some reason, this usually fails to heal henchmen.)

How to perform: There are two known ways to do this. One is to cast Time Stop just before resting (the exact timing is unknown, but a likely guess is that it's one short action lag). The other is to save and reload the game just after resting (again, you need to wait some short length of time for this to work, but not very long). You need to meet all the other conditions for Resting to be legal (i.e. neither you nor any member of your party has been in combat recently, you haven't been damaged recently, and there are no enemies nearby).

Uses: All the reasons you'd normally Rest (notably: planned healing; emergency healing to recover from a fight going wrong; refreshing spells).

=== Dispel Area ===

Works on: unpatched

Effect: Suppress ''any'' area effect, either for a short length of time or permanently.

How to perform: Cast any dispel effect (Lesser Dispel is the most easily obtainable) centred on the area effect.

Uses: If doing the Silver Sails route through the Docks, destroy the web that normally entangles you; this is permanent. (However, the Silver Sails is avoided on any% routes because it's so much slower than the alternative.) Suppress the barrier in the final boss fight that normally instakills you; however, this only lasts for a random time between 0 and 6 seconds, making this glitch quite risky (if it doesn't go down for long enough, you will die running across it unless it happens to roll very low on its damage).

Neverwinter Nights/Routes

2014-09-06T23:29:25Z

Ais523: updated route

== Any%, unpatched, single segment ==

This route was designed by ais523 for an any% completion on an unpatched (1.11) version of Neverwinter Nights. Because unpatched versions have a speed cap that is easy to hit, there is not much point in building for movement speed beyond Chapter 1 (like you would do on a patched version), so this route instead builds towards early Invisibility and fast boss kills. It tries to rely only on high-probability events, so as to be safe for use in a single-segment run.

Where low-probability events could save time, I'll try to point them out, to be useful to players playing segmented. Much of the advice is also applicable to other routes, but it focuses on the Cleric route because that's what I know and practice. Likewise, I'll also try to point out advice suitable to other categories (e.g. 100%, no-major-skips, glitchless) at appropriate points, even if this isn't a guide to them.

Directions here will be given relative to your running direction, because I play using Chase Cam. You might need to translate them if you use a Top Down camera.

=== Starting Character ===

* Gender: irrelevant
** Reasoning: There is only one gender-specific effect that is potentially relevant in an any%, which is saving Aribeth. It is faster to save her than to kill her; but it is also faster to do so via Persuade check than via the romance sub-plot, negating the reason to play male.
* Race: Human
** Reasoning: Quick to Master is more useful than any of the ability adjustments; this route is tight on skills, and wants three feats before hitting level 6. This also makes some conversations a little easier/faster.
* Alignment: Chaotic Evil
** Reasoning: This impresses the demon in Chapter 1E, meaning you get a double reward from the glitched conversation, each time round the glitch. This more than makes up for the extra text, especially as it gives a useful item that would not otherwise be reliably obtainable.
* Starting Role: Cleric
** Reasoning: You need Invisibility (available at Cleric [Trickery] 3) by the start of chapter 1, thus at level 3. This means the first three levels must all be in Cleric.
* Abilities: Str 16 / Dex 8 / Con 12 / Int 8 / Wis 18 / Cha 14
** Reasoning: The most important abilities are Wis (for spellcasting) and Str (for DPS early). Raising them to 16 (the highest reasonable value) leaves 8 improvement points. A higher Charisma helps prevent Turn Undead whiffing, which can really damage the run. The remaining points go in Con, because we have enough skill points even at Int 8, and Dex does not help anything but Reflex (mildly important early on) and AC (on this route, much more than a +2 to AC would be needed to make a noticeable difference).
* Skills: Open Lock 1 [cost 2], Persuade 4, Lore 2
** Reasoning: None of these skills become relevant until Chapter 1 (or later in the case of Lore), so we pre-place the skill points where they will later be needed to save time levelling up. We need 1 point of Open Lock and as many points of Persuade as possible in Chapter 1; we need no other skills until Chapter 2, which also needs Use Magic Device (unbuyable) and Lore, so we pre-place points there to save a marginal amount of time.
* Feats: Weapon Proficiency (martial), Lightning Reflexes
** Reasoning: Being able to wield a greatsword gives us much better DPS early than we could otherwise manage. There is one unavoidable Reflex check in Chapter 1 that saves noticeable time if we pass it, so the bonus from Lightning Reflexes increases the chance of getting it in a single-segment.
** Segmented: You don't need Lightning Reflexes in a segmented run; instead, you'd manipulate the 5% chance of hitting the Reflex check in question naturally. It's unclear which feat to replace it with, though.
* Domains: Trickery, Plant
** Reasoning: Trickery gives access to Invisibility, which is very useful on speedruns. The second domain is less obvious. Plant gives access to Creeping Doom, which is used to help with two of the boss fights, and Turn Vermin, which helps marginally in chapter 1. It is possible that some other domain could serve the same purposes more efficiently, but this is currently unexplored.

=== Prelude ===

==== Senior Barracks ====

* Either run round Pavel, or let him talk to you then cancel the conversation via clicking on Bim.
* You must talk to Bim to open the door, but he will open it immediately upon choosing option 2 in the conversation. You can run to the door using the mouse during the conversation to save a marginal amount of time.

==== Training Halls ====

* The correct sequence to skip Olgerd's tutorial without opening the shop is 1112113211. (It may be marginally faster to skip the tutorial and open the shop in the process, but that leaves windows that need closing.)
** Glitchless: Not that this route works glitchless past Chapter 1, but if you want to use this route for a glitchless route in Chapter 1, you want to raise at least 50 gold via selling items to Olgerd. The only item in your inventory right now that will save you any time at any point of the run is your starting mace.
* You need to rest and memorize spells while still in the first room. Otherwise, you are too close to "enemies" (actually, the targets that register the Warrior training) for the rest to succeed. You need to do so now because spellcasting is required to complete the Divine Caster training, which is faster than the alternatives.
* You can start resting and rearrange spells during the rest. Level 1 spells are refreshed at approximately 40% and again at 100%. You want to have them all in place by 40% so that you can cancel the rest, saving over 15 seconds of waiting. (There's no point in doing an Instant Rest here because it takes most of that 40% to do the memorization you need.)
* Which spells you memorize is mostly unimportant because the only spellcasting you ''need'' to do is spontaneous. I memorize two copies of Endure Elements and one copy of Bless; all these spells are needed at the start of Chapter 1, so it saves on menuing later. Additionally, Bless is helpful in the Prelude itself.
* Once the spells are memorized, start sorting out the quickbar so you can see when the level 1 refresh happens. After memorizing your L1 spells, drag any of them to an empty quickbar slot as fast as possible. As soon as it stops being greyed out, cancel your rest using <code>W</code>. (If you don't manage this in time – which is entirely possible, because the timing is quite tight – just reset, this is the second room of the game.) Place all the L1 spells you need during the entire run on the quickbar: Bless, Endure Elements, Summon Creature I, Spontaneous Cure Light Wounds.
* Run to the Divine Caster training using the keyboard. While you're doing that, you can arrange your quickbar how you want it using the mouse. There should be enough spare time to also wield your mace. All of this can be done in parallel with movement; generally speaking, in this game, you want to, as much as possible, be moving with one hand and menuing with the other.
* Complete the Divine Caster training (cast Spontaneous Cure Light Wounds at the injured man, and Turn Undead at the skeleton; Turn Undead is on the quickbar by default). Turn Undead will reach the skeleton from most places in the room; the correct place to cast it from is thus next to Elynwynd towards the door, and the correct time is after Spontaneous Cure Light Wounds due to the 6-second lag between non-movement actions (you have plenty enough time to get into position after healing the man). However, it is far from guaranteed to succeed. You need luck to complete this room quickly, as a result. (Of course, this is still the second area of the game, so you can just reset if something goes wrong.)
* Talk to Elynwynd and, while running out of the room, advance the conversation by one screen in order to gain Chainmail. This will be your armour throughout chapter 1.
* Start a conversation with the Door Guard. You don't actually have to go through the conversation to get into the next area, just start it.

==== Graduation Chamber ====

* Cast Bless on the two groups of NPCs nearer the door (target it between them), catching yourself in the radius in the process. This maximizes the chance of the fight in this room going quickly.
* This is your only chance to equip your armour without losing time, but the naive method (using the keyboard to move and the mouse to equip it) is prone to accidentally cancelling the "equip" action, because keyboard movement cancels everything. The better method is to use action queueing with the mouse. Click on Aribeth to start a talk action with her, and your character will start running towards her. Then open the inventory (<tt>I</tt> on the keyboard) and quickly equip the Chainmail and the Small Shield (the fastest way to equip an item is to drag the right mouse button away from it to the right, or to the left for an offhand item like a shield; avoid doing this in a shop, because that will sell the item instead). The equip actions will be queued behind the talk action, with the result that as soon as the conversation starts, your equipment will change instantly (you're not in combat). Conversations also close the inventory window.
* Mash 1 to get through the conversation with Aribeth quickly.
* This starts a fight, which is impossible to lose (the enemies will never attack you personally and cannot injure Aribeth, who will eventually finish them all no matter what). However, there are ways to make it much faster or slower. The important thing is to help out the low-level NPCs in the room, who will usually get slaughtered; and in particular, you want to help the ones furthest from Aribeth (nearest the door), because they are the most likely to die, and attacking the enemies that are least likely to die early. My current technique is to attack the Unknown Mage in the near left corner as you enter the room (the far right as you look from Aribeth's location towards the door). Once he's dead, help out the other group of NPCs near the door (who are often either dead or nearly dead at that point). If you're lucky, Aribeth will finish the fight in the process. Otherwise you might have to wait a few seconds, or even help her.
** Warning: Do not cast Summon Creature I in this fight, even though it seems appropriate. The badger will spend too long buffing itself to help in the fight, and it will influence the encounter tables, increasing the chance you get obstructed in the following corridors.
* When the fight ends, you want to be near the door, as Aribeth will run towards you, and you can't talk to her until she's out of combat. She'll rarely run all the way to the door, but you can lure her quite some distance during otherwise unusable time. Once she stops moving, click on her repeatedly until the conversation starts. The inability to talk to people during combat, combined with the game's definition of "combat", is frustrating; but don't worry, we can turn it to our advantage much later in the run.
* Once the conversation starts, start mashing 1, but also start running towards the door (using the mouse). The conversation can continue while you're running, as long as you don't get too far away, and if you mash 1 fast enough you'll finish it in time.

==== Training Halls ====

* You can just run to the next area during the cutscene, meaning you shouldn't be attacked. I love the way Neverwinter Nights does cutscenes (in particular, the fact that you can move around during them).

==== Academy ====

* Just like in the previous area, run to the next room during the cutscene.
* Ignore Pavel; nothing forces you to talk to him and he doesn't help enough to be worth the time the conversation takes.
* The faster route out of Pavel's room is east (the left of the two doors in the corner).
* Run around the Tough Goblin, and the set of three Weak Goblins. There is some randomness in the way they spawn; it is possible that you will need to kill one or more of them to get through.
* Speak to Geldar and press 1 a few times to get an immediate experience boost to level 2. (Nice of the game to give you a free level just so it could teach you how to level up.) I believe (but am not 100% sure) that this conversation is flagged so that it can be started even during combat. Run towards the door, and while running, level up. (You need to do the levelling up substantially before you reach the door, or it won't open.) For some reason, I'm in the habit of mashing 1 during this sequence even though it doesn't help at all (it doesn't hinder either).

Level 2:
* Role: Cleric
** Reasoning: Cleric is required to get Invisibility by the start of Chapter 1.
* Skills: postpone buying
** Reasoning: You'll level up again before the next time your skills become relevant, so postponing buying them saves time trying to find them in the menu.

* While running, you can use the time to memorize your fourth Level 1 spell in order to save time at the start of Chapter 1. This should be Summon Creature I, if you memorized Endure Elements twice and Bless once as recommended above.
* Don't take any side passages; you want to go straight down the corridor, take the turn to the right as the corridor turns, dodge the group of goblins (again, if you're unlucky with the way they spawn you might have to fight one or two of them), and open the door in front of you when the corridor splits to the left and right. (This is the fastest route through the area.)
* Something easily missed and very important in the room beyond the door you just opened: there are two large stone pillars near you in the room, and the obvious route is to run between them, but you want to run to the right of both of them instead. This postpones getting into the Mysterious Mage's line of sight as long as possible, greatly increasing the chance that he only gets one round of actions against you. If he gets two rounds, which is reasonably likely if you run between them (still possible, but much less likely, if you run to the right), you will probably die. Just run past him and out the door to the next area.

==== Stables ====

* It is likely some enemies will follow you into this room. Any undead who turn up can be ignored; Fenthick will Turn Undead and one-shot them. It is normally fastest to focus on the goblins near Fenthick and Desther first, because they do less damage to nearby targets (they punch them) than to distant targets (who get shot with a crossbow). You do more damage than anyone else here; Coup de Grace anything that gets hit with a paralysis effect, and otherwise just melee things to death (the points in Str you bought are pretty useful here). If low on health, you might want to heal; you should have one spontaneous cast of Cure Light Wounds available for the purpose (in addition to potions). Or you might prefer to just risk not getting hit.
* After the fight, you can start the first conversation by talking to either Fenthick or Desther. Pay attention to whoever was in combat more recently, and talk to the other. If you aren't sure, just try to start conversation with both of them until it works.
* The first conversation here can be completed just by spamming 1. The second conversation is harder and I frequently mess it up; you want to spam 1 until you get a screen with exactly two options, then press 2. If you miss it, you might actually have to read the options you're given to work out which one you need to take (it's the one where you agree to meet Fenthick within the week).
* The fastest way to proceed is to click on the door to Chapter 1 and level up while your character is running to it, but it's possible to mess this up. If you have to level up in Chapter 1 instead, don't worry; it's only marginally slower.

Level 3:
* Role: Cleric
** Reasoning: You need Invisibility.
* Skills: Persuade +2 (=6), 2 points postponed
** Reasoning: This is your last chance to buy skills at Cleric costs until after Chapter 1 has finished, and a high Persuade score saves you time in the Alaefin fight. 6 is the highest value a level 3 Cleric can set their Persuade to. There's no benefit to buying other skills, as they're either already high enough, or would not be useful before the next time we level up.
* Feats: Weapon Focus (greatsword)
** Reasoning: Even with your high Strength, you have problems hitting during the Chapter 1 boss fights. This gives enough of an edge to make those fights quicker. (Note that it also totally screws up the loot you get from one fight in Chapter 3, which I'll point out when it happens, but this is a comparatively small price to pay.) By the way, you can't legally buy this as a level 1 Cleric, so if you want to buy this and have it useful in chapter 1, it must be at this specific level-up.

=== Chapter 1 ===

* To skip the cutscene when SafeMovie=1 (required for it to render correctly on Windows XP or higher, which you are probably using), press the spacebar. (This took me an annoyingly long time to figure out.)

==== City Core: Sanatorium ====

* You can just run past Fenthick. The conversation will naturally cancel once you're far enough away from him.
* Use the time before you reach Aribeth, during the Aribeth conversation, and perhaps in the next area, to adjust your spells; conversations cancel the inventory window but not spell arrangement. You need to memorize your level 2 spells: two copies of Invisibility and one of Bull's Strength. Also place them on the quickbar (you can overwrite Spontaneous Cure Light Wounds, you're not going to need it for the rest of the run).

==== City Core: Hall of Justice ====

* Do not cancel the Aribeth conversation: if you do, you will not have enough gold to complete the City Core section of the run. In fact, you want to perform the Aribeth gold glitch once (ask her about the Stone of Recall when you get a chance to ask her questions); this hardly costs any time and is necessary in single-segment because otherwise you won't get enough gold.
** Segmented: You don't need to perform the gold glitch (even though it only takes a few seconds and makes things much easier), because you're lucky and (this no longer being single-segment) can perform reset glitches.
* Before leaving the room (as this is an any%, leave it towards the City Core, the other options are for optional sidequests), open the inventory and quickbar the Stone of Recall. Conversations make this awkward to do in future rooms, and doing it right now means your inventory will close naturally.

==== City Core ====

* Bethany will bug you every time through here unless you at least advance the conversation. The fastest method, therefore, is the "run away while spamming 1" option used on Aribeth in the prelude. I find it easiest to use the keyboard to move and the mouse to talk, for this conversation (typically the spell memorization window is still open at this point, which makes it hard to find something to click on to move with the mouse).
* Go towards the Trade of Blades. The extra DPS and Concentration interruptions added by a henchman save a huge amount of time over the course of Chapter 1.

==== City Core: Trade of Blades ====

* Hire Daelan.
** Segmented: You will need to persuade Daelan down to 175 in order to be able to afford to hire him. (As this is segmented, you may as well aim for 150; it's not particularly unlikely with your current stats. Persuading him below 150 is impossible.)
** Glitchless: You will need to persuade Daelan down to 175 in order to have enough gold in the Meldanen boss fight.
** I like to Persuade Daelan down to at least 175 even in other circumstances, because I think it doesn't waste time if the check succeeds, which it usually does, and having the extra gold can help later on (I have literally been just a few gold pieces short of something I needed before now).
* Rest to restore your L1 and L2 spells. You can cancel your rest once those spells are restored (press <tt>W</tt>). Then use the Stone of Recall to recall out.
** Rationale: We want Daelan for every chapter 1 boss fight, as he has the highest DPS. This would make it fastest to do the Docks first (he's right next to them), but that turns out to be untenable on this route due to issues with weaponry and experience, and in general due to issues with gold. So it's faster to recall out in order to get to the other end of City Core more quickly. If you have particularly slow loading screens and aren't subtracting them from timing, it might be faster to just walk out of the door.

==== City Core: Hall of Justice ====

* Leave towards the City Core.

==== City Core ====

* Run towards Blacklake. While doing this, tell Daelan to stand ground (with the mouse, you can do this via right-dragging; with the keyboard, press <tt>VWX</tt>). This is necessary to stop him taking damage in No Man's Land.
* Just open the gate leading into Blacklake; the guard will protest, but he won't stop you.
* Before going through, cast Invisibility on yourself.
** Segmented: You can go without this cast of Invisibility if you're very lucky through the next area; its only purpose is to prevent you being hit, and each single enemy is relatively likely to miss, it's the cumulative effect that's the problem.

==== Blacklake: No-Man's-Land ====

* Just run through to the Barricades via the shortest route. Daelan will be perfectly safe while in stand-ground mode. The enemies here will all ignore you while you're invisible (unless you attack them).

==== Blacklake: Barricades ====

* Talk to the captain to request entry to Blacklake. With your current statistics, the shortest conversation path is 141. (This can differ with other characters.)

==== Blacklake ====

* Run round to the front entrance of Meldanen's (i.e. round to the right, up the ramp, then to the left). This is around the same speed to enter as the back entrance is, but puts you much nearer to your goal once you've gained entry. There's plenty of time for menuing while doing this; a good use for it is to quickbar L2 spells that will be used later in the run (Negative Energy Ray and Hold Person). There should still be some time spare, which I use to examine NPCs just for fun. Perhaps there's a better use.
* Talk to Orrean. This conversation is normally difficult and has no guaranteed route for most characters, but as a high-strength human, 22111 is both very short and guaranteed to let you in. (This is another good reason to play a human, by the way.) The requirement to be human might or might not be a mistake in the code, incidentally, because there's no reason given in the dialogue for why being human should matter.
* Enter Meldanen's estate through the front door.

==== Blacklake: Meldanen's Estate ====

* Talk to Grommin, mashing 1 to get through the conversation; this is the fastest way to unlock the door to the next area. This requires a Persuade check to get him to unlock the door; however, with our Persuade modifier of +8, I am not convinced it is even possible to fail it, and I never have done in practice. If you do fail it, it should be possible to click on Grommin to reset the conversation and try again.
* You have time to cast one or two spells while Grommin is opening the door. One of them should be Endure Elements on Daelan; you won't get a chance to do this elsewhere without losing time. For the other, I like to cast Bull's Strength on Daelan, but am not 100% certain he is the best target for it (it might be faster to cast it on yourself). Then go down the corridor that Grommin opened.
** Segmented: One of the spells needs to be Invisibility on yourself, if you didn't cast it earlier.
* While running down the corridor, continue casting the spells you need for the Meldanen fight. Remember that although casting spells prevents you moving for only 3 seconds or so, you can only cast one spell every 6 seconds, and so it is best to space them out in time.
* The list of spells that need casting in this area (either at the door, or while running):
** Endure Elements on Daelan
*** Rationale: Otherwise, Meldanen often kills him with Cone of Cold. In a segmented run, you could probably skip this.
** Endure Elements on yourself
*** Rationale: Ditto.
** Bull's Strength on Daelan
*** Rationale: For the DPS. Casting it on yourself might or might not be better; I'm not sure.
** Invisibility on yourself
*** Rationale: If you don't refresh this, it will run out at a very inconvenient time, and you may well die as a result.
* Go through the second-last door on the corridor. Then continue forwards and open the door in front of you (at the other side of the room).
* This corridor is trapped; you'll need to weave first left, then right, to avoid the traps.

==== Blacklake: Meldanen's Sanctum ====

* Run forwards (east) through the first room; take the door opposite you, not the side door. This route is more difficult than the other, but has a pretty notable reward on it: there is a guaranteed Greatsword +1 on the weapon rack in the second room (with the fire beetles). Take and equip this weapon. You will be using it pretty much all game. (This is why the character bought two greatsword-related feats.)
* In the next room, press up against the shelf on your left to avoid a trap (use the keyboard). There is only a small amount of leeway to avoid triggering the trap.
* Enter the boss arena. There are basically two strategies that can be used for this:
** Recall drop (does not rely on glitches, legal in single-segment-without-resets, costs 50gp): run towards the dryad to spawn Meldanen. Then run back towards Meldanen and recall out. Cast Summon Creature I and Bless (both for DPS purposes), then use the Recall portal to enter the fight. As soon as you arrive, declare an attack on Meldanen with the mouse, and type VWE with the keyboard to get the rest of your party to also declare attacks (this works outside turn order and perception order, so is faster than waiting for them to join the fight naturally, and is also required because Daelan's still in stand ground mode).
** Reset glitch (is a glitch, requires a reset, costs no money): Reset and reload the game. This warps Daelan into the room. Then cast Summon Creature I and Bless, whilst typing VEE to take Daelan out of stand ground mode, and run towards the dryad to spawn Meldanen.
* During the fight itself, your aim is to melee-lock Meldanen: every time he tries to cast a spell, you want either you or Daelan to hit him hard enough to knock him out of the spellcast. A recall drop makes this easier to pull off, because your party is nearer to him at the start of the fight. However, the reset glitch leaves his AI more predictable (he is very likely to cast Cone of Cold if the melee lock breaks, quite possibly killing the badger, and wiping your party if he casts it twice), whereas with a recall drop, more or less anything could happen, and some possibilities (e.g. Ghoul Touch) will massively slow down your run. That said, I normally go for the recall drop, but which method is better depends on your segmentation discipline, timing method, and how lucky you feel.
* When Meldanen surrenders, you should normally just force-attack him; this gives the most gold out of any of the non-massively-time-consuming options and is also probably fastest. Loot the master key (for plot progression), the gold (why you do this area first), and the staff (for selling). Be very careful when looting; you can collect loot by clicking on it, but if your click is interpreted as a drag, the item won't be looted and you'll have to go back for it. You can look at the message area to see if this has happened; it won't show the "Acquired Item:" message.
** Backup strategy: If the fight goes badly wrong (e.g. Daelan dies), you will not be able to reliably win the fight. You can get all the relevant rewards but the Staff of Meldanen through dialogue: ask him to make you an offer, then accept the gold and the dryad. This is awkward to do because there are so many choices on the conversation menu (I haven't worked out the required numbers because of that; I think there's even an 8 in there somewhere).
* Unlock the door to the Dryad's prison, then talk to her. The fastest route through the conversation is to type 23 then to recall out of the conversation. (Don't worry about her, I checked the scripts, and the Dryad takes the opportunity to walk to safety after you unexpectedly leave.)

==== City Core: Hall of Justice ====

* While running to the door to the City Croe, expel Daelan from your party (right-click on him in the party list, then click top-left and bottom-right). He's going to die and respawn here anyway if you don't, but making him leaves serves two purposes: altering the experience formula (thus making it possible to get enough experience to hit level 4 in the Beggar's Nest overworld), and preventing him forcing you into combat and thus leaving you unable to have conversations. If you have a badger in your party, leave it until just before your next Turn Undead cast; it'll make more enemies spawn, meaning you have much more leeway for unlucky Turn Undead results.

==== City Core ====

* Perform a partial rest to refresh L1 and L2 spells. (Bear in mind that some spells on your quickbar are not memorized, so they won't refresh at all. Also, try not to cancel the rest after just the L1 spells have refreshed, with the L2 spells missing; I do that far too often.)
** Resets allowed: You can do an Instant Rest here instead. Even better, however, is delaying this glitch until just after talking to Jemanie; there's enough of a window to rest in that area that you can pull an Instant Rest off, and that gives you more leeway on bad Turn Undead dice rolls.
** Segmented: It may be possible to do without the spell refresh here altogether, although that would mean doing Blacklake and the Beggar's Nest in one Invisibility charge each. Blacklake is possible like this if you're lucky enough; the Beggar's Nest is more difficult on one charge, but possibly not by enough that skipping the rest is slower. This is probably not worth it unless the run is also glitchless, though; an Instant Rest does not cost much time.
* Go to the Beggar's Nest. Like Blacklake, you can just walk through the door despite the guard's protests. (All the main areas work like this.)

==== Beggar's Nest ====

* You need to grind to level 4 in this area, and you do that via 5 casts of Turn Undead (i.e. about 15 seconds out of your way for the casting, plus maybe 30 seconds or so because not all the locations are precisely on your route). The first two locations (before you temporarily go to a different area) are:
** Turn left as you enter; you reach an intersection with a sewer grate behind and to your right, and paths forwards and to the left. You want to cast Turn Undead at the point where the path to the left opens up and starts to expand into the main area. This is almost exactly on your route.
** Then take the path in front of you (not the path to the left), and turn left towards Jemanie's house. Use Turn Undead to kill the three zombies outside it. This is exactly on the route.
* Enter Jemanie's house at this point.

==== Beggar's Nest: House ====

* Talk to Jemanie. As soon as the conversation starts, immediately click on the entrance door while mashing 1. If you hear one "quest complete" sound effect, followed by three "journal updated" sound effects, you mashed fast enough; this is not particularly difficult. The developers tied a lot of quests to this area for some reason. You should end up running out of the door with all the required quest advancement, taking hardly any time.

==== Beggar's Nest ====

* Here are the other three Turn Undead locations:
** Leave Jemanie's house to the north-east (i.e. the direction you were going before you entered it). Warning: the door to the house is attached backwards (a mistake the developers occasionally made when connecting areas), so you will need to use the mouse to turn immediately after leaving). To the north-east of that house (i.e. to the right of your path) is a small building-like cluster. Run round the right side of it, letting the zombies follow you, and go towards the locked entrance to the Great Graveyard. Cast Turn Undead in the chokepoint just before the area with the sewer grate. This is a few seconds off the route, but worth it for the huge amount of experience it gains you.
** Run round to the north-west corner of the building-like cluster, and cast Turn Undead there; this should kill the zombies that started following you as you ran round it, plus the zombies attacking the nearby citizen. This is the fastest route, given the detour you just took. (If you had a badger with you as you entered the area, this cast can be omitteds.)
** Run just beyond the entrance to the cultist hideout and cast Turn Undead there, killing the zombies on the far side of it. This is only about a second away from the fastest route.
* Before interacting with the Hideout itself, cast Invisibility on yourself. You need to cast it to get through the next area anyway, and
* Open the door to the Cultist Hideout, and go through the conversation. This is worth 50 experience. If you killed all but one (or all) of the zombies in range of these five Turn Undead blasts, you should have had at least 5950 experience and so levelled up as a result.
** Backup strategy: If you don't have enough experience yet (i.e. you missed more than one zombie, or perhaps failed to kill Meldanen earlier), you can make the time up by killing zombies either now, or in the Great Graveyard a few rooms from now. Open the character sheet to see how much experience you have; zombies give this character 75 each, so you need one more kill if you're on 5925 or more (5875 if you haven't opened the door yet), two if on 5850 or more (5800 if you haven't opened the door yet), three if on 5775 or more (5725 if you haven't opened the door yet). The most likely zombies to miss are at the Great Graveyard entrance; this can happen due to bad dice rolls. Also, note that (unless doing a single segment without resets) you can reset glitch to restore your Turn Undead charges.

Level 4:
* Role: Barbarian
** Rationale: Barbarian Fast Movement gives the greatest time gain in Chapter 1 of anything you could purchase with this level. A Monk's fast movement scales higher, but starts smaller, so the Barbarian's boost is more useful for a 1-level splash. The rage can be occasionally useful, too.
* Ability: Wisdom
** Rationale: It actually doesn't matter whether you put this in Wisdom or Strength (odd ability scores function pretty much identically to the even scores one point lower), but I got into the habit of doing the Wisdom boosts before the Strength boosts.
* Skills: postpone buying
** Rationale: Barbarians have an awful skill point price list. It's better to wait until we can get skills at reasonable prices.

* Enter the estate.

==== Beggar's Nest: Snake Cult Estate ====

* Run to the exit via the shortest (only) route; your invisibility will prevent any enemies perceiving you. Quickbar Barbarian Rage while running.

==== Beggar's Nest: Crypts ====

* This is another "run to the exit via the shortest route", but that route is a little non-obvious and full of traps that will ruin your run (either due to long-duration paralysis or very heavy damage), so it's written in full here.
* Leave the first room through the corridor to your right.
* In this corridor, run along the left-hand side at least up until the collapsed wall section (which will prevent you continuing along the left-hand side), to avoid a trap. Don't take the branch to the left; the door there is locked right now.
* As the corridor bends to the right, take the corner very tightly, and stay near the right wall until it opens up into a room.
* Pull the lever near the cultists to unlock the door in the corridor you passed by earlier.
* Retrace your steps back to the junction. This means running along the left hand side of the corridor leaving the room (the corridor you entered by, but now you're going in the other direction), then keeping to the right just after the collapsed wall.
* The corridor opens up into a room, then collapses back into a corridor. The first bend in that corridor must be taken ''very'' wide to avoid a massively damaging trap; you're pretty much running along the outside wall.
* Then go to the left and through the door to leave the area.

==== Beggar's Nest: Great Graveyard ====

* If you aren't level 4 yet due to mistakes earlier, grind up to level 4 on zombies here (using reset glitch + Turn Undead, or just meleeing them down).
* Refresh Invisibility on yourself: otherwise it'll run out at or near the entrance to Gulnan's room, which makes the fight rather harder as a) she'll start buffing herself early, and b) some of the enemies from outside are likely to follow you into the fight.
* Enter the Warrens through the door to your right.

==== Beggar's Nest: Warrens of the Damned ====

* After the first room, turn right. (I've never actually tested that this is faster, but I assume that it's faster because it's one of the few points where my instincts agree with the existing runs, and I don't have the other route memorized to compare.)
* The way this area works is that there's a large ring with many smaller rooms off it, two of which contain keys, and you need one of the two keys. Thus, you need to open the door in front of you, even though it's a detour off the ring, to get a key. The door just beyond it is trapped; however, it's a pretty weak trap that deals only damage, so just tank the damage. Loot the key off the corpse of Torin.
* Backtrack to the main ring, and continue running round it. (There are no detours/side rooms between here and Gulnan.)
* Run right up to Gulnan, then recall out; we're going to do this fight with a recall drop (this seems to be by far the most reliable method).
* Do a full rest, even though it "wastes" a level 2 spell slot if you rested after Meldanen. This is for health, Turn Undead charges, and Invisibility charges.
* Join back up with Daelan, then cast buffs for the fight. I'm not sure which buffs save time on average, but as Gulnan is the hardest fight in the run (although Callik is more luck-dependent), I prefer to err on the safe side (a segmented run should try to do without some of these):
** Summon Creature I (DPS);
** Bless (DPS);
** Bull's Strength on Daelan (DPS, and to help disrupt Gulnan's casting);
** Endure Elements on yourself and again on Daelan (to mitigate Flame Strike to some extent);
** Barbarian Rage.
* Recall back in, hit VWE, and start attacking Gulnan. It's possible you may have to cast Turn Undead at some point in order to stop them interfering with the fight, but if you're lucky, you can go without.
* Loot Gulnan's heart (for plot advancement) and Scimitar +1 (for money), then recall out.

==== City Core: Hall of Justice ====

* Just leave. We're about to do a combat sequence, and have enough spells remaining (two Invisibility) to take us through to just before Callik, so resting would be counterproductive as it would remove the buffs we set up for Gulnan, but are still useful here.
** Backup strategy: If you got heavily injured in the Gulnan fight, heal at Aribeth.

==== City Core ====

* Head to the Docks. (This gate works like all the others.)

==== Docks ====

* This is the most luck-dependent area, although there are backup strategies almost everywhere. As such, a guide to the route has to be a bit looser than it would be otherwise. The basic idea is to kill enough generic enemies along the shortest path to get 5 Smuggler's Coins. Use Daelan and (if alive) your badger to do most of the killing; you can also kill, but looting is a better use of your time when loot is available. Drop back and/or drink Cure Light Wounds potions if you're running low on health.
* The shortest path is to turn left upon entering, then right, then it's a straight path to the Seedy Tavern. The route starts with a group of three enemies, and then no enemies for a while. There's another group of three near the fountain, and another just beyond them. You should try to avoid combat beyond those three groups, because then Daelan will start running all over the map, preventing you entering conversation. (VEE helps to avoid him running off, if he hasn't already entered combat; if he has, he'll break it off, but that'll just bring the combat to you. Once I have five Smuggler's Coins, I spam VEE in order to try to avoid unwanted combat.)
** Backup strategy: if you don't get five Smuggler's Coins off these nine enemies, you can enter the shop to the right of your route and ''buy'' up to three for 150gp each. The loot from Meldanen and Gulnan should mean you can afford this.
* Bribe your way into the Seedy Tavern (1431).

==== Docks: Seedy Tavern ====

* Buy three Potions of Invisibility and one Potion of Speed from the auctioneer. (You will have to sell some of your loot first to get enough money.) The basic idea behind the Potions of Invisibility is to save having to rest to refresh spells, which saves around 15 seconds; it costs about that in time spent shopping, but I think the ability to buy a Potion of Speed at the same time makes the shopping route faster. (In categories where resets are allowed, this rationale is less clear, because of the Instant Rest glitch; there may be a faster route that doesn't buy items here.)
** Segmented: You only need two Potions of Invisibility; the third is a hedge against Peninsula trolling you, and a segmented run can just reset if that happens.
** Untested: It might be worth spending all remaining money (including from saleable items) on Potions of Speed, purely for the running speed boost in the remaining running regions in Chapter 1. This seems like a waste, but probably actually does save time, if only a little. Remember to leave a little left over; many backup strategies involve unrecalling.
* Attempt to open the door to the basement, in order to get Daelan to start bashing it. Then bash it yourself at the same time. Chef will go to get help, but you'll be gone before it arrives.
* Skew your route to the left beyond the door, to avoid a trap. Also, press <tt>VWX</tt> during this time; you don't want Daelan and a possible badger running around inside the next area.

==== Docks: Bloodsailor Hideout (B1F) ====

* Cast Invisibility on yourself.
* Run invisibly to the end of the corridor (there's only the one junction, go straight on at that junction), opening the door at the end. Then take the only route down to the next level. As you're invisible, nobody will interfere with this. While running, quickbar the potions you just bought.

==== Docks: Bloodsailor Hideout (B2F) ====

* Cancel your <tt>VWX</tt> (with <tt>VWE</tt> or <tt>VEE</tt>); there's going to be combat here.
* Kill the enemies near Daranei. (You don't need to interact with Daranei herself.) Loot the Instructions from Callik.
* Establish your <tt>VWX</tt> again; Daelan should have killed the Bloodsailor patrolling outside by now, so this area will be undisturbed by enemies.
* Cast Invisibility, then leave past the Bloodsailor Lieutenant (follow the corridor round to the right, go to the end, then through the door at the left). While running, dememorize both castings of Invisibility (you'll use potions for that for the rest of Chapter 1); memorize two castings of Hold Person instead (it should already be on your quickbar). Also dememorize both castings of Endure Elements in favour of Summon Creature I (this is a case of removing something entirely useless in favour of something potentially useful if something goes wrong).

==== Docks ====

* Run round the outside of the building you just left (turning right three times), then head off west towards the Aqueducts.
* Pick the lock to the Aqueducts. (The rank in Open Lock is needed for other reasons too, but this is the reason it had to be bought so early.) Note that the pathing around the door is a little awkward; you might need to manually move closer to the door before you start to pick it. At Dex 8, Open Lock 1, you have a 5% chance of picking the lock, and under Neverwinter Nights rules (which are a corruption of the D&D "take 20" rules), a skill check outside combat and outside conversation always succeeds if it has a nonzero chance of succeeding. Therefore, the lock will always open.

==== Docks: Aqueducts ====

* Start crossing the bridge. The Bloodsailor will attack Daelan (or possibly the badger) as you start to cross. Spam VEE in order to try to keep Daelan alive and out of combat.
* Start conversation with Charon. As soon as you do, pause the game. Pause-buffer this conversation in order to preserve your precious "outside combat" state and Daelan's life; if you don't, you'll enter a fight with a Bloodsailor horde that you will not win, and that will knock you out of conversation.
** Backup strategy: If Daelan dies anyway, recall back to his respawn point in the next area and retrieve him that way. If the conversation is broken, you can try to re-establish it by pausing the game and clicking on Charon again.

==== Docks: Sewers ====

* Rest to regain L2 spells, and perhaps also HP if you or Daelan is badly injured. (In other words, how long to rest depends on your HP and whether the category allows Instant Rest.)
* As you run along the corridor, start buffing for the fight:
** Bull's Strength on Daelan
** Summon Creature I
** Bless
* Once inside the room with Callik, move moderately near to him (about to where the room's narowest point is), ten cast Hold Person on him. If it doesn't stick, try again. If it still doesn't stick, you're in trouble, but can try to complete the fight via brute force and recalling when on low HP. Whether it sticks or not, you want to type <tt>VWE</tt> to improve Daelan's reaction time to what just happened, drink the Potion of Speed, then kill the guards first and Callik afterwards. If Callik breaks free of the paralysis and you still have a Hold Person cast left, run back and cast it on him to see if you can make it stick again. If Callik starts attacking you, run behind Daelan until he switches target. If you get disarmed, pick the greatsword back up again. (This is a pretty luck-dependent fight.) In emergencies, recall out to heal, or just die and respawn for the free heal and get teleported back to the fight; the respawn penalty is negligible right now because your wealth is mostly in the form of saleable items you haven't sold yet, and you don't care about experience due to a glitch coming up later. If Daelan gets badly injured, you may want to let Callik kill him because it's the fastest way to heal him; however, this is kind-of risky if you can't finish off the fight yourself from there.
* There is no need to loot the corpses for anything (there's a saleable Rapier +1 but it's not worth enough to be worth picking up at this point); just run round to Vengaul. He will start conversation automatically, and you must complete the conversation to progress the plot (but mashing 1 works). Don't click on the crate that contains the feather until after Vengaul's conversation is done; it breaks conversation.
* Pick up the Cockatrice Feather, then recall out.

==== City Core: Hall of Justice ====

* Just leave. You might want to request healing for safety if you are critically low on hitpoints, but you shouldn't be; and the potions you bought mean that you don't have to rest just yet.
** Resets allowed: The Instant Rest glitch is faster than healing at Aribeth. Although it won't necessarily heal Daelan.

==== City Core ====

* If you don't have a surviving badger, summon one; you'll need it later.
* Head to Peninsula. (As usual, you can ignore the guard and just open the gate yourself.) On the way, tell Daelan and the badger to stand ground (because I'm running with the keyboard right now, <tt>VWX</tt> wouldn't work, so I use the radial menu instead for the same purpose).

==== Peninsula ====

* Ignore the guard just inside the gate: he doesn't actually do anything if you leave without talking.
* Cast Invisibility from a potion while still near the entrance.
* Head round to the Tanglebrook Estate, using the key under the mat to gain entrance.

==== Peninsula: Tanglebrook Estate ====

* Run to the stairs down. Use Turn Undead (for its Turn Vermin feature) on the Stink Beetles, to get them out of your way. Then go on to the next area. If you're unlucky, this won't work first time, but you can just try again.

==== Peninsula: Tanglebrook Tunnels ====

* Run around the chessboard. It's full of traps.
* Use Turn Vermin to oneshot the fire beetles blocking your path on the distant bridge (you can typically get all five with one blast if you have a good idea of what its area of effect is shaped like). Then go on to the next area.

==== Peninsula: Prison Main Floor ====

* Note that the door to this area is attached backwards, so be careful not to run right back to the previous area.
* Just before the first door, turn invisible via potion. Then open it, pull the Door Lever beyond it, and follow the shortest path (i.e. turn left whenever it isn't an obvious dead end) to the next level. There is just about room for you to slip past the boss of the level (and being invisible, he won't notice).

==== Peninsula: Containment Level ====

* This is the worst level in the entire game for NPCs standing in your way for minutes on end, so some other tactic is needed to mitigate it in a single-segment run. Run forwards to the door in front of where you open. As you enter, tell the badger (specifically) to follow, leaving Daelan where he is (you will need to use the radial menu for this). Pull the lever and open the door opposite where you entered. If you are lucky, the badger will distract the prisoners into walking into locations where they don't block the door, and you can run through. If you aren't, you may have to improvise.
** Backup strategy: The spare Potion of Invisibility is for if you take too long to do this area. If you get blocked for more than 20 seconds or so, you will need to drink it at some point to stop the invisibility wearing off; judge when based on how long you were blocked for.
** Backup strategy: If you're improvising, things can go spectacularly wrong if enemies run past you, because you'll take an attack of opportunity and break Invisibility. It's possible to go all Prelude-style in this area and just run around visibly, tanking damage, but I wouldn't recommend it unless you have no other option. You'll need the spare potion of Invisibility anyway when doing this because you definitely need to be invisible to get past Kurdan.
* At the end of the level, running to the left gives you a very marginally shorter running distance, and running to the right gives you considerably less camera movement. I prefer to go to the right, as I find manipulating the camera harder than running.

==== Peninsula: The Pits ====

* Pull the lever when you enter. Then run through to the end of the area via the fastest route. (Note: I'm not actually 100% sure what the fastest route is, so I'm not listing it here.) Memorize the trap locations to avoid triggering them. Sometimes the enemies will block your path; you can sometimes work around this by using the spare casts of Summon Creature I to distract them.
* The jewelled door (the first one past the doors opened by the last set of door levers) is trapped with a slowing trap, which is annoyingly time-wasting. My current strategy here is to hope that Lightning Reflexes works (a 15% chance), or to take the time penalty if it doesn't. It might be possible to pull something off with Potions of Speed to work around this.
* Being invisible, you can just run past Kurdan.

==== Peninsula: Lair of the Devourer ====

* Perhaps unexpectedly and surprisingly, you can ''usually'' rest at the start of this area, without even recalling out. Do so, at least up to L2 spells. (Alaefin will occasionally interrupt the rest via random-walking; often, though, you already have the spells you need regained by that point.)
** Resets allowed: You can Instant Rest at the start of this area, which means that this rest is even more risk-free.
* Cast Summon Creature I, Bless, and Bull's Strength on Daelan.
** Backup strategy: Recall out, and rest and buff there. This is mostly for use if something goes disastrously wrong, like Alaefin killing Daelan during buffing, because it costs a lot of time.
* If he isn't already, get Daelan into comabt with Alaefin. Then cast Hold Person on Alaefin until it sticks or you run out of charges. Either way, go round rescuing guards until they're all gone; just because you're chaotic evil doesn't mean you have to be ''stupid''. After that, join the fight.
** Dubious: Divine Trickery might or might not make persuading the guards faster. I mean, it does make it faster on average, but not by much, and it takes time to cast.
* When phase 2 of the fight starts (i.e. Alaefin dies, revealing the Intellect Devourer), enter rage, and start beating on it along with the rest of your party. The occasional <tt>VWE</tt> doesn't hurt, either. If you aren't very low on HP when this stage of the fight starts, you are almost guaranteed to win it; the devourer does hardly any damage. The rage is thus useful in multiple ways: boosting the Will save means you spend more time attacking and less being mind-affected, and the Strength boost means you hit more often and do more damage.
* Pick up the reagent off the corpse and recall out.

==== City Core: Hall of Justice ====

* Talk to Aribeth, and hand over the reagents. Take care not to accidentally donate your reward to charity; losing the gold is minor (although significant), but losing your Evil reputation would be a lot worse. When she asks you whether to leave right away, accept and end the chapter.
* You will typically level up at this point. There's no real advantage to going through the level up dialogue now, though; better to leave it until after the experience glitch.

=== Chapter 1e ===

==== Ritual Chamber ====

* You have to talk to all the major characters, but you don't have to complete the conversation; just opening up the first screen and moving onto the next person is enough. The exception is that you need to complete the last conversation in the area. This should be Nasher, as his is trivial to complete (14).
* During the following cutscene, cast Summon Creature I for a small amount of bonus DPS in the next fight. Dememorize Hold Person in favour of Negative Energy Ray; this makes menuing in Chapter 1e somewhat easier. Spend the rest of the time rearranging your quickbar. The only slots from it you still need are Negative Energy Ray, Bull's Strength, Summon Creature I, and the Stone of Recall; although in most cases you can just overwrite a quickslot, I find that explicitly emptying them (during time where I have to wait anyway) makes it easier to avoid mistakes where I overwrite the wrong quick slot.
* It also helps to get Daelan over the opposite end of the room to you (which can be accomplished via <tt>VWX</tt> or, to some extent, via the "follow at long distance" dialogue command). You want him picking a different target to you in the ensuing fight, if you can.
* Once the fight starts, try to kill the enemies efficiently (i.e. don't get in the way of NPCs or other party members who are fighting), and in particular, chase down any enemies who try to flee the fight (because the allied NPCs have an annoying tendency to cast fear-based spells).
* With all enemies dead, you must complete the conversation with Aribeth before you can use the portal.

==== Road to Helm's Hold ====

* Run to the next area. While doing so, unsummon the badger (which will almost certainly be alive at this point), and tell Daelan to leave the party; you have no combat until the Desther fight, and that fight is complex enough without the ally AI messing it up further.
* You can just ignore the Strange Visage.

==== Courtyard ====

* Run to and use the side entrance on the right. This is not only the shortest path to where you need to go, it also lets you avoid combat, as you will avoid stepping on the spawn trigger for the enemies who are meant to be in this area.

==== Helm's Hold (1F) ====

* Turn left upon entering, go through the door, then turn right at every opportunity after that until you come to a bookshelf. Take the Black Grimoire from it. For the only time in the run, we're doing a sidequest for experience.
* Use the Black Grimoire to complete the summoning on the nearby altar.
* Now talk to the demon, who has a very glitched conversation:
** First, go through the conversation normally (use 111131 because it gives the best rewards for a chaotic evil character). The conversation is not over at that point, but it has reached a point at which you get maximum benefit from starting the glitches. Note that the final "1" is one of two options saying "Continue"; this conversation is more glitched than many people realise. You get an unidentified cloak and unidentified boots from this.
** Warning: the rest of the glitches with the conversation must be completed within three in-game seconds. This requires very heavy pause buffering (to pause-buffer a conversation, you have the game paused, and select an item via pressing the digit, then very quickly hitting Space twice). This limits how much you can gain from the glitches.
* First up is an item glitch. Pause the game, then click on the demon to reset the conversation (this causes the "despawn" sound effect and animation but the despawn is delayed three in-game seconds), then pause-buffer 111131 to get the reward again. Then do this two more times (for a total of four sets of rewards). This is the maximum that seems to be possible within three in-game seconds, given the amount of text in the resulting dialogues.
* Next is an experience glitch. With the game paused, just click on the demon repeatedly; you get experience for every click (because as it happens, the experience is granted in the first node of the conversation, meaning that the game doesn't need unpausing at all). You can double the speed of this by using both a mouse and a touchpad and mashing with both hands. Gain enough experience to reach level 17. (The game will start lagging because every click also causes a separate despawn animation to be drawn, but the lag won't be visible until you unpause it, and will only last a few seconds.)
* You can (and should) level up with the game still paused, so that if you fell short on experience, you can go glitch yourself some more.

Levels 5-16:
* Role: Cleric
** Rationale: We're trying to gain access to various Cleric spells that let us completely break boss fights. The highest-levelled of these is Aura versus Alignment, at level 8, meaning we need 15 levels (12 more levels) of Cleric to cast it. Additionally, this means we hit a total level of 17, which gives the most ''expensive'' random drops from chests (level 16 gives the most ''useful'' random drops, but we can't rely on any particular drop in a single-segment, so instead we just hope for expensive saleable items).
* Ability: Wisdom, Strength, Strength
** Rationale: We need to pump Wisdom to 18 to cast Aura versus Alignment. The remaining points go into Strength for carry capacity (which can matter if our random loot items happen to be very heavy), and melee prowess (marginally useful, but more useful than the benefits of higher Wisdom; some enemies need melee attacks to finish them after being Harmed).
* Skills: postpone buying
** Rationale: We need to buy skills at level 17, and doing all the buying at once makes menuing easier.
* Feats: Still Spell, Extend Spell, Spell Penetration, Toughness
** Rationale: Still Spell and Extend Spell both let us adjust spell levels in order to avoid clashes and memorize more copies of a spell than we would otherwise be able to. Extend Spell is generally better, as many of our spells have awkwardly short durations, but it doesn't work on all spells, so we need a second metamagic feat for that purpose. Spell Penetration makes the run both safer and faster because in many fights, SR checks are the ''only'' randomness involved, and a bonus to beating SR checks is thus very welcome. Toughness is mostly just filler, but filler that can occasionally save a run that would otherwise take just a little too much damage.

Level 17:
* Role: Rogue
** Rationale: We need a role that can both equip Monk-specific items, and cast Sorcerer/Wizard-specific spells. Rogues have the ability to do those, within limits that we can make high enough.
* Skills: Use Magic Device 13, Lore +18 (=20), Persuade +7 (=13)
** Rationale: 13 points of Use Magic Device, plus a Charisma of 14, lets us cast Time Stop even if it's in a large stack of scrolls, meaning that we don't need to constantly waste time working around a bug in the game just to cast Time Stop. (If not for the bug, 8 would be enough; if playing in a category where resets are allowed, 8 is also enough, because then you only need five scrolls). Maxed Lore gives us the best possible chance of identifying items on the run, rather than having to examine them at a shop (which wastes a few seconds), and also lets us identify certain specific items in time to use them in the Desther fight. The remaining points go into Persuade, because there are some hard Persuade checks later on that we benefit from passing.

* Run along the corridor leading out of this room from the nearest door (i.e. westwards), sorting out spells as you go. When reaching the door at the end of the corridor, rest to regain spells. During the run and the rest, the following spells must be memorized (this list is based on when the spells are needed):
** L7: Creeping Doom *3
*** Rationale: Needed in the Desther fight, probably. This is currently one of the two main reasons to pick the Plant domain. Also required for Host Tower Level 9, which is the reason to memorize maximum copies. Upon reaching Chapter 3, this is no longer required and will be swapped out for more Harm casts (via Still Spell).
** L6: Harm *4
*** Rationale: The best boss-killing spell in the game, basically because the damage isn't capped, is resistable only by SR (or negative energy protection but nothing has that), and ignores the enemy's max HP. Almost every boss fight is about finding an opening to cast Harm.
** L4: Extended Invisibility Sphere *6 (must be quickbarred immediately)
*** Rationale: It's Invisibility, except you don't waste your time clicking a target, so it's faster and less "typo"-prone.
** L3: Protection from Elements *7
*** Rationale: Being able to tank traps is faster than having to heal up from them (and increasingly, it becomes impossible to run round them), and most traps do elemental damage. You don't need this many copies, but more never hurts in case something goes wrong, or for no-major-skips (which takes a ''lot'' of elemental damage in Chapter 3).
* The following spells also need memorizing and quickbarring during Chapter 1e or Chapter 2 (and can simply be memorized now if there's spare time):
** L8: Aura versus Alignment *2
*** Rationale: The only Cleric spell I could find in unpatched that deals damage that bypasses SR (in this case, via dealing it in a rather indirect manner). It isn't that much, but it's enough for the purposes of the route.
** L5: Extended Divine Power *5
*** Rationale: Temporary hitpoints and a +5 to base attack bonus are both exactly what we need in melee combat, e.g. trying to land Harm against an enemy with minions, or trying to finish a Harmed enemy in situations where neither Aura versus Alignment nor Negative Energy Ray works. You really don't need all five copies here – one is probably enough – but it's fastest just to mash the memorize button.
** L2: Negative Energy Ray *5 (2 should already be memorized)
*** Rationale: Many sequence breaks need either a ranged attack, or an attack that deals an unusual sort of damage. This is both. Two casts are needed during chapter 2, but you should have those memorized already; the extra 3 are for spamming against spell-resistant enemies until one of them goes through.
** L2: Lesser Dispel *1
*** Rationale: For glitching the final boss, and that's it. Do not quickbar this spell until later, to save slots. You can skip this in a segmented run, because there are faster but riskier strategies for the final boss that don't need it.
** L2: Bull's Strength *1 (should already be memorized)
*** Rationale: Gives either +2 or +3 to attack and damage. This makes finishing off Harmed enemies more reliable in Chapter 4.
** L1: Summon Creature I *1 (should already be memorized)
*** Badgers are no longer that great at fighting, but you can use them to trigger traps remotely.
* Cast Extended Invisibility Sphere, go through the door, and head up towards Fenthick.
* Between now and the Desther fight, quickbar Creeping Doom and Harm. Spend the rest of the time memorizing and quickbarring other such spells. Note: you can't quickbar Aura versus Alignment from the spellbook, as that locks it as Unholy Aura, which is useless. Instead, use the radial menu from the quickbar, and lock it as Holy Aura, which is what we want as most bosses are Evil. The quickbarring here accounts for nine slots; the other three should be Stone of Recall, Divine Trickery, and one empty slot that will later be used for Time Stop.

==== Helm's Hold (2F) ====

* Just ignore Fenthick, and continue with your identification, equipping, and quickbarring.

==== Helm's Hold (3F) ====

* Continue with your quickbarring up to the door of the Desther fight.
* Go into the Desther fight (invisibly), and run to and open the door on the far right-hand corner, but don't go through it yet.
* Cast Creeping Doom centred on Desther. As soon as you regain control after the spellcasting lag, run into the room beyond the door you just opened, and loot the two nearest chests (these contain "boss-quality" drops, so unless they're healing kits, they should fetch you a lot of money).
* If you did things correctly, after about 24 seconds or so (the exact timing depends on luck), Desther will lose spell resistance due to the deaths of four Ritual Creatures, Meanwhile, his custom AI will cause him (and only him) to run into the room with you (or perhaps just to the entrance). Spend this time identifying your Cloaks of Movement and Dragon Slippers, and equip one pair of each (the Dragon Slippers, in particular, are required in this fight if things go wrong because the room is full of fear auras). Then you can simply kill him with Harm and complete the conversation to end the chapter. (If you can get him alone, you can also try the Harm kill earlier; just hang onto the last cast in case the first three are stopped by SR.)
** Backup strategy: If enemies other than Desther start attacking you, stay alive by recasting Extended Invisibility Sphere and running out of the entrance to the room; then later, try to locate and Harm Desther. You may have to turn invisible multiple times due to enemies random-walking into Creeping Doom's AoE. This is the best of several bad options.

=== Chapter 2 ===

This chapter is very short on a speedrun; although it has a lot of content, almost none of it is mandatory, and it is possible to use sequence breaks to make it even shorter.

==== Port Llast - Kendrack's Barracks ====

* Recall out. It's fastest to do all the mandatory stuff here in one go, which means doing it later.
** 100%: Getting Vardoc's journal requires a series of actions with mandatory waits between them, so there are a bunch of effective frame rules in chapter 2. Thus, the very first thing to do is to start the timer, which you do by going to the inn and killing Solomon.

==== Port Llast - Temple of Tyr ====

* Sell saleable items (the boss drops from Chapter 1e, the items you got from the demon other than the ones you equipped, and the +1 weapons from Chapter 1 other than the ones you equipped).
* Buy and equip the Robes of the Dark Moon. (The radial action for equipping is the same as for selling, so you'll need to equip them the slow way, by dragging them to the "equipped armour" slot.) This immediately sets your movement speed to the fastest possible value available in unpatched.
** No major skips: If you're willing to use the experience glitch on the demon, but not to sequence break the main plot of the game, you'll also want to buy and equip a Lesser Amulet of Health here in a single-segment run, or you will have too high a risk of failing Chapter 3.
* Leave the temple through the door.

==== Port Llast ====

* Run south towards Charwood. The Farmer's Son will interrupt you, but you can just ignore him and the conversation will cancel due to distance.
* Cast Extended Invisibility Sphere just before using the south exit.

==== South Road ====

* Use your running time in this and the next few areas to finish any spell memorization or quickbarring that you didn't manage to fit into Chapter 1e.
* Aim towards Charwood by the shortest path (which involves crossing the river at an angle after the bridge).

==== South Road - Farmland ====

* Continue towards Charwood. (For some reason, I have a huge tendency to go the wrong way here. The correct route is to turn right and uphill just after the footbridge.)

==== Charwood - Haunted Forest ====

* Continue towards Charwood. The fastest route is to go right across the small stream at the first fork in the road, and to the left rather than crossing the bridge. You won't be attacked, because you're invisible.

==== Charwood ====

* Open and walk through the two gates. (You have to walk through the left-hand half, because the right-hand half is stuck.) Follow the path up to the house next to two people, then enter that house.

==== Charwood - Inn ====

* Immediately declare an attack on the Strange Man; you should kill him in one round of sneak attacks (if you're unlucky, it'll take two, but this is a minimal time loss). He will drop a journal, plus boss-quality treasure; take both and recall out.
** Segmented: It's possible to buy Pick Pocket and steal the journal off him instead, which is slightly faster but requires quite a bit of luck. You miss out on the treasure, but that doesn't really matter in segmented as you can manipulate expensive items out of chests.

==== Port Llast - Temple of Tyr ====

* Duplicate the journal you just looted/stole, by dropping it, buying a copy from the divining pool, then picking up the original.
** No major skips: you will have to get another journal legitimately; the fastest is obtained during the Neverwinter Wood main quest (you can just recall out after you get it, you don't need to complete the quest at that point).
* Then leave through the front entrance. (You might also have to sell items if your random drops have been particularly heavy.)

==== Port Llast ====

* Head to Aribeth via the fastest route. (You'll need to open the door to the barracks, even though it's normally always open, because you didn't open it from the inside when you arrived here.)

==== Port Llast - Kendrack's Barracks ====

* Talk to Aribeth to do the "start of chapter 2" conversation and turn in the journals, then to Aarin to gain access to Luskan. Warning: escaping the Aarin conversation too early seems to make the game unwinnable. I'm not sure of the exact point in the conversation that the guard in question spawns, but tend to finish the conversation naturally to make sure (there's easily enough time to do that while running towards the door). Then turn round and run north.

==== Port Llast ====

* You want to leave via the north exit. Assuming that you're not doing a 100%, you'll hit the spawn trigger for Solomon if you follow the road directly, which can cause interruptions/complications. You can minimize the risk by memorizing the location of the spawn trigger and running round it.
* While doing this, recast Extended Invisibility Sphere, if it doesn't replenish itself spontaneously (Invisibility Sphere is kind-of glitchy in this game, and seems to have a pretty high chance of spontaneously replenishing itself while leaving the raised area that holds the temple entrance).

==== North Road ====

* Ignore everyone and run north.
* Spend the time while running identifying items.

==== North Road - Green Griffon Inn ====

* Run north to the gates of Luskan. (Darktongue Breakbone will ignore you because you're invisible, but he may be blocking the way, forcing you to run round. Alternatively, it's possible he won't spawn at all; I'm unsure of the exact trigger.)
* Talk to the Luskan Sergeant to gain entry to Luskan. (There's an option to skip to the end of the conversation.)
* Walk through the transition to trigger the next chapter.

=== Chapter 2e ===

==== Luskan ====

* Recall to the temple; it's closer to where you need to go than your current location. (If you're using including loading screens in your timing and you have slow loading screens, it may be faster to do the first bit of the chapter without recalling, to reduce the loading screens; in this case, cast Extended Invisibility Sphere immediately.)

==== Luskan - Temple of Tyr ====

* You may have to rest here if you're low on spells due to needing to improvise earlier. The spells you need before the next time you rest are Summon Creature I x1, Protection from Elements x1, Negative Energy Ray x2, Extended Invisibility Sphere x3, Creeping Doom x2; following this route exactly should give you all those spells (and more), but you might be missing them if you had to improvise. (If you're in a category that allows resets, you can do an Instant Rest.)
* Cast Extended Invisibility Sphere.
* Leave through the front door.

==== Luskan ====

* Ignoring everyone, leave for the gap in the wall that leads to Kurth's base. (This is the fastest of the four routes that lead to seals.)
* While running, cast Protection from Elements. (This will be up all chapter, for the purpose of tanking traps.)
** Segmented: it might be possible to go without and just tank traps on your HP total, but I'm not sure if you can survive that.

==== Luskan - Docks ====

* With your current stats, you can't open the entrance door from outside. Thus, you need Kurth's men to open it from the inside. Run to approximately the corner of the island you're on (where there's a chest and a barrel), and cast Negative Energy Ray at one of the generic Bugbear Archers. This should turn the inside of the base hostile. As soon as they open the gate to reach you, cast Extended Invisibility Sphere and run past them into the base. You'll be taking some attacks, but they won't do enough damage to kill you.
** Untested: Is it possible to summon a monster on the other side of the bridge to turn the enemies hostile? Is that enough to unlock the door?
** Untested: Can a spell like Knock be used to enter the base without breaking invisibility?
* Follow the fastest route to Kurth's castle (turn right, run past/through a market area, take the first right on the bridge tiles. The Bugbear Archers can really get in your way on the first corner after that right turn, but I don't know of any reliable way to get them to move.
** Untested: AquaTiger's segmented run uses Fireball here, but I can't see it saving time overall given the detour needed to obtain it. It might be possible to do something with Summon Creature I, but the problem is that the enemies are archers and thus unlikely to move to attack.
* Enter the castle. The entrance is also a little dubious in terms of NPCs blocking the path, but much easier to get past than the archers; make sure to observe the area to see where the clear path is.

==== Luskan - Kurth's Lair ====

* Run to the right upon entering, then take the leftmost door in the resulting room (i.e. you're now running the way you were facing when you entered).
* Pick the lock on the door that leads to Kurth.
* Run past Kurth (he can't see invisible), and enter the far left room. There's an acid trap there which is awkward to avoid, but the Protection from Elements you cast earlier will tank it for you. Open the chest behind the curved screen, and loot the High Captain's Seal. Then recall out. This chest often but not always contains some pretty good treasure; I'm not sure offhand what treasure table it is, it doesn't seem to follow any of the standard patterns.

==== Luskan - Temple of Tyr ====

* Talk to Aarin. The fastest route through this conversation is 4141, followed by running out of the door (there's no need to end the conversation naturally).

==== Luskan ====

* Go to Host Tower via the fastest route (go forwards after leaving the temple, cross the bridge to your left, then follow the shoreline left until you reach the bridge to Host Tower).
* Claim to be an ambassador to gain entry to the Host Tower.

==== Host Tower - Courtyard ====

* Talk to Captain Islund to gain entry. This conversation is awkward, because although I think there are guaranteed paths through it no matter what, which path you need to take depends on randomness, thus you need to actually read the conversation to know what to do. I can't generally remember all the paths except when I actually read the text, but IIRC the correct route is to Threaten, and then if that fails ask if he's denying you entry.

==== Host Tower - Ambassadors' Quarters ====

* Go to Aribeth's room (centre left) and take her key from the armoire. There's a hostile construct there, but it can't see you because you're still invisible.
* Use the portal to warp to the second floor.

==== Host Tower - Level 2 ====

* Go into Blaskar's room (it's the nearest one to your portal, behind you and to you right).
* Loot the boss treasure from the nearer chest, and the 6th floor portal stone from the more distant chest. Both chests are trapped, and both traps will be tanked by Protection from Elements. (Note that tanking a chest or door trap requires one extra click compared to the trap not being there, so you need to be aware of the traps even though they are unlikely to hurt you.)
* Use the portal to warp to the 6th floor.

==== Host Tower - Level 6 ====

* This level has one-way doors in, so you run round it in a circle rather than the more common there-and-back route. Open the wooden door behind you and to the right, then cycle round to the left (as always, tanking traps as you go). Ignore the first door you pass, and go in the second (the one near Valindra).
* Shuffle to the left (press <tt>Q</tt>), causing the Familiar to spawn. It is normally, but not always, fastest to wait for it to random-walk onto the nearby negative trap, which kills it and removes the trap. You might want to summon a monster or just take the level drain if it doesn't cooperate.
* Tank the trap on the chest, and loot the boss treasure and Pinnacle Portal Stone from it.
* Continue your cycle to go back round to the portal. The door blocking your way will open spontaneously. Bear to the right as you go through it to avoid a particularly nasty trap.
* Use the portal to warp to the 9th floor (marked "Pinnacle" in the menu).

==== Host Tower - Level 9 ====

* This fight is a pain in pretty much every category. This is the fastest route I know, but it's not 100% reliable (although it is reliable enough for single-segment), and there may be other routes that are faster.
** Resets allowed, partially tested: Doing an Instant Rest (which may be necessary anyway if low on health) gives you a third Creeping Doom charge, which makes things substantially easier. This should make some of the more time-consuming parts of this strategy skippable, but it's unclear which ones.
* Open all four portcullises first, so that you get the maximum possible mobility during the ensuing fight. This really does make a difference.
* Cast two copies of Creeping Doom centred on the same location, placed so as to not hit Arklem but to hit as much of the rest of the main area as possible. The correct centering location can be determined by looking at the floor; anywhere near the centre of the right-angled isoceles triangle furthest from Arklem will do. The purpose of this is not primarily for damage (although the damage does matter on occasion), but for the slowing effect. (Although it's a little slower, you can ensure that both are centred on exactly the same spot via standing there yourself and then casting at yourself; I used to do this, but nowadays just try to judge it by eye.)
* Destroy the braziers in the following order: the one nearest the entrance, the one furthest from the entrance, the one second-nearest the entrance, the one third-nearest the entrance. This gives you the largest possible head start on the enemies that spawn, and with only two casts of Creeping Doom remaining, it seems to be required. (If you're using a route with three casts, this is one of the prime candidates for simplification.)
** Untested: Because the Fire Elemental (which spawns second) is the main issue, there may be a faster order that still works.
* Run anti-clockwise around the outside of the room and talk to Arklem. If everything is set up perfectly, neither him nor you will be in combat, and you'll be able to move on even though you didn't technically complete the fight.
** Backup strategy: if something does go wrong, do a cycle of the room anti-clockwise and try again. You can repeat this for as long as your HP holds out.
* Run through the portal to the next level. Normally you won't be chased, or chased only by a red slaad (which you can ignore, they don't do enough damage to disrupt the route). If something more powerful does come through, try to avoid it.

==== Host Tower - Pinnacle ====

* An explanation of what's going on here, for people who aren't hugely familiar with the game, because this entire level is set up to deceive you. The previous room was actually the final boss fight of Chapter 2, despite being disguised as a mini-boss. (It's difficult enough to be one in both a speedrun and in casual play.) What you need from this level is for your character to become aware of Aribeth's fate and the Words of Power. There is a mini-boss on this level, but it doesn't actually do anything; in particular, there is no reason to fight it, and it's just there to aid in the deception. There is also no way to leave the area but to recall out. (Future versions of the game had an extra Stone of Recall placed there, as a clue and in case you didn't take your own Stone of Recall with you.)
* Thus, what you're trying to do is to reach the end of the cutscene where Aribeth becomes a blackguard. This is trivial to accomplish because nothing's attacking you, but you want to accomplish it quickly. The easiest way that I know to accelerate this cutscene is to cast Negative Energy Ray on a generic lizard warrior; this causes them to become hostile, and (after an apparently random length of time) the resulting cascade of combat statuses interrupts the cutscene, and the game automatically sets the required plot flag to prevent the game becoming unwinnable. You can tell that this has happened when you hear the click of a journal entry being updated. If it's being slow, using a second cast tends to help.
* As soon as your journal is appropriately updated, recall out.

==== Luskan - Temple of Tyr ====

* Talk to Aarin and spam 1 to end the chapter.

=== Chapter 3 ===

==== Beorunna's Well: Aarin's Lodge ====

* Run to the right-hand door, talking to Aarin on the way (if you stay far enough from the wall, he will force conversation on you).
* You need to get to at least a certain point in the conversation for the doors to open and the Stone of Recall to start working, which is awkward because spamming 1 isn't enough. I currently don't have a set route through this conversation and improvise it.
* Leave through the door you were running to.

==== Beorunna's Well ====

* Enter the drinking house.

==== Beorunna's Well: Drinking House ====

* Talk to Lillian Cambridge. (This is one of the only sidequests that's actually completed during the run, incidentally; there's a sidequest called, literally, "Talk to Lillian Cambridge", because the first part of the Coldwood quest was split into its own journal category for some reason. Talking to Jemanie back in chapter 1 completed another similar sidequest.) This conversation can be completed by spamming 1; there are routes which have fewer keystrokes, but which are probably slower because entering sequences other than 1-spam requires actual thought. The conversation gets stuck in a loop, but you can leave as soon as you get the Teleport Scroll (watch the message area).
* Leave the drinking house again.

==== Beorunna's Well ====

* Go to the Many-Starred Cloak enclave.

==== Beorunna's Well: Many-Starred Cloak Enclave ====

* Talk to Eltoora and open the shop.
* Sell all the saleable items you have (other than the ones that are equipped) in order to buy as many scrolls of Time Stop as you can afford. (You only need 8 of these scrolls if everything goes right, but the Instant Rest glitch is ''very'' useful for recovering if something goes wrong, so extras never hurt on a single segment.) This is the last time you buy items in the entire game, so don't worry about spending your entire gold supply.
** Resets allowed: You need only 5 scrolls, because the Instant Rest glitch can be done via resetting rather than via Time Stop.
** Segmented: 4 will suffice; you don't need the extra help against the Half-Dragon Baalor.
* Leave again.

==== Beorunna's Well ====

* Run to the north exit (to your right, towards Coldwood). Before you get there, cast Extended Invisibility Sphere.

==== Coldwood (southwest) ====

* Run to the east exit (run forwards until you get an opportunity to turn right, take that right turn, then run forwards and across the bridge, then continue running forwards). While on the way, start changing your spell memorization: dememorize Creeping Doom in favour of Still Harm, and change the quickbar to match.

==== Coldwood (east) ====

* You spawn facing in an awkward direction; the way you need to go initially is behind you and to the right.
* Run anticlockwise round the level to the magic circle, then run to the floor design; the Teleport Scroll will activate automatically.

==== Coldwood: Wizard's Dungeon ====

* Use the door to the left of your spawnpoint, then make your way clockwise around the level.
* The quintet of mephits can easily get in your way (they block your way by default, and will continue to do so unless they random-walk into a pattern that doesn't). You can use Summon Creature I to try to persuade them to move; you will need to get the badger to attack (<tt>VWE</tt>) or it will be just as invisible as you are. I normally attempt this trick, but have trouble pulling it off.
* Enter the first room after the mephits, tank the trap just inside the door on your HP (it'll hurt but it's survivable), and solve the puzzle. The solution is always the same: a Z shape, starting at the bottom-right as you enter the room, and continuing to the bottom-left, top-right, and top-left. The door opens automatically.
* Run to the snowglobe and take it. There's a nasty trap to the left of the nearest pillar, so run round the right of that pillar. Because you're invisible, the Huge Fire Elemental won't attack.
* Recall out.

==== Beorunna's Well: Temple of Tyr ====

* Just leave via the main (only) exit.

==== Beorunna's Well ====

* Enter the Drinking House.

==== Beorunna's Well: Drinking House ====

* Return the snow globe to Lillian. (Spamming 1 works.) You can flee the conversation as soon as the animation and sound effect starts playing.
* Go upstairs.

==== Beorunna's Well: Drinking House Upstairs ====

* Go to Lillian's room (the furthest one on the left after you enter the main area).
* Do an Instant Rest (by Resting a couple of seconds after casting Time Stop in single segment, or if resets are allowed, starting to rest, then saving and reloading).
* Cast Extended Invisibility Sphere (resting causes the old one to time out).
* Talk to the Pedestal, spamming 1. There's a few seconds of delay between the end of the conversation and entering the Snow Globe; don't be fooled into thinking you screwed up the conversation.

==== Snow Globe ====

* Start by turning left, then run round clockwise until you reach the central area. (This is the shorter of the two routes.)
* Enter the cave.

==== Snow Globe Cave ====

* Run up to the dragon. Cast Holy Aura on yourself before the fight starts (this is a pre-emptive backup strategy for if Time Stop runs out early or you can't land a melee hit), then Time Stop. Spam Harm until you pierce the spell resistance; then cast Bull's Strength and Divine Power and attack in melee. Eventually either you'll hit, or the dragon will hit you, and either will kill the dragon.
** Segmented: You can do this fight with just Holy Aura and Harm (in that order), but this requires a lot of luck (Harm has to hit, and the dragon has to attack you in melee).
* Once either the dragon is dead, or else it has taken fatal damage and is only alive due to Time Stop preventing it dying, run over to the chest, wait for Time Stop to end if it hasn't already, then open the chest.
* Loot any items from the chest you want (you probably don't want any, but if you're critically low on gold after buying Time Stop scrolls, take the gold so that you can afford to unrecall throughout the rest of the game), then take the Word of Power (this spawns Haedraline to force conversation with you, so you need to do it last).
** Something to consider: This chest should spawn a guaranteed top-tier weapon for you, but it doesn't because you have Weapon Focus (greatsword) and a greatsword doesn't fit in the chest. This probably doesn't matter much, as the Greatsword +1 you've had nearly all game works just fine on this route.
* Go through Haedraline's conversation (spamming 1 works on this one), then recall out (don't be tempted to step into the portal, it's slower). You can't recall until the conversation ends naturally.

==== Beorunna's Well: Temple of Tyr ====

* Time to make two copies of the Word of Power; this is substantially more complex than making one copy, because there is no known way to do the plot item duplication glitch if two copies of the item already exist in the game.
* Run over to the divining pool; drop the original Word of Power, then buy a copy from the divining pool.
* Leaving the original on the ground, leave the area.

==== Beorunna's Well ====

* Enter Aarin's lodge via the nearer door (you'll have to open it, as you left via the other door).

==== Beorunna's Well: Aarin's Lodge ====

* Turn in the duplicate Word of Power to Aarin.
* Recall out (you have to leave the house first, because it's flagged no-recall for some reason).

==== Beorunna's Well: Temple of Tyr ====

* Pick up the original Word of Power, and drop it again.
* Buy a duplicate Word of Power from the divining pool.
* Pick up the original Word of Power again.
* Unrecall out (I think this is faster than just running to Aarin).

==== Beorunna's Well: Aarin's Lodge ====

* Cast Divine Trickery; there's a Persuade check you need to pass, and your natural Persuade score isn't high enough to guarantee passing (the odds seem to be a little better than 50:50).
** Segmented: You don't ''need'' the Persuade bonus if you can use luck manipulation to ensure you pass the check; it's certainly not a remote chance.
** Resets allowed: Because you can do the Instant Rest glitch without Time Stop in this category, you have more Persuade ranks because you need fewer ranks for Use Magic Device. This means that it's probably better to just risk the roll unbuffed.
* Turn in the two Words of Power. Persuade a bonus reward from the last Word you turn in (the third altogether); it's three Potions of Heal, which will potentially save a noticeable amount of time later on between the Aribeth and Maugrim fights (where you can't rest without recalling or backtracking), and/or allow recovery from problems in the Morag fight. This ends the chapter.

=== Chapter 4 ===

==== Castle Never ====

* Talk to Lord Nasher at least until you reach the "generic questions" part of the conversation; this is required to unlock the door.
* Do an Instant Rest to replenish Harm charges. Even the full seven is not always enough to guarantee success at the Balor/Aribeth/Maugrim gauntlet; trying to do it with fewer in a single-segment run is just foolhardy. If you're feeling really confident and have six charges left, you can go for it, but you'll lose much more time than you saved if the luck doesn't work out.
** Segmented: Assuming you used a minimum of spells earlier, resting probably isn't necessary. You might want to memorize a second copy of Bull's Strength over one of the redundant copies of Negative Energy Ray earlier in the run in order to account for the lack of a rest here.
* Cast Extended Invisibility Sphere.
* Leave through the main door of the castle.

==== City Core ====

* Cast Bull's Strength now; it lasts for ages, you'll want it against Maugrim, and casting it early means you also get the marginal benefits it has for the other fights in this chapter.
* While running, quickbar the Potions of Heal over Summon Creature I.
* Run forwards past the Hall of Justice and the Great Tree, then turn about 45 degrees to the left and run into the far left corner of the map.
* Enter the War Zone via running to the left of the two soldiers and impaled corpse; otherwise, you tend to get stuck.

==== War Zone ====

* Run along the road that goes approximately forwards until you reach the dividing wall.
* Turn right, then enter the first house on the left.
** Untested: It may be possible to get through the gate directly using a combination of Divine Trickery, extra Open Lock ranks, and Thieves' Tools. It's unclear if there's anywhere you could buy a set of Thieves' Tools +10 without losing more time than this would save, though. I believe that they can be manipulated out of the 6th Floor Portal Stone chest in chapter 6, but that would only be useful in a segmented run, because you've already decided how to allocate your skill ranks at that point in a single-segment run and so couldn't take advantage of a random Thieves' Tools drop. A Potion of Cat's Grace is also worth an effective point or two of Open Lock.
** Untested: Is it possible to buy a scroll of Knock without losing time, and get through the gate that way?

==== Old Man's Home ====

* Run to the back bookshelf and open it.

==== War Zone ====

* You spawn facing backwards again, which is something to take note of as you start running in the area; using the mouse may help. Note, however, that the ''camera'' is facing in the correct direction; it's just the character that's facing the wrong way.
* Follow the only path to the burnt-out building; then run over that building to the intact building beyond, and enter via the door in the left-hand side as you look at it.

==== Luskan Guardhouse ====

* Buff up with Protection from Elements, Extended Divine Power, and Holy Aura.
* Open and go through the door. (It's trapped, but Protection from Elements will tank most of the damage; and you want all the HP you can get through here in case something goes wrong in the Aribeth fight.)

==== War Zone ====

* Spam Harm at the Half-Dragon Baalor until it lands. Then spam melee attacks until it dies, either due to it hitting you or due to you hitting it. Casting Time Stop makes this fight more reliable, but potentially slows you down if it takes too long to wear off.
** Segmented, untested: With a freakishly lucky roll, you can kill this enemy using a single use of Finger of Death (it needs a natural 1 on its save, ''and'' you have to bypass its spell resistance). It shouldn't be beyond the limits of what you can manipulate. The issue is finding a Finger of Death scroll in the first place, although it's probably possible to manipulate one out of a chest.
* Run through the portal; you want to take on Aribeth with your buffs still active.

==== Maugrim's Sanctuary ====

* Run up to Aribeth and let her talk to you. If you don't, this can break her script in a way that will probably get you killed.
** Untested: It might be possible to use Time Stop to break her script in a way that gets ''her'' killed instead, which would be preferable.
* Cancel the conversation via casting Harm on Aribeth. Spam it until it breaks her SR. (If you fail to break her SR, there is a decent chance she'll kill you, because she knows about the Harm + finisher combo too. In such a case, your only real backup strategy is to respawn.)
* Once you land Harm, don't bother with a finisher; Aribeth will surrender, and can't be killed in this state.
* It's faster to save Aribeth than kill her after she surrenders (she has ''far'' too many charges of Heal and isn't afraid to use them). The correct conversation path is to spam 1 until you get the option to Lie on 1, then follow with 212 and resume spamming 1. I'm not convinced that it's possible to fail the Persuade check involved here at your current stats; this particular route through the conversation gives the easiest Persuade check possible to save Aribeth. (Do ''not'' screw up this conversation; the resulting fight will run you so low on Harm charges that you will probably run out before your next chance to rest.)
* Heal up with a Potion of Heal.
* Remember the cloak you equipped back in Chapter 1e? That comes into play now, because it allows you to tank paralysis effects from traps. Combined with the Protection from Elements that should still be active (because you haven't been hit by the same element multiple times since you cast it), you can tank the unavoidable acid+paralysis trap in the route onwards to Maugrim. Once the route splits, take the leftmost direct route to avoid hitting further traps.
* Once you are near Maugrim, cast Time Stop. (You need to do this before his conversation trigger, or you get into a Time Stop war that lasts ages and normally causes him to reanimate extra enemies, which is an almost unwinnable situation with this build.)
* Spam Harm at Maugrim until it sticks.
* If Extended Divine Power has worn out, recast it. Then melee attack Maugrim until you hit. (Holy Aura does not work in this fight; being a spellcaster, Maugrim doesn't melee you anyway, so you can't get a retributive attack in.)
* Open the chest and loot the Word of Power and the upgrade to your current greatsword. (It is guaranteed to contain an upgrade to your greatsword, but ''which'' upgrade is random. There's no real reason not to upgrade, anyway.)
* Recall out.

==== City Core: Hall of Justice ====

* Leave via the main entrance.

==== City Core ====

* Head back to the castle where you started.

==== Castle Never ====

* Head towards the dungeons (go almost to the room where you started, then turn right).

==== Castle Never Dungeons ====

* Run through to the level below. You don't have to talk to anyone; in particular, there is no need to talk to Haedraline.

==== Castle Caverns ====

* Quickbar Lesser Dispel (over Divine Trickery) while you're running in this area.
* Do an Instant Rest (mostly for Harm charges, but you also need to ensure you aren't low on HP right now because you're highly likely to take moderately large amounts of damage against the Corrupted Dragons).
* Run to the Word of Power Pedestals, and place your Word of Power on the unlit one.
* Cast Extended Invisibility Sphere, then enter the Source Stone.

==== Source Stone Sanctuary ====

* Run to the end of the level. (I like to ensure the minimap is open for this, as it's easy to get lost.) There's a nasty trap just before the portal; you want to keep along the right-hand wall in that area to avoid taking damage from it.
* Before entering the portal, buff up with Holy Aura (the only buff you need for the area; you also need fear immunity, but the boots you equipped in Chapter 1e provide that).

==== Source Stone Guardian Lair ====

* Run forwards for about 1 second, then cast Time Stop.
* Cast Harm at the dragons until it sticks.
* There isn't much you can usefully do in the remaining duration of Time Stop; I like to buff my melee attack and then try to melee them to death, but this doesn't actually save any time. (Incidentally, you can't safely cast Holy Aura ''during'' Time Stop because it gives you less time to cast Harm, and that sometimes matters if Time Stop happens to roll a low duration. You would do things in that order in a segmented run, though.)
* The dragons will melee attack you and die to the retributive damage.
* Loot the keys off the dragons, and use them to open the gates.
* Before leaving the area, Instant Rest to heal up (mostly for Harm charges). Then cast Extended Invisibility Sphere and move onwards.

==== Source Stone Inner Sanctum ====

* There are two possible strategies for the first part of this fight:
*# Original strategy (''probably'' faster, but a lot can go wrong):
*#* Run up to the first door, cast Extended Divine Power, then open the door and Harm+melee the Old One Cleric.
*#* Run up to the next door. You can't open it because you're missing a key, but it'll get you far enough from the enemies that you can (and should) break combat by casting Extended Invisibility Sphere.
*#** Segmented: It's faster to swap this step with the next one, but this will cause you to take ''much'' more damage, and you'll probably die as a result. So that strategy is segmented-only without huge buffs to AC (as are available on, e.g., no-large-skips or 100%).
*#* Run back to the Old One Cleric's deathdrop, and loot the Key.
*#* Open the large door. If there are any nearby Old Ones, you may need to close it again to stop them following you into the fight.
*# Newer strategy (much more reliable for single-segment):
*#* Run up to the first door. Open it, run past the cutscene trigger (otherwise it screws with your controls) then cast Time Stop, Extended Divine Power, Harm at the Old One Cleric, and melee to do the remaining damage (you'll need to watch the combat log, as you can't see it die during Time Stop).
*#* Run back the way you came, round the corner.
*#* Once you're safely round the corner, wait for Time Stop to end (if it hasn't already ended), then immediately cast Extended Invisibility Sphere.
*#* Run back into the fight, loot the Key, and run into the next section. If you've done things correctly, none of the enemies should know where you are, and so you won't be attacked.
* '''Bash''' down the door before Morag, even though you can open it normally. This sets your "in combat" flag and breaks her script. It possibly breaks differently in patched to unpatched, but in unpatched it's particularly useful because it causes the fight to not start until you're ready. (And in patched, you shouldn't be using this route,
* Get past the blade barrier. There are three methods to do this, from the riskest to the least risky (I normally try the second):
** Try to run past it before it spawns. This is possible with a low probability, based on the interaction between timers. If you fail this, you die.
** Make it temporarily disappear using Lesser Dispel, then run past it before it respawns. This is more likely to work than the previous case, but also capable of instakilling you through bad randomness, as the respawn will take a random length of time from 0 to 6 seconds. Note that if you cast Lesser Dispel within about 1 second of it spawning and you're near enough (within about twice the distance the Statue is from the barrier), you're guaranteed to have enough time to run past it before it respawns, because the spawn and respawn are on the same timer.
** Kill the Statue with melee attacks and wait for it to despawn. This is 100% safe, but takes ages.
* Kill the Protector Against the Lessers using Harm (until it sticks) then Negative Energy Ray.
* Cast Negative Energy Ray at Morag (to cause her to teleport to your current location). You may want to precede this with Holy Aura to hedge against emergencies (in particular, Morag entering melee mode; she doesn't normally, but you can run out of Negative Energy Ray due to spell disruption if she does, and then you'll have to rely on a backup strategy).
* Kill Morag with Harm (until it sticks) then Negative Energy Ray. If it doesn't stick quickly, Morag may cast Time Stop, in which case you can just wait for it to finish then continue Harm spam.
** Backup strategy: If something goes wrong with your normal boss kill strategy, cast Divine Power, then kill the Protector Against the Sword and try to melee Morag to death, healing as necessary.
* After killing Morag, stay where you are; the exit portal should spawn almost on top of you, about where Morag teleported to.

==== Astral Pocket ====

* Spam transition clicks on the portal in order to skip Haedraline's conversation.

Neverwinter Nights/Mechanics and Glitches

2014-09-03T20:23:55Z

Ais523: /* Time Stop + Rest */ to /* Instant Rest */: we found a new and much more generally useful setup for this, possibly obsoleting the old setup

== Game Mechanics ==

=== Timing rules ===

There are basically three sorts of action you can perform in Neverwinter Nights:
* Standard actions, like attacking and casting spells, have two lag periods, a shorter one which prevents you performing standard actions or moving, and a longer one that just prevents you performing standard actions. (Typical times for these lag periods are on the order of 2 seconds and 4 more seconds, respectively). As such, if you want to cast a lot of spells before a battle or the like, it's best to space them apart in time somewhat; the casting will happen just as fast as it would if you were standing still, but you'll be able to combine it with your movement. A good example is the divine casting trial in the Prelude; you need to cast a Cure spell, and Turn Undead (which internally implemented as a spell), and you get several seconds of running between them (which are best spent walking from the Injured Man back towards the door).
* Movement. You can move around with WASD or clicking at almost any time, apart from the short lag period after a standard action (or while entangled, paralysed, etc.). However, this will cancel any queued actions you have at the time. The reverse is not true: you can order a long move (via clicking on a distant target), then queue up other actions to perform after it completes. The cancelling-other-actions effect is sometimes useful; for instance, pressing W is the fastest way to cancel a rest (you can start giving useful orders faster after pressing W than after manually clicking on the "cancel rest" button, which is also a pretty small target). Another way to move is to give melee-only actions (like "open door" or "attack") on distant targets; this is similar to moving up to the target then performing the action, but it doesn't cancel queued actions. So on the "hit the gongs in sequence" puzzles in Chapter 3, you can get a perfect time just by clicking on all the gongs faster than the character can reach them, causing the character to run to the next gong as soon as a gong is hit.
* Conversation and changing equipment. These actions happen instantaneously, so long as you aren't in combat and don't have an action queued, and the game isn't paused. (Some equipment slots can be changed even when in combat, so long as you aren't in either lag period after a standard action). There is '''no lag''' after these actions; you can spam equipment changes and conversation items as fast as you can input them. Starting and resetting conversations (you reset a conversation via clicking on the person you're conversing with) can be done even while the game is paused; this is essential to one of the major glitches. Other similar actions cannot be performed while the game is paused, but can be pause-buffered; in order to get through a conversation quickly in in-game time, you can pause the game, select an option from the conversation, quickly hit Space twice, and repeat. This is slower in terms of the time you actually get for the run, but sometimes necessary to finish a conversation before you get attacked (forcing you into combat) or before an enemy despawns.

== Glitches ==

=== Plot item duplication ===

Works on: unpatched, Diamond

Effect: If you have the only copy in the game universe of an item flagged as "essential to the plot", gain a second copy of it (if it's unsellable, for 1gp).

How to perform: Drop your plot item (preferably near a Divining Pool; this isn't necessary to the glitch, but makes it faster to perform). Go to a Divining Pool (there's one near each Recall target point), which should now sell you a second copy of the item. Then pick up the original.

Uses: The main (and probably only) use of this glitch is to sequence-break past most of Chapters 2 and 3. You can duplicate a cultist's journal in Chapter 2 (probably the Charwood Cultist's; it's the fastest to obtain), then use both copies to immediately unlock the gate to Luskan. Chapter 3 can be broken a similar way, but the glitch is a little harder to perform because you need three Words of Power to complete the chapter; you'll have to turn in the duplicate Word of Power to Aarin (leave the original on the ground), then pick up and drop the original in order to get a second duplicate (allowing you to turn in the second duplicate and the original to complete the chapter).

You can duplicate plot items in Chapter 1, but it isn't useful; Aribeth won't accept the same reagent twice.

=== Item and experience farming in Chapter 1e ===

Works on: unpatched, Diamond

Effect: Gain multiple copies of the quest reward items from the Guardian of Helm quest in Chapter 1e (both the "good" and "evil" paths), and arbitrarily large experience.

How to perform: After completing the Guardian of Helm quest (either by completing the summoning of the demon, or banishing it and summoning the Guardian in its place), and gaining the quest rewards, resetting the conversation works and allows you to get the rewards again, but only for 3 in-game seconds. Pause-buffering the conversation will let you get the item rewards several times; the experience reward happens right at the start of the conversation, so you can just reset the conversation repeatedly to gain arbitrary experience.

Uses: The Guardian of Helm quest is less than a minute off the fastest route in Chapter 1e, and can farm you enough experience for the whole run, and enough gold (via saleable items) to at least get through Chapter 2.

Notes: The number of items you can get depends on your alignment. When using the demon (which is faster and has better item rewards), Good has less text than Neutral, which has less text than Evil; so being of a more Good alignment will allow you to farm more items in those 3 in-game seconds you have. However, being more Evil means you get more experience per click, so although you get less gold, you save time farming experience. The best of both worlds is to be Chaotic Evil for the demon (or Lawful Good for the Good route through the quest); this gives you the fastest possible experience gain rate, but also gives you a double item reward from the conversation (which is badly bugged; it shows two "Continue" options, you need to take the first).

You can farm experience faster by using two mice (say, a mouse and a touchpad), and spamming clicks with both hands.

=== Gold farming at the start of Chapter 1 ===

Works on: unpatched

Effect: Gain 100gp from conversation, an unlimited number of times.

How to perform: Ask Aribeth if she'll answer some questions, then for a reminder on how to use the Stone of Recall. Then go through the conversation naturally.

Uses: Although this is a relatively slow method of gold farming, it's available so early that it can get you through early-game purchases. In particular, it can allow you to afford henchmen and Recalls until you've defeated Meldanen.

=== Immunity exploits ===

Works on: unpatched

Effect: Damage enemies that are meant to be invulnerable.

How to perform: Use a spell whose damage type is not physical nor one of the standard elements (fire, cold, electricity, acid, sonic). Good examples include Horrid Wilting (works on all such enemies, as far as I know), and Harm (won't work in the endgame, will work elsewhere).

Uses: You can combine Harm and Negative Energy Ray to sequence-break the Creator Race Ruins in chapter 3, but the current any% route doesn't go there. Horrid Wilting can also work as a decent backup strategy for the Protectors during the final boss, but it won't oneshot them unless they make their save.

=== DetermineCombatRound breaking ===

Works on: unpatched, Diamond

Effect: An enemy is hostile to you, but does not attack you unless you actively provoke them.

How to perform: This is only possible due to mistakes in an enemy's script; "turn hostile" (i.e. reputation changes) and "enter combat AI" (DetermineCombatRound in the code) calls are separate, and sometimes the code has different triggers for one than the other. In particular, the final fight against Morag starts her combat AI loop when attacked or via conversation, and you can break the conversation via being in combat at the time, such as via bashing the door next to her at or just before the instant she tries to force conversation.

A more minor version of this glitch causes several plot enemies (e.g. Callik, Klauth) to waste their first round of combat if you initiate combat yourself via spellcasting (possibly also via other means), meaning you get two tries to land a particular spell on them before being attacked back.

Uses: You can deal with Statue and the Protectors as you wish before Morag starts fighting, making the boss fight much easier. Once that's been done, you can start the fight correctly by using any attack on Morag (ranged attacks work best as she teleports across the room after being attacked, and you can make her teleport to your position).

There are mixed reports about reproducing this glitch on Diamond; it is definitely possible to glitch Morag out, but may require a more complicated setup (one theory is that the timing is more precise and thus you have to be on the other side of the door for the glitch to work).

=== Instant Rest ===

Works on: unpatched, untested on Diamond

Effect: Get the full effect of a Rest (hitpoint gain, spell and ability refresh) in 6 seconds rather than 30.

How to perform: There are two known ways to do this. One is to cast Time Stop just before resting (the exact timing is unknown, but a likely guess is that it's one short action lag). The other is to save and reload the game just after resting (again, you need to wait some short length of time for this to work, but not very long). You need to meet all the other conditions for Resting to be legal (i.e. neither you nor any member of your party has been in combat recently, you haven't been damaged recently, and there are no enemies nearby).

Uses: All the reasons you'd normally Rest (notably: planned healing; emergency healing to recover from a fight going wrong; refreshing spells).

=== Dispel Area ===

Works on: unpatched

Effect: Suppress ''any'' area effect, either for a short length of time or permanently.

How to perform: Cast any dispel effect (Lesser Dispel is the most easily obtainable) centred on the area effect.

Uses: If doing the Silver Sails route through the Docks, destroy the web that normally entangles you; this is permanent. (However, the Silver Sails is avoided on any% routes because it's so much slower than the alternative.) Suppress the barrier in the final boss fight that normally instakills you; however, this only lasts for a random time between 0 and 6 seconds, making this glitch quite risky (if it doesn't go down for long enough, you will die running across it unless it happens to roll very low on its damage).

Neverwinter Nights/Mechanics and Glitches

2014-09-03T20:19:25Z

Ais523: /* Final boss script break */ renamed to /* DetermineCombatRound breaking */: this is more general than we thought

== Game Mechanics ==

=== Timing rules ===

There are basically three sorts of action you can perform in Neverwinter Nights:
* Standard actions, like attacking and casting spells, have two lag periods, a shorter one which prevents you performing standard actions or moving, and a longer one that just prevents you performing standard actions. (Typical times for these lag periods are on the order of 2 seconds and 4 more seconds, respectively). As such, if you want to cast a lot of spells before a battle or the like, it's best to space them apart in time somewhat; the casting will happen just as fast as it would if you were standing still, but you'll be able to combine it with your movement. A good example is the divine casting trial in the Prelude; you need to cast a Cure spell, and Turn Undead (which internally implemented as a spell), and you get several seconds of running between them (which are best spent walking from the Injured Man back towards the door).
* Movement. You can move around with WASD or clicking at almost any time, apart from the short lag period after a standard action (or while entangled, paralysed, etc.). However, this will cancel any queued actions you have at the time. The reverse is not true: you can order a long move (via clicking on a distant target), then queue up other actions to perform after it completes. The cancelling-other-actions effect is sometimes useful; for instance, pressing W is the fastest way to cancel a rest (you can start giving useful orders faster after pressing W than after manually clicking on the "cancel rest" button, which is also a pretty small target). Another way to move is to give melee-only actions (like "open door" or "attack") on distant targets; this is similar to moving up to the target then performing the action, but it doesn't cancel queued actions. So on the "hit the gongs in sequence" puzzles in Chapter 3, you can get a perfect time just by clicking on all the gongs faster than the character can reach them, causing the character to run to the next gong as soon as a gong is hit.
* Conversation and changing equipment. These actions happen instantaneously, so long as you aren't in combat and don't have an action queued, and the game isn't paused. (Some equipment slots can be changed even when in combat, so long as you aren't in either lag period after a standard action). There is '''no lag''' after these actions; you can spam equipment changes and conversation items as fast as you can input them. Starting and resetting conversations (you reset a conversation via clicking on the person you're conversing with) can be done even while the game is paused; this is essential to one of the major glitches. Other similar actions cannot be performed while the game is paused, but can be pause-buffered; in order to get through a conversation quickly in in-game time, you can pause the game, select an option from the conversation, quickly hit Space twice, and repeat. This is slower in terms of the time you actually get for the run, but sometimes necessary to finish a conversation before you get attacked (forcing you into combat) or before an enemy despawns.

== Glitches ==

=== Plot item duplication ===

Works on: unpatched, Diamond

Effect: If you have the only copy in the game universe of an item flagged as "essential to the plot", gain a second copy of it (if it's unsellable, for 1gp).

How to perform: Drop your plot item (preferably near a Divining Pool; this isn't necessary to the glitch, but makes it faster to perform). Go to a Divining Pool (there's one near each Recall target point), which should now sell you a second copy of the item. Then pick up the original.

Uses: The main (and probably only) use of this glitch is to sequence-break past most of Chapters 2 and 3. You can duplicate a cultist's journal in Chapter 2 (probably the Charwood Cultist's; it's the fastest to obtain), then use both copies to immediately unlock the gate to Luskan. Chapter 3 can be broken a similar way, but the glitch is a little harder to perform because you need three Words of Power to complete the chapter; you'll have to turn in the duplicate Word of Power to Aarin (leave the original on the ground), then pick up and drop the original in order to get a second duplicate (allowing you to turn in the second duplicate and the original to complete the chapter).

You can duplicate plot items in Chapter 1, but it isn't useful; Aribeth won't accept the same reagent twice.

=== Item and experience farming in Chapter 1e ===

Works on: unpatched, Diamond

Effect: Gain multiple copies of the quest reward items from the Guardian of Helm quest in Chapter 1e (both the "good" and "evil" paths), and arbitrarily large experience.

How to perform: After completing the Guardian of Helm quest (either by completing the summoning of the demon, or banishing it and summoning the Guardian in its place), and gaining the quest rewards, resetting the conversation works and allows you to get the rewards again, but only for 3 in-game seconds. Pause-buffering the conversation will let you get the item rewards several times; the experience reward happens right at the start of the conversation, so you can just reset the conversation repeatedly to gain arbitrary experience.

Uses: The Guardian of Helm quest is less than a minute off the fastest route in Chapter 1e, and can farm you enough experience for the whole run, and enough gold (via saleable items) to at least get through Chapter 2.

Notes: The number of items you can get depends on your alignment. When using the demon (which is faster and has better item rewards), Good has less text than Neutral, which has less text than Evil; so being of a more Good alignment will allow you to farm more items in those 3 in-game seconds you have. However, being more Evil means you get more experience per click, so although you get less gold, you save time farming experience. The best of both worlds is to be Chaotic Evil for the demon (or Lawful Good for the Good route through the quest); this gives you the fastest possible experience gain rate, but also gives you a double item reward from the conversation (which is badly bugged; it shows two "Continue" options, you need to take the first).

You can farm experience faster by using two mice (say, a mouse and a touchpad), and spamming clicks with both hands.

=== Gold farming at the start of Chapter 1 ===

Works on: unpatched

Effect: Gain 100gp from conversation, an unlimited number of times.

How to perform: Ask Aribeth if she'll answer some questions, then for a reminder on how to use the Stone of Recall. Then go through the conversation naturally.

Uses: Although this is a relatively slow method of gold farming, it's available so early that it can get you through early-game purchases. In particular, it can allow you to afford henchmen and Recalls until you've defeated Meldanen.

=== Immunity exploits ===

Works on: unpatched

Effect: Damage enemies that are meant to be invulnerable.

How to perform: Use a spell whose damage type is not physical nor one of the standard elements (fire, cold, electricity, acid, sonic). Good examples include Horrid Wilting (works on all such enemies, as far as I know), and Harm (won't work in the endgame, will work elsewhere).

Uses: You can combine Harm and Negative Energy Ray to sequence-break the Creator Race Ruins in chapter 3, but the current any% route doesn't go there. Horrid Wilting can also work as a decent backup strategy for the Protectors during the final boss, but it won't oneshot them unless they make their save.

=== DetermineCombatRound breaking ===

Works on: unpatched, Diamond

Effect: An enemy is hostile to you, but does not attack you unless you actively provoke them.

How to perform: This is only possible due to mistakes in an enemy's script; "turn hostile" (i.e. reputation changes) and "enter combat AI" (DetermineCombatRound in the code) calls are separate, and sometimes the code has different triggers for one than the other. In particular, the final fight against Morag starts her combat AI loop when attacked or via conversation, and you can break the conversation via being in combat at the time, such as via bashing the door next to her at or just before the instant she tries to force conversation.

A more minor version of this glitch causes several plot enemies (e.g. Callik, Klauth) to waste their first round of combat if you initiate combat yourself via spellcasting (possibly also via other means), meaning you get two tries to land a particular spell on them before being attacked back.

Uses: You can deal with Statue and the Protectors as you wish before Morag starts fighting, making the boss fight much easier. Once that's been done, you can start the fight correctly by using any attack on Morag (ranged attacks work best as she teleports across the room after being attacked, and you can make her teleport to your position).

There are mixed reports about reproducing this glitch on Diamond; it is definitely possible to glitch Morag out, but may require a more complicated setup (one theory is that the timing is more precise and thus you have to be on the other side of the door for the glitch to work).

=== Time Stop + Rest ===

Works on: unpatched, untested on Diamond

Effect: Get the full effect of a Rest (hitpoint gain, spell and ability refresh) in 6 seconds rather than 30.

How to perform: In an situation where you can legally rest, use Time Stop. Just after you finish casting it (I don't know the exact timing, but suspect it's the end of the short lag), press Rest. The Rest ends immediately, as does the Time Stop.

Uses: Getting effectively unlimited spells through Chapters 3 and 4.

=== Dispel Area ===

Works on: unpatched

Effect: Suppress ''any'' area effect, either for a short length of time or permanently.

How to perform: Cast any dispel effect (Lesser Dispel is the most easily obtainable) centred on the area effect.

Uses: If doing the Silver Sails route through the Docks, destroy the web that normally entangles you; this is permanent. (However, the Silver Sails is avoided on any% routes because it's so much slower than the alternative.) Suppress the barrier in the final boss fight that normally instakills you; however, this only lasts for a random time between 0 and 6 seconds, making this glitch quite risky (if it doesn't go down for long enough, you will die running across it unless it happens to roll very low on its damage).

Neverwinter Nights/Mechanics and Glitches

2014-08-17T01:34:07Z

Ais523: add more glitches

== Game Mechanics ==

=== Timing rules ===

There are basically three sorts of action you can perform in Neverwinter Nights:
* Standard actions, like attacking and casting spells, have two lag periods, a shorter one which prevents you performing standard actions or moving, and a longer one that just prevents you performing standard actions. (Typical times for these lag periods are on the order of 2 seconds and 4 more seconds, respectively). As such, if you want to cast a lot of spells before a battle or the like, it's best to space them apart in time somewhat; the casting will happen just as fast as it would if you were standing still, but you'll be able to combine it with your movement. A good example is the divine casting trial in the Prelude; you need to cast a Cure spell, and Turn Undead (which internally implemented as a spell), and you get several seconds of running between them (which are best spent walking from the Injured Man back towards the door).
* Movement. You can move around with WASD or clicking at almost any time, apart from the short lag period after a standard action (or while entangled, paralysed, etc.). However, this will cancel any queued actions you have at the time. The reverse is not true: you can order a long move (via clicking on a distant target), then queue up other actions to perform after it completes. The cancelling-other-actions effect is sometimes useful; for instance, pressing W is the fastest way to cancel a rest (you can start giving useful orders faster after pressing W than after manually clicking on the "cancel rest" button, which is also a pretty small target). Another way to move is to give melee-only actions (like "open door" or "attack") on distant targets; this is similar to moving up to the target then performing the action, but it doesn't cancel queued actions. So on the "hit the gongs in sequence" puzzles in Chapter 3, you can get a perfect time just by clicking on all the gongs faster than the character can reach them, causing the character to run to the next gong as soon as a gong is hit.
* Conversation and changing equipment. These actions happen instantaneously, so long as you aren't in combat and don't have an action queued, and the game isn't paused. (Some equipment slots can be changed even when in combat, so long as you aren't in either lag period after a standard action). There is '''no lag''' after these actions; you can spam equipment changes and conversation items as fast as you can input them. Starting and resetting conversations (you reset a conversation via clicking on the person you're conversing with) can be done even while the game is paused; this is essential to one of the major glitches. Other similar actions cannot be performed while the game is paused, but can be pause-buffered; in order to get through a conversation quickly in in-game time, you can pause the game, select an option from the conversation, quickly hit Space twice, and repeat. This is slower in terms of the time you actually get for the run, but sometimes necessary to finish a conversation before you get attacked (forcing you into combat) or before an enemy despawns.

== Glitches ==

=== Plot item duplication ===

Works on: unpatched, Diamond

Effect: If you have the only copy in the game universe of an item flagged as "essential to the plot", gain a second copy of it (if it's unsellable, for 1gp).

How to perform: Drop your plot item (preferably near a Divining Pool; this isn't necessary to the glitch, but makes it faster to perform). Go to a Divining Pool (there's one near each Recall target point), which should now sell you a second copy of the item. Then pick up the original.

Uses: The main (and probably only) use of this glitch is to sequence-break past most of Chapters 2 and 3. You can duplicate a cultist's journal in Chapter 2 (probably the Charwood Cultist's; it's the fastest to obtain), then use both copies to immediately unlock the gate to Luskan. Chapter 3 can be broken a similar way, but the glitch is a little harder to perform because you need three Words of Power to complete the chapter; you'll have to turn in the duplicate Word of Power to Aarin (leave the original on the ground), then pick up and drop the original in order to get a second duplicate (allowing you to turn in the second duplicate and the original to complete the chapter).

You can duplicate plot items in Chapter 1, but it isn't useful; Aribeth won't accept the same reagent twice.

=== Item and experience farming in Chapter 1e ===

Works on: unpatched, Diamond

Effect: Gain multiple copies of the quest reward items from the Guardian of Helm quest in Chapter 1e (both the "good" and "evil" paths), and arbitrarily large experience.

How to perform: After completing the Guardian of Helm quest (either by completing the summoning of the demon, or banishing it and summoning the Guardian in its place), and gaining the quest rewards, resetting the conversation works and allows you to get the rewards again, but only for 3 in-game seconds. Pause-buffering the conversation will let you get the item rewards several times; the experience reward happens right at the start of the conversation, so you can just reset the conversation repeatedly to gain arbitrary experience.

Uses: The Guardian of Helm quest is less than a minute off the fastest route in Chapter 1e, and can farm you enough experience for the whole run, and enough gold (via saleable items) to at least get through Chapter 2.

Notes: The number of items you can get depends on your alignment. When using the demon (which is faster and has better item rewards), Good has less text than Neutral, which has less text than Evil; so being of a more Good alignment will allow you to farm more items in those 3 in-game seconds you have. However, being more Evil means you get more experience per click, so although you get less gold, you save time farming experience. The best of both worlds is to be Chaotic Evil for the demon (or Lawful Good for the Good route through the quest); this gives you the fastest possible experience gain rate, but also gives you a double item reward from the conversation (which is badly bugged; it shows two "Continue" options, you need to take the first).

You can farm experience faster by using two mice (say, a mouse and a touchpad), and spamming clicks with both hands.

=== Gold farming at the start of Chapter 1 ===

Works on: unpatched

Effect: Gain 100gp from conversation, an unlimited number of times.

How to perform: Ask Aribeth if she'll answer some questions, then for a reminder on how to use the Stone of Recall. Then go through the conversation naturally.

Uses: Although this is a relatively slow method of gold farming, it's available so early that it can get you through early-game purchases. In particular, it can allow you to afford henchmen and Recalls until you've defeated Meldanen.

=== Immunity exploits ===

Works on: unpatched

Effect: Damage enemies that are meant to be invulnerable.

How to perform: Use a spell whose damage type is not physical nor one of the standard elements (fire, cold, electricity, acid, sonic). Good examples include Horrid Wilting (works on all such enemies, as far as I know), and Harm (won't work in the endgame, will work elsewhere).

Uses: You can combine Harm and Negative Energy Ray to sequence-break the Creator Race Ruins in chapter 3, but the current any% route doesn't go there. Horrid Wilting can also work as a decent backup strategy for the Protectors during the final boss, but it won't oneshot them unless they make their save.

=== Final boss script break ===

Works on: unpatched, partially on Diamond

Effect: Prevent the final boss fight from starting properly, allowing you to kill enemies individually rather than having to fight them all at once.

How to perform: Instead of opening the door before Morag, bash it down. Then run near her as you run through the room.

Uses: You can deal with Statue and the Protectors as you wish before Morag starts fighting, making the boss fight much easier. Once that's been done, you can start the fight correctly by using any attack on Morag (ranged attacks work best as she teleports across the room after being attacked, and you can make her teleport to your position).

On Diamond, this glitch has been partially patched, but still appears to break the enemy AI to some extent (and in a way that benefits the player)

=== Time Stop + Rest ===

Works on: unpatched, untested on Diamond

Effect: Get the full effect of a Rest (hitpoint gain, spell and ability refresh) in 6 seconds rather than 30.

How to perform: In an situation where you can legally rest, use Time Stop. Just after you finish casting it (I don't know the exact timing, but suspect it's the end of the short lag), press Rest. The Rest ends immediately, as does the Time Stop.

Uses: Getting effectively unlimited spells through Chapters 3 and 4.

=== Dispel Area ===

Works on: unpatched

Effect: Suppress ''any'' area effect, either for a short length of time or permanently.

How to perform: Cast any dispel effect (Lesser Dispel is the most easily obtainable) centred on the area effect.

Uses: If doing the Silver Sails route through the Docks, destroy the web that normally entangles you; this is permanent. (However, the Silver Sails is avoided on any% routes because it's so much slower than the alternative.) Suppress the barrier in the final boss fight that normally instakills you; however, this only lasts for a random time between 0 and 6 seconds, making this glitch quite risky (if it doesn't go down for long enough, you will die running across it unless it happens to roll very low on its damage).

Neverwinter Nights/Mechanics and Glitches

2014-08-17T01:24:45Z

Ais523: list some mechanics and glitches

Neverwinter Nights

2014-08-17T00:48:37Z

Ais523: add cats

* [[/Version differences|Version differences]]
* [[/Routes|Routes]]
* [[/Mechanics and Glitches|Mechanics and Glitches]]

[[Category:Games]]
[[Category:PC]]

Neverwinter Nights/Version differences

2014-08-17T00:47:53Z

Ais523: mention the basic differences between unpatched and diamond; I'm still annoyed at diamond being faster, but I guess it's my own fault for discovering plot item duplication

If you're playing the original campaign, there are two main categories: Unpatched (version 1.11 seems to be the one that everyone owns), and Diamond (i.e. a version with all expansions installed). For obvious reasons, playing the expansion campaigns can only be done on Diamond.

== Unpatched ==

Several glitches are only possible on unpatched Neverwinter Nights, or work better without patches. In particular, you can skip the golems in the Creator Race Ruins Past because they're missing several important immunities. However, this is not a huge advantage: in the current any% route, the places where unpatched gets a large time advantage are mostly not on the route anyway (not even on the unpatched route).

Unpatched games do not have an Appraise skill. This makes prices more consistent; Diamond can get lower prices than unpatched, but only with luck. So for a single-segment run, unpatched gives you less chance of losing a lot of time through bad luck.

The most notable feature of unpatched, though, is a bug in speed stacking. It is impossible to get a speed of faster than base Haste speed (i.e. 50% faster than normal) via any means whatsoever. This reduces the benefit of movement speed enhancers; by Chapter 2, once you get Haste, anything else that might boost your movement speed is irrelevant.

== Diamond ==

Although many glitches are fixed on Diamond, it is most notable for its speed stacking rules; there is no longer a speed cap, and there are more ways to boost your speed, so a standard setup would be something along the lines of Monk + Expeditious Retreat + Haste (Expeditious Retreat does not exist in unpatched). In general, there is more content available in the game, but the actual mandatory parts of the game are the same as in unpatched. This means that in Diamond, you move faster and have more options.

Despite many glitches being fixed on Diamond, the two most important (experience/item farming in Chapter 1e and plot item duplication) are still unfixed.

Neverwinter Nights/Routes

2014-08-17T00:37:21Z

Ais523: copy in the routing notes I made offline

== Any%, unpatched, single segment ==

This route was designed by ais523 for an any% completion on an unpatched (1.11) version of Neverwinter Nights. Because unpatched versions have a speed cap that is easy to hit, there is not much point in building for movement speed beyond Chapter 1 (like you would do on a patched version), so this route instead builds towards early Invisibility and fast boss kills. It tries to rely only on high-probability events, so as to be safe for use in a single-segment run.

Where low-probability events could save time, I'll try to point them out, to be useful to players playing segmented. Much of the advice is also applicable to other routes, but it focuses on the Cleric route because that's what I know and practice. Likewise, I'll also try to point out advice suitable to other categories (e.g. 100%, no-major-skips, glitchless) at appropriate points, even if this isn't a guide to them.

Directions here will be given relative to your running direction, because I play using Chase Cam. You might need to translate them if you use a Top Down camera.

=== Starting Character ===

* Gender: irrelevant
** Reasoning: There is only one gender-specific effect that is potentially relevant in an any%, which is saving Aribeth. It is faster to save her than to kill her; but it is also faster to do so via Persuade check than via the romance sub-plot, negating the reason to play male.
* Race: Human
** Reasoning: Quick to Master is more useful than any of the ability adjustments; this route is tight on skills, and wants three feats before hitting level 6. This also makes some conversations a little easier/faster.
* Alignment: Chaotic Evil
** Reasoning: This impresses the demon in Chapter 1E, meaning you get a double reward from the glitched conversation, each time round the glitch. This more than makes up for the extra text, especially as it gives a useful item that would not otherwise be reliably obtainable.
* Starting Role: Cleric
** Reasoning: You need Invisibility (available at Cleric [Trickery] 3) by the start of chapter 1, thus at level 3. This means the first three levels must all be in Cleric.
* Abilities: Str 16 / Dex 8 / Con 12 / Int 8 / Wis 18 / Cha 14
** Reasoning: The most important abilities are Wis (for spellcasting) and Str (for DPS). Raising them to 16 (the highest reasonable value) leaves 8 improvement points. A higher Charisma helps prevent Turn Undead whiffing, which can really damage the run. The remaining points go in Con, because we have enough skill points even at Int 8, and Dex does not anything but Reflex (mildly important early on) and AC (on this route, much more than a +2 to AC would be needed to make a noticeable difference).
** Segmented: With less feat pressure, it's worth considering moving points away from Cha. However, this is untested, so this might cause problems down the line.
* Skills: Open Lock 1 [cost 2], Persuade 4, Lore 2
** Reasoning: None of these skills become relevant until Chapter 1 (or later in the case of Lore), so we pre-place the skill points where they will later be needed to save time levelling up. We need 1 point of Open Lock and as many points of Persuade as possible in Chapter 1; we need no other skills until Chapter 2, which also needs Use Magic Device (unbuyable) and Lore, so we pre-place points there to save a marginal amount of time.
* Feats: Weapon Proficiency (martial), Lightning Reflexes
** Reasoning: Being able to wield a greatsword gives us much better DPS early than we could otherwise manage. There is one unavoidable Reflex check in Chapter 1 that saves noticeable time if we pass it, so the bonus from Lightning Reflexes increases the chance of getting it in a single-segment.
** Segmented: You don't need Lightning Reflexes in a segmented run; instead, you'd manipulate the 5% chance of hitting the Reflex check in question naturally. It's unclear which feat to replace it with, though.
* Domains: Trickery, Plant
** Reasoning: Trickery gives access to Invisibility, which is very useful on speedruns. The second domain is less obvious. Plant gives access to Creeping Doom, which is used to help with two of the boss fights, and Turn Vermin, which helps marginally in chapter 1. It is possible that some other domain could serve the same purposes more efficiently, but this is currently unexplored.

=== Prelude ===

==== Senior Barracks ====

* Either run round Pavel, or let him talk to you then cancel the conversation via clicking on Bim.
* You must talk to Bim to open the door, but he will open it immediately upon choosing option 2 in the conversation. You can run to the door using the mouse during the conversation to save a marginal amount of time.

==== Training Halls ====

* The correct sequence to skip Olgerd's tutorial without opening the shop is 1112113211. (It may be marginally faster to skip the tutorial and open the shop in the process, but that leaves windows that need closing.)
** Glitchless: Not that this route works glitchless past Chapter 1, but if you want to use this route for a glitchless route in Chapter 1, you want to raise at least 50 gold via selling items to Olgerd. The only item in your inventory right now that will save you any time at any point of the run is your starting mace.
* You need to rest and memorize spells while still in the first room. Otherwise, you are too close to "enemies" (actually, the targets that register the Warrior training) for the rest to succeed. You need to do so now because spellcasting is required to complete the Divine Caster training, which is faster than the alternatives.
* You can start resting and rearrange spells during the rest. Level 1 spells are refreshed at approximately 40% and again at 100%. You want to have them all in place by 40% so that you can cancel the rest, saving over 15 seconds of waiting.
* Which spells you memorize is mostly unimportant because the only spellcasting you ''need'' to do is spontaneous. I memorize two copies of Endure Elements and one copy of Bless; all these spells are needed at the start of Chapter 1, so it saves on menuing later. Additionally, Bless is helpful in the Prelude itself.
* Once the spells are memorized, start sorting out the quickbar so you can see when the level 1 refresh happens. After memorizing your L1 spells, drag any of them to an empty quickbar slot as fast as possible. As soon as it stops being greyed out, cancel your rest using <code>W</code>. (If you don't manage this in time – which is entirely possible, because the timing is quite tight – just reset, this is the second room of the game.) Place all the L1 spells you need during the entire run on the quickbar: Bless, Endure Elements, Summon Creature I, Spontaneous Cure Light Wounds.
* Run to the Divine Caster training using the keyboard. While you're doing that, you can arrange your quickbar how you want it using the mouse. There should be enough spare time to also wield your mace. All of this can be done in parallel with movement; generally speaking, in this game, you want to, as much as possible, be moving with one hand and menuing with the other.
* Complete the Divine Caster training (cast Spontaneous Cure Light Wounds at the injured man, and Turn Undead at the skeleton; Turn Undead is on the quickbar by default). Turn Undead will reach the skeleton from most places in the room; the correct place to cast it from is thus next to Elynwynd towards the door, and the correct time is after Spontaneous Cure Light Wounds due to the 6-second lag between non-movement actions (you have plenty enough time to get into position after healing the man). However, it is far from guaranteed to succeed. You need luck to complete this room quickly, as a result. (Of course, this is still the second area of the game, so you can just reset if something goes wrong.)
* Talk to Elynwynd and, while running out of the room, advance the conversation by one screen in order to gain Chainmail. This will be your armour throughout chapter 1.
* Start a conversation with the Door Guard. You don't actually have to go through the conversation to get into the next area, just start it.

==== Graduation Chamber ====

* This is your only chance to equip your armour without losing time, but the naive method (using the keyboard to move and the mouse to equip it) is prone to accidentally cancelling the "equip" action, because keyboard movement cancels everything. The better method is to use action queueing with the mouse. Click on Aribeth to start a talk action with her, and your character will start running towards her. Then open the inventory (<tt>I</tt> on the keyboard) and quickly equip the Chainmail and the Small Shield (the fastest way to equip an item is to drag the right mouse button away from it to the right, or to the left for an offhand item like a shield; avoid doing this in a shop, because that will sell the item instead). The equip actions will be queued behind the talk action, with the result that as soon as the conversation starts, your equipment will change instantly (you're not in combat). Conversations also close the inventory window.
* Mash 1 to get through the conversation with Aribeth quickly.
* This starts a fight, which is impossible to lose (the enemies will never attack you personally and cannot injure Aribeth, who will eventually finish them all no matter what). However, there are ways to make it much faster or slower. The important thing is to help out the low-level NPCs in the room, who will usually get slaughtered; and in particular, you want to help the ones furthest from Aribeth (nearest the door), because they are the most likely to die, and attacking the enemies that are least likely to die early. My current technique is to cast Bless so as to hit myself and the two groups of NPCs nearest the door, then attack the Unknown Mage in the near left corner as you enter the room (the far right as you look from Aribeth's location towards the door). Once he's dead, help out the other group of NPCs near the door (who are normally either dead or nearly dead at that point). If you're lucky, Aribeth will finish the fight in the process. Otherwise you might have to wait a few seconds, or even help her.
** Warning: Do not cast Summon Creature I in this fight, even though it seems appropriate. The badger will spend too long buffing itself to help in the fight, and it will influence the encounter tables, increasing the chance you get obstructed in the following corridors.
* When the fight ends, you want to be near the door, as Aribeth will run towards you, and you can't talk to her until she's out of combat. She'll rarely run all the way to the door, but you can lure her quite some distance during otherwise unusable time. Once she stops moving, click on her repeatedly until the conversation starts. The inability to talk to people during combat, combined with the game's definition of "combat", is frustrating; but don't worry, we can turn it to our advantage much later in the run.
* Once the conversation starts, start mashing 1, but also start running towards the door (using the mouse). The conversation can continue while you're running, as long as you don't get too far away, and if you mash 1 fast enough you'll finish it in time.

==== Training Halls ====

* You can just run to the next area during the cutscene, meaning you shouldn't be attacked. I love the way Neverwinter Nights does cutscenes (in particular, the fact that you can move around during them).

==== Academy ====

* Just like in the previous area, run to the next room during the cutscene.
* Ignore Pavel; nothing forces you to talk to him and he doesn't help enough to be worth the time the conversation takes.
* The faster route out of Pavel's room is east (the left of the two doors in the corner).
* Run around the Tough Goblin, and the set of three Weak Goblins. There is some randomness in the way they spawn; it is possible that you will need to kill one or more of them to get through.
* Speak to Geldar to get an immediate experience boost to level 2. (Nice of the game to give you a free level just so it could teach you how to level up.) I believe (but am not 100% sure) that this conversation is flagged so that it can be started even during combat. Run towards the door, and while running, level up. (You need to do the levelling up substantially before you reach the door, or it won't open.) For some reason, I'm in the habit of mashing 1 during this sequence even though it doesn't help at all (it doesn't hinder either).

Level 2:
* Role: Cleric
** Reasoning: Cleric is required to get Invisibility by the start of Chapter 1.
* Skills: postpone buying
** Reasoning: You'll level up again before the next time your skills become relevant, so postponing buying them saves time trying to find them in the menu.

* While running, you can use the time to memorize your fourth Level 1 spell in order to save time at the start of Chapter 1. This should be Summon Creature I, if you memorized Endure Elements twice and Bless once as recommended above.
* Don't take any side passages; you want to go straight down the corridor, take the turn to the right as the corridor turns, dodge the group of goblins (again, if you're unlucky with the way they spawn you might have to fight one or two of them), and open the door in front of you when the corridor splits to the left and right. (This is the fastest route through the area.)
* Something easily missed and very important in the room beyond the door you just opened: there are two large stone pillars near you in the room, and the obvious route is to run between them, but you want to run to the right of both of them instead. This postpones getting into the Mysterious Mage's line of sight as long as possible, greatly increasing the chance that he only gets one round of actions against you. If he gets two rounds, which is reasonably likely if you run between them (still possible, but much less likely, if you run to the right), you will probably die. Just run past him and out the door to the next area.

==== Stables ====

* It is likely some enemies will follow you into this room. Any undead who turn up can be ignored; Fenthick will Turn Undead and one-shot them. It is normally fastest to focus on the goblins near Fenthick and Desther first, because they do less damage to nearby targets (they punch them) than to distant targets (who get shot with a crossbow). You do more damage than anyone else here; Coup de Grace anything that gets hit with a paralysis effect, and otherwise just melee things to death (the points in Str you bought are pretty useful here). If low on health, you might want to heal; you should have one spontaneous cast of Cure Light Wounds available for the purpose (in addition to potions). Or you might prefer to just risk not getting hit.
* After the fight, you can start the first conversation by talking to either Fenthick or Desther. Pay attention to whoever was in combat more recently, and talk to the other. If you aren't sure, just try to start conversation with both of them until it works.
* The first conversation here can be completed just by spamming 1. The second conversation is harder and I frequently mess it up; you want to spam 1 until you get a screen with exactly two options, then press 2. If you miss it, you might actually have to read the options you're given to work out which one you need to take (it's the one where you agree to meet Fenthick within the week).
* The fastest way to proceed is to click on the door to Chapter 1 and level up while your character is running to it, but it's possible to mess this up. If you have to level up in Chapter 1 instead, don't worry; it's only marginally slower.

Level 3:
* Role: Cleric
** Reasoning: You need Invisibility.
* Skills: Persuade +2 (=6), 2 points postponed
** Reasoning: This is your last chance to buy skills at Cleric costs until after Chapter 1 has finished, and a high Persuade score saves you time in the Alaefin fight. 6 is the highest value a level 3 Cleric can set their Persuade to. There's no benefit to buying other skills, as they're either already high enough, or would not be useful before the next time we level up.
* Feats: Weapon Focus (greatsword)
** Reasoning: Even with your high Strength, you have problems hitting during the Chapter 1 boss fights. This gives enough of an edge to make those fights quicker. (Note that it also totally screws up the loot you get from one fight in Chapter 3, which I'll point out when it happens, but this is a comparatively small price to pay.) By the way, you can't legally buy this as a level 1 Cleric, so if you want to buy this and have it useful in chapter 1, it must be at this specific level-up.

=== Chapter 1 ===

* To skip the cutscene when SafeMovie=1 (required for it to render correctly on Windows XP or higher, which you are probably using), press the spacebar. (This took me an annoyingly long time to figure out.)

==== City Core: Sanatorium ====

* You can just run past Fenthick. The conversation will naturally cancel once you're far enough away from him.
* Use the time before you reach Aribeth, during the Aribeth conversation, and perhaps in the next area, to adjust your spells; conversations cancel the inventory window but not spell arrangement. You need to memorize your level 2 spells: two copies of Invisibility and one of Bull's Strength. Also place them on the quickbar (you can overwrite Spontaneous Cure Light Wounds, you're not going to need it for the rest of the run).

==== City Core: Hall of Justice ====

* Do not cancel the Aribeth conversation: if you do, you will not have enough gold to complete the City Core section of the run. In fact, you want to perform the Aribeth gold glitch once (ask her about the Stone of Recall when you get a chance to ask her questions); this hardly costs any time and is necessary in single-segment because otherwise you won't get enough gold.
** Segmented: You don't need to perform the gold glitch (even though it only takes a few seconds and makes things much easier), because you're lucky and (this no longer being single-segment) can perform reset glitches.
* Before leaving the room (as this is an any%, leave it towards the City Core, the other options are for optional sidequests), open the inventory and quickbar the Stone of Recall. Conversations make this awkward to do in future rooms, and doing it right now means your inventory will close naturally.

==== City Core ====

* Bethany will bug you every time through here unless you end the conversation naturally. The fastest method, therefore, is the "run away while spamming 1" option used on Aribeth in the prelude. I find it easiest to use the keyboard to move and the mouse to talk, for this conversation (typically the spell memorization window is still open at this point, which makes it hard to find something to click on to move with the mouse).
* Go towards the Trade of Blades. The extra DPS and Concentration interruptions added by a henchman save a huge amount of time over the course of Chapter 1.

==== City Core: Trade of Blades ====

* Hire Daelan.
** Segmented: You will need to persuade Daelan down to 175 in order to be able to afford to hire him. (As this is segmented, you may as well aim for 150; it's not particularly unlikely with your current stats. Persuading him below 150 is impossible.)
** Glitchless: You will need to persuade Daelan down to 175 in order to have enough gold in the Meldanen boss fight.
** I like to Persuade Daelan down to at least 175 even in other circumstances, because I think it doesn't waste time if the check succeeds, which it usually does, and having the extra gold can help later on (I have literally been just a few gold pieces short of something I needed before now).
* Rest to restore your L1 and L2 spells. You can cancel your rest once those spells are restored (press <tt>W</tt>). Then use the Stone of Recall to recall out.
** Rationale: We want Daelan for every chapter 1 boss fight, as he has the highest DPS. This would make it fastest to do the Docks first (he's right next to them), but that turns out to be untenable on this route due to issues with weaponry and experience, and in general due to issues with gold. So it's faster to recall out in order to get to the other end of City Core more quickly. If you have particularly slow loading screens and aren't subtracting them from timing, it might be faster to just walk out of the door.

==== City Core: Hall of Justice ====

* Leave towards the City Core.

==== City Core ====

* Run towards Blacklake. While doing this, tell Daelan to stand ground (with the mouse, you can do this via right-dragging; with the keyboard, press <tt>VWX</tt>). This is necessary to stop him taking damage in No Man's Land.
* Just open the gate leading into Blacklake; the guard will protest, but he won't stop you.
* Before going through, cast Invisibility on yourself.
** Segmented: You can go without this cast of Invisibility if you're very lucky through the next area; its only purpose is to prevent you being hit, and each single enemy is relatively likely to miss, it's the cumulative effect that's the problem.

==== Blacklake: No-Man's-Land ====

* Just run through to the Barricades via the shortest route. Daelan will be perfectly safe while in stand-ground mode. The enemies here will all ignore you while you're invisible (unless you attack them).

==== Blacklake: Barricades ====

* Talk to the captain to request entry to Blacklake. With your current statistics, the shortest conversation path is 141. (This can differ with other characters.)

==== Blacklake ====

* Run round to the front entrance of Meldanen's (i.e. round to the right, up the ramp, then to the left). This is around the same speed to enter as the back entrance is, but puts you much nearer to your goal once you've gained entry. There's plenty of time for menuing while doing this; a good use for it is to quickbar L2 spells that will be used later in the run (Negative Energy Ray and Hold Person). There should still be some time spare, which I use to examine NPCs just for fun. Perhaps there's a better use.
* Talk to Orrean. This conversation is normally difficult and has no guaranteed route for most characters, but as a high-strength human, 22111 is both very short and guaranteed to let you in. (This is another good reason to play a human, by the way.) The requirement to be human might or might not be a mistake in the code, incidentally, because there's no reason given in the dialogue for why being human should matter.
* Enter Meldanen's estate through the front door.

==== Blacklake: Meldanen's Estate ====

* Talk to Grommin, mashing 1 to get through the conversation; this is the fastest way to unlock the door to the next area. This requires a Persuade check to get him to unlock the door; however, with our Persuade modifier of +8, I am not convinced it is even possible to fail it, and I never have done in practice. If you do fail it, it should be possible to click on Grommin to reset the conversation and try again.
* You have time to cast two spells while Grommin is opening the door. One of them should be Endure Elements on Daelan; you won't get a chance to do this elsewhere without losing time. For the other, I like to cast Bull's Strength on Daelan, but am not 100% certain he is the best target for it (it might be faster to cast it on yourself). Then go down the corridor that Grommin opened.
** Segmented: One of the spells needs to be Invisibility on yourself, if you didn't cast it earlier.
* While running down the corridor, continue casting the spells you need for the Meldanen fight. Remember that although casting spells prevents you moving for only 3 seconds or so, you can only cast one spell every 6 seconds, and so it is best to space them out in time.
* The list of spells that need casting in this area (either at the door, or while running):
** Endure Elements on Daelan
*** Rationale: Otherwise, Meldanen often kills him with Cone of Cold. In a segmented run, you could probably skip this.
** Endure Elements on yourself
*** Rationale: Ditto.
** Bull's Strength on Daelan
*** Rationale: For the DPS. Casting it on yourself might or might not be better; I'm not sure.
** Invisibility on yourself
*** Rationale: If you don't refresh this, it will run out at a very inconvenient time, and you may well die as a result.
* Go through the second-last door on the corridor. Then continue forwards and open the door in front of you (at the other side of the room).
* This corridor is trapped; you'll need to weave first left, then right, to avoid the traps.

==== Blacklake: Meldanen's Sanctum ====

* Run forwards (east) through the first room; take the door opposite you, not the side door. This route is more difficult than the other, but has a pretty notable reward on it: there is a guaranteed Greatsword +1 on the weapon rack in the second room (with the fire beetles). Take and equip this weapon. You will be using it all game. (This is why the character bought two greatsword-related feats.)
* In the next room, press up against the shelf on your left to avoid a trap (use the keyboard). There is only a small amount of leeway to avoid triggering the trap.
* Enter the boss arena. There are basically two strategies that can be used for this:
** Recall drop (does not rely on glitches, legal in single-segment-without-resets, costs 50gp): run towards the dryad to spawn Meldanen. Then run back towards Meldanen and recall out. Cast Summon Creature I and Bless (both for DPS purposes), then use the Recall portal to enter the fight. As soon as you arrive, declare an attack on Meldanen with the mouse, and type VWE with the keyboard to get the rest of your party to also declare attacks (this works outside turn order and perception order, so is faster than waiting for them to join the fight naturally, and is also required because Daelan's still in stand ground mode).
** Reset glitch (is a glitch, requires a reset, costs no money): Reset and reload the game. This warps Daelan into the room. Then cast Summon Creature I and Bless, whilst typing VEE to take Daelan out of stand ground mode, and run towards the dryad to spawn Meldanen.
* During the fight itself, your aim is to melee-lock Meldanen: every time he tries to cast a spell, you want either you or Daelan to hit him hard enough to knock him out of the spellcast. A recall drop makes this easier to pull off, because your party is nearer to him at the start of the fight. However, the reset glitch leaves his AI more predictable (he is very likely to cast Cone of Cold if the melee lock breaks, quite possibly killing the badger, and wiping your party if he casts it twice), whereas with a recall drop, more or less anything could happen, and some possibilities (e.g. Ghoul Touch) will massively slow down your run. That said, I normally go for the recall drop, but which method is better depends on your segmentation discipline, timing method, and how lucky you feel.
* When Meldanen surrenders, you should normally just force-attack him; this gives the most gold out of any of the non-massively-time-consuming options and is also probably fastest. Loot the master key (for plot progression), the gold (why you do this area first), and the staff (for selling). Be very careful when looting; you can collect loot by clicking on it, but if your click is interpreted as a drag, the item won't be looted and you'll have to go back for it. You can look at the message area to see if this has happened; it won't show the "Acquired Item:" message.
** Backup strategy: If the fight goes badly wrong (e.g. Daelan dies), you will not be able to reliably win the fight. You can get all the relevant rewards but the Staff of Meldanen through dialogue: ask him to make you an offer, then accept the gold and the dryad. This is awkward to do because there are so many choices on the conversation menu (I haven't worked out the required numbers because of that; I think there's even an 8 in there somewhere).
* Unlock the door to the Dryad's prison, then talk to her. The fastest route through the conversation is to type 23 then to recall out of the conversation. (Don't worry about her, I checked the scripts, and the Dryad takes the opportunity to walk to safety after you unexpectedly leave.)

==== City Core: Hall of Justice ====

* While running to the door to the City Croe, expel Daelan from your party (right-click on him in the party list, then click top-left and bottom-right). He's going to die and respawn here anyway if you don't, but making him leaves serves two purposes: altering the experience formula (thus making it possible to get enough experience to hit level 4 in the Beggar's Nest overworld), and preventing him forcing you into combat and thus leaving you unable to have conversations.
** Untested: In my current route, I also unsummon a badger here if I have one, but I suspect this is incorrect strategy; it needs to be unsummoned before the next kill to influence experience, but it is probably better to keep it around until the next spawn trigger so that more enemies spawn, then unsummon it then, possibly meaning slightly less of a detour would be needed for experience grinding, and likely meaning that the odds of failing to get enough kills would be much lower.

==== City Core ====

* Perform a partial rest to refresh L1 and L2 spells. (Bear in mind that some spells on your quickbar are not memorized, so they won't refresh at all. Also, try not to cancel the rest after just the L1 spells have refreshed, with the L2 spells missing; I do that far too often.)
** Segmented: It may be possible to do without the spell refresh here, although that would mean doing Blacklake and the Beggar's Nest in one Invisibility charge each. Blacklake is possible like this if you're lucky enough; the Beggar's Nest is more difficult on one charge, but possibly not by enough that skipping the rest is slower.
* Go to the Beggar's Nest. Like Blacklake, you can just walk through the door despite the guard's protests. (All the main areas work like this.)

==== Beggar's Nest ====

* You need to grind to level 4 in this area, and you do that via 5 casts of Turn Undead (i.e. about 15 seconds out of your way for the casting, plus maybe 30 seconds or so because not all the locations are precisely on your route). The first two locations (before you temporarily go to a different area) are:
** Turn left as you enter; you reach an intersection with a sewer grate behind and to your right, and paths forwards and to the left. You want to cast Turn Undead at the point where the path to the left opens up and starts to expand into the main area. This is almost exactly on your route.
** Then take the path in front of you (not the path to the left), and turn left towards Jemanie's house. Use Turn Undead to kill the three zombies outside it. This is exactly on the route.
* Enter Jemanie's house at this point.

==== Beggar's Nest: House ====

* Talk to Jemanie. As soon as the conversation starts, immediately click on the entrance door while mashing 1. If you hear one "quest complete" sound effect, followed by three "journal updated" sound effects, you mashed fast enough; this is not particularly difficult. The developers tied a lot of quests to this area for some reason. You should end up running out of the door with all the required quest advancement, taking hardly any time.

==== Beggar's Nest ====

* Here are the other three Turn Undead locations:
** Leave Jemanie's house to the north-east (i.e. the direction you were going before you entered it). Warning: the door to the house is attached backwards (a mistake the developers occasionally made when connecting areas), so you will need to use the mouse to turn immediately after leaving). To the north-east of that house (i.e. to the right of your path) is a small building-like cluster. Run round the right side of it, letting the zombies follow you, and go towards the locked entrance to the Great Graveyard. Cast Turn Undead in the chokepoint just before the area with the sewer grate. This is a few seconds off the route, but worth it for the huge amount of experience it gains you.
** Run round to the north-west corner of the building-like cluster, and cast Turn Undead there; this should kill the zombies that started following you as you ran round it, plus the zombies attacking the nearby citizen. This is the fastest route, given the detour you just took.
** Run just beyond the entrance to the cultist hideout and cast Turn Undead there, killing the zombies on the far side of it. This is only about a second away from the fastest route.
* Before interacting with the Hideout itself, cast Invisibility on yourself. You need to cast it to get through the next area anyway, and
* Open the door to the Cultist Hideout, and go through the conversation. This is worth 50 experience. If you killed all but one of the zombies in range of these five Turn Undead blasts, you should have had at least 5950 experience and so levelled up as a result.
** Backup strategy: If you don't have enough experience yet (i.e. you missed more than one zombie, or perhaps failed to kill Meldanen earlier), you can make the time up by killing zombies either now, or in the Great Graveyard a few rooms from now. Open the character sheet to see how much experience you have; zombies give this character 75 each, so you need one more kill if you're on 5925 or more (5875 if you haven't opened the door yet), two if on 5850 or more (5800 if you haven't opened the door yet), three if on 5775 or more (5725 if you haven't opened the door yet). The most likely zombies to miss are at the Great Graveyard entrance; this can happen due to bad dice rolls. Also, note that (unless doing a single segment without resets) you can reset glitch to restore your Turn Undead charges.

Level 4:
* Role: Barbarian
** Rationale: Barbarian Fast Movement gives the greatest time gain in Chapter 1 of anything you could purchase with this level. A Monk's fast movement scales higher, but starts smaller, so the Barbarian's boost is more useful for a 1-level splash. The rage can be occasionally useful, too.
* Ability: Wisdom
** Rationale: It actually doesn't matter whether you put this in Wisdom or Strength (odd ability scores function pretty much identically to the even scores one point lower), but I got into the habit of doing the Wisdom boosts before the Strength boosts.
* Skills: postpone buying
** Rationale: Barbarians have an awful skill point price list. It's better to wait until we can get skills at reasonable prices.

* Enter the estate.

==== Beggar's Nest: Snake Cult Estate ====

* Run to the exit via the shortest (only) route; your invisibility will prevent any enemies perceiving you. Quickbar Barbarian Rage while running.

==== Beggar's Nest: Crypts ====

* This is another "run to the exit via the shortest route", but that route is a little non-obvious and full of traps that will ruin your run (either due to long-duration paralysis or very heavy damage), so it's written in full here.
* Leave the first room through the corridor to your right.
* In this corridor, run along the left-hand side at least up until the collapsed wall section (which will prevent you continuing along the left-hand side), to avoid a trap. Don't take the branch to the left; the door there is locked right now.
* As the corridor bends to the right, take the corner very tightly, and stay near the right wall until it opens up into a room.
* Pull the lever near the cultists to unlock the door in the corridor you passed by earlier.
* Retrace your steps back to the junction. This means running along the left hand side of the corridor leaving the room (the corridor you entered by, but now you're going in the other direction), then keeping to the right just after the collapsed wall.
* The corridor opens up into a room, then collapses back into a corridor. The first bend in that corridor must be taken ''very'' wide to avoid a massively damaging trap; you're pretty much running along the outside wall.
* Then go to the left and through the door to leave the area.

==== Beggar's Nest: Great Graveyard ====

* If you aren't level 4 yet due to mistakes earlier, grind up to level 4 on zombies here (using reset glitch + Turn Undead, or just meleeing them down).
* Refresh Invisibility on yourself: otherwise it'll run out at or near the entrance to Gulnan's room, which makes the fight rather harder as a) she'll start buffing herself early, and b) some of the enemies from outside are likely to follow you into the fight.
* Enter the Warrens through the door to your right.

==== Beggar's Nest: Warrens of the Damned ====

* After the first room, turn right. (I've never actually tested that this is faster, but I assume that it's faster because it's one of the few points where my instincts agree with the existing runs, and I don't have the other route memorized to compare.)
* The way this area works is that there's a large ring with many smaller rooms off it, two of which contain keys, and you need one of the two keys. Thus, you need to open the door in front of you, even though it's a detour off the ring, to get a key. The door just beyond it is trapped; however, it's a pretty weak trap that deals only damage, so just tank the damage. Loot the key off the corpse of Torin.
* Backtrack to the main ring, and continue running round it. (There are no detours/side rooms between here and Gulnan.)
* Run right up to Gulnan, then recall out; we're going to do this fight with a recall drop (this seems to be by far the most reliable method).
* Do a full rest, even though it "wastes" a level 2 spell slot if you rested after Meldanen. This is for health, Turn Undead charges, and Invisibility charges.
* Join back up with Daelan, then cast buffs for the fight. I'm not sure which buffs save time on average, but as Gulnan is the hardest fight in the run (although Callik is more luck-dependent), I prefer to err on the safe side (a segmented run should try to do without some of these):
** Summon Creature I (DPS);
** Bless (DPS);
** Bull's Strength on Daelan (DPS, and to help disrupt Gulnan's casting);
** Endure Elements on yourself and again on Daelan (to mitigate Flame Strike to some extent);
** Barbarian Rage.
* Recall back in, hit VWE, and start attacking Gulnan. It's possible you may have to cast Turn Undead at some point in order to stop them interfering with the fight, but if you're lucky, you can go without.
* Loot Gulnan's heart (for plot advancement) and Scimitar +1 (for money), then recall out.

==== City Core: Hall of Justice ====

* Just leave. We're about to do a combat sequence, and have enough spells remaining (two Invisibility) to take us through to just before Callik, so resting would be counterproductive as it would remove the buffs we set up for Gulnan, but are still useful here.
** Backup strategy: If you got heavily injured in the Gulnan fight, heal at Aribeth.

==== City Core ====

* Head to the Docks. (This gate works like all the others.)

==== Docks ====

* This is the most luck-dependent area, although there are backup strategies almost everywhere. As such, a guide to the route has to be a bit looser than it would be otherwise. The basic idea is to kill enough generic enemies along the shortest path to get 5 Smuggler's Coins. Use Daelan and (if alive) your badger to do most of the killing; you can also kill, but looting is a better use of your time when loot is available. Drop back and/or drink Cure Light Wounds potions if you're running low on health.
* The shortest path is to turn left upon entering, then right, then it's a straight path to the Seedy Tavern. The route starts with a group of three enemies, and then no enemies for a while. There's another group of three near the fountain, and another just beyond them. You should try to avoid combat beyond those three groups, because then Daelan will start running all over the map, preventing you entering conversation. (VEE helps to avoid him running off, if he hasn't already entered combat; if he has, he'll break it off, but that'll just bring the combat to you. Once I have five Smuggler's Coins, I spam VEE in order to try to avoid unwanted combat.)
** Backup strategy: if you don't get five Smuggler's Coins off these nine enemies, you can enter the shop to the right of your route and ''buy'' up to three for 150gp each. The loot from Meldanen and Gulnan should mean you can afford this.
* Bribe your way into the Seedy Tavern (1431).

==== Docks: Seedy Tavern ====

* Buy three Potions of Invisibility and one Potion of Speed from the auctioneer. (You will have to sell some of your loot first to get enough money.) The basic idea behind the Potions of Invisibility is to save having to rest to refresh spells, which saves around 15 seconds; it costs about that in time spent shopping, but I think the ability to buy a Potion of Speed at the same time makes the shopping route faster.
** Segmented: You only need two Potions of Invisibility; the third is a hedge against Peninsula trolling you, and a segmented run can just reset if that happens.
** Untested: It might be worth spending all remaining money (including from saleable items) on Potions of Speed, purely for the running speed boost in the remaining running regions in Chapter 1. This seems like a waste, but probably actually does save time, if only a little.
* Attempt to open the door to the basement, in order to get Daelan to start bashing it. Then bash it yourself at the same time. Chef will go to get help, but you'll be gone before it arrives.
* Skew your route to the left beyond the door, to avoid a trap. Also, press <tt>VWX</tt> during this time; you don't want Daelan and a possible badger running around inside the next area.

==== Docks: Bloodsailor Hideout (B1F) ====

* Cast Invisibility on yourself.
* Run invisibly to the end of the corridor (there's only the one junction, go straight on at that junction), opening the door at the end. Then take the only route down to the next level. As you're invisible, nobody will interfere with this. While running, quickbar the potions you just bought.

==== Docks: Bloodsailor Hideout (B2F) ====

* Cancel your <tt>VWX</tt> (with <tt>VWE</tt> or <tt>VEE</tt>); there's going to be combat here.
* Kill the enemies near Daranei. (You don't need to interact with Daranei herself.) Loot the Instructions from Callik.
* Establish your <tt>VWX</tt> again; Daelan should have killed the Bloodsailor patrolling outside by now, so this area will be undisturbed by enemies.
* Cast Invisibility, then leave past the Bloodsailor Lieutenant (follow the corridor round to the right, go to the end, then through the door at the left). While running, dememorize both castings of Invisibility (you'll use potions for that for the rest of Chapter 1); memorize two castings of Hold Person instead (it should already be on your quickbar). Also dememorize both castings of Endure Elements in favour of Summon Creature I (this is a case of removing something entirely useless in favour of something potentially useful if something goes wrong).

==== Docks ====

* Run round the outside of the building you just left (turning right three times), then head off west towards the Aqueducts.
* Pick the lock to the Aqueducts. (The rank in Open Lock is needed for other reasons too, but this is the reason it had to be bought so early.) Note that the pathing around the door is a little awkward; you might need to manually move closer to the door before you start to pick it. At Dex 8, Open Lock 1, you have a 5% chance of picking the lock, and under Neverwinter Nights rules (which are a corruption of the D&D "take 20" rules), a skill check outside combat and outside conversation always succeeds if it has a nonzero chance of succeeding. Therefore, the lock will always open.

==== Docks: Aqueducts ====

* Start crossing the bridge. The Bloodsailor will attack Daelan (or possibly the badger) as you start to cross. Spam VEE in order to try to keep Daelan alive and out of combat.
* Start conversation with Charon. As soon as you do, pause the game. Pause-buffer this conversation in order to preserve your precious "outside combat" state and Daelan's life; if you don't, you'll enter a fight with a Bloodsailor horde that you will not win, and that will knock you out of conversation.
** Backup strategy: If Daelan dies anyway, recall back to his respawn point in the next area and retrieve him that way. If the conversation is broken, you can try to re-establish it by pausing the game and clicking on Charon again.

==== Docks: Sewers ====

* Rest to regain L2 spells, and perhaps also HP if you or Daelan is badly injured. (In other words, how long to rest depends on your HP.)
* As you run along the corridor, start buffing for the fight:
** Bull's Strength on Daelan
** Summon Creature I
** Bless
* Once inside the room with Callik, move moderately near to him (about to where the room's narowest point is), ten cast Hold Person on him. If it doesn't stick, try again. If it still doesn't stick, you're in trouble, but can try to complete the fight via brute force and recalling when on low HP. Whether it sticks or not, you want to type <tt>VWE</tt> to improve Daelan's reaction time to what just happened, drink the Potion of Speed, then kill the guards first and Callik afterwards. If Callik breaks free of the paralysis and you still have a Hold Person cast left, run back and cast it on him to see if you can make it stick again. If Callik starts attacking you, run behind Daelan until he switches target. If you get disarmed, pick the greatsword back up again. (This is a pretty luck-dependent fight.) In emergencies, recall out to heal, or just die and respawn for the free heal and get teleported back to the fight; the respawn penalty is negligible right now because your wealth is mostly in the form of saleable items you haven't sold yet, and you don't care about experience due to a glitch coming up later.
* There is no need to loot the corpses for anything (there's a saleable Rapier +1 but it's not worth enough to be worth picking up at this point); just run round to Vengaul. He will start conversation automatically, and you must complete the conversation to progress the plot (but mashing 1 works).
* Pick up the Cockatrice Feather, then recall out.

==== City Core: Hall of Justice ====

* Just leave. You might want to request healing for safety if you are critically low on hitpoints, but you shouldn't be; and the potions you bought mean that you don't have to rest just yet.

==== City Core ====

* If you don't have a surviving badger, summon one; you'll need it later.
* Head to Peninsula. (As usual, you can ignore the guard and just open the gate yourself.) On the way, tell Daelan and the badger to stand ground (because I'm running with the keyboard right now, <tt>VWX</tt> wouldn't work, so I use the radial menu instead for the same purpose).

==== Peninsula ====

* Ignore the guard just inside the gate: he doesn't actually do anything if you leave without talking.
* Cast Invisibility from a potion while still near the entrance.
* Head round to the Tanglebrook Estate, using the key under the mat to gain entrance.

==== Peninsula: Tanglebrook Estate ====

* Run to the stairs down. Use Turn Undead (for its Turn Vermin feature) on the Stink Beetles, to get them out of your way. Then go on to the next area. If you're unlucky, this won't work first time, but you can just try again.

==== Peninsula: Tanglebrook Tunnels ====

* Run around the chessboard. It's full of traps.
* Use Turn Vermin to oneshot the fire beetles blocking your path on the distant bridge (you can typically get all five with one blast if you have a good idea of what its area of effect is shaped like). Then go on to the next area.

==== Peninsula: Prison Main Floor ====

* Note that the door to this area is attached backwards, so be careful not to run right back to the previous area.
* Just before the first door, turn invisible via potion. Then open it, pull the Door Lever beyond it, and follow the shortest path (i.e. turn left whenever it isn't an obvious dead end) to the next level. There is just about room for you to slip past the boss of the level (and being invisible, he won't notice).

==== Peninsula: Containment Level ====

* This is the worst level in the entire game for NPCs standing in your way for minutes on end, so some other tactic is needed to mitigate it in a single-segment run. Run forwards to the door in front of where you open. As you enter, tell the badger (specifically) to follow, leaving Daelan where he is (you will need to use the radial menu for this). Pull the lever and open the door opposite where you entered. If you are lucky, the badger will distract the prisoners into walking into locations where they don't block the door, and you can run through. If you aren't, you may have to improvise.
** Backup strategy: The spare Potion of Invisibility is for if you take too long to do this area. If you get blocked for more than 20 seconds or so, you will need to drink it at some point to stop the invisibility wearing off; judge when based on how long you were blocked for.
* At the end of the level, running to the left gives you a very marginally shorter running distance, and running to the right gives you considerably less camera movement. I prefer to go to the right, as I find manipulating the camera harder than running.

==== Peninsula: The Pits ====

* Pull the lever when you enter. Then run through to the end of the area via the fastest route. (Note: I'm not actually 100% sure what the fastest route is, so I'm not listing it here.) Memorize the trap locations to avoid triggering them. Sometimes the enemies will block your path; you can sometimes work around this by using the spare casts of Summon Creature I to distract them.
* The jewelled door (the first one past the doors opened by the last set of door levers) is trapped with a slowing trap, which is annoyingly time-wasting. My current strategy here is to hope that Lightning Reflexes works, or to take the time penalty if it doesn't. It might be possible to pull something off with Potions of Speed to work around this.
* Being invisible, you can just run past Kurdan.

==== Peninsula: Lair of the Devourer ====

* Perhaps unexpectedly and surprisingly, you can ''usually'' rest at the start of this area, without even recalling out. Do so, at least up to L2 spells. (Alaefin will occasionally interrupt the rest via random-walking; often, though, you already have the spells you need regained by that point.)
* Cast Summon Creature I, Bless, and Bull's Strength on Daelan.
** Backup strategy: Recall out, and rest and buff there. This is mostly for use if something goes disastrously wrong, like Alaefin killing Daelan during buffing, because it costs a lot of time.
* If he isn't already, get Daelan into comabt with Alaefin. Then cast Hold Person on Alaefin until it sticks or you run out of charges. Either way, go round rescuing guards until they're all gone; just because you're chaotic evil doesn't mean you have to be ''stupid''. After that, join the fight.
* When phase 2 of the fight starts (i.e. Alaefin dies, revealing the Intellect Devourer), enter rage, and start beating on it along with the rest of your party. The occasional <tt>VWE</tt> doesn't hurt, either. If you aren't very low on HP when this stage of the fight starts, you are almost guaranteed to win it; the devourer does hardly any damage. The rage is thus useful in multiple ways: boosting the Will save means you spend more time attacking and less being mind-affected, and the Strength boost means you hit more often and do more damage.
* Pick up the reagent off the corpse and recall out.

==== City Core: Hall of Justice ====

* Talk to Aribeth, and hand over the reagents. Take care not to accidentally donate your reward to charity; losing the gold is minor (although significant), but losing your Evil reputation would be a lot worse. When she asks you whether to leave right away, accept and end the chapter.
* You will typically level up at this point. There's no real advantage to going through the level up dialogue now, though; better to leave it until after the experience glitch.

=== Chapter 1e ===

==== Ritual Chamber ====

* You have to talk to all the major characters, but you don't have to complete the conversation; just opening up the first screen and moving onto the next person is enough. The exception is that you need to complete the last conversation in the area. This should be Nasher, as his is trivial to complete (14).
* During the following cutscene, cast Summon Creature I for a small amount of bonus DPS in the next fight. Dememorize Hold Person in favour of Negative Energy Ray; this makes menuing in Chapter 1e somewhat easier. Spend the rest of the time rearranging your quickbar. The only slots from it you still need are Negative Energy Ray, Bull's Strength, Summon Creature I, and the Stone of Recall; although in most cases you can just overwrite a quickslot, I find that explicitly emptying them (during time where I have to wait anyway) makes it easier to avoid mistakes where I overwrite the wrong quick slot.
* It also helps to get Daelan over the opposite end of the room to you (which can be accomplished via <tt>VWX</tt> or, to some extent, via the "follow at long distance" dialogue command). You want him picking a different target to you in the ensuing fight, if you can.
* Once the fight starts, try to kill the enemies efficiently (i.e. don't get in the way of NPCs or other party members who are fighting), and in particular, chase down any enemies who try to flee the fight (because the allied NPCs have an annoying tendency to cast fear-based spells).
* With all enemies dead, you must complete the conversation with Aribeth before you can use the portal.

==== Road to Helm's Hold ====

* Run to the next area. While doing so, unsummon the badger (which will almost certainly be alive at this point), and tell Daelan to leave the party; you have no combat until the Desther fight, and that fight is complex enough without the ally AI messing it up further.
* You can just ignore the Strange Visage.

==== Courtyard ====

* Run to and use the side entrance on the right. This is not only the shortest path to where you need to go, it also lets you avoid combat, as you will avoid stepping on the spawn trigger for the enemies who are meant to be in this area.

==== Helm's Hold (1F) ====

* Turn left upon entering, go through the door, then turn right at every opportunity after that until you come to a bookshelf. Take the Black Grimoire from it. For the only time in the run, we're doing a sidequest for experience.
* Use the Black Grimoire to complete the summoning on the nearby altar.
* Now talk to the demon, who has a very glitched conversation:
** First, go through the conversation normally (use 111131 because it gives the best rewards for a chaotic evil character). The conversation is not over at that point, but it has reached a point at which you get maximum benefit from starting the glitches. Note that the final "1" is one of two options saying "Continue"; this conversation is more glitched than many people realise. You get an unidentified cloak and unidentified boots from this.
** Warning: the rest of the glitches with the conversation must be completed within three in-game seconds. This requires very heavy pause buffering (to pause-buffer a conversation, you have the game paused, and select an item via pressing the digit, then very quickly hitting Space twice). This limits how much you can gain from the glitches.
* First up is an item glitch. Pause the game, then click on the demon to reset the conversation (this causes the "despawn" sound effect and animation but the despawn is delayed three in-game seconds), then pause-buffer 111131 to get the reward again. Then do this two more times (for a total of four sets of rewards). This is the maximum that seems to be possible within three in-game seconds, given the amount of text in the resulting dialogues.
* Next is an experience glitch. With the game paused, just click on the demon repeatedly; you get experience for every click (because as it happens, the experience is granted in the first node of the conversation, meaning that the game doesn't need unpausing at all). You can double the speed of this by using both a mouse and a touchpad and mashing with both hands. Gain enough experience to reach level 17. (The game will start lagging because every click also causes a separate despawn animation to be drawn, but the lag won't be visible until you unpause it, and will only last a few seconds.)
* You can (and should) level up with the game still paused, so that if you fell short on experience, you can go glitch yourself some more.

Levels 5-16:
* Role: Cleric
** Rationale: We're trying to gain access to various Cleric spells that let us completely break boss fights. The highest-levelled of these is Aura versus Alignment, at level 8, meaning we need 15 levels (12 more levels) of Cleric to cast it. Additionally, this means we hit a total level of 17, which gives the most ''expensive'' random drops from chests (level 16 gives the most ''useful'' random drops, but we can't rely on any particular drop in a single-segment, so instead we just hope for expensive saleable items).
* Ability: Wisdom, Strength, Strength
** Rationale: We need to pump Wisdom to 18 to cast Aura versus Alignment. The remaining points go into Strength for carry capacity (which can matter if our random loot items happen to be very heavy), and DPS (marginally useful, but more useful than the benefits of higher Wisdom).
* Skills: postpone buying
** Rationale: We need to buy skills at level 17, and doing all the buying at once makes menuing easier
* Feats: Still Spell, Extend Spell, Spell Penetration, Toughness
** Rationale: Still Spell and Extend Spell both let us adjust spell levels in order to avoid clashes and memorize more copies of a spell than we would otherwise be able to. Extend Spell is generally better, as many of our spells have awkwardly short durations, but it doesn't work on all spells, so we need a second metamagic feat for that purpose. Spell Penetration makes the run both safer and faster because in many fights, SR checks are the ''only'' randomness involved, and a bonus to beating SR checks is thus very welcome. Toughness is mostly just filler, but filler that can occasionally save a run that would otherwise take just a little too much damage.

Level 17:
* Role: Rogue
** Rationale: We need a role that can both equip Monk-specific items, and cast Sorceror/Wizard-specific spells. Rogues have the ability to do those, within limits that we can make high enough.
* Skills: Use Magic Device 13, Lore +18 (=20), Persuade +7 (=13)
** Rationale: 13 points of Use Magic Device, plus a Charisma of 14, lets us cast Time Stop even if it's in a large stack of scrolls, meaning that we don't need to constantly waste time working around a bug in the game just to cast Time Stop. (If not for the bug, 8 would be enough). Maxed Lore gives us the best possible chance of identifying items on the run, rather than having to examine them at a shop (which wastes a few seconds), and also lets us identify certain specific items in time to use them in the Desther fight. The remaining points go into Persuade, because there are some hard Persuade checks later on that we benefit from passing.

* Run along the corridor leading out of this room from the nearest door (i.e. westwards), sorting out spells as you go. When reaching the door at the end of the corridor, rest to regain spells. During the run and the rest, the following spells must be memorized (this list is based on when the spells are needed):
** L7: Creeping Doom *3
*** Rationale: Needed in the Desther fight, probably. This is currently one of the two main reasons to pick the Plant domain.
** L6: Harm *4
*** Rationale: The best boss-killing spell in the game, basically because the damage isn't capped, is resistable only by SR (or negative energy protection but nothing has that), and ignores the enemy's max HP. Almost every boss fight is about finding an opening to cast Harm.
** L4: Extended Invisibility Sphere *6 (must be quickbarred immediately)
*** Rationale: It's Invisibility, except you don't waste your time clicking a target, so it's faster and less "typo"-prone.
** L3: Protection from Elements *7
*** Rationale: Being able to tank traps is faster than having to heal up from them (and increasingly, it becomes impossible to run round them), and most traps do elemental damage.
* The following spells also need memorizing and quickbarring during Chapter 1e or Chapter 2 (and can simply be memorized now if there's spare time):
** L8: Aura versus Alignment *2
*** Rationale: The only Cleric spell I could find that deals damage that bypasses SR (in this case, via dealing it in a rather indirect manner). It isn't that much, but it's enough for the purposes of the route.
** L5: Extended Divine Power *5
*** Rationale: Temporary hitpoints and a +5 to base attack bonus are both exactly what we need in melee combat, e.g. trying to land Harm against an enemy with minions, or trying to finish a Harmed enemy in situations where neither Aura versus Alignment nor Negative Energy Ray works.
** L2: Negative Energy Ray *5 (2 should already be memorized)
*** Rationale: Many sequence breaks need either a ranged attack, or an attack that deals an unusual sort of damage. This is both. Two casts are needed during chapter 2, but you should have those memorized already; the extra 3 are for spamming against spell-resistant enemies until one of them goes through.
** L2: Lesser Dispel *1
*** Rationale: For glitching the final boss, and that's it. Do not quickbar this spell until later, to save slots.
** L2: Bull's Strength *1 (should already be memorized)
*** Rationale: Gives either +2 or +3 to attack and damage. The attack bonus, in particular, is pretty meaningful in some fights.
** L1: Summon Creature I *1 (should already be memorized)
*** Badgers are no longer that great at fighting, but you can use them to trigger traps remotely.
* Cast Extended Invisibility Sphere, go through the door, and head up towards Fenthick.
* Between now and the Desther fight, identify all the cloaks and boots obtained from the item glitch, and equip one of each. Also quickbar Creeping Doom and Harm, and spend the rest of the time memorizing and quickbarring other such spells. Note: you can't quickbar Aura versus Alignment from the spellbook, as that locks it as Unholy Aura, which is useless. Instead, use the radial menu from the quickbar, and lock it as Holy Aura, which is what we want as most bosses are Evil. The quickbarring here accounts for nine slots; the other three should be Stone of Recall, Divine Trickery, and one empty slot that will later be used for Time Stop.

==== Helm's Hold (2F) ====

* Just ignore Fenthick, and continue with your identification, equipping, and quickbarring.

==== Helm's Hold (3F) ====

* Continue with your quickbarring up to the door of the Desther fight (you should be equipped by now, because you might need the fear immunity from the boots, especially if things go wrong).
* Go into the Desther fight (invisibly), and run to and open the door on the far right-hand corner, but don't go through it yet.
* Cast Creeping Doom centred on Desther. As soon as you regain control after the spellcasting lag, run into the room beyond the door you just opened, and loot the two nearest chests (these contain "boss-quality" drops, so unless they're healing kits, they should fetch you a lot of money).
* If you did things correctly, after about 24 seconds or so (the exact timing depends on luck), Desther will lose spell resistance due to the deaths of four Ritual Creatures, Meanwhile, his custom AI will cause him (and only him) to run into the room with you (or perhaps just to the entrance). Then you can simply kill him with Harm and complete the conversation to end the chapter. (If you can get him alone, you can also try the Harm kill earlier; just hang onto the last cast in case the first three are stopped SR.)
** Backup strategy: If enemies other than Desther start attacking you, stay alive by recasting Extended Invisibility Sphere and running out of the entrance to the room; then later, try to locate and Harm Desther. You may have to turn invisible multiple times due to enemies random-walking into Creeping Doom's AoE. This is the best of several bad options.

=== Chapter 2 ===

This chapter is very short on a speedrun; although it has a lot of content, almost none of it is mandatory, and it is possible to use sequence breaks to make it even shorter.

==== Port Llast - Kendrack's Barracks ====

* Recall out. It's fastest to do all the mandatory stuff here in one go, which means doing it later.
** 100%: Getting Vardoc's journal requires a series of actions with mandatory waits between them, so there are a bunch of effective frame rules in chapter 2. Thus, the very first thing to do is to start the timer, which you do by going to the inn and killing Solomon.

==== Port Llast - Temple of Tyr ====

* Sell saleable items (the boss drops from Chapter 1e, the items you got from the demon other than the ones you equipped, and the +1 weapons from Chapter 1 other than the ones you equipped).
* Buy and equip the Robes of the Dark Moon. (The radial action for equipping is the same as for selling, so you'll need to equip them the slow way, by dragging them to the "equipped armour" slot.) This immediately sets your movement speed to the fastest possible value available in unpatched.
** No major skips: If you're willing to use the experience glitch on the demon, but not to sequence break the main plot of the game, you'll also want to buy and equip a Lesser Amulet of Health here in a single-segment run, or you will have too high a risk of failing Chapter 3.
* Leave the temple through the door.

==== Port Llast ====

* Run south towards Charwood. The Farmer's Son will interrupt you, but you can just ignore him and the conversation will cancel due to distance.
* Cast Extended Invisibility Sphere just before using the south exit.

==== South Road ====

* Use your running time in this and the next few areas to finish any spell memorization or quickbarring that you didn't manage to fit into Chapter 1e.
* Aim towards Charwood by the shortest path (which involves crossing the river at an angle after the bridge).

==== South Road - Farmland ====

* Continue towards Charwood. (For some reason, I have a huge tendency to go the wrong way here. The correct route is to turn right and uphill just after the footbridge.)

==== Charwood - Haunted Forest ====

* Continue towards Charwood. The fastest route is to go right across the small stream at the first fork in the road, and to the left rather than crossing the bridge. You won't be attacked, because you're invisible.

==== Charwood ====

* Open and walk through the two gates. (You have to walk through the left-hand half, because the right-hand half is stuck.) Follow the path up to the house next to two people, then enter that house.

==== Charwood - Inn ====

* Immediately declare an attack on the Strange Man; you should kill him in one round of sneak attacks (if you're unlucky, it'll take two, but this is a minimal time loss). He will drop a journal, plus boss-quality treasure; take both and recall out.
** Segmented: It's possible to buy Pick Pocket and steal the journal off him instead, which is slightly faster but requires quite a bit of luck. You miss out on the treasure, but that doesn't really matter in segmented as you can manipulate expensive items out of chests.

==== Port Llast - Temple of Tyr ====

* Duplicate the journal you just looted/stole, by dropping it, buying a copy from the divining pool, then picking up the original.
** No major skips: you will have to get another journal legitimately; the fastest is obtained during the Neverwinter Wood main quest (you can just recall out after you get it, you don't need to complete the quest at that point).
* Then leave through the front entrance. (You might also have to sell items if your random drops have been particularly heavy.)

==== Port Llast ====

* Head to Aribeth via the fastest route. (You'll need to open the door to the barracks, even though it's normally always open, because you didn't open it from the inside when you arrived here.)

==== Port Llast - Kendrack's Barracks ====

* Talk to Aribeth to do the "start of chapter 2" conversation and turn in the journals, then to Aarin to gain access to Luskan. Warning: escaping the Aarin conversation too early seems to make the game unwinnable. I'm not sure of the exact point in the conversation that the guard in question spawns, but tend to finish the conversation naturally to make sure (there's easily enough time to do that while running towards the door). Then turn round and run north.

==== Port Llast ====

* You want to leave via the north exit. Assuming that you're not doing a 100%, you'll hit the spawn trigger for Solomon if you follow the road directly, which can cause interruptions/complications. You can minimize the risk by memorizing the location of the spawn trigger and running round it.
* While doing this, recast Extended Invisibility Sphere, if it doesn't replenish itself spontaneously (Invisibility Sphere is kind-of glitchy in this game).

==== North Road ====

* Ignore everyone and run north.
* Spend the time while running identifying items.

==== North Road - Green Griffon Inn ====

* Run north to the gates of Luskan. (Darktongue Breakbone will ignore you because you're invisible, but he may be blocking the way, forcing you to run round. Alternatively, it's possible he won't spawn at all; I'm unsure of the exact trigger.)
* Talk to the Luskan Sergeant to gain entry to Luskan. (There's an option to skip to the end of the conversation.)
* Walk through the transition to trigger the next chapter.

=== Chapter 2e ===

==== Luskan ====

* Recall to the temple; it's closer to where you need to go than your current location. (If you're using including loading screens in your timing and you have slow loading screens, it may be faster to do the first bit of the chapter without recalling, to reduce the loading screens; in this case, cast Extended Invisibility Sphere immediately.)

==== Luskan - Temple of Tyr ====

* You may have to rest here if you're low on spells due to needing to improvise earlier. The spells you need before the next time you rest are Summon Creature I x1, Protection from Elements x1, Negative Energy Ray x2, Extended Invisibility Sphere x3, Creeping Doom x2; following this route exactly should give you all those spells (and more), but you might be missing them if you had to improvise.
* Cast Extended Invisibility Sphere.
* Leave through the front door.

==== Luskan ====

* Ignoring everyone, leave for the gap in the wall that leads to Kurth's base. (This is the fastest of the four routes that lead to seals.)
* While running, cast Protection from Elements. (This will be up all chapter, for the purpose of tanking traps.)
** Segmented: it might be possible to go without and just tank traps on your HP total, but I'm not sure if you can survive that.

==== Luskan - Docks ====

* With your current stats, you can't open the entrance door from outside. Thus, you need Kurth's men to open it from the inside. Run to approximately the corner of the island you're on (where there's a chest and a barrel), and cast Negative Energy Ray at one of the generic Bugbear Archers. This should turn the inside of the base hostile. As soon as they open the gate to reach you, cast Extended Invisibility Sphere and run past them into the base. You'll be taking some attacks, but they won't do enough damage to kill you.
* Follow the fastest route to Kurth's castle (turn right, run past/through a market area, take the first right on the bridge tiles. The Bugbear Archers can really get in your way on the first corner after that right turn, but I don't know of any reliable way to get them to move.
** Untested: AquaTiger's segmented run uses Fireball here, but I can't see it saving time overall given the detour needed to obtain it. It might be possible to do something with Summon Creature I, but the problem is that the enemies are archers and thus unlikely to move to attack.
* Enter the castle. The entrance is also a little dubious in terms of NPCs blocking the path, but much easier to get past than the archers; make sure to observe the area to see where the clear path is.

==== Luskan - Kurth's Lair ====

* Run to the right upon entering, then take the leftmost door in the resulting room (i.e. you're now running the way you were facing when you entered).
* Pick the lock on the door that leads to Kurth.
* Run past Kurth (he can't see invisible), and enter the far left room. There's an acid trap there which is awkward to avoid, but the Protection from Elements you cast earlier will tank it for you. Open the chest behind the curved screen, and loot the High Captain's Seal. Then recall out. This chest often but not always contains some pretty good treasure; I'm not sure offhand what treasure table it is, it doesn't seem to follow any of the standard patterns.

==== Luskan - Temple of Tyr ====

* Talk to Aarin. The fastest route through this conversation is 4141, followed by running out of the door (there's no need to end the conversation naturally).

==== Luskan ====

* Go to Host Tower via the fastest route (go forwards after leaving the temple, cross the bridge to your left, then follow the shoreline left until you reach the bridge to Host Tower).
* Claim to be an ambassador to gain entry to the Host Tower.

==== Host Tower - Courtyard ====

* Talk to Captain Islund to gain entry. This conversation is awkward, because although I think there are guaranteed paths through it no matter what, which path you need to take depends on randomness, thus you need to actually read the conversation to know what to do. I can't generally remember all the paths except when I actually read the text, but IIRC the correct route is to Threaten, and then if that fails ask if he's denying you entry.

==== Host Tower - Ambassadors' Quarters ====

* Go to Aribeth's room (centre left) and take her key from the armoire. There's a hostile construct there, but it can't see you because you're still invisible.
* Use the portal to warp to the second floor.

==== Host Tower - Level 2 ====

* Go into Blaskar's room (it's the nearest one to your portal, behind you and to you right).
* Loot the boss treasure from the nearer chest, and the 6th floor portal stone from the more distant chest. Both chests are trapped, and both traps will be tanked by Protection from Elements. (Note that tanking a chest or door trap requires one extra click compared to the trap not being there, so you need to be aware of the traps even though they are unlikely to hurt you.)
* Use the portal to warp to the 6th floor.

==== Host Tower - Level 6 ====

* This level has one-way doors in, so you run round it in a circle rather than the more common there-and-back route. Open the wooden door behind you and to the right, then cycle round to the left (as always, tanking traps as you go). Ignore the first door you pass, and go in the second (the one near Valindra).
* Shuffle to the left (press <tt>Q</tt>), causing the Familiar to spawn. It is normally, but not always, fastest to wait for it to random-walk onto the nearby negative trap, which kills it and removes the trap. You might want to summon a monster or just take the level drain if it doesn't cooperate.
* Tank the trap on the chest, and loot the boss treasure and Pinnacle Portal Stone from it.
* Continue your cycle to go back round to the portal. The door blocking your way will open spontaneously. Bear to the right as you go through it to avoid a particularly nasty trap.
* Use the portal to warp to the 9th floor (marked "Pinnacle" in the menu).

==== Host Tower - Level 9 ====

* This fight is a pain in pretty much every category. This is the fastest route I know, but it's not 100% reliable (although it is reliable enough for single-segment), and there may be other routes that are faster.
* Open all four portcullises first, so that you get the maximum possible mobility during the ensuing fight. This really does make a difference.
* Cast two copies of Creeping Doom centred on the same location, placed so as to not hit Arklem but to hit as much of the rest of the main area as possible. The correct centering location can be determined by looking at the floor; anywhere near the centre of the right-angled isoceles triangle furthest from Arklem will do. The purpose of this is not for damage (although the damage does matter on occasion), but for the slowing effect. (Although it's a little slower, you can ensure that both are centred on exactly the same spot via standing there yourself and then casting at yourself. I currently do this because I fear messing up the placement and runing the run, but I should probably just go for it.)
* Destroy the braziers in the following order: the one nearest the entrance, the one furthest from the entrance, the one second-nearest the entrance, the one third-nearest the entrance. This gives you the largest possible head start on the enemies that spawn, and with only two casts of Creeping Doom remaining, you'll need it. (If you have three casts available, say because you needed to rest earlier as a backup strategy, you can normally use a more direct route safely.)
** Untested: Because the Fire Elemental (which spawns second) is the main issue, there may be a faster order that still works.
* Run anti-clockwise around the outside of the room and talk to Arklem. If everything is set up perfectly, neither him nor you will be in combat, and you'll be able to move on even though you didn't technically complete the fight.
** Backup strategy: if something does go wrong, do a cycle of the room anti-clockwise and try again. You can repeat this for as long as your HP holds out.
* Run through the portal to the next level. Normally you won't be chased, or chased only by a red slaad (which you can ignore, they don't do enough damage to disrupt the route). If something more powerful does come through, try to avoid it.

==== Host Tower - Pinnacle ====

* An explanation of what's going on here, for people who aren't hugely familiar with the game, because this entire level is set up to deceive you. The previous room was actually the final boss fight of Chapter 2, despite being disguised as a mini-boss. (It's difficult enough to be one in both a speedrun and in casual play.) What you need from this level is for your character to become aware of Aribeth's fate and the Words of Power. There is a mini-boss on this level, but it doesn't actually do anything; in particular, there is no reason to fight it, and it's just there to aid in the deception. There is also no way to leave the area but to recall out. (Future versions of the game had an extra Stone of Recall placed there, as a clue and in case you didn't take your own Stone of Recall with you.)
* Thus, what you're trying to do is to reach the end of the cutscene where Aribeth becomes a blackguard. This is trivial to accomplish because nothing's attacking you, but you want to accomplish it quickly. The easiest way that I know to accelerate this cutscene is to cast Negative Energy Ray on a generic lizard warrior; this causes them to become hostile, and (after an apparently random length of time) the resulting cascade of combat statuses interrupts the cutscene, and the game automatically sets the required plot flag to prevent the game becoming unwinnable. You can tell that this has happened when you hear the click of a journal entry being updated.
* As soon as your journal is appropriately updated, recall out.

==== Luskan - Temple of Tyr ====

* Talk to Aarin and spam 1 to end the chapter.

=== Chapter 3 ===

==== Beorunna's Well: Aarin's Lodge ====

* Run to the right-hand door, talking to Aarin on the way (if you stay far enough from the wall, he will force conversation on you).
* You need to get to at least a certain point in the conversation for the doors to open and the Stone of Recall to start working, which is awkward because spamming 1 isn't enough. I currently don't have a set route through this conversation and improvise it.
* Leve through the door you were running to.

==== Beorunna's Well ====

* Enter the drinking house.

==== Beorunna's Well: Drinking House ====

* Talk to Lillian Cambridge. (This might be the only sidequest that's actually completed during the run, incidentally; there's a sidequest called, literally, "Talk to Lillian Cambridge", because the first part of the Coldwood quest was split into its own journal category for some reason.) This conversation can be completed by spamming 1; there are routes which have fewer keystrokes, but which are probably slower because entering sequences other than 1-spam requires actual thought. The conversation gets stuck in a loop, but you can leave as soon as you get the Teleport Scroll (watch the message area).
* Leave the drinking house again.

==== Beorunna's Well ====

* Go to the Many-Starred Cloak enclave.

==== Beorunna's Well: Many-Starred Cloak Enclave ====

* Talk to Eltoora and open the shop.
* Sell all the saleable items you have (other than the ones that are equipped) in order to buy as many scrolls of Time Stop as you can afford. (You only need 7 of these scrolls if everything goes right, but the scrolls are ''very'' useful for recovering if something goes wrong, so extras never hurt on a single segment.) This is the last time you buy items in the entire game, so don't worry about spending your entire gold supply.
** Segmented: You can save time by buying only 7 scrolls.
* Leave again.

==== Beorunna's Well ====

* Run to the north exit (to your right, towards Coldwood). Before you get there, cast Extended Invisibility Sphere.

==== Coldwood (southwest) ====

* Run to the east exit (run forwards until you get an opportunity to turn right, take that right turn, then run forwards and across the bridge, then continue running forwards). While on the way, start changing your spell memorization: dememorize Creeping Doom in favour of Still Harm, and change the quickbar to match.

==== Coldwood (east) ====

* You spawn facing in an awkward direction; the way you need to go initially is behind you and to the right.
* Run anticlockwise round the level to the magic circle, then run to the floor design; the Teleport Scroll will activate automatically.

==== Coldwood: Wizard's Dungeon ====

* Use the door to the left of your spawnpoint, then make your way clockwise around the level.
* The quintet of mephits can easily get in your way (they block your way by default, and will continue to do so unless they random-walk into a pattern that doesn't). You can use Summon Creature I to try to persuade them to move; you will need to get the badger to attack (<tt>VWE</tt>) or it will be just as invisible as you are. I normally attempt this trick, but have trouble pulling it off.
* Enter the first room after the mephits, tank the trap just inside the door on your HP (it'll hurt but it's survivable), and solve the puzzle. The solution is always the same: a Z shape, starting at the bottom-right as you enter the room, and continuing to the bottom-left, top-right, and top-left. The door opens automatically.
* Run to the snowglobe and take it. There's a nasty trap to the left of the nearest pillar, so run round the right of that pillar. Because you're invisible, the Huge Fire Elemental won't attack.
* Recall out.

==== Beorunna's Well: Temple of Tyr ====

* Just leave via the main (only) exit.

==== Beorunna's Well ====

* Enter the Drinking House.

==== Beorunna's Well: Drinking House ====

* Return the snow globe to Lillian. (Spamming 1 works.) You can flee the conversation as soon as the animation and sound effect starts playing.
* Go upstairs.

==== Beorunna's Well: Drinking House Upstairs ====

* Go to Lillian's room (the furthest one on the left after you enter the main area).
* Cast Time Stop from a scroll, and then press the Rest button. If you leave enough time (about 1 to 2 seconds) between the Time Stop and the Rest, they will cancel each other out, leaving you with full spells and HP but without having to wait through the Rest animation or the Time Stop animation. (This trick lets you rest in about 6 seconds, rather than 30 seconds, meaning that resting is a lot cheaper throughout the rest of the run. I'm torn on whether it's intended or a glitch; currently I lean towards glitch.)
* Cast Extended Invisibility Sphere (resting causes the old one to time out).
* Talk to the Pedestal, spamming 1. There's a few seconds of delay between the end of the conversation and entering the Snow Globe; don't be fooled into thinking you screwed up the conversation.

==== Snow Globe ====

* Start by turning left, then run round clockwise until you reach the central area. (This is the shorter of the two routes.)
* Enter the cave.

==== Snow Globe Cave ====

* Run up to the dragon. Cast Holy Aura on yourself before the fight starts (this is a pre-emptive backup strategy for if Time Stop runs out early or you can't land a melee hit), then Time Stop. Spam Harm until you pierce the spell resistance; then cast Bull's Strength and Divine Power and attack in melee. Eventually either you'll hit, or the dragon will hit you, and either will kill the dragon.
** Segmented: You can do this fight with just Holy Aura and Harm (in that order), but this requires a lot of luck (Harm has to hit, and the dragon has to attack you in melee).
* Once either the dragon is dead, or else it has taken fatal damage and is only alive due to Time Stop preventing it dying, run over to the chest, wait for Time Stop to end if it hasn't already, then open the chest.
* Loot any items from the chest you want (you probably don't want any, but if you're critically low on gold after buying Time Stop scrolls, take the gold so that you can afford to unrecall throughout the rest of the game), then take the Word of Power (this spawns Haedraline to force conversation with you, so you need to do it last).
** Something to consider: This chest should spawn a guaranteed top-tier weapon for you, but it doesn't because you have Weapon Focus (greatsword) and a greatsword doesn't fit in the chest. This probably doesn't matter much, as the Greatsword +1 you've had nearly all game works just fine on this route.
* Go through Haedraline's conversation (spamming 1 works on this one), then recall out (don't be tempted to step into the portal, it's slower). You can't recall until the conversation ends naturally.

==== Beorunna's Well: Temple of Tyr ====

* Time to make two copies of the Word of Power; this is substantially more complex than making one copy, because there is no known way to do the plot item duplication glitch if two copies of the item already exist in the game.
* Run over to the divining pool; drop the original Word of Power, then buy a copy from the divining pool.
* Leaving the original on the ground, leave the area.

==== Beorunna's Well ====

* Enter Aarin's lodge via the nearer door (you'll have to open it, as you left via the other door).

==== Beorunna's Well: Aarin's Lodge ====

* Turn in the duplicate Word of Power to Aarin.
* Recall out.

==== Beorunna's Well: Temple of Tyr ====

* Pick up the original Word of Power, and drop it again.
* Buy a duplicate Word of Power from the divining pool.
* Pick up the original Word of Power again.
* Unrecall out (I think this is faster than just running to Aarin).

==== Beorunna's Well: Aarin's Lodge ====

* Cast Divine Trickery; there's a Persuade check you need to pass, and your natural Persuade score isn't high enough to guarantee passing (the odds seem to be a little better than 50:50).
** Segmented: You don't ''need'' the Persuade bonus if you can use luck manipulation to ensure you pass the check; it's certainly not a remote chance.
* Turn in the two Words of Power. Persuade a bonus reward from the second Word you turn in; it's three Potions of Heal, which will potentially save a noticeable amount of time later on between the Aribeth and Maugrim fights (where you can't rest without recalling or backtracking). This ends the chapter.

=== Chapter 4 ===

==== Castle Never ====

* Talk to Lord Nasher at least until you reach the "generic questions" part of the conversation; this is required to unlock the door.
* I use the Time Stop + Rest combo here; arguably it's not strictly necessary if you're lucky with SR checks and melee rolls, but it gives you the best possible chances of recovering from bad luck, so it's worth doing in single-segment.
** Segmented: Assuming you used a minimum of spells earlier, resting probably isn't necessary. You might want to memorize a second copy of Bull's Strength over one of the redundant copies of Negative Energy Ray earlier in the run in order to account for the lack of a rest here.
* Cast Extended Invisibility Sphere.
* Leave through the main door of the castle.

==== City Core ====

* Cast Bull's Strength now; it lasts for ages, you'll want it against Maugrim, and casting it early means you also get the marginal benefits it has for the other fights in this chapter.
* While running, quickbar the Potions of Heal over Summon Creature I.
* Run forwards past the Hall of Justice and the Great Tree, then turn about 45 degrees to the left and run into the far left corner of the map.
* Enter the War Zone via running to the left of the two soldiers and impaled corpse; otherwise, you tend to get stuck.

==== War Zone ====

* Run along the road that goes approximately forwards until you reach the dividing wall.
* Turn right, then enter the first house on the left.
** Untested: It may be possible to get through the gate directly using a combination of Divine Trickery, extra Open Lock ranks, and Thieves' Tools. It's unclear if there's anywhere you could buy a set of Thieves' Tools +10 without losing more time than this would save, though. I believe that they can be manipulated out of the 6th Floor Portal Stone chest in chapter 6, but that would only be useful in a segmented run, because you've already decided how to allocate your skill ranks at that point in a single-segment run and so couldn't take advantage of a random Thieves' Tools drop. A Potion of Cat's Grace is also worth an effective point or two of Open Lock.

==== Old Man's Home ====

* Run to the back bookshelf and open it.

==== War Zone ====

* You spawn facing backwards again, which is something to take note of as you start running in the area; using the mouse may help. Note, however, that the ''camera'' is facing in the correct direction; it's just the character that's facing the wrong way.
* Follow the only path to the burnt-out building; then run over that building to the intact building beyond, and enter via the door in the left-hand side as you look at it.

==== Luskan Guardhouse ====

* Buff up with Protection from Elements, Extended Divine Power, and Holy Aura.
* Open and go through the door. (It's trapped, but Protection from Elements will tank most of the damage; and you want all the HP you can get through here in case something goes wrong in the Aribeth fight.)

==== War Zone ====

* Spam Harm at the Half-Dragon Baalor until it lands. Then spam melee attacks until it dies, either due to it hitting you or due to you hitting it.
* Run through the portal; you want to take on Aribeth with your buffs still active.

==== Maugrim's Sanctuary ====

* Run up to Aribeth and let her talk to you. If you don't, this can break her script in a way that will probably get you killed.
** Untested: It might be possible to use Time Stop to break her script in a way that gets ''her'' killed instead, which would be preferable.
* Cancel the conversation via casting Harm on Aribeth. Spam it until it breaks her SR. (If you fail to break her SR, there is a decent chance she'll kill you, because she knows about the Harm + finisher combo too. In such a case, your only real backup strategy is to respawn.)
* Once you land Harm, don't bother with a finisher; Aribeth will surrender.
* It's faster to save Aribeth than kill her after she surrenders (she has ''far'' too many charges of Heal and isn't afraid to use them). The correct conversation path is to spam 1 until you get the option to Lie on 1, then follow with 212 and resume spamming 1. I'm not convinced that it's possible to fail the Persuade check involved here at your current stats; this particular route through the conversation gives the easiest Persuade check possible to save Aribeth. (Do ''not'' screw up this conversation; the resulting fight will run you so low on Harm charges that you will probably run out before your next chance to rest.)
* Heal up with a Potion of Heal.
* Remember the cloak you equipped back in Chapter 1e? That comes into play now, because it allows you to tank paralysis effects from traps. Combined with the Protection from Elements that should still be active (because you haven't been hit by the same element multiple times since you cast it), you can tank the unavoidable acid+paralysis trap in the route onwards to Maugrim. Once the route splits, turn left, right, left, right at the various junctions to avoid hitting further traps.
* Once you are near Maugrim, cast Time Stop. (You need to do this before his conversation trigger, or you get into a Time Stop war that lasts ages.)
* Spam Harm at Maugrim until it sticks.
* If Extended Divine Power has worn out, recast it. Then melee attack Maugrim until you hit. (Holy Aura does not work in this fight; being a spellcaster, Maugrim doesn't melee you anyway, so you can't get a retributive attack in.)
* Open the chest and loot the Word of Power and the upgrade to your current greatsword. (It is guaranteed to contain an upgrade to your greatsword, but ''which'' upgrade is random. There's no real reason not to upgrade, anyway.)
* Recall out.

==== City Core: Hall of Justice ====

* Leave via the main entrance.

==== City Core ====

* Head back to the castle where you started.

==== Castle Never ====

* Head towards the dungeons (go almost to the room where you started, then turn right).

==== Castle Never Dungeons ====

* Run through to the level below. You don't have to talk to anyone; in particular, there is no need to talk to Haedraline.

==== Castle Caverns ====

* Quickbar Lesser Dispel (over Divine Trickery) while you're running in this area.
* Use the Time Stop + Rest combo to heal up.
* Run to the Word of Power Pedestals, and place your Word of Power on the unlit one.
* Cast Extended Invisibility Sphere, then enter the Source Stone.

==== Source Stone Sanctuary ====

* Run to the end of the level. (I like to ensure the minimap is open for this, as it's easy to get lost.) There's a nasty trap just before the portal; you want to keep along the right-hand wall in that area to avoid taking damage from it.
* Before entering the portal, buff up with Holy Aura (the only buff you need for the area; you also need fear immunity, but the boots you equipped in Chapter 1e provide that).

==== Source Stone Guardian Lair ====

* Run forwards for about 1 second, then cast Time Stop.
* Cast Harm at the dragons until it sticks.
* There isn't much you can usefully do in the remaining duration of Time Stop; I like to buff my melee attack and then try to melee them to death, but this doesn't actually save any time. (Incidentally, you can't safely cast Holy Aura ''during'' Time Stop because it gives you less time to cast Harm, and that sometimes matters if Time Stop happens to roll a low duration. You would do things in that order in a segmented run, though.)
* The dragons will melee attack you and die to the retributive damage.
* Loot the keys off the dragons, and use them to open the gates.
* Before leaving the area, use Time Stop + Rest to heal up (mostly for Harm charges). Then cast Extended Invisibility Sphere and move onwards.

==== Source Stone Inner Sanctum ====

* Run up to the first door, cast Extended Divine Power, then open the door and Harm+melee the Old One Cleric.
* Run up to the next door. You can't open it because you're missing a key, but it'll get you far enough from the enemies that you can (and should) break combat by casting Extended Invisibility Sphere.
** Segmented: It's faster to swap this step with the next one, but this will cause you to take ''much'' more damage, and you'll probably die as a result. So that strategy is segmented-only without huge buffs to AC (as are available on, e.g., no-large-skips or 100%).
* Run back to the Old One Cleric's deathdrop, and loot the Key.
* Open the large door. To avoid accidents where the Old Ones run into the Morag fight, I like to close it again.
* '''Bash''' down the door before Morag, even though you can open it normally. This sets your "in combat" flag and breaks her script. It seems to break differently in patched to unpatched, but in unpatched it's particularly useful because it causes the fight to not start until you're ready.
* Get past the blade barrier. There are three methods to do this, from the riskest to the least risky (I normally try the second):
** Try to run past it before it spawns. This is possible with a low probability, based on the interaction between timers. If you fail ths, you die.
** Make it temporarily disappear using Lesser Dispel, then run past it before it respawns. This is more likely to work than the previous case, but also capable of instakilling you through bad randomness, as the respawn will take a random length of time from 0 to 6 seconds.
** Kill the Statue with melee attacks and wait for it to despawn. This is 100% safe, but takes ages.
* Kill the Protector Against the Lessers using Harm (until it sticks) then Negative Energy Ray.
* Cast Holy Aura (not strictly necessary, but very useful if things go wrong), then Negative Energy Ray at Morag (to cause her to teleport to your current location).
* Kill Morag with Harm (until it sticks) then Negative Energy Ray. If it doesn't stick quickly, Morag may cast Time Stop, in which case you can just wait for it to finish then continue Harm spam.
** Backup strategy: If something goes wrong with your normal boss kill strategy, cast Divine Power, then kill the Protector Against the Sword and try to melee Morag to death, healing as necessary.
* After killing Morag, stay where you are; the exit portal should spawn almost on top of you, about where Morag teleported to.

==== Astral Pocket ====

* Spam transition clicks on the portal in order to skip Haedraline's conversation.

Neverwinter Nights

2014-08-17T00:36:37Z

Ais523: appparently piped links don't work with subpages the way I expected

* [[/Version differences|Version differences]]
* [[/Routes|Routes]]
* [[/Mechanics and Glitches|Mechanics and Glitches]]

Neverwinter Nights

2014-08-17T00:36:02Z

Ais523: lets's start this

* [[/Version differences|/Version differences]]
* [[/Routes|/Routes]]
* [[/Mechanics and Glitches|/Mechanics and Glitches]]