Advice on designing a game with speed running in mind

seagaia

Edit history:

seagaia: 2016-11-20 10:55:42 am

seagaia: 2016-11-20 10:52:05 am

seagaia: 2014-03-27 04:20:49 pm

2013-11-05 09:33:41 am

Update (2016/11/20)

years later the game's done! thanks for all the suggestions.

(I made a speedrunner coupon sale for 30% off if anyone wants to try: https://seanhtch.itch.io/etospeedrunnersale)

(otherwise there is steam u can buy from) http://store.steampowered.com/app/265470

there have been a few speedrunners already taking stabs at it, too!

https://www.twitch.tv/lifning/v/102201140

--
Update (2014-3-27) - The game I'm working on, I made a demo for. Check it out and let me know what you think in terms of speed running things, or control feel: thanks! http://seanhogan.itch.io/even-the-ocean-motion-demo-1/download/ftH1aU5kG5MVRvjTTs2xqP9BE9QDhoAt85882T31 (Don't share this link)
----
Hey guys, I'm working on a game right now that it seems (after some people played it at PAX) would end up as interesting for speed running. The game in question is Even the Ocean (http://forums.tigsource.com/index.php?topic=32220.0) (I also made Anodyne which some people at SDA have sped run!).

Even the Ocean is two games ("the ocean" and "even"), but "The Ocean" seems like it would be good for speed running. The mechanic premise is that it's a platformer with wall jumping, but instead of health or a OHKO for death, there is an energy bar which can fill to the left or to the right with "Dark" or "Light" energy . More dark drastically changes your horizontal speed but you jump lower, more light drastically changes jump height but you move horizontally very slow. And then we build the game around that idea - the game progresses in "chunks", so there's a number of areas you can visit in a non-linear fashion at any point in the game. Levels themselves vary between Knytt/Metroid-like open levels, and more MMX-like linear levels.

ANYWAYS

I was wondering what are some things that I should keep in mind in terms of making it more speed run friendly!!

This is a video with the PAX prime demo running in the back - you can sort of see the energy-changing at work, a little bit.

thanks for any help!

Thread title:

Update (2016/11/20)

years later the game's done! thanks for all the suggestions.
 
(I made a speedrunner coupon sale for 30% off if anyone wants to try: https://seanhtch.itch.io/etospeedrunnersale)

(otherwise there is steam u can buy from) http://store.steampowered.com/app/265470

there have been a few speedrunners already taking stabs at it, too!

https://www.youtube.com/watch?v=dv6TEIOsI5c

https://www.twitch.tv/lifning/v/102201140

--
Update (2014-3-27) - The game I'm working on, I made a demo for. Check it out and let me know what you think in terms of speed running things, or control feel: thanks! http://seanhogan.itch.io/even-the-ocean-motion-demo-1/download/ftH1aU5kG5MVRvjTTs2xqP9BE9QDhoAt85882T31 (Don't share this link) 
----
Hey guys, I'm working on a game right now that it seems (after some people played it at PAX) would end up as interesting for speed running. The game in question is Even the Ocean (http://forums.tigsource.com/index.php?topic=32220.0) (I also made Anodyne which some people at SDA have sped run!).

Even the Ocean is two games ("the ocean" and "even"), but "The Ocean" seems like it would be good for speed running. The mechanic premise is that it's a platformer with wall jumping, but instead of health or a OHKO for death, there is an energy bar which can fill to the left or to the right with "Dark" or "Light" energy . More dark drastically changes your horizontal speed but you jump lower, more light drastically changes jump height but you move horizontally very slow. And then we build the game around that idea - the game progresses in "chunks", so there's a number of areas you can visit in a non-linear fashion at any point in the game. Levels themselves vary between Knytt/Metroid-like open levels, and more MMX-like linear levels.

ANYWAYS

[b]I was wondering what are some things that I should keep in mind in terms of making it more speed run friendly!![/b]

This is a video with the PAX prime demo running in the back - you can sort of see the energy-changing at work, a little bit.

https://www.youtube.com/watch?v=0jF2umy5CpQ&feature=player_detailpage#t=158

thanks for any help!

Judgy

Edit history:

Judgy: 2013-11-05 10:50:24 am

Judgy: 2013-11-05 10:28:09 am

2013-11-05 10:27:07 am

Borderlands 2 Glitch Hunter/ router.

There is a fine line between making a game more "speedrun friendly" and making a game which is purposely broken lol, from the sounds of the gameplay style itself it's speedrun friendly enough, its has aspects which can help / hinder your progression leaving it up to the skill of whomever is playing. metroidvania style games are very popular anyway making this an interesting prospect for many.

personally I believe this is a good formula as it is.

~Judgy~ (I broke Anodyne) <3 <3

P.S -- I'd love to play test it if you needed someone to do so before release Smiley

Lag.Com

Edit history:

Lag.Com: 2013-11-05 10:34:28 am

2013-11-05 10:33:54 am

sda loyalist

Honestly the most important thing you can do is make it fun. Speedrunners get tired of bad games before good ones (usually). The second most important thing you can do is make retrying fast - have responsive menus so you can get back into the action quickly, don't have drawn out unskippable death sequences, you get the idea.

Oh, and build in video-recording. :p

moooh

2013-11-05 11:16:54 am

Exoray

If you have any cutscene included, make sure to also add a skip-cutscene key.

doicm

2013-11-05 11:39:54 am

Design it with the purpose in mind of being like Super Metroid, where you can access areas earlier or skip items without any real in-game glitches.
Don't design it with having in-game glitches like Ganondoor from Ocarina of Time.

Also, IL's are pretty fun to do. I appreciated the IL choices in Mega Man 9 and 10, as well as other puzzle games.

ymh

2013-11-05 11:57:23 am

Maybe an accurate in-game timer, that starts with the first imput and stops at the last.

TheBarrel

Edit history:

TheBarrel: 2013-11-05 03:30:26 pm

2013-11-05 11:57:31 am

It's weather time!

From what you've said, both here and in the interview, I like the concept already. I'm already imagining a lot of strategy involved with progression and movement that could make speed running incredibly unique and fun.

Though, I do wonder: will it be easy on the system requirements like Anodyne? I imagine that would make it easy to record and publish runs for. Not a big concern in the long run, and by all means do whatever it takes technically to make the game great, but I was just wondering.

[A little edit to add on something I forgot]
Remember to allow the player to change their control scheme if they want to. I notice A LOT of indie games miss that small detail. Again, Anodyne did this pretty well.

ProfessorBroman

2013-11-05 01:42:59 pm

Quote from ymh:

Maybe an accurate in-game timer, that starts with the first imput and stops at the last.

SO MUCH THIS! Accurate in game timers make things SO MUCH EASIER!

lifning

2013-11-05 02:05:27 pm

intranational speedmoseyer ordinaire

I remember Cosmo said some agreeable things on this subject (in the context of Monkey Ball):

Basically having a good 'menu feel' (which I feel Anodyne had, very responsive when I menu->return to entrance) and a nice efficient way to reset (debatable for Anodyne, as I remember having to quit and then delete the save with many conformation prompts, but that's probably better for the average player) goes a long way. A sense of 'easy to learn, difficult to master' is good, and I get the feeling you'll hit that in The Ocean, as you've described it, as well.

Making early game levels be much faster with late game techniques would probably encourage people to try speedrunning after ordinary completion. Making early game levels be much faster with late game *items/abilities* would probably encourage people to try and find sequence-breaks Smiley

seagaia

2013-11-05 04:02:27 pm

Okay yeah cool, thank you for the help, guys! There aren't cutscenes planned (For The Ocean) so that's not a problem.

IL: Yeah, there is a concept of a 'gauntlet' we are using with level design, and I plan to add in a timer option (Basically most 'areas' are these nonlinear-rooms then a set of linear rooms - so we'd add a timer to the linear rooms and probably do the timer based on game update loop ticks based on hitting the first and last checkpoints.

System requirements: It's not cpu intensive - it's 2D plus it uses the GPU this time around because of what I'm programming it with. On my entry-level laptop I can get full fps (it's only 30 fps) and i'm able to stream it no problem.

Control scheme: yeah, this is a thing i learned after doing a flash game, and it is already built in to EtO.

Items: Since there are no items I'm hoping that people will develop an intuition for how the movement changes as the energy level changes (since movement is scaled linearly as the energy bar moves), and that will play in how to approach the levels, which are designed to be pretty open in terms of "solutions". there's also sort of some 'advanced' techniques (short window of time) with some of the entities, probably more as we keep building the game.

menus/death - yeah, menus are fast. and i'm going to just let a few extra button presses skip the screen fades between areas, game-> title. restarting the game is pretty fast, there are 15 files and to start a new game you just pick the slot and there's one confirmation to pick that slot

Okay yeah cool, thank you for the help, guys! There aren't cutscenes planned (For The Ocean) so that's not a problem.

IL: Yeah, there is a concept of a 'gauntlet' we are using with level design, and  I plan to add in a timer option (Basically most 'areas' are these nonlinear-rooms then a set of linear rooms - so we'd add a timer to the linear rooms and probably do the timer based on game update loop ticks based on hitting the first and last checkpoints.

System requirements: It's not cpu intensive - it's 2D plus it uses the GPU this time around because of what I'm programming it with. On my entry-level laptop I can get full fps (it's only 30 fps) and i'm able to stream it no problem.

Control scheme: yeah, this is a thing i learned after doing a flash game, and it is already built in to EtO.

Items: Since there are no items I'm hoping that people will develop an intuition for how the movement changes as the energy level changes (since movement is scaled linearly as the energy bar moves), and that will play in how to approach the levels, which are designed to be pretty open in terms of "solutions". there's also sort of some 'advanced' techniques (short window of time) with some of the entities, probably more as we keep building the game.

menus/death - yeah, menus are fast. and i'm going to just let a few extra button presses skip the screen fades between areas, game-> title. restarting the game is pretty fast, there are 15 files and to start a new game you just pick the slot and there's one confirmation to pick that slot

Patashu

Edit history:

Patashu: 2013-11-05 06:14:19 pm

2013-11-05 06:12:49 pm

My thoughts:

Be careful about including random elements - if you use them, you want a good run of the game to feel more like 'has the skills to deal with whatever random pattern comes up' rather than 'I didn't get the bad pattern so I didn't lose minutes here so I got the good run by default' (for example, an enemy that can only be attacked if you get lucky). Don't forget that in place of a random number generator you can use information like a global/local timer, the player's current X and Y position and animation state, etc. to create random seeming things that are actually controllable with understanding.

Make sure that inputs are not dropped if the game lags.

If there are transitions/loading times/etc, make it so you can press or hold a button during the delay and it instantly takes effect when the loading time is over. (Contrast Braid, where if you want to jump the instant a stage begins you have to hammer the jump button as you can't buffer it.)

If there's a menu system, a map that works like a menu, etc. make it so that you can buffer and queue up inputs to it and they will all be executed losslessly. Good examples: Golden Sun (Werster loves doing the menus in this game because they're super responsive, never drop inputs and you can plan in advance where everything will be, so you can memorize a menuing at a certain point in the game as the list of button presses needed to do it), Nimbus (nimbus has a level select overworld, and not only can you buffer inputs while the map is loading to execute when the map appears, you can buffer as many inputs as you want, so you can memorize how to get from stage A to stage B and tap the sequence of buttons while it's still going. Feels really nice and responsive)

If you patch out bugs/glitches post release, don't patch out stuff that's cool for speedrunning and doesn't hurt casual playing experience, as that will disincentivize speedrunning the game to begin with. (Cool example: Mega Man Unlimited has a normal download and a Speedrunning download with all the glitches unpatched.)

Make practicing easy (individual level speedruns, quick restarting from checkpoints, an easy way to get to any part in the game so you can practice it, if there are upgrades then an ability to turn them off, Super Metroid style, et cetera).

Finally - leaderboards that are online and accessible from within the game. If your game prompts people to speedrun it and gives them the tools to see how fast you can go then you'll get more speedrunning by design.

My thoughts:

Be careful about including random elements - if you use them, you want a good run of the game to feel more like 'has the skills to deal with whatever random pattern comes up' rather than 'I didn't get the bad pattern so I didn't lose minutes here so I got the good run by default' (for example, an enemy that can only be attacked if you get lucky). Don't forget that in place of a random number generator you can use information like a global/local timer, the player's current X and Y position and animation state, etc. to create random seeming things that are actually controllable with understanding.

Make sure that inputs are not dropped if the game lags.

If there are transitions/loading times/etc, make it so you can press or hold a button during the delay and it instantly takes effect when the loading time is over. (Contrast Braid, where if you want to jump the instant a stage begins you have to hammer the jump button as you can't buffer it.)

If there's a menu system, a map that works like a menu, etc. make it so that you can buffer and queue up inputs to it and they will all be executed losslessly. Good examples: Golden Sun (Werster loves doing the menus in this game because they're super responsive, never drop inputs and you can plan in advance where everything will be, so you can memorize a menuing at a certain point in the game as the list of button presses needed to do it), Nimbus (nimbus has a level select overworld, and not only can you buffer inputs while the map is loading to execute when the map appears, you can buffer as many inputs as you want, so you can memorize how to get from stage A to stage B and tap the sequence of buttons while it's still going. Feels really nice and responsive)

If you patch out bugs/glitches post release, don't patch out stuff that's cool for speedrunning and doesn't hurt casual playing experience, as that will disincentivize speedrunning the game to begin with. (Cool example: Mega Man Unlimited has a normal download and a Speedrunning download with all the glitches unpatched.)

Make practicing easy (individual level speedruns, quick restarting from checkpoints, an easy way to get to any part in the game so you can practice it, if there are upgrades then an ability to turn them off, Super Metroid style, et cetera).

Finally - leaderboards that are online and accessible from within the game. If your game prompts people to speedrun it and gives them the tools to see how fast you can go then you'll get more speedrunning by design.

MMAN

Edit history:

MMAN: 2013-11-05 06:24:36 pm

2013-11-05 06:22:40 pm

The obvious stuff, like skippable cutscenes and easy restarts, has been listed. Beyond that I think the key thing is simply to not design your game as anti-speedrunning; which is different from outright designing the game for it, which I think can backfire if it's designed to be accommodating for speedrunners to the point of making the best route obvious. Don't arbitrarily limit level design and mobility just because a good player can sequence break it a little (as long as it's not super-obvious the average player) and don't remove cool glitches and skill-techniques just because they let you break the game a bit (again, as long as the average player is unlikely to encounter them or be able to exploit them).

Hazdogga

2013-11-05 06:57:49 pm

Avid watcher

This one is kind of picky, but have text display all at once / a method of skipping blocks of text. This way, the Japanese version is not necessarily faster than the English version in a speedrun.

For me, this makes better viewing. I know speedruns aren't done for the story, but when viewers can understand the bits and bobs of text that they do see, it gives that much more context and is much more viewer-friendly. Smiley

Patashu

2013-11-05 07:00:30 pm

Quote from Hazdogga:

This one is kind of picky, but have text display all at once / a method of skipping blocks of text. This way, the Japanese version is not necessarily faster than the English version in a speedrun.

For me, this makes better viewing. I know speedruns aren't done for the story, but when viewers can understand the bits and bobs of text that they do see, it gives that much more context and is much more viewer-friendly. Smiley

Ooh, this reminds me - in the original Paper Mario you can hold down a button and it auto skips all text as long as the button is held.

Blink

2013-11-07 10:00:27 am

I'm not sure on the specifics, but if you can make it Hourglass compatible that will help people to TAS it. Never a bad thing Smiley

zewing

2013-11-07 01:47:38 pm

just( •_•)>⌐■-■ ..... (⌐■_■)wing it

If you want to make a game with speedrunning in mind super meat boy and f-zero gx are perfect examples. intentionally making coding errors wont be something i see being wanted but these 2 games are just games that didn't outright say "speedrun me" but had elements that made it very simple to just run it.

Patashu

2013-11-07 03:04:58 pm

Quote from Blink:

I'm not sure on the specifics, but if you can make it Hourglass compatible that will help people to TAS it. Never a bad thing Smiley

For the record, making a game hourglass-friendly is tricky (I don't think anyone has explicitly tried though). It would need to be non-Java, non-Flash, able to run on 32-bit windows XP (ideally anyway), multi-threading might make it not work, certain drivers might make it not work, etc. I would go for this only if it already works in hourglass by a stroke of luck.

Quote from zewing:

If you want to make a game with speedrunning in mind super meat boy and f-zero gx are perfect examples. intentionally making coding errors wont be something i see being wanted but these 2 games are just games that didn't outright say "speedrun me" but had elements that made it very simple to just run it.

Super Meat Boy is actually a game that Edumnd wanted people to speedrun, though I'm not sure if he had full game runs in mind or just individual level runs. And of course, in racing games you gotta go fast~

[quote="Blink"]I'm not sure on the specifics, but if you can make it Hourglass compatible that will help people to TAS it.  Never a bad thing :)[/quote]

For the record, making a game hourglass-friendly is tricky (I don't think anyone has explicitly tried though). It would need to be non-Java, non-Flash, able to run on 32-bit windows XP (ideally anyway), multi-threading might make it not work, certain drivers might make it not work, etc. I would go for this only if it already works in hourglass by a stroke of luck.

[quote="zewing"]If you want to make a game with speedrunning in mind super meat boy and f-zero gx are perfect examples.  intentionally making coding errors wont be something i see being wanted but these 2 games are just games that didn't outright say "speedrun me" but had elements that made it very simple to just run it. [/quote]

Super Meat Boy is actually a game that Edumnd wanted people to speedrun, though I'm not sure if he had full game runs in mind or just individual level runs. And of course, in racing games you gotta go fast~

Melodia

2013-11-08 12:01:04 am

F-Zero GX is a racing game. Of COURSE it's made to play as fast as possible. What a wierd comment.

presjpolk

Edit history:

presjpolk: 2013-11-08 05:48:58 am

presjpolk: 2013-11-08 05:48:50 am

2013-11-08 05:47:55 am

HELLO!

1. Yes, cutscene and text skipping in a consistent way is important. If I can just mash start or whatever, to skip all text at once, that helps.

2. Rich movement physics with acceleration, attack, and jumping options.

3. Levels tested to see that effective speedrunning is possible. Time things so that you don't have to wait for cycles of things if you're efficient.

4. Minimize randomness. Make things that happen depend on what the player does, not on some frame counter or total PRNG whim.

5. Consider making powerups technically optional, but in practice silly not to get for casual play. Letting speed runners skip things at a cost of greater difficulty is great.

Note that glitches don't come up in my list. You can make a game totally glitch-free and still make it great for speed running.

TheBarrel

2013-11-09 09:34:17 am

It's weather time!

As far as cutscene skipping, no one's mentioned this example specifically but I like what the Castlevania games SotN onward did with that. The first time you played, you had to watch the cutscenes. But once you had a "cleared" game on file you could skip all of the cutscenes by hitting start.

That way whatever story you want the players to see doesn't have to be sacrificed, since they had to have seen it at least once to skip it in the first place. But people who are replaying casually or attempting and reattempting runs don't have to worry about long, obnoxious, unskippable cutscenes(Really wish Metroid Fusion did this).

presjpolk

2013-11-09 10:20:34 am

HELLO!

I have to disagree with that. If you want players to watch your cutscenes, make them that good that the player will choose to watch them. You shouldn't have to force it.

Alko

2013-11-09 12:34:51 pm

Caution: This user contains Kana ^_^

Quote from presjpolk:

I have to disagree with that. If you want players to watch your cutscenes, make them that good that the player will choose to watch them. You shouldn't have to force it.

Couldn't agree with this more.

TheBarrel

2013-11-09 01:13:23 pm

It's weather time!

Quote from presjpolk:

I have to disagree with that. If you want players to watch your cutscenes, make them that good that the player will choose to watch them. You shouldn't have to force it.

Yeah, I get what you're saying. Besides, given the structure of the game (or at least what has been explained so far) and how things went overall with Anodyne, I doubt they'll do anything obnoxious with the cutscenes/dialog anyhow.

Phazonelite7

2013-11-09 01:44:45 pm

I don't know if people would agree with me on this, but I've always liked this idea of hidden depth when it comes to movement in video games--various things that affect movement speed positively/negatively that are subtle and require creative thinking and testing in order to expose them. The game would never tell you what these things are but they would be coded into the game intentionally. People who set out to speedrun a game like this might not even be aware of these things despite identifying massive glitches and pouring a lot of time into the game.

I've been messing around with a lot of first person shooters lately, so I'll just use a hypothetical example. If I were to make a first person shooter, I would include a complex weight system. Every weapon would have a specific weight that added up to a cumulative weight. This is something that Killing Floor has. The more weight the slower you move. However, I would take this a step further. Armor and total ammunition (taking into account ammunition types) would affect this further. Movement speed would also be affected when you had lower health. All of this would be subtle and the game wouldn't tell you or indicate how much weight you're carrying. Having full ammunition versus having very little ammunition might only make you 1% slower, but it is an important difference you would want to capitalize on in order to minimize your time. This might sound ridiculously complex, but it's fascinating to me as a speedrunner if developers were to inject this kind of depth within the game's movement. Granted, I'm not entirely sure what kind of mechanics like that could be incorporated into a game such as your own (maybe moving even faster when you do a wall jump on the first possible frame), but it's an idea.

I don't know how the energy mechanic works (whether you collect items to change the bar or if you simply press a button or something), but you should make sure the level design has a lot of variety so it forces a speedrunner to be changing the balance of the energy constantly to minimize their time. If the game ends up devolving to "The fastest way to complete the game is simply to have the energy bar at so much dark energy all the time and to never change it" simply because of consistency in the level design, then the game in a speedrunning scenario loses a lot of depth. Each individual area should be a puzzle that makes the speedrunner think about how much light or dark energy would be the fastest to traverse that specific area.

I don't know if people would agree with me on this, but I've always liked this idea of hidden depth when it comes to movement in video games--various things that affect movement speed positively/negatively that are subtle and require creative thinking and testing in order to expose them. The game would never tell you what these things are but they would be coded into the game intentionally. People who set out to speedrun a game like this might not even be aware of these things despite identifying massive glitches and pouring a lot of time into the game.

I've been messing around with a lot of first person shooters lately, so I'll just use a hypothetical example. If I were to make a first person shooter, I would include a complex weight system.  Every weapon would have a specific weight that added up to a cumulative weight. This is something that Killing Floor has. The more weight the slower you move. However, I would take this a step further. Armor and total ammunition (taking into account ammunition types) would affect this further. Movement speed would also be affected when you had lower health. All of this would be subtle and the game wouldn't tell you or indicate how much weight you're carrying. Having full ammunition versus having very little ammunition might only make you 1% slower, but it is an important difference you would want to capitalize on in order to minimize your time.  This might sound ridiculously complex, but it's fascinating to me as a speedrunner if developers were to inject this kind of depth within the game's movement. Granted, I'm not entirely sure what kind of mechanics like that could be incorporated into a game such as your own (maybe moving even faster when you do a wall jump on the first possible frame), but it's an idea.

I don't know how the energy mechanic works (whether you collect items to change the bar or if you simply press a button or something), but you should make sure the level design has a lot of variety so it forces a speedrunner to be changing the balance of the energy constantly to minimize their time. If the game ends up devolving to "The fastest way to complete the game is simply to have the energy bar at so much dark energy all the time and to never change it" simply because of consistency in the level design, then the game in a speedrunning scenario loses a lot of depth. Each individual area should be a puzzle that makes the speedrunner think about how much light or dark energy would be the fastest to traverse that specific area.

ais523

2013-11-09 04:20:26 pm

Some minor things that it's easy to miss:

- Make sure that all your levels have some easy way for people to refer to them. Either numbers, or preferably, names (and names that abbreviate to unique acronyms; look at Super Mario 64 for an example, where runners talk about "TTC" and "HMC" and so on all the time; it's effective and memorable shorthand).
- Make sure that your save system is compatible with both single-segment and segmented runs (unless it's a game where an IL run makes sense). In particular, if you have an autosave feature (which is a good idea for marathon safety, as well as for the convenience of your players), also include a copy save feature to allow people to back up a file where it won't be autosaved over. (/me glares at Donkey Kong 64.) Make sure that absolutely everything is copied (including run time); an added bonus would be a counter of how many times the game was saved (so that people can "prove" that their runs are single-segment more easily).
- Try to avoid autoscrollers, or give alternatives to them. For unassisted speedruns (what SDA is about), zero is probaby the best number; you can't improve them, so they are mostly just boring for both the runner and the watchers. For tool-assisted speedruns (as are hosted at TASvideos), the optimal number of autoscrollers in a run is 1, because they give a TASer a chance to show off glitches and interesting things that are possible with the engine, without having to lose time to do so.
- Additionally, giving a way to skip levels, or to choose between alternatives for a level, is good for making a game speedrunnable in general, not just with autoscrollers; not only does it allow runners to skip levels that might happen to be particularly obnoxious for speedrunning for one reason or another, it also gives you distinct "any%" and "all levels" categories, which helps to keep the game fresh. (Doing this was probably the only thing that made Hammerfight runnable at all; it has some very obnoxious levels, but they're fortunately skippable, with the game allowing players to skip levels but not to skip two in a row.)
- Try to react sensibly to the game being sequence broken. You don't have to (in fact, probably shouldn't) add in sequence breaks intentionally; but if someone finds one, the game should just go with it rather than glitch out. (The main place to watch out here is with event flags; you should make sure that each flag can trigger separately, rather than, say, having a variable for how many flags have been triggered and assuming you can use it to determine which flags have been triggered.) Just compare Super Metroid to Metroid Fusion for an extreme example of what I'm talking about. This rule mostly only matters for Metroidvanias and RPGs, or games with Metroidvania or RPG elements; other games are likely to fulfil it by accident.

Some minor things that it's easy to miss:

- Make sure that all your levels have some easy way for people to refer to them. Either numbers, or preferably, names (and names that abbreviate to unique acronyms; look at Super Mario 64 for an example, where runners talk about "TTC" and "HMC" and so on all the time; it's effective and memorable shorthand).
- Make sure that your save system is compatible with both single-segment and segmented runs (unless it's a game where an IL run makes sense). In particular, if you have an autosave feature (which is a good idea for marathon safety, as well as for the convenience of your players), also include a copy save feature to allow people to back up a file where it won't be autosaved over. (/me glares at Donkey Kong 64.) Make sure that absolutely everything is copied (including run time); an added bonus would be a counter of how many times the game was saved (so that people can "prove" that their runs are single-segment more easily).
- Try to avoid autoscrollers, or give alternatives to them. For unassisted speedruns (what SDA is about), zero is probaby the best number; you can't improve them, so they are mostly just boring for both the runner and the watchers. For tool-assisted speedruns (as are hosted at TASvideos), the optimal number of autoscrollers in a run is 1, because they give a TASer a chance to show off glitches and interesting things that are possible with the engine, without having to lose time to do so.
- Additionally, giving a way to skip levels, or to choose between alternatives for a level, is good for making a game speedrunnable in general, not just with autoscrollers; not only does it allow runners to skip levels that might happen to be particularly obnoxious for speedrunning for one reason or another, it also gives you distinct "any%" and "all levels" categories, which helps to keep the game fresh. (Doing this was probably the only thing that made Hammerfight runnable at all; it has some very obnoxious levels, but they're fortunately skippable, with the game allowing players to skip levels but not to skip two in a row.)
- Try to react sensibly to the game being sequence broken. You don't have to (in fact, probably shouldn't) add in sequence breaks intentionally; but if someone finds one, the game should just go with it rather than glitch out. (The main place to watch out here is with event flags; you should make sure that each flag can trigger separately, rather than, say, having a variable for how many flags have been triggered and assuming you can use it to determine which flags have been triggered.) Just compare Super Metroid to Metroid Fusion for an extreme example of what I'm talking about. This rule mostly only matters for Metroidvanias and RPGs, or games with Metroidvania or RPG elements; other games are likely to fulfil it by accident.