Making your game speedrunner-friendly - Revision history

Ais523: /* Capturability/streamability */ typo fix

2019-06-22T06:09:34Z

‎Capturability/streamability: typo fix

Ais523: /* Unlockables */ all-achievements categories

2019-06-22T05:13:32Z

‎Unlockables: all-achievements categories

LotBlind at 22:11, 9 October 2018

2018-10-09T22:11:47Z

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

2017-03-18T21:17:28Z

‎Cutscenes: mention customization of player names

Ais523: /* Determinism and recording */ typo fix

2017-02-17T23:24:40Z

‎Determinism and recording: typo fix

Ais523: /* Game flow */ typo fix

2016-12-12T02:56:41Z

‎Game flow: typo fix

LotBlind: LotBlind moved page SDA Knowledge Base:Making your game speedrunner-friendly to Making your game speedrunner-friendly: Publishing (moving to correct place now)

2016-12-11T20:44:41Z

LotBlind moved page SDA Knowledge Base:Making your game speedrunner-friendly to Making your game speedrunner-friendly: Publishing (moving to correct place now)

LotBlind: LotBlind moved page User:Ais523/Making your game speedrunner-friendly to SDA Knowledge Base:Making your game speedrunner-friendly: Publishing

2016-12-11T20:41:47Z

LotBlind moved page User:Ais523/Making your game speedrunner-friendly to SDA Knowledge Base:Making your game speedrunner-friendly: Publishing

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

2016-12-04T06:52:35Z

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

Show changes

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

2016-09-23T02:00:49Z

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

Show changes

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

@@ Line 91: / Line 91: @@
 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.
+One problem is that the act of unlocking something can potentially speed up or slow down a run, meaning that players with a brand new game install or cartridge are advantaged or disadvantaged compared to players who've been playing on one install or cartridge for a while. Having to sit through "new cartridge interruptions" on a TAS (which plays from a clean install) would make the game less entertaining to watch; and needing to reinstall the game every run would obviously be very detrimental to the reset cycle! This can be fixed via ensuring that "you have unlocked X" messages are entirely cosmetic and have no influence on the game while you're playing it. An alternative fix, which is generally less helpful but which is worth doing in addition to other fixes in order to make it impossible to mess your unlockables up in a way that will make the game entirely unspeedrunnable, is to have a method of resetting a game to a "fresh install" state (with suitably scary warnings to discourage casual players from doing it, or alternatively designing the method to require editing game files directly so that casual players never discover it). This will make sure that nobody will ever be entirely locked out of a "things locked / things unlocked" state that would be helpful for a run (and also makes it viable to speedrun categories such as "start with everything locked, and unlock everything").
 Another problem is that things such as the ability to skip cutscenes, and options that would make it possible to practice the run or do IL competition, are sometimes locked until the game is completed; more commonly, it's common to lock playable characters, and sometimes one of the unlockable characters will be better for speedrunning than the ones that are unlocked by default. If there's a reason (either category-wise, such as with a TAS, or gameplay-wise, typically due to a glitch) to want to run from a clean install/cartridge, the fact that everything is locked there can end up making some forms of speedrun impossible. The normal approach here is to have some way to ''override'' the lock, hidden by any means you want (feel free to discourage players from using it). It's worth noting that overriding a lock in order to make a speedrun category possible from a clean install/cartridge is one of the few circumstances in which the use of cheat codes is generally accepted in speedrunning, even though it's nearly always considered abhorrent; that's how desperate speedrunners can be to be allowed to play the categories they want to play.

← Older revision		Revision as of 22:11, 9 October 2018
Line 248:		Line 248:

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

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

@@ Line 125: / Line 125: @@
 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.)
+Most cases of nondeterminism are simply errors on the developer's part, and fixing them improves the game. However, there's one notable exception: nondeterminism from randomness is normally intentional and intended to add to the game. Randomness is problematic for speedrunners for the same reason that other nondeterminism sources are, but sometimes you might want to keep it in your game for gameplay reasons (especially because it often genuinely improves the gameplay, and speedrunners will benefit from the improved gameplay too). As such, you might want to use a gameplay-based solution to the problems with nondeterminism from randomness, rather than the technical solution of removing the randomness. Some of these were discussed earlier. (Note, though, that if the randomness isn't essential to the gameplay, removing it is still a good idea; for example, if the player is expected to fire 100 shots at an enemy to defeat them and the shots randomly deal either 1 or 2 damage, changing them to alternate between dealing 1 damage and dealing 2 damage is unlikely to have a huge effect on the game and yet will eliminate that randomness from being a factor.)
 On the subject of determinism, something that speedrunners like is the ability to record their games in such a way that they can later look over the recording to see what happened, frame by frame. This is obviously used for posting world records, and less obviously used for recreating glitches. Of course, it's possible to record a game using a screen recording program to see what's happening onscreen, and this is widely done, but screen recordings take up a large amount of space and so most players don't make them habitually. If you have a deterministic engine, you can record the initial gamestate and the player's input at every frame, and create a recording of the game that way. These recordings tend to be small enough that you can safely save them automatically, meaning that nobody will regret having failed to set their screen recorder up upon getting a record in what was meant to be a practice run, or stumbling across a crazy glitch. Another advantage of this sort of recording is that it recreates the gamestate rather than just the view on screen (so that by editing the recording, it's possible to answer "what would have happened" questions, something that makes life much easier for routers). This feature isn't essential, but if you have a deterministic engine, it doesn't cost much to add and will make your players happier. (It also makes it possible, in a crude way, to TAS a game that doesn't have an appropriate TAS emulator, via editing recordings.)

@@ Line 43: / Line 43: @@
 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.
+Another method you can use is to make fast movement interesting from a strategic point of view. Perhaps there's a relatively straightforward way to move faster like holding a key, but with some cost to doing so. This could be on a short timescale (a common implementation is that running drains a meter that's restored by waiting, and the character is more vulnerable while the meter is low/recharging, forcing a tradeoff between moving quickly and staying alive). It could be subtle rather than an overt mechanic; one of the best examples is that in many games, being knocked back by being damaged by an enemy moves the player faster than running would, allowing speedrunners to trade their character's health points for temporary fast movement (as they can often manipulate the enemies into knocking them forward instead). It could also be on a large timescale (e.g. purchasable consumables that make you move faster), although note that given that moving from one place to another forms the bulk of most games (unless they consist of a series of small, tightly constrained scenarios), speedrunners are likely to spend their money on faster movement in preference to almost anything else.
 Finally, in a situation that's otherwise boring, you can make it more interesting to a speedrunner by giving them more to manage at once. Walking through a corridor is uninteresting, but walking through a corridor while dodging bullets, or using your other hand to navigate a menu, is much more interesting. This isn't quite as good as the other options, though, because although the skill ceiling is higher, it's still finite; if players can negotiate the secondary task without wasting any time in the walking, they get the best possible time, and doing better than "good enough" at the secondary task thus doesn't improve the player's time further. (That said, a nice advantage of this trick is that it works on autoscrollers too; if you need to put one somewhere a speedrunner will see it, which can be unavoidable in 100% play, keeping the player occupied will help to prevent them becoming bored.)

← Older revision	Revision as of 20:44, 11 December 2016
(No difference)

← Older revision	Revision as of 20:41, 11 December 2016
(No difference)