Speedrunners are terrible. They ruin games for everyone, and love to talk about how your coders are buffoons when they perform intricate tricks with elaborate setup and tight inputs that no ordinary player would ever think of doing, let alone be able to perform. Here’s how to drive these pests away from your games.

First, make an inaccurate ingame timer. Include load times (multiplied by 2, so now everyone needs to buy an SSD), cutscenes, character creation, time since the game was started. Hide it until they beat the game so they can’t reliably check if it’s accurate without cross referencing another timer.

Next, make file management annoying, or impossible. Utilize cloud saves, have events in one save affect events in a new game. Store savedata in the game files, encrypted, so they’re difficult to access, and difficult to modify. This makes starting completely fresh annoying.

Include unskippable cutscenes or autoscrollers that are about a minute or more, and vary their length randomly. Unskippable cutscenes are intensely irritating to speedrunners who just want to play the game. If they’re too long, the runner can take a break, but if they’re only a minute or so, they can’t comfortably do anything but sit and wait. Prompt the player to continue with text to make them all the more annoying.

Add RNG to practically everything. Damage, speed, enemy behavior, drops, etc. Be sure to include a big time saver powerup or item as a random drop that can only be obtained about a third of the way through the game, so speedrunners are obliged to obtain it, and need to waste time playing the game to see if it’ll drop. If you can work multiple of these in, all the better.

Ruin the wrists of speedrunners by including actions that go faster or deal more damage per second when they mash harder. Make the speedup from mashing grow exponentially as they mash faster, so the fastest possible mash has a significantly bigger benefit.

Next, don’t implement deltatime correctly for framerate independence. Make it so the timescale is faster at lower FPS, so that in order to move fastest, you need to reduce the FPS to as low as possible. Additionally, don’t benchmark the game to any specific FPS, just let it do whatever it wants, so then speedrunners need to argue about where to set the framerate standard, and need to force it to behave with outside programs. Make the input delay vary randomly over time, and don’t have a buffer for actions. This makes any frame-perfect input more difficult, and in general makes the game more frustrating to play.

Vary the speed of things like elevators and doors based on the difficulty picked. Higher difficulties should have faster elevators and doors, but also higher self-damage where applicable, forcing runners to play on the highest difficulty in order to get the fastest times.

Include drop-in online elements like Dark Souls so runners need to intentionally disconnect the game from the internet. Combine this with Denuvo, or other always-online DRM, which should also be set up to avoid tampering with Cheat Engine, which speedrunners use to practice and occasionally mod out RNG. Between these, runners will either need to accept that runs include online elements, they’ll need to authenticate with denuvo and play offline until authentication expires, or crack the game outright to disable always-online.

Make the game fast, make it linear (or open world, but with a linear sequence of objectives), and make it so the player snaps onto a bunch of environmental features, but has random animations of random length for traversing them. This helps narrow the skill gap, and introduce more random variation in timing. Making it linear makes the routing less difficult, and making it fast is something that you’d think would appeal to speedrunners, but they’re actually indifferent about. Making it open world means everything takes longer than it needs to. When making it open world, be sure that every event flag checks for multiple prerequisite event flags, so nothing can be completed out of order.

Don’t allow players to bind anything to scroll wheel, especially not jump or use. This has been used in countless games for various exploits.

Practice good coding conventions, don’t mutate state unnecessarily, use a strongly typed language with collections and avoid using pointers. Have each element interact with as few others as possible. Validate and sanitize your inputs. More safe coding practices means less glitches. Design mechanics to have a singular purpose that it accomplishes with no variation in output and no interaction with other elements. This reduces the chance of players finding unexpected uses of mechanics.

Thoroughly wall off areas that aren’t supposed to be accessed. Include kill planes in out of bounds areas. Don’t spawn loading zones before they’re supposed to be accessed. Lock players in rooms/arenas until they’re done with their current objective, or defeating all enemies. If players aren’t supposed to reach an area yet, make sure it’s unreachable, either with walls, or by making sure it doesn’t exist until it’s supposed to be reached. If possible, define levels in terms of areas the player is supposed to be, so they can’t exist outside of the places you want them to be.

Bundle bugfixes with new content patches, especially new bosses and new areas, because it forces all bosses and 100% runners to run on the patched version of the game in order to meet the category requirements.

Of course, a lot of these things make the game worse, even for casual players, but there’s no price too high to remove the speed demon menace!

One of the most powerful tools speedrunners have to save time is Skips. Games are usually designed where goals are supposed to be completed in a certain order, a skip is where you complete later goals without completing the prerequisite ones. This can mean completing story flags out of order, or simply going to an area before it’s supposed to be accessible. The thing that makes such skips possible is usually level design in the shape of a horseshoe, where the start and the end are close to each other in physical space, but are separated by a wall inbetween. The Valve Developer Wiki helpfully has some examples of this, which they call Loops and Bounces. Hub areas that unlock into more areas also tend to facilitate skips, if you can find a way to get past the gates blocking you.

John Romero, one of the level designers of Doom, remarked on the Horseshoe level design in the Hangar map in this lets play, as well as some of the benefits of it. You get to see where you’re going, you’re not traveling in a literal straight line, even if you only have one way to go, and you can cut across the horseshoe to the end.

Getting Over It with Bennett Foddy is designed as a series of horseshoes laid over each other, which sometimes makes skips possible, but more frequently is used to dump the player back into earlier areas. The whole map looks like a serpentine pattern, crossing back and forth over itself. Many areas in Super Mario Odyssey are structured similarly, letting you get to later parts of the level if you can perform the advanced jumping tricks. Even ancient games like Castlevania have skips based on connecting the ends of a horseshoe, using the small boost they get from taking damage to climb up and over ledges they can’t quite reach otherwise.

The most practical form of designing for speedrunners that you can do as a developer is simply to make horseshoes in your level design all over the place, and leave it up to them to find a way to connect the ends. Incidentally, this happens to be good level design practice in general, as it gives players sight of the areas they’ll go to in the future (and thus clear eyes on their goal), and frequently gives them more routes through the level.

Speedrunning is fundamentally a big optimization puzzle, similar to the traveling salesman problem. Speedrunners tend to enjoy games that are difficult to route, where they have freedom to choose to pursue a lot of different goals, that each have an effect on completing their other goals. Metroidvanias are popular among speedrunners for this reason, because they typically afford a lot of freedom in which order bosses can be tackled, and powerups can be collected. Those powerups frequently open new routes around the map, or make traversal faster relative to certain geographic features present on some routes. These types of optimization problems can be quantified in how complex they are, through their complexity class, or Big O notation.

Making a game difficult to optimize is difficult in-of itself, but some easy steps are to have multiple active goals at once, to open and close routes relative to certain events, and to give the player multiple routes across the map at any given time, as well as limit teleporters to locations that are out of the way, and avoid central hub locations that are connected to all the other objectives.

Having alternative or optional objectives is also helpful for speedrunners, because they frequently incorporate these into alternative categories (alternative speedrun rulesets whose runs are compared against each other, instead of the general crowd). The most common of these is 100% or all bosses. As skips are found for intended goals, speedrunners make categories for avoiding the use of major glitches, and completing some of the intended goals. More whimsical categories sometimes get introduced as well, such as collecting all the items, or playing with a restriction, such as no jumps, or the fewest powerups possible.

While it might be tempting to leave bugs in, in order to entice speedrunners, or to patch bugs out in the name of releasing a polished product, the real consideration should be: Will a casual player run into this bug by accident? And does this bug create new interesting choices with regards to saving time, or playing the game? For most bugs, the answer is no, but sometimes the answer is yes. A common policy is to leave in any bugs that affect the speedrun after the game is released, unless they’re easily triggered showstopper bugs, such as a crash, or softlock. If the QA team can’t catch it, most players probably won’t either. Rather than blindly sticking to the value that all bugs are bad bugs, it can be helpful to consider more abstractly what creates value for the customer.

In some ways, the way the game is coded or designed can influence what tricks are possible in a game. A lot of glitches in older games involved memory manipulation and corruption that isn’t really possible in modern games, largely because modern engines and modern languages have a level of type safety and memory safety that games from the 90s didn’t. Programmers working in assembly or C frequently made mistakes with pointers, arrays, or structs. They would transform data using a process meant for a different set of data, or jump to the wrong location in memory. This is what made so many glitches possible in pokemon, ocarina of time, and other games from that time period.

Beyond just coding conventions, glitches or exploits are made possible by simply making detailed unique mechanics that had interactions with a number of other elements, which is good game design. Good games tend to also be good speedgames, with the exception of autoscrollers, and beat em ups, because those tend not to allow for much routing freedom, and playing beat em ups for speed tends to deemphasize what makes the combat in beat em ups interesting. When a mechanic is designed to accomplish many different purposes, interact with many other elements, and modulate its output based on the input, it’s almost inevitable that some unintended outcomes will occur. The iceless skip in Megaman X isn’t some weird quirk of the code, it’s just the natural result of giving the player the freedom to jump off walls and near perfect air control.

A general quality of life feature for speedrunners in any game is having a good in-game timer. A good in-game timer will not count loading screens, and sometimes pause time or character creation, but will count every other part of gameplay. Good in-game timers avoid the need for speedrunners to manually remove load times in their video software, or with complicated timer splitting programs that need to be developed per-game. Another quality of life feature is a speedrunner mode where the RNG is deterministic, or where you can input an RNG seed to always get consistent results. Making sure that players can cleanly wipe their save and start from complete scratch is also important.

Building a game that accommodates or even encourages speedrunners is not usually a development goal for most games, but for the few projects that aim to entice speedrunners it can be helpful to know what actually makes a speedgame more interesting instead of assuming that speedrunners want something like a racing game with a single path forward, and you happen to move at a fast unbroken pace. Most games deliberately oriented around speedrunning, such as Speedrunners or SEUM: Speedrunners from Hell, tend not to actually be very popular speedgames, because they don’t really consider what speedrunners enjoy about speedrunning various games, instead building for an aesthetic of speed. It’s more important to build a good game than a good speedgame.

It’s also nice to do the bare minimum to accommodate anyone choosing to speedrun (timer without loads/character creation, good save file management, not actively patching out speed tech). For any game, it’s helpful to avoid actively burning your players. It’s up to the player to decide how they want to play your game, whether it be pacifist, speedrun, or modding. Intentionally snubbing players who play a certain way may not impact your overall sales numbers, but it’s kind of a dick move and many games get a second life from the speedrun community.