Making your game speedrunner-friendly

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:

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

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 static (fixed memory location) and volatile (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 new, malloc, 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. int is good, string 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.