What features should a developer put in their game for speedrunners?

larsiusprime

Edit history:

larsiusprime: 2016-07-02 08:28:28 pm

larsiusprime: 2016-07-02 08:26:11 pm

2016-07-02 08:25:46 pm

Hey there, I've been a fan of speed-running for a long time now but I've only ever lurked on the archive until signing up for an account just now.

I hope there's no rule against this or anything, but I'm a game developer and I'm really interested in what features, if any, should a dev put in their game to make it more attractive/interesting to speedrunners? This is assuming the game itself is already finished; I'm speaking mostly in terms of UX / quality of life features rather than your basic criteria about what makes a game speed-runnable in the first place (don't have it take a fixed amount of time no matter what, etc).

I have a specific game in mind (mine), but I don't know if leading with that is bad form on this forum or not, so I'll start things out more generally. In any case, here's some things I've thought about:

- Cutscene / tutorial autoskip option
- In-game timer
- Should it contain built-in splits? Does the community prefer to define those themselves? If so, should the game provide an API or data format for user-defined splits?
- Should it clock real time or game time? (IE, real time elapsed vs. game time simulated not counting slowdown / fps drops)
- If the game includes fast-forward or slow-down for UX purposes, should the clock track absolute time vs. relative time, or both?
- Should the clock split out time spent in menus vs time spent in stuff like meta stuff like overworlds/towns/shops vs time spent in core gameplay?
- What are the best ways to track completion? Do you prefer one big fat 0-100% tracker, or do you like it broken down by categories of thing, or both?
- I know glitches and exploits and bugs are often a big part of runs. For a game that's released & mature, but continuously patched for this sort of thing, how do you deal with that? What do you want to see from the developer?
- For a PC game with a multitude of resolution options, how do you go about picking a preferred default? "Whatever's fastest" or "1080p fullscreen with medium settings", etc?

Thread title:

Hey there, I've been a fan of speed-running for a long time now but I've only ever lurked on the archive until signing up for an account just now.

I hope there's no rule against this or anything, but I'm a game developer and I'm really interested in what features, if any, should a dev put in their game to make it more attractive/interesting to speedrunners? This is assuming the game itself is already finished; I'm speaking mostly in terms of UX / quality of life features rather than your basic criteria about what makes a game speed-runnable in the first place (don't have it take a fixed amount of time no matter what, etc).

I have a specific game in mind (mine), but I don't know if leading with that is bad form on this forum or not, so I'll start things out more generally. In any case, here's some things I've thought about:

- Cutscene / tutorial autoskip option
- In-game timer
  - Should it contain built-in splits? Does the community prefer to define those themselves? If so, should the game provide an API or data format for user-defined splits?
  - Should it clock real time or game time? (IE, real time elapsed vs. game time simulated not counting slowdown / fps drops)
  - If the game includes fast-forward or slow-down for UX purposes, should the clock track absolute time vs. relative time, or both?
  - Should the clock split out time spent in menus vs time spent in stuff like meta stuff like overworlds/towns/shops vs time spent in core gameplay?
- What are the best ways to track completion? Do you prefer one big fat 0-100% tracker, or do you like it broken down by categories of thing, or both?
- I know glitches and exploits and bugs are often a big part of runs. For a game that's released & mature, but continuously patched for this sort of thing, how do you deal with that? What do you want to see from the developer?
- For a PC game with a multitude of resolution options, how do you go about picking a preferred default? "Whatever's fastest" or "1080p fullscreen with medium settings", etc?

Ekelbatzen

2016-07-03 05:19:50 am

Quote from larsiusprime:

- Should it contain built-in splits? Does the community prefer to define those themselves? If so, should the game provide an API or data format for user-defined splits?

Normally people program ASL scripts for LiveSplit because most devs don't provide them. This works by searching for the necessary code variables via CheatEngine, then finding RAM pointers for them, but only if the
game(-engine) allows this, Unity for example is really difficult to manage. If you don't already provide a script it may help to assign the relevant code variables to a static class or make them static, I don't know yet how it works in code. Best case is that the variable in RAM is a static address that never changes, instead of looking for dynamic pointers.

Quote from larsiusprime:

- If the game includes fast-forward or slow-down for UX purposes, should the clock track absolute time vs. relative time, or both?

Depends on whether you track real time or game time I guess, for real time I would say RL time measuring.

Quote from larsiusprime:

- Should the clock split out time spent in menus vs time spent in stuff like meta stuff like overworlds/towns/shops vs time spent in core gameplay?

Splits normally only pause (Gametime) in irrelevant menus, mostly only loading screens. Some runs may depend on changing ingame settings quick or doing some menu or save glitches, so that time should still count.

Quote from larsiusprime:

- What are the best ways to track completion? Do you prefer one big fat 0-100% tracker, or do you like it broken down by categories of thing, or both?

Most autosplitters I've seen for games that take more than a few minutes do multiple segments so you can track how well you are doing.

Quote from larsiusprime:

- I know glitches and exploits and bugs are often a big part of runs. For a game that's released & mature, but continuously patched for this sort of thing, how do you deal with that? What do you want to see from the developer?

Runners may run different versions of a game, but it might become seperate run categories if there are advantages between the versions.

Quote from larsiusprime:

- For a PC game with a multitude of resolution options, how do you go about picking a preferred default? "Whatever's fastest" or "1080p fullscreen with medium settings", etc?

Depends on the game, but of course in most cases you want high FPS, after that better graphics only if your system can run it.

[quote="larsiusprime"]
  - Should it contain built-in splits? Does the community prefer to define those themselves? If so, should the game provide an API or data format for user-defined splits?[/quote]
Normally people program ASL scripts for LiveSplit because most devs don't provide them. This works by searching for the necessary code variables via CheatEngine, then finding RAM pointers for them, but only if the
game(-engine) allows this, Unity for example is really difficult to manage. If you don't already provide a script it may help to assign the relevant code variables to a static class or make them static, I don't know yet how it works in code. Best case is that the variable in RAM is a static address that never changes, instead of looking for dynamic pointers.

[quote="larsiusprime"]
- If the game includes fast-forward or slow-down for UX purposes, should the clock track absolute time vs. relative time, or both?[/quote]
Depends on whether you track real time or game time I guess, for real time I would say RL time measuring.

[quote="larsiusprime"]
- Should the clock split out time spent in menus vs time spent in stuff like meta stuff like overworlds/towns/shops vs time spent in core gameplay?[/quote]
Splits normally only pause (Gametime) in irrelevant menus, mostly only loading screens. Some runs may depend on changing ingame settings quick or doing some menu or save glitches, so that time should still count.

[quote="larsiusprime"]
- What are the best ways to track completion? Do you prefer one big fat 0-100% tracker, or do you like it broken down by categories of thing, or both?[/quote]
Most autosplitters I've seen for games that take more than a few minutes do multiple segments so you can track how well you are doing.

[quote="larsiusprime"]
- I know glitches and exploits and bugs are often a big part of runs. For a game that's released & mature, but continuously patched for this sort of thing, how do you deal with that? What do you want to see from the developer?[/quote]
Runners may run different versions of a game, but it might become seperate run categories if there are advantages between the versions.

[quote="larsiusprime"]
- For a PC game with a multitude of resolution options, how do you go about picking a preferred default? "Whatever's fastest" or "1080p fullscreen with medium settings", etc?[/quote] Depends on the game, but of course in most cases you want high FPS, after that better graphics only if your system can run it.

ais523

Edit history:

ais523: 2016-07-03 10:44:47 am

2016-07-03 10:41:26 am

I really need to make some sort of full list of things developers should add to games to make them more speedrunnable, because the question comes up a lot and I keep forgetting things. First, to answer the points you mention:

- In terms of cutscene skips and the like, the underlying reason is that one thing that speedrunners really want is to speed up the reset cycle. If you make a mistake, you want to be able to get back into the action as quickly as possible. Long unskippable cutscenes get in the way of that, and even pressing a cutscene skip combination can slow it down by a couple of seconds (which can get annoying over time, depending on the game's genre; it's less bad in slow-paced games like RPGs, and worse in faster games like platformers and shooters). An option to disable cutscenes entirely is thus a good idea, and if your game's tutorials are skippable (advisable if they aren't interesting to play through), an option to automatically decline all tutorials also sounds like a good idea. Along similar lines, there should probably be a button combination to restart from the last save that can be quickly pressed to restart. (A single button is probably a bad idea here because it can be pressed by mistake, so most games use a chord or sequence of buttons; most commonly, the first button pressed in the sequence is the button that pauses the game, making it very unlikely to trigger by mistake unless pausing is a major part of the game's gameplay.)

- With an in-game timer, the most important thing is accuracy; count every frame of gameplay, stop counting during loading times (assuming a PC game; on other platforms doing this still helps but is merely nice rather than essential), never let the timer skip backwards for any reason (rounding errors is a common one). You can choose what's important for the timer to count during your game, but it should be based on where the "heart" of your game's gameplay is; if the game has a heavily menu-driven interface that uses menus for most of its gameplay, you'd count menus, whereas if menus were something that the player would hardly ever use in the normal flow of gameplay, you should probably stop the timer during them. The timer should basically be counting the period of time in which the runner is making decisions and pressing inputs; thus, if your game has some way to manipulate time, the timer should ignore that and keep counting in realtime anyway. (A good example here is Braid; its speedrun timer is immune to the game's normal time-manipulation mechanics. In fact, if you look closely at it, it has a green tint, which is Braid's universal signal for "this thing is immune to time manipulation".) You shouldn't count cutscenes or things like score countups at the end of levels (the latter is so that players don't have to play to minimize their score in order to save time; this is especially important if going fast gives you score!). If you're not sure what the best thing to count would be, having multiple in-game timers that count different things makes sense. If your game has multiple levels that are mostly or entirely independent of each other, I'd also recommend a timer for the individual levels so that speedrunners can make IL tables.

- In terms of splits, the feedback I've seen in the past is that speedrunners generally don't much care for the game doing splits for them (because external splitting programs tend to be much more customizable), but that autosplit programs are useful. If you want your game to work well with autosplit programs, having a couple of volatile global variables (one which indicates which area you're in, one which specifies whether you're in a loading screen) will make them much easier to write, although an actual API might be even better. (The important thing from a technical point of view is that the variables load at the same address each time (a property which is common among global variables but rare among other sorts of variable), and that accesses to them aren't optimized. In C, you would write this as a "volatile static" variable or as a "volatile" variable at file scope; many other languages have something similar, such as properties that apply to a class as a whole rather than an individual object of that class (these are also effectively global variables). What you want to avoid is having the relevant variables hidden inside an object that's dynamically allocated with an operator like "malloc" or "new".)

- Completion tracking in the game helps to avoid arguments over what a 100% run is. However, occasionally a developer's intended definition of 100% is ridiculous and thus speedrunners adopt a different metric. The best example I've seen here is the Metroid Prime series, which have separate percentage counters for 100% items (i.e. pick up every item in the game) and 100% scans (i.e. scan every enemy in the game). Early versions of Metroid Prime 1 had only the item percentage counter, and that's also the counter that speedrunners use to define 100% in all Prime games, because scanning enemies is slow and not particularly interesting (and also has "lost forever" issues). Later versions, and later games in the series, have a scan percentage counter too (apparently due to demand from casual players who like collecting scans); this counter is routinely ignored by speedrunners, with "all items" still being the 100% category. As such, you should probably have some main completion score that tracks completing everything non-tedious in the game, and possibly secondary scores if there's something you think casual players will care about but competitive players will dislike.

- In terms of glitches, you shouldn't go out of your way to add them or avoid fixing them. However, it's helpful to make old versions of the game available so that it's possible for people to compete on a level playing field (either as separate downloads, or via an option to switch to an old version of the game engine). One other thing I'd add is that you should design the game to react gracefully to impossible events. For example, if the player reaches a boss earlier than the plot of the game expects, let them fight it, and if they beat it, give them the reward that they'd normally get for defeating that boss; one of the most annoying things for speedrun routers is if they find a brand new sequence break and then discovers that the game softlocks in response rather than reacting reasonably. This may mean you need to code in support for combinations of items that you expect to be impossible. In particular, you should probably have flags for individual items/events in the game, rather than a counter that tracks how far through the plot the player is (because the counter can't handle things being done out of sequence). If you're worried about potentially unwinnable situations affecting casual players due to skips, an alternative is to "fast forward" the game to the point which the player skipped to, i.e. giving the player all items they should theoretically have a point if they reach that point early.

- Ideally the game should be designed so that all resolution options are equally fast, meaning that speedrunners have a personal choice to pick whichever one they find most reasonable for their game. One thing I'd note here is that if you can easily make the game capable of running in a window, you should (especially if you can do "borderless" mode where you remove the window decorations and the window occupies the whole screen, making it look like it's fullscreen, but even if you can't); this makes life much easier for streaming programs like OBS, and thus makes it easier for runners to set up a stream.

Some things you didn't touch on:

- Having a robust save system is very useful for segmented speedruns and for practicing. An ideal for practicing is the ability to make savestates (i.e. you can save anywhere, and the game can be loaded at exactly the point you saved it with a single keypress); depending on the game's complexity and genre, this might either be easy or almost impossible. Speedrunners trying to learn a trick will savestate just before it and then try it hundreds of times in a row until they've got it down, and having to play through the level to reach that point makes it much slower. If you can't do this, you should at least have a level select or equivalent to let players get to a particular part of the game quickly. (All this can be hidden in a separate "practice mode" if it would interfere with the plot/idea behind the game for some reason.) I'd also strongly recommend a "copy save" feature; there are a huge number of ways to screw up saving in such a way that it makes it hard to create segmented runs or to make a set of saves for practice, but implementing a way to copy saves lets people work around pretty much any mistake you could make in that respect. (This doesn't necessarily have to be part of the game's interface; for a PC game, you could allow players to copy saves directly on the filesystem instead.)

- Level design is also something that can attract or repel speedrunners. In particular, people will only enjoy speedrunning a game if they have a lot of influence on how fast or slowly it goes. The most obvious thing to do here is to avoid/minimize "autoscrolling" levels or sections of the game which are completed via surviving for a fixed length of time; human speedrunners will prefer to have none of these in their speedruns, and TASers like to have exactly one (so that they can do a glitch demonstration without having to waste time to do so). A common trick is to have these exist in the game, but in places that aren't on the any% (i.e. fastest) path, so that they don't come up in most speedrun categories. Less obvious, but related, is "frame rules": points at which you have to wait for something attached to a global timer to happen. (An example would be a platform that moves slowly back and forth and starts moving when you enter a level; if the platform needs to be used as part of the fastest sequence through the level, then players will wait for it, basically causing minor mistakes beforehand to become irrelevant because you need to wait for the platform anyway.) Frame rules aren't disastrous, but it's still better to avoid them if there's a reasonable alternative (in this case, you could start a set of platforms moving only when the player got nearby, so they'd always be in the same place upon reaching them). Likewise, you don't want long easy sections followed by difficult sections without an ability to save in between, because the speedrunner then has to replay the easy section each time they attempt the difficult section.

- Be careful with how you use randomness in the game. Randomness can be a good thing, due to forcing speedrunners to think on their feet, but it's more commonly a bad thing, because it can lead to speedruns becoming a test of who's luckiest rather than who's most skilful. As such, if your game contains random behaviour, you should try to mitigate the extent to which that will influence a player's time. Examples include randomizing the sequence in which level segments appear but making sure that the same set appears overall, limiting randomness so that all options have similar lengths (e.g. if you create a random maze, ensuring that the path that solves it has a constant length and merely randomizing its shape and that of the dead ends) and ensuring that the player never has to guess (e.g. in the case of the maze, making the entire maze layout visible on the minimap rather than forcing the player to explore a passageway to see if it's a dead end or not). If the game relies heavily on randomness, consider adding a "set seed" option that can be used to make the game reproducible; this can be used for seeded speedruns (so that your game can also be enjoyed by runners who dislike randomness), and to make races fair and more interesting to watch (you get all participants in the race to play on a seed that they've never seen before, so things are random from their point of view, but differences between the various runners will be due to their choices rather than the RNG's).

- Try to minimize lag (times when the game runs more slowly because the computer it's on can't process as fast as the game is trying to run). Controlling lag can be an important part of speedruns, but few people really enjoy it, and lag reduction methods can be very boring to watch (a common such method is to point the camera away from the action so that the graphics rendering has less work to do, making it hard for viewers to see what's going on as a side effect) so it's best to try to reduce the impact it has on the game. The usual method to do this is to allow the graphics settings to be turned down. You might want to consider adding an FPS meter to the game as an option (or even just adding it unconditionally if there's spare room in the UI), and perhaps making it change colour if the game is running much more slowly than it "should" be; this'll both help you notice lag when developing, and allow players to understand how the game behaves from a lag point of view. (At least one competitive gaming community I'm aware of also uses the game's FPS meter as a method of detecting cheating via intentionally lagging the game to make it easier to play.) On that subject, it's worth putting in some thought as to what your game's physics framerate should be (equal to the screen's vblank rate ("vsync"), fixed 60/30/20 fps, or customizable); having a fixed physics framerate can help avoid issues such as framerate-sensitive glitches.

- Likewise, try to minimize the game's "input lag" (the length of time between when the player presses a button and when the result is visible onscreen). The way to do this is to be intelligent about when you read from the controller/keyboard; you want to do it immediately before your game's physics calculations, and you want those to happen immediately before rendering. This makes it easier for speedrunners to perform precise tricks and to react better to what they seen onscreen.

And finally, something that always comes up in these threads: one of the most important things is to make your game fun! If people don't like playing your game, they probably won't enjoy speedrunning it either.

There are probably other things too, but I can't remember them right now. Hopefully this will work as a starting point, though.

I really need to make some sort of full list of things developers should add to games to make them more speedrunnable, because the question comes up a lot and I keep forgetting things. First, to answer the points you mention:

- In terms of cutscene skips and the like, the underlying reason is that one thing that speedrunners really want is to speed up the reset cycle. If you make a mistake, you want to be able to get back into the action as quickly as possible. Long unskippable cutscenes get in the way of that, and even pressing a cutscene skip combination can slow it down by a couple of seconds (which can get annoying over time, depending on the game's genre; it's less bad in slow-paced games like RPGs, and worse in faster games like platformers and shooters). An option to disable cutscenes entirely is thus a good idea, and if your game's tutorials are skippable (advisable if they aren't interesting to play through), an option to automatically decline all tutorials also sounds like a good idea. Along similar lines, there should probably be a button combination to restart from the last save that can be quickly pressed to restart. (A single button is probably a bad idea here because it can be pressed by mistake, so most games use a chord or sequence of buttons; most commonly, the first button pressed in the sequence is the button that pauses the game, making it very unlikely to trigger by mistake unless pausing is a major part of the game's gameplay.)

- With an in-game timer, the most important thing is accuracy; count every frame of gameplay, stop counting during loading times (assuming a PC game; on other platforms doing this still helps but is merely nice rather than essential), never let the timer skip backwards for any reason (rounding errors is a common one). You can choose what's important for the timer to count during your game, but it should be based on where the "heart" of your game's gameplay is; if the game has a heavily menu-driven interface that uses menus for most of its gameplay, you'd count menus, whereas if menus were something that the player would hardly ever use in the normal flow of gameplay, you should probably stop the timer during them. The timer should basically be counting the period of time in which the runner is making decisions and pressing inputs; thus, if your game has some way to manipulate time, the timer should ignore that and keep counting in realtime anyway. (A good example here is Braid; its speedrun timer is immune to the game's normal time-manipulation mechanics. In fact, if you look closely at it, it has a green tint, which is Braid's universal signal for "this thing is immune to time manipulation".) You shouldn't count cutscenes or things like score countups at the end of levels (the latter is so that players don't have to play to minimize their score in order to save time; this is especially important if going fast gives you score!). If you're not sure what the best thing to count would be, having multiple in-game timers that count different things makes sense. If your game has multiple levels that are mostly or entirely independent of each other, I'd also recommend a timer for the individual levels so that speedrunners can make IL tables.

- In terms of splits, the feedback I've seen in the past is that speedrunners generally don't much care for the game doing splits for them (because external splitting programs tend to be much more customizable), but that autosplit programs are useful. If you want your game to work well with autosplit programs, having a couple of volatile global variables (one which indicates which area you're in, one which specifies whether you're in a loading screen) will make them much easier to write, although an actual API might be even better. (The important thing from a technical point of view is that the variables load at the same address each time (a property which is common among global variables but rare among other sorts of variable), and that accesses to them aren't optimized. In C, you would write this as a "volatile static" variable or as a "volatile" variable at file scope; many other languages have something similar, such as properties that apply to a class as a whole rather than an individual object of that class (these are also effectively global variables). What you want to avoid is having the relevant variables hidden inside an object that's dynamically allocated with an operator like "malloc" or "new".)

- Completion tracking in the game helps to avoid arguments over what a 100% run is. However, occasionally a developer's intended definition of 100% is ridiculous and thus speedrunners adopt a different metric. The best example I've seen here is the Metroid Prime series, which have separate percentage counters for 100% items (i.e. pick up every item in the game) and 100% scans (i.e. scan every enemy in the game). Early versions of Metroid Prime 1 had only the item percentage counter, and that's also the counter that speedrunners use to define 100% in all Prime games, because scanning enemies is slow and not particularly interesting (and also has "lost forever" issues). Later versions, and later games in the series, have a scan percentage counter too (apparently due to demand from casual players who like collecting scans); this counter is routinely ignored by speedrunners, with "all items" still being the 100% category. As such, you should probably have some main completion score that tracks completing everything non-tedious in the game, and possibly secondary scores if there's something you think casual players will care about but competitive players will dislike.

- In terms of glitches, you shouldn't go out of your way to add them or avoid fixing them. However, it's helpful to make old versions of the game available so that it's possible for people to compete on a level playing field (either as separate downloads, or via an option to switch to an old version of the game engine). One other thing I'd add is that you should design the game to react gracefully to impossible events. For example, if the player reaches a boss earlier than the plot of the game expects, let them fight it, and if they beat it, give them the reward that they'd normally get for defeating that boss; one of the most annoying things for speedrun routers is if they find a brand new sequence break and then discovers that the game softlocks in response rather than reacting reasonably. This may mean you need to code in support for combinations of items that you expect to be impossible. In particular, you should probably have flags for individual items/events in the game, rather than a counter that tracks how far through the plot the player is (because the counter can't handle things being done out of sequence). If you're worried about potentially unwinnable situations affecting casual players due to skips, an alternative is to "fast forward" the game to the point which the player skipped to, i.e. giving the player all items they should theoretically have a point if they reach that point early.

- Ideally the game should be designed so that all resolution options are equally fast, meaning that speedrunners have a personal choice to pick whichever one they find most reasonable for their game. One thing I'd note here is that if you can easily make the game capable of running in a window, you should (especially if you can do "borderless" mode where you remove the window decorations and the window occupies the whole screen, making it [i]look[/i] like it's fullscreen, but even if you can't); this makes life much easier for streaming programs like OBS, and thus makes it easier for runners to set up a stream.

Some things you didn't touch on:

- Having a robust save system is very useful for segmented speedruns and for practicing. An ideal for practicing is the ability to make savestates (i.e. you can save anywhere, and the game can be loaded at exactly the point you saved it with a single keypress); depending on the game's complexity and genre, this might either be easy or almost impossible. Speedrunners trying to learn a trick will savestate just before it and then try it hundreds of times in a row until they've got it down, and having to play through the level to reach that point makes it much slower. If you can't do this, you should at least have a level select or equivalent to let players get to a particular part of the game quickly. (All this can be hidden in a separate "practice mode" if it would interfere with the plot/idea behind the game for some reason.) I'd also strongly recommend a "copy save" feature; there are a huge number of ways to screw up saving in such a way that it makes it hard to create segmented runs or to make a set of saves for practice, but implementing a way to copy saves lets people work around pretty much any mistake you could make in that respect. (This doesn't necessarily have to be part of the game's interface; for a PC game, you could allow players to copy saves directly on the filesystem instead.)

- Level design is also something that can attract or repel speedrunners. In particular, people will only enjoy speedrunning a game if they have a lot of influence on how fast or slowly it goes. The most obvious thing to do here is to avoid/minimize "autoscrolling" levels or sections of the game which are completed via surviving for a fixed length of time; human speedrunners will prefer to have none of these in their speedruns, and TASers like to have exactly one (so that they can do a glitch demonstration without having to waste time to do so). A common trick is to have these exist in the game, but in places that aren't on the any% (i.e. fastest) path, so that they don't come up in most speedrun categories. Less obvious, but related, is "frame rules": points at which you have to wait for something attached to a global timer to happen. (An example would be a platform that moves slowly back and forth and starts moving when you enter a level; if the platform needs to be used as part of the fastest sequence through the level, then players will wait for it, basically causing minor mistakes beforehand to become irrelevant because you need to wait for the platform anyway.) Frame rules aren't [i]disastrous[/i], but it's still better to avoid them if there's a reasonable alternative (in this case, you could start a set of platforms moving only when the player got nearby, so they'd always be in the same place upon reaching them). Likewise, you don't want long easy sections followed by difficult sections without an ability to save in between, because the speedrunner then has to replay the easy section each time they attempt the difficult section.

- Be careful with how you use randomness in the game. Randomness can be a good thing, due to forcing speedrunners to think on their feet, but it's more commonly a bad thing, because it can lead to speedruns becoming a test of who's luckiest rather than who's most skilful. As such, if your game contains random behaviour, you should try to mitigate the extent to which that will influence a player's time. Examples include randomizing the sequence in which level segments appear but making sure that the same set appears overall, limiting randomness so that all options have similar lengths (e.g. if you create a random maze, ensuring that the path that solves it has a constant length and merely randomizing its shape and that of the dead ends) and ensuring that the player never has to guess (e.g. in the case of the maze, making the entire maze layout visible on the minimap rather than forcing the player to explore a passageway to see if it's a dead end or not). If the game relies heavily on randomness, consider adding a "set seed" option that can be used to make the game reproducible; this can be used for seeded speedruns (so that your game can also be enjoyed by runners who dislike randomness), and to make races fair and more interesting to watch (you get all participants in the race to play on a seed that they've never seen before, so things are random from their point of view, but differences between the various runners will be due to their choices rather than the RNG's).

- Try to minimize lag (times when the game runs more slowly because the computer it's on can't process as fast as the game is trying to run). Controlling lag can be an important part of speedruns, but few people really enjoy it, and lag reduction methods can be very boring to watch (a common such method is to point the camera away from the action so that the graphics rendering has less work to do, making it hard for viewers to see what's going on as a side effect) so it's best to try to reduce the impact it has on the game. The usual method to do this is to allow the graphics settings to be turned down. You might want to consider adding an FPS meter to the game as an option (or even just adding it unconditionally if there's spare room in the UI), and perhaps making it change colour if the game is running much more slowly than it "should" be; this'll both help you notice lag when developing, and allow players to understand how the game behaves from a lag point of view. (At least one competitive gaming community I'm aware of also uses the game's FPS meter as a method of detecting cheating via intentionally lagging the game to make it easier to play.) On that subject, it's worth putting in some thought as to what your game's physics framerate should be (equal to the screen's vblank rate ("vsync"), fixed 60/30/20 fps, or customizable); having a fixed physics framerate can help avoid issues such as framerate-sensitive glitches.

- Likewise, try to minimize the game's "input lag" (the length of time between when the player presses a button and when the result is visible onscreen). The way to do this is to be intelligent about when you read from the controller/keyboard; you want to do it immediately before your game's physics calculations, and you want those to happen immediately before rendering. This makes it easier for speedrunners to perform precise tricks and to react better to what they seen onscreen.

And finally, something that always comes up in these threads: one of the most important things is to make your game fun! If people don't like playing your game, they probably won't enjoy speedrunning it either.

There are probably other things too, but I can't remember them right now. Hopefully this will work as a starting point, though.

Uilnslcoap

2016-07-03 10:49:01 am

F*ckin' sanity effects...

Emphasizing a point already made: a chapter select (or similar) option, usually available after completing a level or the whole game. The ability to save everywhere is a big plus.

ais523

2016-07-03 10:55:10 am

Right, you definitely need some way to get to various parts of the game quickly to practice. If you can save anywhere, and have unlimited save slots, then it's quite easy to make your own "manual level select" via doing a run and saving repeatedly (this is how I made my practice saves for Neverwinter Nights); this is the best option if early levels have a large influence on late ones, because it's hard to know what stats a level select should give you in such a case. If the levels / sections of the game have less influence on each other, having an official way to jump to the start of a level or to play a single level (depending on how the game works) is a good idea both for practice and for IL runs. Of course, if your game's mechanics allow it, it's best to do both.

LotBlind

Edit history:

LotBlind: 2016-07-03 01:44:41 pm

2016-07-03 01:44:15 pm

This surfaces from time to time. I don't blame you for not finding either of those seeing as it took me some effort. (and you have slightly different questions)

You should hire me to speedrun-test your game. $40/hour but we can negotiate.

PS I'm going to ask someone to move this to a more appropriate thread as this is for actually running existing PC games.

PS PS ais did a pretty sick job there LULZ: I could just add about sequence breaks, glitches etc. - if 99% of casual players on 99% of their playthroughs aren't going to run into it, and it doesn't immediately lead into a) crashing, b) save file corruption, c) unwinnable states - just leave it... Tongue

Saves you some dev time and makes the game have a bit more depth. On the other hand anything that gives you a big advantage but you have to be really clever to find it - doesn't matter if it slightly breaks your precious balancing etc.

Ais I command you to make that list so someone can sticky it. What you wrote is especially good because you're talking on a very general plane.

Something no-one mentioned - I've often felt super-convenienced when there's a console and plenty of cheats/cvars/etc. available. It saves so much time doing boring testing if you can just activate cheats and set yourself to where you should be or could be at. If the game reasonably allows it, even leaving in "dev" stuff like disable drawing the world, disable drawing entities, draw hitboxes, etc. giving the runners detailed information about how the game works (e.g. how damage is rolled) as they're playing saves them a lot of hassle and enables the runs to be "smarter". Sometimes an accurate demo recording system that acts exactly the same as any external recording device would - requirement for runs recorded this way - is appreciated by those who can't/don't want to buy the latest gear (read: me Cheesy

). In that case make sure you can automatically get the recording to start when the level starts or carry across multiple levels or whatever.

If the game is an FPS or if movement is otherwise interesting / non-linear leave in a speedometer so runners can practice movement easier.

As Ais said, the game itself defining its 100% completion is nice but poll your playerbase if you're not sure what speedrunners would have fun going for.

"If there's fast-forwarding..." I feel it's the best if you count real-time so players can show off their skills by playing at a higher speed and still winning, however I'm not sure if I've ever run into this in practice and there might even be some resentment about it if it makes gameplay really stupid.

This surfaces from [url=https://forum.speeddemosarchive.com/post/im_building_a_game_for_speedrunning._i_dont_speedrun._you_do._help.html]time[/url] to [url=https://forum.speeddemosarchive.com/post/ludilogical_question_what_makes_a_game_more_funinteresting_to_route_and_speed_run.html]time[/url]. I don't blame you for not finding either of those seeing as it took me some effort. (and you have slightly different questions)

You should hire me to speedrun-test your game. $40/hour but we can negotiate.

PS I'm going to ask someone to move this to a more appropriate thread as this is for actually running existing PC games.

PS PS ais did a pretty sick job there LULZ: I could just add about sequence breaks, glitches etc. - if 99% of casual players on 99% of their playthroughs aren't going to run into it, and it doesn't immediately lead into a) crashing, b) save file corruption, c) unwinnable states - just leave it... :P Saves you some dev time and makes the game have a bit more depth. On the other hand anything that gives you a big advantage but you have to be really clever to find it - doesn't matter if it slightly breaks your precious balancing etc.

Ais I command you to make that list so someone can sticky it. What you wrote is especially good because you're talking on a very general plane.

Something no-one mentioned - I've often felt super-convenienced when there's a console and plenty of cheats/cvars/etc. available. It saves so much time doing boring testing if you can just activate cheats and set yourself to where you should be or could be at. If the game reasonably allows it, even leaving in "dev" stuff like disable drawing the world, disable drawing entities, draw hitboxes, etc. giving the runners detailed information about how the game works (e.g. how damage is rolled) as they're playing saves them a lot of hassle and enables the runs to be "smarter". Sometimes an accurate demo recording system that acts exactly the same as any external recording device would - requirement for runs recorded this way - is appreciated by those who can't/don't want to buy the latest gear (read: me :D ). In that case make sure you can automatically get the recording to start when the level starts or carry across multiple levels or whatever.

If the game is an FPS or if movement is otherwise interesting / non-linear leave in a speedometer so runners can practice movement easier.

As Ais said, the game itself defining its 100% completion is nice but poll your playerbase if you're not sure what speedrunners would have fun going for.

"If there's fast-forwarding..." I feel it's the best if you count real-time so players can show off their skills by playing at a higher speed and still winning, however I'm not sure if I've ever run into this in practice and there might even be some resentment about it if it makes gameplay really stupid.

larsiusprime

2016-07-03 02:11:31 pm

Wow, this is some extremely interesting feedback, drinking from the firehose here, haha.

So, in addition to working on my own game I'm also a major contributor to the HaxeFlixel framework, and I think a lot of this stuff is something we could standardize in the framework itself (or make available as an optional add-on from the add-ons package).

I'll need some time to think about this, but would it be okay to run some specific implementation ideas by you folks as I iterate on some of these?

Now to go from the general to the specific:

-For long form games (such as RPG's) what are some best practices? Glitches aside some of these might take hours to speedrun so they might have different requirements?

-It seems like FRAMES needs to be the basic unit of timing measurement here, no matter what. I'm assuming that this strongly favors game design built around a fixed simulation timestep? (IE speedup runs several simulation updates per real-time update, slowdown widens the gap between simulation updates and optionally interpolates positions between them)

- For games that are defaulting to autosave, a separate full-control save system (even if it's just spot saves on a keypress) seems like a must-do?

Wow, this is some extremely interesting feedback, drinking from the firehose here, haha.

So, in addition to working on my own game I'm also a major contributor to the HaxeFlixel framework, and I think a lot of this stuff is something we could standardize in the framework itself (or make available as an optional add-on from the add-ons package).

I'll need some time to think about this, but would it be okay to run some specific implementation ideas by you folks as I iterate on some of these?

Now to go from the general to the specific:

-For long form games (such as RPG's) what are some best practices? Glitches aside some of these might take hours to speedrun so they might have different requirements?

-It seems like FRAMES needs to be the basic unit of timing measurement here, no matter what. I'm assuming that this strongly favors game design built around a fixed simulation timestep? (IE speedup runs several simulation updates per real-time update, slowdown widens the gap between simulation updates and optionally interpolates positions between them)

- For games that are defaulting to autosave, a separate full-control save system (even if it's just spot saves on a keypress) seems like a must-do?

larsiusprime

Edit history:

larsiusprime: 2016-07-03 02:20:46 pm

larsiusprime: 2016-07-03 02:20:29 pm

larsiusprime: 2016-07-03 02:19:09 pm

larsiusprime: 2016-07-03 02:18:37 pm

2016-07-03 02:17:28 pm

Okay, here's my idea for a "timing split API"

-- The game has an ingame timer based on frames (in flixel, ticks of the update() function)
- The timer can also track "sub-frames" -- ie, subsequent updates() for a fixed simulation timestep, so if you're at x16 speed, count 16 sub updates for every main "real time" update
-- The ingame timer can be displayed or not displayed
-- The game has a single class called SpeedRunStats or something like that, with a large number of public static variables, all integers, and just generically numbered STAT_0 - STAT_100 or something, so they are extremely easy to find with something like cheat engine (a dyamically sized array, even if public static, might be harder to poll).
-- The game reads from a user-defined (or dev-defined, whichever) text file at loadup that determines what in game events are associated with speedrun STAT_0, STAT_1, etc. It is up to the game developer to broadcast these events "you got the magic flute!" or whatever, but the user can change what gets marked in what public static stat slots. So the dev broadcasts all sorts of interesting stats, and you decide "STAT_0 is having the magic flute, STAT_1 is being at full health, STAT_2 marks a split for finishing level 3, STAT_4 is set on the dragon's death, etc." These text files could then be shared, revised, and codified to define a specific run.
-- Possible built-in things to track by default:
- Flixel has a concept called "states" which corresponds with game screens/modes, loosely stated. Level Select vs. Mario running around vs. Inventory management, etc. Each of these could have an integer associated with it so your SpeedRunStats is always flagging which is currently active
- Could have a special stat the developer sets that notes when the player "has control" or not. This doesn't require the developer to prescribe beginning or end of the run, just demarcate "no control" and "has control" and then the speedrunner can define for themselves which counts as the beginning or end of the run, or use it for splits, etc.

Is that a good start?

Okay, here's my idea for a "timing split API"

-- The game has an ingame timer based on frames (in flixel, ticks of the update() function)
   - The timer can also track "sub-frames" -- ie, subsequent updates() for a fixed simulation timestep, so if you're at x16 speed, count 16 sub updates for every main "real time" update
-- The ingame timer can be displayed or not displayed
-- The game has a single class called SpeedRunStats or something like that, with a large number of public static variables, all integers, and just generically numbered STAT_0 - STAT_100 or something, so they are extremely easy to find with something like cheat engine (a dyamically sized array, even if public static, might be harder to poll).
-- The game reads from a user-defined (or dev-defined, whichever) text file at loadup that determines what in game events are associated with speedrun STAT_0, STAT_1, etc. It is up to the game developer to broadcast these events "you got the magic flute!" or whatever, but the user can change what gets marked in what public static stat slots. So the dev broadcasts all sorts of interesting stats, and you decide "STAT_0 is having the magic flute, STAT_1 is being at full health, STAT_2 marks a split for finishing level 3, STAT_4 is set on the dragon's death, etc." These text files could then be shared, revised, and codified to define a specific run.
-- Possible built-in things to track by default:
   - Flixel has a concept called "states" which corresponds with game screens/modes, loosely stated. Level Select vs. Mario running around vs. Inventory management, etc. Each of these could have an integer associated with it so your SpeedRunStats is always flagging which is currently active
   - Could have a special stat the developer sets that notes when the player "has control" or not. This doesn't require the developer to prescribe beginning or end of the run, just demarcate "no control" and "has control" and then the speedrunner can define for themselves which counts as the beginning or end of the run, or use it for splits, etc.

Is that a good start?

Ekelbatzen

2016-07-03 02:24:00 pm

If you want to try to find your own variables for testing, this playlist is quite good for learning the normal process of writing a LiveSplit script: https://www.youtube.com/playlist?list=PLF7E7487FE8AEA4D2

ais523

2016-07-03 04:56:21 pm

Quote from larsiusprime:

Now to go from the general to the specific:

-For long form games (such as RPG's) what are some best practices? Glitches aside some of these might take hours to speedrun so they might have different requirements?

In terms of speedruns measured in hours, if it's longer than 3-4 hours or so, you might want to put a long unskippable cutscene in the middle to give runners a chance to take a break to get water, go to the bathroom, etc. It sounds a bit silly, but the health of speedrunners is something you need to care about if the run is [i]very[/] long.

Other than that, I'd say the main thing is that you need to be even more focused on avoiding boring/downtime sections where the runner is doing things but that they aren't very interesting; a common issue in RPGs is that the player spends a lot of time running from one place to another, avoiding (or running away from) encounters; this easy, time consuming, and not very interesting. You might want to look into adding movement techniques to make such sections more interesting. For an RPG, this might be an item that allows you to run faster in the overworld and in dungeons, but with a minor resource cost (for example, in Final Fantasy XIII: Lightning Returns, if you enter battle soon after running you start with a lower ATB, so you want to stop running just before a battle happens). Platformers often do this via allowing special moves to be chained in such a way to move faster than just walking, but with a more complex movement pattern.

Quote:

-It seems like FRAMES needs to be the basic unit of timing measurement here, no matter what. I'm assuming that this strongly favors game design built around a fixed simulation timestep? (IE speedup runs several simulation updates per real-time update, slowdown widens the gap between simulation updates and optionally interpolates positions between them)

The main reason you want the game to be consistent on the basis of frames is that it avoids unreproducibility based on rounding/quantization errors. In the worst case, this can lead to some glitches being possible on some processors/framerates/whatever and impossible on others. You probably don't want people playing your game at 5fps in order to make the collision detection more tolerant, for example (which would happen with a naively implemented engine); it'd be frustrating to play and it would look terrible, but the game would go faster. Using a frame-based engine makes that sort of mistake impossible to make.

Quote:

- For games that are defaulting to autosave, a separate full-control save system (even if it's just spot saves on a keypress) seems like a must-do?

Definitely. As a concrete example, Donkey Kong 64 speedrunning was held back for years because it autosaved too aggressively, making testing very difficult (the game had a tendency to save beyond the point you were testing). If it had an ability to quit out of the game and copy your save, that wouldn't have happened. Or to put it another way: autosaving is far from a bad thing (it helps for safety in races and the like), but you want to give people some way to go back to older saves too.

[quote="larsiusprime"]Now to go from the general to the specific:

-For long form games (such as RPG's) what are some best practices? Glitches aside some of these might take hours to speedrun so they might have different requirements?[/quote]
In terms of speedruns measured in hours, if it's longer than 3-4 hours or so, you might want to put a long unskippable cutscene in the middle to give runners a chance to take a break to get water, go to the bathroom, etc. It sounds a bit silly, but the health of speedrunners is something you need to care about if the run is [i]very[/] long.

Other than that, I'd say the main thing is that you need to be even more focused on avoiding boring/downtime sections where the runner is doing things but that they aren't very interesting; a common issue in RPGs is that the player spends a lot of time running from one place to another, avoiding (or running away from) encounters; this easy, time consuming, and not very interesting. You might want to look into adding movement techniques to make such sections more interesting. For an RPG, this might be an item that allows you to run faster in the overworld and in dungeons, but with a minor resource cost (for example, in Final Fantasy XIII: Lightning Returns, if you enter battle soon after running you start with a lower ATB, so you want to stop running just before a battle happens). Platformers often do this via allowing special moves to be chained in such a way to move faster than just walking, but with a more complex movement pattern.

[quote]-It seems like FRAMES needs to be the basic unit of timing measurement here, no matter what. I'm assuming that this strongly favors game design built around a fixed simulation timestep? (IE speedup runs several simulation updates per real-time update, slowdown widens the gap between simulation updates and optionally interpolates positions between them)[/quote]
The main reason you want the game to be consistent on the basis of frames is that it avoids unreproducibility based on rounding/quantization errors. In the worst case, this can lead to some glitches being possible on some processors/framerates/whatever and impossible on others. You probably don't want people playing your game at 5fps in order to make the collision detection more tolerant, for example (which would happen with a naively implemented engine); it'd be frustrating to play and it would look terrible, but the game would go faster. Using a frame-based engine makes that sort of mistake impossible to make.

[quote]- For games that are defaulting to autosave, a separate full-control save system (even if it's just spot saves on a keypress) seems like a must-do?[/quote]
Definitely. As a concrete example, Donkey Kong 64 speedrunning was held back for years because it autosaved too aggressively, making testing very difficult (the game had a tendency to save beyond the point you were testing). If it had an ability to quit out of the game and copy your save, that wouldn't have happened. Or to put it another way: autosaving is far from a bad thing (it helps for safety in races and the like), but you want to give people some way to go back to older saves too.

ais523

Edit history:

ais523: 2016-07-03 05:04:40 pm

2016-07-03 05:04:02 pm

Quote from larsiusprime:

Okay, here's my idea for a "timing split API"

-- The game has an ingame timer based on frames (in flixel, ticks of the update() function)
- The timer can also track "sub-frames" -- ie, subsequent updates() for a fixed simulation timestep, so if you're at x16 speed, count 16 sub updates for every main "real time" update
-- The ingame timer can be displayed or not displayed

Right, that all makes a lot of sense.

Quote:

-- The game has a single class called SpeedRunStats or something like that, with a large number of public static variables, all integers, and just generically numbered STAT_0 - STAT_100 or something, so they are extremely easy to find with something like cheat engine (a dyamically sized array, even if public static, might be harder to poll).

The array needs to not be dynamically sized, because that implies it's dynamically allocated (and thus a reference rather than being stored in the class directly). You want public static integers, and you want them to be unboxed value types (e.g. "int" in Java) rather than boxed types (e.g. "Integer" in Java). (Or to summarize: your suggestion is the correct way to do it.) This will make them as easy as possible to find. (If you want to make it even easier, you might want to give the first two fixed "magic" values that can be searched for; pick random large numbers that are unlikely to be used for other purposes.)

Quote:

-- The game reads from a user-defined (or dev-defined, whichever) text file at loadup that determines what in game events are associated with speedrun STAT_0, STAT_1, etc. It is up to the game developer to broadcast these events "you got the magic flute!" or whatever, but the user can change what gets marked in what public static stat slots. So the dev broadcasts all sorts of interesting stats, and you decide "STAT_0 is having the magic flute, STAT_1 is being at full health, STAT_2 marks a split for finishing level 3, STAT_4 is set on the dragon's death, etc." These text files could then be shared, revised, and codified to define a specific run.

This is a problem that hasn't generally been solved (that of defining where to split when you don't know the route); this sounds like a good solution to it. I'll be interested to see if your solution works, and don't see why it wouldn't.

Quote:

-- Possible built-in things to track by default:
- Flixel has a concept called "states" which corresponds with game screens/modes, loosely stated. Level Select vs. Mario running around vs. Inventory management, etc. Each of these could have an integer associated with it so your SpeedRunStats is always flagging which is currently active
- Could have a special stat the developer sets that notes when the player "has control" or not. This doesn't require the developer to prescribe beginning or end of the run, just demarcate "no control" and "has control" and then the speedrunner can define for themselves which counts as the beginning or end of the run, or use it for splits, etc.

It strikes me that this is also a good way to determine when to run the ingame timer, by default.

Quote:

Is that a good start?

Yes, it seems like a pretty good idea! Thanks for making things easy for us :-)

[quote="larsiusprime"]Okay, here's my idea for a "timing split API"

-- The game has an ingame timer based on frames (in flixel, ticks of the update() function)
   - The timer can also track "sub-frames" -- ie, subsequent updates() for a fixed simulation timestep, so if you're at x16 speed, count 16 sub updates for every main "real time" update
-- The ingame timer can be displayed or not displayed
[/quote]
Right, that all makes a lot of sense.
[quote]-- The game has a single class called SpeedRunStats or something like that, with a large number of public static variables, all integers, and just generically numbered STAT_0 - STAT_100 or something, so they are extremely easy to find with something like cheat engine (a dyamically sized array, even if public static, might be harder to poll).[/quote]
The array needs to not be dynamically sized, because that implies it's dynamically allocated (and thus a reference rather than being stored in the class directly). You want public static integers, and you want them to be unboxed value types (e.g. "int" in Java) rather than boxed types (e.g. "Integer" in Java). (Or to summarize: your suggestion is the correct way to do it.) This will make them as easy as possible to find. (If you want to make it even easier, you might want to give the first two fixed "magic" values that can be searched for; pick random large numbers that are unlikely to be used for other purposes.)
[quote]-- The game reads from a user-defined (or dev-defined, whichever) text file at loadup that determines what in game events are associated with speedrun STAT_0, STAT_1, etc. It is up to the game developer to broadcast these events "you got the magic flute!" or whatever, but the user can change what gets marked in what public static stat slots. So the dev broadcasts all sorts of interesting stats, and you decide "STAT_0 is having the magic flute, STAT_1 is being at full health, STAT_2 marks a split for finishing level 3, STAT_4 is set on the dragon's death, etc." These text files could then be shared, revised, and codified to define a specific run.[/quote]
This is a problem that hasn't generally been solved (that of defining where to split when you don't know the route); this sounds like a good solution to it. I'll be interested to see if your solution works, and don't see why it wouldn't.
[quote]-- Possible built-in things to track by default:
   - Flixel has a concept called "states" which corresponds with game screens/modes, loosely stated. Level Select vs. Mario running around vs. Inventory management, etc. Each of these could have an integer associated with it so your SpeedRunStats is always flagging which is currently active
   - Could have a special stat the developer sets that notes when the player "has control" or not. This doesn't require the developer to prescribe beginning or end of the run, just demarcate "no control" and "has control" and then the speedrunner can define for themselves which counts as the beginning or end of the run, or use it for splits, etc.[/quote]
It strikes me that this is also a good way to determine when to run the ingame timer, by default.

[quote]Is that a good start?[/quote]
Yes, it seems like a pretty good idea! Thanks for making things easy for us :-)

LotBlind

2016-07-04 10:59:05 am

RPGs: What ais said about movement - Maybe you could let the player have some simple vehicles to ride around with slightly more complicated physics or "physics". I'm reminded of the bikes in Earthbound, but those are in one town and not very interesting. Instead, how about you get to buy gas for a fast-traveling bike and by driving skilfully (letting go of the gas bind while airborne lets say) you conserve the gas and get further using the same amount... or something! Same goes with fighting... Chrono Triggers party-based attacks spring to mind because a) more thought going into party selection, b) sometimes the exact positioning of enemies affects which attacks will work the best for a given fight. Anything that makes for more dynamics.

You wanna make it so (to re-emphasize what ais probably already said) that stuff is generally not IMPOSSIBLE, just unlikely. Stuff like defeating bosses early. Even many RPGs have somewhat skill-based systems (hit the enemy on the beats like Earthbound Zero or what have you) that leave room for skilful plays. Something like FF minigames sometimes require fast mashing (not so fun) or quick thinking (yes fun).

I can confirm that speedrunners hate restrictive saving Tongue

If you think you can't balance it right, make there be a separate cheating/beginner mode that otherwise works the same but allows to use cheats and save anywhere.

STAT_0 etc. - Yes that seems to make sense!

RPGs: What ais said about movement - Maybe you could let the player have some simple vehicles to ride around with slightly more complicated physics or "physics". I'm reminded of the bikes in Earthbound, but those are in one town and not very interesting. Instead, how about you get to buy gas for a fast-traveling bike and by driving skilfully (letting go of the gas bind while airborne lets say) you conserve the gas and get further using the same amount... or something! Same goes with fighting... Chrono Triggers party-based attacks spring to mind because a) more thought going into party selection, b) sometimes the exact positioning of enemies affects which attacks will work the best for a given fight. Anything that makes for more dynamics.

You wanna make it so (to re-emphasize what ais probably already said) that stuff is generally not IMPOSSIBLE, just unlikely. Stuff like defeating bosses early. Even many RPGs have somewhat skill-based systems (hit the enemy on the beats like Earthbound Zero or what have you) that leave room for skilful plays. Something like FF minigames sometimes require fast mashing (not so fun) or quick thinking (yes fun).

I can confirm that speedrunners hate restrictive saving :P If you think you can't balance it right, make there be a separate cheating/beginner mode that otherwise works the same but allows to use cheats and save anywhere.

STAT_0 etc. - Yes that seems to make sense!

larsiusprime

Edit history:

larsiusprime: 2016-07-05 12:31:14 pm

larsiusprime: 2016-07-05 12:15:47 pm

2016-07-05 12:12:43 pm

Cool, now that I've tested the waters a bit, and if it's not bad form, I'd like to go from the general to the specific to the very specific -- my own game, the one I have in mind for this.

The game is Defender's Quest, you can see a video of some of the gameplay here:

DQ is a hybrid of Tower-Defense and RPG. Think standard RPG storytelling melodrama + colorful characters & party/inventory/skill progression & management, but battles that are based on tower-defense where each tower is one of your unique, persistent, party members.

Speed up potential:

Based on y'all's feedback, this seems like the biggest issue I need to address, given the genre.
Because the battles are wave-based Tower Defense, they do generally take a certain base amount of game time to finish.

Things you can do to go faster:
- You can elect to send waves early by clicking "send next", which would speed up the battle time.
- I think for speedrunners I should have a simple toggle for "always send next right away" that you turn on and off as a mode, rather than having to OCD-click the send next button
- Since it's an RPG, there's a lot of battles, and we implement a stacked difficulty system where each battle has several difficulty modes and you can go back and replay older missions with new enemy configurations for more loot. It's not a particularly grindy game, but some amount of progression pace is needed to beat the later levels. So one way to speed up the whole time might be finding an ideal play path through the game that lets you play the minimum number of battles.
- Play optimally so that there's as little time as possible from when the last enemy has spawned to when they're all dead
- There's a few boss battles with infinite waves of mobs that repeat with increasing levels until you kill the boss. So kill the boss faster.

But the biggest, most obvious way to speed up the game is to take advantage of time dilation, and this is what I'm really interested in getting feedback on, because I could see it being either really interesting, or totally ridiculous and unworkable for speedrunners.

You can play battles on any speed between 1/4x and 16x, and can issue commands when paused. So if you're tracking *global time* rather than *simulation time*, you can play this game pretty dang fast, provided you can hotkey your way to victory like a speed typist. Playing the game this way becomes much more a test of reactions, speed, and attention than it normally is on typical speeds, but maybe that appeals to the speedrun crowd. The best analogy I can think of is Tetris played on ultra fast mode -- it always takes the same amount of basic time to get through 1000 Tetris blocks, but you can drop some of the pieces early, and you can play the game itself on a ridiculous speed and count that instead.

RNG:

The game doesn't use a lot of RNG, mostly just does it for "noise & variation", and I think I even have a class called "SortaRandom" that is just a giant table of pre-generated values that it reads from one at a time (just to scatter rocks around, etc). So I think I could very easily make all the RNG in the game purely deterministic based on a seed of the given level's file ID or something.

RNG controls the following things:
- Slight offset to enemy spawn points (just so they're not all in a straight line, and I believe this might even be purely visual, not affecting targeting/collision logic)
- Chance of certain "flavored" attacks (critical hit, poison, bleed, etc) -- I could make these use "SortaRandom", which would be deterministic but still chaotic & highly influenced by small variation, or I could simply make it "25% chance literally just means every fourth enemy gets hit" without much change to gameplay at all. Since DQ has such a high volume of attacks, whether this or that attack rolls a critical doesn't really matter, just the overall statistical average.

Quality of Life:

I think I need to put options in for:
- Autoskip cutscenes
- Autoskip tutorials
- Put in an "unskippable intermission" at certain points for pee breaks Cheesy

- Better keyboard/gamepad map controls so you don't have to waste time with error-prone scrolling & clicking, just point to your destination, hit the key, go.
- Do a very careful controls pass to make sure that fiddly, slow, or error prone mouse controls always have a keyboard / gamepad alternative
- Autosaves need to be complemented by backup incremental saves and saves-on-demand

Is that a good approach? Also, with or without these additions, does Defender's Quest sound like the kind of game speedrunners would even be interested in, or is this all a fool's errand? Tongue

Cool, now that I've tested the waters a bit, and if it's not bad form, I'd like to go from the general to the specific to the very specific -- my own game, the one I have in mind for this.

The game is Defender's Quest, you can see a video of some of the gameplay here:
https://www.youtube.com/watch?v=RwVm4vlcC-Y

DQ is a hybrid of Tower-Defense and RPG. Think standard RPG storytelling melodrama + colorful characters & party/inventory/skill progression & management, but battles that are based on tower-defense where each tower is one of your unique, persistent, party members.

[b]Speed up potential[/b]:

Based on y'all's feedback, this seems like the biggest issue I need to address, given the genre.
Because the battles are wave-based Tower Defense, they do generally take a certain base amount of game time to finish.

Things you can do to go faster:
- You can elect to send waves early by clicking "send next", which would speed up the battle time.
  - I think for speedrunners I should have a simple toggle for "always send next right away" that you turn on and off as a mode, rather than having to OCD-click the send next button
- Since it's an RPG, there's a lot of battles, and we implement a stacked difficulty system where each battle has several difficulty modes and you can go back and replay older missions with new enemy configurations for more loot. It's not a particularly grindy game, but some amount of progression pace is needed to beat the later levels. So one way to speed up the whole time might be finding an ideal play path through the game that lets you play the minimum number of battles.
- Play optimally so that there's as little time as possible from when the last enemy has spawned to when they're all dead
- There's a few boss battles with infinite waves of mobs that repeat with increasing levels until you kill the boss. So kill the boss faster.

But the biggest, most obvious way to speed up the game is to take advantage of time dilation, and this is what I'm really interested in getting feedback on, because I could see it being either really interesting, or totally ridiculous and unworkable for speedrunners.

You can play battles on any speed between 1/4x and 16x, and can issue commands when paused. So if you're tracking *global time* rather than *simulation time*, you can play this game pretty dang fast, provided you can hotkey your way to victory like a speed typist. Playing the game this way becomes much more a test of reactions, speed, and attention than it normally is on typical speeds, but maybe that appeals to the speedrun crowd. The best analogy I can think of is Tetris played on ultra fast mode -- it always takes the same amount of basic time to get through 1000 Tetris blocks, but you can drop some of the pieces early, and you can play the game itself on a ridiculous speed and count that instead.

[b]RNG[/b]:

The game doesn't use a lot of RNG, mostly just does it for "noise & variation", and I think I even have a class called "SortaRandom" that is just a giant table of pre-generated values that it reads from one at a time (just to scatter rocks around, etc). So I think I could very easily make all the RNG in the game purely deterministic based on a seed of the given level's file ID or something.

RNG controls the following things:
- Slight offset to enemy spawn points (just so they're not all in a straight line, and I believe this might even be purely visual, not affecting targeting/collision logic)
- Chance of certain "flavored" attacks (critical hit, poison, bleed, etc) -- I could make these use "SortaRandom", which would be deterministic but still chaotic & highly influenced by small variation, or I could simply make it "25% chance literally just means every fourth enemy gets hit" without much change to gameplay at all. Since DQ has such a high volume of attacks, whether this or that attack rolls a critical doesn't really matter, just the overall statistical average.

[b]Quality of Life[/b]:

I think I need to put options in for:
- Autoskip cutscenes
- Autoskip tutorials
- Put in an "unskippable intermission" at certain points for pee breaks :D
- Better keyboard/gamepad map controls so you don't have to waste time with error-prone scrolling & clicking, just point to your destination, hit the key, go.
- Do a very careful controls pass to make sure that fiddly, slow, or error prone mouse controls always have a keyboard / gamepad alternative
- Autosaves need to be complemented by backup incremental saves and saves-on-demand

Is that a good approach? Also, with or without these additions, does Defender's Quest sound like the kind of game speedrunners would even be interested in, or is this all a fool's errand? :P

ais523

2016-07-05 06:03:24 pm

I assume that each level unlocks the next when completed on Casual? I assume the any% wouldn't involve the higher difficulties at all (unless necessary to grind money, which it sounds like it will be on occasion; this is about typical for RPGs). Unless the world map is very, very extensive (which I doubt it is, given how the plot works), I think a speedrun would complete the game fast enough that breaks wouldn't be needed. Note that most likely, a speedrun of your game will involve discovering the levels which give the best grinding rewards, and playing them repeatedly to get enough money for the rest of the game, playing every other level once. (You could avoid this problem somewhat via giving a numerical bonus for a first-time completion of a level, e.g. 3 times the rewards. Obviously you'd reduce the rewards for subsequent completions to compensate.)

Your main menu is an obvious place to put a "copy save" feature, but if those three save slots are all there are, that might not be enough. (If you design the game so that copying the save files directly works, that + the three save slots + a copy save would be reasonable; you'd use the copy save for retrying segments, and the manual backups for practice.) The current save system is inappropriate for a segmented run (and this game is the sort that very much prefers segmented runs to single-segment), because being forced to gain experience upon failing a level would cause the segments to mismatch.

Your overworld (the world map) is already much more suitable for speedrunning than that of most RPGs, because it's basically just menu-driven. One thing that concerns me a little is that there's a lot of clicking in one place, then clicking in a different place to confirm. I'd advise making sure that you can double-click on a level, then double-click on the difficulty, to make the level start (and not have to wait for any animations, like the main character walking to the level, in the process).

In terms of timing, I suspect that you should have a "simulation time" timer for each level for IL purposes; the existence of "next wave" means that players will have interest in solving the puzzle of working out what the best strategy is for clearing a level ASAP. One problem is that IL'ing this game is likely to be based on grinding up a perfect set of characters first. I'd recommend having some sort of "puzzle mode", probably separate from the main game at least plot-wise, which lets you try any level you've unlocked with a fixed, powerful set of characters with fixed, powerful equipment; something like that will be necessary for IL to work, and it's where your game is most potentially interesting from a speedrun point of view (the tower defence aspects are interesting enough that they work even in the absence of the RPG aspects, and the RPG aspects complicate things a bit for speedrunning via making it hard to find a level playing field unless there's one blessed by the developer). Making the RNG deterministic is probably ideal for this, as even minor variations in when critical hits happen might affect what the perfect IL time (critting the last enemy would necessarily get you a better time, wouldn't it?). I'm in favour of using a repetitive pattern (i.e. 25% chances happening against every fourth enemy), as it makes it easier to plan out your route than having to memorize a table of RNG seeds.

On the other hand, I think a full game run would probably be based on global time. Minimizing simulation time would be very fiddly and involve repeated pausing; that's fine for short runs like IL, but nobody would want to keep that up for a full game of that length. (That said, at least there wouldn't be a problem finding time for breaks.) It'd be a run that's very much about memorizing a route and then doing precise menuing to input it; there's a subset of players that enjoy this, although you might have trouble attracting them to your game in particular. Come to think of it, this game would probably make a better TAS than speedrun. Given that it's almost deterministic as is, you could try making it completely deterministic and adding a replay + view replay feature, so that people could TAS it via editing the replays.

I have a suspicion that sending all the waves simultaneously would not be the best strategy in all battles, especially in an IL. Tower defence is basically a genre about ensuring that your characters outDPS the wave coming in, so they'd need to be substantially more powerful to handle simultaneous waves. One solution might be to have some special input (e.g. right-clicking the "send wave" button) to send all the waves at once. (To extend your Tetris analogy: the TASes don't play it on the highest possible speed as that restricts the options for placing pieces; it's physically impossible to place the pieces in the right place once they're dropping sufficiently fast.) You should note that the "next wave" feature is the only thing preventing your game being a game full of near-autoscrollers (i.e. pointless to speedrun), and so managing it correctly is where most of the speedrun interest is going to come from.

And in terms of speedrun suitability: this isn't within the mainstream of the sort of games that are most popular to speedrun, so the speedrunner audience is going to be limited, but it may well not be absent, especially in terms of IL runs (if you design the game mechanics to make them possible). There's enough going on that it's going to inspire the people who enjoy routing runs. The problem is that there's possibly more of a supply of routing-heavy games than there is demand, so the problem will be attracting the runners who are interested to your game rather than the others they could be playing. The best way is to make it a fun game so that people generally are attracted to it, and maybe some will be speedrunners already or decide to take up speedrunning, and once a community is built that'll attract more speedrunners to it.

I assume that each level unlocks the next when completed on Casual? I assume the any% wouldn't involve the higher difficulties at all (unless necessary to grind money, which it sounds like it will be on occasion; this is about typical for RPGs). Unless the world map is very, very extensive (which I doubt it is, given how the plot works), I think a speedrun would complete the game fast enough that breaks wouldn't be needed. Note that most likely, a speedrun of your game will involve discovering the levels which give the best grinding rewards, and playing them repeatedly to get enough money for the rest of the game, playing every other level once. (You could avoid this problem somewhat via giving a numerical bonus for a first-time completion of a level, e.g. 3 times the rewards. Obviously you'd reduce the rewards for subsequent completions to compensate.)

Your main menu is an obvious place to put a "copy save" feature, but if those three save slots are all there are, that might not be enough. (If you design the game so that copying the save files directly works, that + the three save slots + a copy save would be reasonable; you'd use the copy save for retrying segments, and the manual backups for practice.) The current save system is inappropriate for a segmented run (and this game is the sort that very much prefers segmented runs to single-segment), because being forced to gain experience upon failing a level would cause the segments to mismatch.

Your overworld (the world map) is already much more suitable for speedrunning than that of most RPGs, because it's basically just menu-driven. One thing that concerns me a little is that there's a lot of clicking in one place, then clicking in a different place to confirm. I'd advise making sure that you can double-click on a level, then double-click on the difficulty, to make the level start (and not have to wait for any animations, like the main character walking to the level, in the process).

In terms of timing, I suspect that you should have a "simulation time" timer for each level for IL purposes; the existence of "next wave" means that players will have interest in solving the puzzle of working out what the best strategy is for clearing a level ASAP. One problem is that IL'ing this game is likely to be based on grinding up a perfect set of characters first. I'd recommend having some sort of "puzzle mode", probably separate from the main game at least plot-wise, which lets you try any level you've unlocked with a fixed, powerful set of characters with fixed, powerful equipment; something like that will be necessary for IL to work, and it's where your game is most potentially interesting from a speedrun point of view (the tower defence aspects are interesting enough that they work even in the absence of the RPG aspects, and the RPG aspects complicate things a bit for speedrunning via making it hard to find a level playing field unless there's one blessed by the developer). Making the RNG deterministic is probably ideal for this, as even minor variations in when critical hits happen might affect what the perfect IL time (critting the last enemy would necessarily get you a better time, wouldn't it?). I'm in favour of using a repetitive pattern (i.e. 25% chances happening against every fourth enemy), as it makes it easier to plan out your route than having to memorize a table of RNG seeds.

On the other hand, I think a full game run would probably be based on global time. Minimizing simulation time would be very fiddly and involve repeated pausing; that's fine for short runs like IL, but nobody would want to keep that up for a full game of that length. (That said, at least there wouldn't be a problem finding time for breaks.) It'd be a run that's very much about memorizing a route and then doing precise menuing to input it; there's a subset of players that enjoy this, although you might have trouble attracting them to your game in particular. Come to think of it, this game would probably make a better TAS than speedrun. Given that it's almost deterministic as is, you could try making it completely deterministic and adding a replay + view replay feature, so that people could TAS it via editing the replays.

I have a suspicion that sending all the waves simultaneously would not be the best strategy in all battles, especially in an IL. Tower defence is basically a genre about ensuring that your characters outDPS the wave coming in, so they'd need to be [i]substantially[/i] more powerful to handle simultaneous waves. One solution might be to have some special input (e.g. right-clicking the "send wave" button) to send all the waves at once. (To extend your Tetris analogy: the TASes don't play it on the highest possible speed as that restricts the options for placing pieces; it's physically impossible to place the pieces in the right place once they're dropping sufficiently fast.) You should note that the "next wave" feature is the only thing preventing your game being a game full of near-autoscrollers (i.e. pointless to speedrun), and so managing it correctly is where most of the speedrun interest is going to come from.

And in terms of speedrun suitability: this isn't within the mainstream of the sort of games that are most popular to speedrun, so the speedrunner audience is going to be limited, but it may well not be absent, especially in terms of IL runs (if you design the game mechanics to make them possible). There's enough going on that it's going to inspire the people who enjoy routing runs. The problem is that there's possibly more of a supply of routing-heavy games than there is demand, so the problem will be attracting the runners who are interested to your game rather than the others they could be playing. The best way is to make it a fun game so that people generally are attracted to it, and maybe some will be speedrunners already or decide to take up speedrunning, and once a community is built that'll attract more speedrunners to it.

LotBlind

2016-07-06 11:24:37 am

I think reading your description of what the game is actually about:
- Don't know much about tower defense but you've outlined some potential problems yourself: in fact these two observations go very much hand in hand if you consider why a speedrunner wouldn't have had much interest in them.
- Therefore I think this would be an IDEAL time to count real time not game time and let players play super fast. It kinda reminds me of Half-Minute Hero as I'm sure you'll appreciate why.
- I also advice you to take a look at Dungeon Keeper runs because those share a lot of stuff with tower defence, especially levels where you fight heroes. See the runs on this site for some commentary.
- Side note: Why do you need flavor attacks if they don't really do anything? Tongue

Sounds like air-headed design there...
- Instead of having "autoskip this" and "autoskip that" etc. options - or aside from them - some games even have a special "speedrun mode" which gives you the timer etc. and removes all that extra stuff automatically.
- If you allow 16X speed are you sure the run will actually take so long the "pee break" cutscene is necessary? You do NOT want to have it there for no reason.
- Seeing as this game doesn't look terribly break-able, only one argument remains for saves anywhere, which is to test various strategies without having to do the placement of guys all over. However, letting the players see the exact rolls and such is emphasized.

"Fool's errand?" Well as I said, not a lot of tower defense runs exist because of how the games tend to work in the mean... but maybe if you advertise it in the right way? Also there's no real guarantee (no matter what you do) that anyone will run it. That's the sad truth with most releases, barring the very very high-visibility ones, because it does, after all, take considerable effort to speedrun most games on the level SDA expects for submissions here. Well, maybe speedruns.com has more runners. Perhaps you could look around for runs for other tower defence games on that site and contact a few runners if you can to share their genre-precise experiences with you.

Leading on from some of ais's thoughts:
- Balancing rewards: you can go even further and make XP gained decrease every time you redo the same fight on the same difficulty so potential runners have even less grinding to do.
- I agree that it's a bit complicated for ILs (= individual fights) if there's all the four difficulties available with different parties, and that yes, if this was desired, it should be a separate mode.

PS I recognize you now (?) for some write-ups on how Squeenix messed up those FF remakes. Gj there!

I think reading your description of what the game is actually about:
- Don't know much about tower defense but you've outlined some potential problems yourself: in fact these two observations go very much hand in hand if you consider why a speedrunner wouldn't have had much interest in them.
- Therefore I think this would be an IDEAL time to count real time not game time and let players play super fast. It kinda reminds me of Half-Minute Hero as I'm sure you'll appreciate why.
- I also advice you to take a look at Dungeon Keeper runs because those share a lot of stuff with tower defence, especially levels where you fight heroes. See the runs on this site for some commentary.
- Side note: Why do you need flavor attacks if they don't really do anything? :P Sounds like air-headed design there...
- Instead of having "autoskip this" and "autoskip that" etc. options - or aside from them - some games even have a special "speedrun mode" which gives you the timer etc. and removes all that extra stuff automatically.
- If you allow 16X speed are you sure the run will actually take so long the "pee break" cutscene is necessary? You do NOT want to have it there for no reason.
- Seeing as this game doesn't look terribly break-able, only one argument remains for saves anywhere, which is to test various strategies without having to do the placement of guys all over. However, letting the players see the exact rolls and such is emphasized.

"Fool's errand?" Well as I said, not a lot of tower defense runs exist because of how the games tend to work in the mean... but maybe if you advertise it in the right way? Also there's no real guarantee (no matter what you do) that anyone will run it. That's the sad truth with most releases, barring the very very high-visibility ones, because it does, after all, take considerable effort to speedrun most games on the level SDA expects for submissions here. Well, maybe speedruns.com has more runners. Perhaps you could look around for runs for other tower defence games on that site and contact a few runners if you can to share their genre-precise experiences with you.

Leading on from some of ais's thoughts:
- Balancing rewards: you can go even further and make XP gained decrease every time you redo the same fight on the same difficulty so potential runners have even less grinding to do.
- I agree that it's a bit complicated for ILs (= individual fights) if there's all the four difficulties available with different parties, and that yes, if this was desired, it should be a separate mode.

PS I recognize you now (?) for some write-ups on how Squeenix messed up those FF remakes. Gj there!

Zergreenone

Edit history:

Zergreenone: 2016-08-18 02:29:45 pm

Zergreenone: 2016-08-18 02:29:03 pm

Zergreenone: 2016-08-18 02:27:52 pm

Zergreenone: 2016-08-18 02:26:18 pm

Zergreenone: 2016-08-18 02:25:42 pm

Zergreenone: 2016-08-18 02:15:45 pm

Zergreenone: 2016-08-18 02:15:35 pm

2016-08-18 02:12:58 pm

I don't know whether there are hotkeys for menuing, there are obviously hotkeys for choosing units. Hotkeys are important, unless the game is actually supposed to be about mouse accuracy.

Also, repeated pausing would not be allowed for IGT (if it stops while paused), IGT is only counted if it is similar to the RTA. If you pause, and it stops the timer, it invalidates the IGT time, and you have to use RTA instead. Unless enough people decide to allow it in this specific game, obviously. Basically, you aren't really speedrunning it if you pause every few seconds, it is more of a TAS. Same would go for speeds below 1x. The non-accepted age of mythology run somewhere is the perfect example of this.

But the difference between IGT and RTA could potentially discriminate between 1x and 16x speed, if enough people ran the game.