Designing AGAINST Speedrunners

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!

Designing for Speedrunners

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.

Why the Hell Does Depth Matter?

Depth is my primary metric of quality for a game. I believe depth is a good metric because it is “simple” and “generic”. Unfortunately it’s not simple in the way of being simple and relatable to understand. It’s simple like GDP is simple. It’s one final number that represents a whole ton of things going on under the hood. Depth is the emergent result of a lot of different things coming together in a game. Depth, like GDP, is a generic metric in that it doesn’t care what’s being invested in, it could be medical, military, education; puzzle game, RTS, RPG, FPS, or fighting game, it only matters what the final outcome is. Depth doesn’t encompass everything about a game, the same way GDP doesn’t encompass everything about an economy, but both are fairly important metrics regardless. Unlike GDP, there are less ways to fake depth and end up with a cheap result.

I define Depth as the number of states that are differentiated from one another, balanced against each other, and currently known about/preferred by the playerbase. State is the current condition something is in at a specific time. A state with regards to games is the current condition of everything present in a game at a moment in time. Depth is the sum of these states after passing through 2 filters: redundancy, and relevancy.

We start with Possibility Space, which is every single state possible. We filter those into Absolute Depth first by removing all states that are redundant, that are just copies of one another, such as rotations or mirror images of the game board in Tic Tac Toe or Go, or more powerful but functionally identical weapons in RPGs. Then we filter Absolute Depth into Relevant Depth by removing all states that are underpowered and therefore not commonly used in play, or the ones that are unknown to the player community at a given time, such as those that use undeveloped techniques or unknown mechanics. The final result is a measure of the effective complexity of the game.

depth venn

Okay, so, why the hell would the effective complexity of a game matter? What does it matter if a game is more complicated? For this, lets go back to Raph Koster’s Theory of Fun. The gist of his theory of fun is that fun is derived from winning at something inconsistently, like a coin flip. Fun is also derived from improving your consistency over time. Something you can win at effortlessly is boring, and something you never win at is frustrating (this is backed up by Flow theory too). Random things can trick the brain, which is why gambling can be fun, but most people eventually catch on and stop playing, unless they delve into superstitions about luck.

However there’s also a bit of a contradiction there, if you improve your consistency over time, then won’t something that’s fun now eventually become boring when you’re 100% consistent? That’s true. Depth gives players many different measures of consistency, so while you may be consistent at one thing, now you have something else to get consistent at.

Raph Koster’s Theory of Fun posits that fun is the joy of learning (probably because learning things makes us better at surviving, so we adapted to reward learning neurologically). A deep game has a lot to learn about. Therefore a deep game is a fun game.

On top of that, the experience of playing a deep game is different from playing a shallower one. Deep games typically have more choices, and more possible consequences for those choices, requiring more complex thought about each choice. Many board games with less board states are easily solved (connect 4, checkers), where more complex ones require more arcane heuristics in order to perform well at (Go). Simpler games are more about doing 1 thing right, where deeper games are about thinking about future consequences more. Deeper games involve more interesting decisions, as per the Sid Meier definition.

Smash Bros Melee might have less buttons and less attacks than a traditional fighting game, but you can get more results from each move than you can in a fighting game, because Smash Bros is highly responsive to the relative positions of each character, and the timing with which attacks are hit. This isn’t to say that Smash Bros is necessarily better than a Fighting Game though, because both a few nuanced moves, and many differentiated moves are equally prioritized under depth theory, as long as they shake out to the same number of relevant states.

Later Smash Bros games did a lot of work to remove a lot of the nuance in Smash Bros Melee moves, by making them less responsive to differences in timing and spacing (less sweet/sour spots, reverse hits no longer work), by reducing the effect of defensive mechanics during combos, and removing options outright. These games are comparable in their options, but have less depth. This makes progress less clear, since there are no longer an array of clear techniques and strategies to master, and requires players to work harder to get smaller rewards for their effort.

Gamedevs Should Not (Exactly) Copy My Criteria to Make a Successful Game

I don’t expect anyone to make a game that perfectly fits my model of what a good game should be and ignores everything else typically involved in making a commercial game, including me.
The reality is, my idea of what a good game is impractical and conflicting with making a popular or best selling game. I judge games and enjoy games for aspects that I would not prioritize during development, and a lot of aspects of making a successful game fall outside the scope of my work. I try to write articles incorporating this broader perspective too, because I’m interested in it, but the core of my philosophy is about making what I would consider a good game, rather than a successful one.
Of course, I still think that someone interested in designing a game should listen to me to some extent (why else would I write?). I still think that I am providing a unique and helpful perspective, but success will always be a medium between my perspective and what’s actually effective to reach and appeal to a wider audience than just me. There are certainly aspects of my writing and philosophy which overlap with general success, but the line is always going to be up to the developer, and it’s never going to be completely clear.

Continue reading

Nuzzles: Not a Puzzle

CODE FOR DOOR C489 Kia or Welcon 58880

The Legend of Zelda and its imitators, Okami, Darksiders, God of War 2018, Beyond Good and Evil, Legacy of Kain: Soul Reaver, have a particular style of “puzzle”, where you need to notice a switch somewhere and activate it. The developers of Darksiders coined a term for this, “Nuzzle”, short for “Not a Puzzle”. Nuzzles can be useful for teaching a player how to use a puzzle mechanic for the first time. Zelda style games tend to have items or abilities that you unlock which can be used to flip switches that cannot be flipped by any other means. When you get a new ability, it helps to have a simple example of what it can interact with and how it works. The Witness does this in each area that introduces a new puzzle symbol, by having a sequence of 5-10 nuzzles that demonstrate how it works in the simplest way possible, expecting you to learn how the puzzle symbol works via induction so that you can reason out puzzle solutions with deduction.

A nuzzle can be broadly identified as a 1-step puzzle, or a riddle. Nuzzles don’t test critical thinking skills, they simply test if the player is paying attention, or remembers what the switch operating mechanic is at all. Of course this is critical for tutorial purposes, new or inexperienced players need guidance to know how to solve puzzles, but the trouble comes in when Nuzzles are deployed broadly long after the basic puzzle mechanics are understood, as a replacement or filler for puzzles, which is what Zelda-like games tend to do long after puzzle mechanics have already been introduced (such as when you’re asked to light 2 torches in the final dungeon of the game, or hit a sequence of switches in the order they tell you when there are no enemies in the room, and no other confounding factors, such as time limits, or additional puzzle mechanics). Continue reading

The “Silver Bullet” Game Design Problem

A long time ago, I read an article titled, “Silver Bullet Combat”┬áthat was rather coherent about describing a common problem in game design. The article is now only available as a PDF and might eventually disappear, so I’m going to reiterate it in my terms.

So the gist of silver bullet style design is that Werewolves can only be harmed by silver, but once you shoot them with something silver they die instantly. A silver bullet is an option that can simply and clearly solve a problem that has no other (viable) solution. Part of game design is trying to differentiate the player’s options from one another, by making them good at different things. The easy way to do this to give enemies special resistances that can only be penetrated if you use a specific option. The trouble is that if a problem has a specific solution, then it’s not an interesting choice to solve it. There’s no tradeoffs, and no depth. Continue reading

Running Away is Deep!

Can having the option of fighting an enemy or running away be a form of depth?

Yes! Absolutely!

But more appropriately, the question generally tends to be, is having the option of fighting an enemy or running past them a form of depth?

NES games are the masters of this. Especially Castlevania 3 and Contra. Enemies in old games tend to have contact damage, they hurt you if you touch them. Then they’re set up in places where they block your way. This means that to get past them, you need to brush up against them, potentially hurting yourself. Continue reading

What Should be Prioritized in a Fighting Game?

What should be prioritized in making a fighting game? Is balance near the top?

The way I like to put it is, Balance is the least important thing that is still important. It’s way more important for the game to be fun than for it to be balanced.

In terms of sales success, I’d say it’s important to have a lot of characters and good single player content. Also looking good is a big factor.In terms of making the game good, it’s about making Rock-Paper-Scissors loops. It’s about making it so there’s a good web of these RPS loops going around everywhere, so you can beat everything in a couple different ways, usually varying by scenario. Continue reading

Beginner’s Traps

What do you think of beginner’s traps? Can they be interesting? Or are they just doomed to be frustrating for players?

I’d prefer that games don’t have beginner traps. I generally don’t think they’re particularly interesting.

One exception would be Undertale, where it’s used for comedic effect, where they mislead you in the ruins into thinking that it’s possible to spare enemies by weakening them, like pokemon. Then Toriel has an HP range where you’ll instantly kill her as you’re weakening her. So you’re set up with a false expectation, then it’s taken advantage of, ruining you if you’re going for mercy. Flowey will even taunt you if you reset and try again. This is pretty cute, and no big harm if people fall for it. Continue reading

Weird Controls are Good for You

What do you think of games like Octodad or Snake Pass, where most of the difficulty comes from dealing with odd controls?

What do you think of Call of Duty, God Hand, or Mario Odyssey, where most of the difficulty comes from dealing with odd controls?

DWHfrf3VoAUM4Hs.jpg

Learning new control schemes is fun thing to do. All the control schemes we regularly use used to be awkward or confusing when we first encountered them, what do you think of the first time people played FPS games with a controller? Or the first time they played with a mouse? Or the first time they played FPS games at all? Every game was that way for all of us at some point.

What makes these control schemes so odd really is just unfamiliarity. These games are modeling specific types of interactions, and are these the worst controls they could have chosen to do that? Or the best controls? If you want to make a game about slithering like a snake, about gripping objects and wrapping around them, how else could you possibly build it?

Mark Brown did a pretty decent video explaining snakepass, and something he showed rather well was the progression from being bad at the game to coming to a fuller understanding of it, which I really like.

Weird control schemes are a bridge to modeling new types of interaction, and creating new, unfamiliar systems to learn about and develop competency in, which is what games are all about.