next »

[Strife]

This is something I'm currently discussing with my team, but I figured I'd bring it out in the open as well.

Aside from the obvious racing games, there are plenty of other games out there with built-in Time Trial modes, or games that will simply have a ticking clock in the background to keep track of how long it's taking you to clear stages. (Examples: Super Mario Galaxy 2, Mega Man Powered Up, Doom, every Sonic game ever.) Some games handle this differently than others.

I'm wondering how to handle timers in a way that's best suited to the needs of speedrunners so that they're more inclined to time themselves with the in-game clock instead of an external program.

1. Checkpoints

Some games like Sonic will save your current time when you cross a checkpoint and restore it if you die. Other games will not do this, such that if you cross a checkpoint at 3 minutes and die one minute later, you restart at the checkpoint with 4 minutes on the clock.

I'm inclined to believe that the latter method is more ideal for speedrunning, at least with games that are broken up into stages that are timed individually. It seems like it'd be harsh for casual players since it would force them to do a no-deaths run to get the absolute best times, but, I kinda feel like that's a fitting reward for playing it safe. With checkpoint saving, there's no way to differentiate between someone who cleared a stage in 10 minutes without dying or someone who cleared a stage in 10 minutes after spending half an hour repeatedly dying to the boss.

I could, however, see the checkpoint method being useful for games that are really hard to the point where you're expected to die frequently, or games that have really short stages that take less than 30 seconds to clear anyway (i.e. Super Meat Boy, which fits both descriptions).


2. Pausing time during transitions and cutscenes

It goes without saying that accuracy is important to speedrunners, but on the flipside, it can seem a little unfair to players if they're being timed in situations where they have absolutely no control, such as an elaborate cutscene where the stage boss emerges and starts monologuing while the players themselves cannot move until he is done speaking. I'd be interested to see where other people stand on this, particularly when you consider games where cutscenes can be skipped.


3. Powerups and abilities

What if your game has items or special abilities that allow you to slow, stop, or otherwise control the flow of time? My opinion is that for speedrunning, the in-game timer should act independently of everything else, even if the game has time-altering elements in it.

Of course, I don't think this always needs to be the case depending on what gameplay modes you have - For example, if you have a stage where you have to escape before a bomb goes off, in which case you could collect powerups that give you extra seconds and whatnot.


4 - Lag

I feel like it's best that timers should be tied to the game's framerate instead of the system clock. In this case, players who lag frequently don't have any disadvantages over players who can run the game at full speed on their system, even if the lagging game's seconds don't completely match up to a real world second. I think there's too much room for error if you base timers off the system clock.


What's your guys' take on this? There's also aspects of level design to consider as well, particularly with Metroidvanias that allow multiple ways to reach specific goals.

[nickgravelyn]

I'm no expert on the world of speed running but figured I'd share my thoughts:

1. Checkpoints

I would expect the time wouldn't reset if you drop back to an earlier checkpoint. For speed running, having the time reset would encourage reckless attempts at incredibly improbable feats because there is a safety net of the time resetting, effectively making the time spent 0 even if the player attempted some crazy trick a hundred times. If the time doesn't reset, it forces the player to weigh the pros/cons of any maneuver more carefully.

2. Pausing time during transitions and cutscenes

I'd say that as long as it's the same for everyone it doesn't matter so much, but I'd probably opt to stop the time when the player has no control so the time tracks actual played time.

3. Powerups and abilities

It really depends on the powerups and their effect on the game, but I guess I'd initially say no, don't have powerups affect the speedrunning time. The powerups will likely provide the player a skill based benefit (making some part of the game easier because they're moving slower or something) and that will provide them another pro/con to think about: they can slow down time to make something easier but then passing that obstacle may take more time.

4 - Lag

Personally I would use the system clock. Yes people who have slower computers are at a disadvantage if it impacts the performance, but if you tie it to frame rate it can increase the time they have to react to in-game events, thus giving them an unfair advantage. If someone can find a way to manipulate the game into this state at will, they have a very unfair advantage. IMO the most fair solution is to just use the real passage of time.

[SirNiko]

One thing you might want to decide early on - are you designing your game for players to speedrun individual levels, or are you looking at full-game speedruns? Both approaches will turn out differently, since individual levels let players optimize the game in parts whereas a full-game run may cause small improvements early in the game to affect late-game parts of the run. A little more about your game would be helpful, like what kind of genre it is or how the levels are broken up.

For checkpoints, you do need to be careful that you don't design the game in such a way that restoring a checkpoint has an impact on the player: in Sonic, for example, you lose all your forward momentum when you start from a checkpoint so you might as well start over. On the other hand, if a player can lose all their health, die at the checkpoint, then restart with a fresh life bar it may become optimal to die at every checkpoint. It's easiest to just design the game so checkpoints are ignored during speedrunning (for example, disqualify the player from the speedrun if they have any deaths). This isn't a hard rule, though. Some runners enjoy the challenge of finding out how to use death and checkpoints to optimize runs.

For transitions, it might be easiest to just let the player turn these off. Or design the game so that the player can ignore the transitions (eg, give dialogue via radio transmissions so the player doesn't have to stand around). The problem here isn't whether or not the clock runs, but the annoyance to a speedrunner when they sit around waiting for a cutscene to end so they can get back to playing.

For powerups, you might want to avoid things that exist to strictly give the player more time. If you do use them, you'll probably encounter one of two scenarios - the bonus from the powerup is big enough that you always need to grab it for the best score, or that the bonus is too small to be worth the pickup compared to taking a shortcut. You can make either design work (using them is good for a game in which the player is optimizing single levels, especially if you award medals for achieving static goals) but you run the risk of turning off speedrunners if you make the optimal path too obvious.

A major, major issue for powerups and the game in general is randomness. Monsters that drop powerups at random are a no-no, because they make success dependent on luck and make optimal runs reliant on events coming together that are outside the player's control.

This is also a problem for things like monster spawns (getting lucky and having an easy monster spawn instead of a hard one), locations for quest items (getting lucky and having the quest item spawn in a more convenient place) and even randomized bouncing of projectiles will spoil the speedrunning potential of a game.

I'd ignore lag as an issue completely and use an in-game clock. Test it on a couple of different systems with a robot playing the same non-random level and confirm that each run records the same finish time. That should be enough. Be wary if the in-game clock pauses for anything. Super Metroid was unusual that the game paused the clock when you were navigating menus, so you could have to play the game differently depending on whether you were optimizing real time or the in-game timer (this can also be an issue if you use checkpoints that remember your time).

One thing you don't mention but should consider - time-dependent game mechanics (eg, invincibility frames for multi-hit monsters, platforms that move out of reach of the player for short periods of time, anything cyclical that relies on time and not the player) can create situations where the player can't improve their time within certain spans of time. For example, a platform that only moves within reach of the player every 10 seconds. If the player reaches it at 59 seconds, they have to wait until 60 seconds to progress. If they get there five seconds faster, they still have to wait to 60 seconds to progress, preventing improvements in their overall time. Donkey Kong Country Returns addresses this partly by starting moving objects when the player gets near, ensuring that a player who saves a few seconds early in the level won't be stuck waiting for that moving platform later.

You also need to be careful that you don't accidentally design the game in a way that the fastest method of play is really, really dumb. For example, a poorly designed jump-kick attack might become the fastest method of movement and mandate that all speedruns consist of only jumpkicking to move. Or, perhaps one weapon is simply optimal for all speedruns because it has some trick associated with it (eg, a homing gun that lets the player kill enemies without stopping to aim). The end result is a game where most of the mechanics must be ignored to achieve a reasonable run time.

If you're serious about speedrunning, you might want to visit TASVideos.org and do some reading. They're dedicated to tool assisted runs, but much of what you'll see and read is still applicable to standard speedruns (Many videos include detailed notes on how the game mechanics apply to the speedrun, and may give you hints on what not to do or to do in order to make the game more fun to speedrun). You also might enjoy reading specifically about Donkey Kong Country Returns and Mirror's Edge, which are both games with pretty high-quality in-game speedrun mechanics.

[nickgravelyn]

A major, major issue for powerups and the game in general is randomness. Monsters that drop powerups at random are a no-no, because they make success dependent on luck and make optimal runs reliant on events coming together that are outside the player's control.

To be fair Spelunky is packed with randomness and is still a very exciting game for speed running (or at least seems to be given the world record runs I've watched), partly because the randomness requires a truly skilled player who can adapt rather than being the person who can best execute a well planned sequence of actions. Both are valid and different games will work better one way or another, but I don't think randomness itself is a problem for speed running.

[SirNiko]

I think you'll find way more often than not, randomness is going to be an enemy in speedrunning. Spelunky manages to thrive despite it, not because of it. The top runs rely on getting a jetpack or teleporter early on to navigate levels quickly (the game is far more lenient if you're aiming for the 10 minute static time for the achievement). It's doubly problematic for mediocre runners who will see their times fluctuate wildly based on lucky breaks like that. Players competing to shave a few seconds on a world record time will rely more and more heavily on lucky shop, enemy and level arrangement than on good reflexes.

Doubly so because Spelunky is relatively short to run - less than seven minutes in a sitting for a world record now. It's not a big deal for a player to make a dozen attempts or more in a sitting. This doesn't make it good design, though, it just means the player is a little more willing to deal with inconvenience because it comes in small bites.

You can make a random game that people will happily speedrun (like Spelunky), but 99 times out of 100, minimizing the randomness is going to make your game more fun to speedrun. Making the player figure out how to efficiently sacrifice enemies to Kali for a jetpack, for example, would've generally been a good way to ease randomness and create choices and challenges for the player (generally because you'd need to change more about Spelunky before that change would work). You can also use strategies like giving the player a heart every fifth enemy, or making item drops contingent on special tricks (eg, killing an enemy with a perfectly timed blow gives you a powerup).

A good rule of thumb is to have several players make several attempts each at speedrunning. If their times vary widely and wildly from attempt to attempt despite them not changing their strategy much, you have too much randomness and should do something to reduce it.

For TAS videos this is usually a non-issue because luck can be manipulated at a frame-by-frame level of play.

[nickgravelyn]

All very good points. Perhaps Spelunky's randomness makes speed running more interesting to the viewers in those cases. I've never really tried speed running nor gotten deep into the culture, so these were just some of my thoughts.

[SirNiko]

Yeah, there's definitely an appeal to the player dealing with some interesting variable late in the run, and being forced to make a sudden decision to ensure they still get a good time. I certainly find watching Spelunky speedruns interesting, but I'd never be a Spelunky speedrunner myself, for the reasons I stated above. I'd go for the 10 minute achievement, but then leave it at that.

Kingdom of Loathing has (had? It's been a few years since I played) a very active speedrunning community. Randomness was a huge issue for them because the speed game was so academic (reflexes were of no value in that game because it's strictly strategy), and a lot of my experiences/opinions on randomness in speedrunning come from my experiences there. Kingdom of Loathing also is unusual in that the developers simultaneously support a traditional MMO design for non-speed players and carefully craft and tweak mechanics to keep speedrunning interesting and challenging. It's an excellent case study in speed running.

[rosholger]

on the topic of system clock vs frame based timers, both have their disadvantages.
if the timer is based on the frames it could be abused to gain more reaction time, lets take the extreme case where the game is supposed to run in 60 fps and therefore each frame is worth 16.666...7 ms but its actually running in 6 fps then the player would have 10 times the reaction time without any disadvantage on the timer. of course this is very unlikely to happen but its something that should be noted.

[Strife]

With regards to randomness in gameplay, I definitely agree that enemy attack patterns should be as choreographed as possible. The fewer differences the Random Number God brings, the better. Understandably there may be cases where this just isn't practical depending on the game (i.e. fighting games, certain action games, etc); But even if it can't be done, an active attempt to reduce randomness is better than nothing.


System clock vs. framerate is definitely an interesting challenge to address. I reckon that online games, or games that have online leaderboards and such, should probably go with system clocks. Server-side games by their very nature may have to stick with system clocks.

As for my game specifically, it's a 2D action platformer divided into stages. So far we're using the Sonic style of checkpoint saving, but I'm reconsidering this for a few reasons. With a persistent timer, players will no longer be inclined to suicide if they mess up a particular section in order to reset the timer. Additionally, restarting from a checkpoint causes a loss of momentum, so any deaths regardless will result in a run that's not as optimized as a no-deaths run. Might as well go the whole nine yards with it, eh?

One of our teammates is concerned that switching to a persistent timer will discourage casual players from attempting to speedrun due to the length of our stages. They can take anywhere from 5-8 minutes to speed through and 15 minutes to play through normally, and if the player makes a sudden error late into the stage, they'd have to start all over from the beginning. Said person recommends that we retain checkpoint saving, but also save the player's movement speed. Personally I still feel like there's room for error with this due to a multitude of additional factors that need to be considered (such as if the player was in the middle of using a specific ability when they crossed a checkpoint), so, short of using save states, it probably won't be accurate.

[Sopha]

[first post]

Speaking as someone with a small amount of experience speedrunning personally,

The points in the opening post are mostly a matter of convenience. If the in-game timer is accurate and doesn't let you get away with going through the game more slowly to artificially decrease the in-game time somehow, it just saves the trouble of having to standardize a timing system for whoever runs it. If they want to run it, they will regardless of whether the clock is convenient or not. I think the decisions regarding in-game timing should be made more in the context of casual time-trials. That is, so that a casual player would have more fun beating their previous record. Then if speedrunners don't like the timing method, they can just make their own.

There are two things I think that are most important in determining whether a run of the game is fun or not. First, as mentioned, is RNG. It's very annoying when a particular random event must happen in order to get a good time. But on the flip-side, if a run has no RNG at all, it becomes all about memorization and execution of the particular route. So the best type of RNG may be to make it so that the runner has to react and adapt to random events as they happen, without any specific event being so bad that it warrants a reset just by happening. Even then, if there is enough competition and the run is optimized enough, those small random differences could be the difference between a world record or not, making them trigger a reset anyway.

The other thing is how interesting and deep the things the player can do are. Say, if all the player has to do for a run is walk around on a grid and use a certain overpowered attack in turn-based battles, that would be very boring. But if the mechanics are very complex and they can even be used in ways the designers didn't intend, expanding the possibilities even more, that's generally more fun.

All of that said, a major appeal of speedrunning is that it's essentially a no-man's-land with the simple goal of going as fast as possible without intervention from the game designer to make it fun. Due to this, it's an unbalanced mess with absurd challenges and pushes the game's mechanics to their limit.

I think the best way to make a good speedrunning game is to make the mechanics deep enough so that you don't really know how they're like when stretched all the way, but still make them fun at a basic level. Then just hope for the best on the other factors.

[Irock]

Super Mario 64 is one of the most popular games for speedrunning, and I think that's largely because of how powerful the player can be just using the basic mechanics. You can skip portions of levels without doing glitches or exploits, and yet a normal player typically wouldn't even consider it. The game's design handsomely rewards players for mastering the same core mechanics casual players use. I also believe this to be good general game design.

It's the exact reason I believe Super Mario Galaxy isn't great at its core relative to SM64 and even Sunshine. If you compare SM64 playthroughs between a skilled and casual player, the difference is night and day, but if you compare skilled and casual Galaxy playthroughs, you can see that the two are very similar. Even if someone is going as fast as possible in Galaxy, it's not exciting to watch because the game dictates your pace and doesn't typically allow you to go faster than it thinks you should.

• Second by second, the player should be able to increase their speed through the game in some way. Don't force them to play the game like a "normal" person. This gives the runner something to do at all times and keeps the speedrun captivating for both the runner and the viewer. (SM64 example: longjumping repeatedly is faster than walking, repeatedly diving on your belly and jumping up is faster than longjumpinging)
• Allow skilled players to skip content. (SM64 example: this hill in Shifting Sand land. Most players never think to jump over it, either because they're not clever enough, they're not skilled enough, they don't want to risk sliding into sinking sand or they're not looking for ways to go fast.)
• Allow flexibility in the sequence of events so players can devise an optimal route through the game. (SM64 example: star orders are not mandated and there's room for tackling levels in different orders)
• If your game has cutscenes, allow the player to skip them.
• If your game has dialog, provide a way for players to blaze through it. (Paper Mario example: holding B will make the dialog go at an insanely fast speed by drawing characters at like 5 words per frame, skipping all pauses and automatically advancing the dialog.)
• Though if your game is incredibly long, maybe it's not a bad idea to have a period of forced downtime in the middle so the runner can take a leak.

[Graham-]

I agree that if you can measure how fast a player can beat a game, and compare it to his skill level, and see a nice pattern of better players completing the game proportionately faster - if they are trying to play fast - then you have good core mechanics - robust ones.

Let me compare FF6 and FF13, two games not typically associated with speed running. In 6 battles start faster, menu work is faster. The visual feedback, casting times, animation times, are all faster. In 13 there are many unnecessary steps in the menu, for even basic prep. 13 even has unnecessary flourishes in the in-battle menu, for every player action, that slows command input times.

Like Super Mario Galaxy, FF13 tried to expose the high-level experience of earlier FFs. Super Mario Galaxy put the "bumpers up," to help players along, sacrificing the core system in the process. The reason these things happen is: if you want a strong core system, you need solid level design to back it up, otherwise a large - majority - portion of players will be overwhelmed, and will not experience even the intermediate level of play.

Gears of War did the same thing for shooters. Cover is a necessity in Counter-Strike, but it's entirely possible to never realize that because no one taught you how to use it.

[Graham-]

To the OP questions:

1. Check points are a style decision. You can go either way, or do both. The best decision is game dependent.

2. Do not time cut scenes. You want easy comparison between speed-run time proportions. If my run is twice as fast as yours that means I did it twice as fast. If you put in cut scenes that ratio becomes impossible to do in your head, unless you know how much time cut scenes take, and then it is still annoying to do.

3. Don't muck with the timing with abilities. That's one more thing for the player to think about. Unless you want to make speed running a core mechanic - as in progress is dependent on times - then adjusting the clock by power is unnecessarily confusing.

4. For speed runs go by the system clock. You can program your game to skip frames and run at a consistent speed. If players want a faster frame rate just allow graphic fidelity reduction. All Starcraft pros play at lowest detail settings.

edit: For cut scenes you can obviously provide both timings.

[Irock]

@Graham: yeah, it's important for almost every element a game to be relatively "snappy" and for the player's flow to be broken as seldom as possible

Also, there are games that aren't necessarily good for speedrunning at their core, but are made really interesting with esoteric glitches. But you can't count on that happening, because these are typically games that have been around for a long time and are really popular — way beyond what an indie game is likely to be. It took like a decade for the glitches to be discovered that make Ocarina of Time a

.

[Irock]

Oh also, you could forgo RNG and instead create the illusion of randomness by basing it on certain manipulable variables. The Legend of Zelda did this for item drops:

http://tcrf.net/Proto:The_Legend_of_Zelda#Item_Drops

[SirNiko]

Ideally, though, I think that a game that features glitches to make it fun to speedrun is not quite as good as a game where the player uses existing mechanics in combinations that result in surprising but logical results.

For example, an RPG where combining a couple of niche utility skills allows a player to defeat a powerful enemy earlier in the game than expected (such as low-level FF7 runs where stat boosting items become essential to win) or where special abilities can be combined in unusual ways to reach previously unreachable areas (such as Super Metroid where infinite bomb jumps and shine spark dashes are combined to skip items that seem mandatory to low-skilled players).

There's an arena where exploitation of ridiculous glitches is appreciated (for example, the TAS community loves the challenge of discovering ways to catapult through walls or cause bosses to fail to spawn) but that will turn off all but the most dedicated of speedrunners. Getting top times in Mirror's Edge isn't fun when it relies on exploiting quirks such as increasing your speed by side jumping to move forward, and Goldeneye made strafing and running forward at the same time mandatory to beat many of the target times. Most Mario 64 top times rely on exploiting various wall clipping glitches to massively reduce the number of stars needed to access the final battle. Sometimes it's really hard to determine what is a glitch, and what is a logical use of the in-game mechanics - is jumping and kicking to slowly climb slippery slopes and skip parts of the level in Mario 64 a glitch or not?

When possible I think you ought to squash as many bugs as possible and try to replace them with interesting but logical mechanics, even when the bugs only affect speedrunners and produce cool effects. Or even, turn the bugs into in-game mechanics and teach them to the player to reduce the number of hurdles that a beginning speed runner much cross to become an expert speedrunner.

[Irock]

It's really down to personal taste as to what's more enjoyable as a speedrun. Glitch-heavy speedruns are my cup of tea. I think Ocarina of Time is one of the most enjoyable speedruns out there, right next to SM64. I also (poorly) ran Wind Waker which also relies on glitches and adored every second of it.

But I agree that you should fix any bugs you find during development. You're expected to make your game as flawless as you feasibly can, and letting bugs slide for the sake of potential speedruns can come across as disingenuous. It's cooler to see a solid game become broken than a broken game remain broken.

[Graham-]

Fix glitches. They'll show up anyway. And if they don't that's better.

[Strife]

Some solid advice. :D Thanks!

I think it's interesting how games with a certain amount of non-linearity are the most enjoyable to speedrun. The freedom of selecting between multiple worlds in games like SM64 and Mega Man lends itself pretty awesomely to diverse tactics. Some players might tackle Area A because it gives them an item/power that makes getting through Area B faster, or they might skip Area A altogether since it's a long section.


Something else I think worth mentioning is how you could make certain powerups and collectables advantageous for speedrunners. In the game I'm working on, for example, there's a variety of shield powerups that absorb 2 hits before disappearing. The player doesn't flinch from attacks while holding a shield, allowing them to tank through hazards without losing any speed or momentum. This could bring a number of player-specific tactics to the table; Do they take a detour and lose a few seconds to grab a shield that will allow them to speed through an area up ahead a few seconds faster than before? It gets more interesting when you consider that the shields come in different elements (fire, water, etc) and grant immunity to specific types of hazards, so the player could face a boss that uses Fire and Electric attacks and bring either a Fire or Lightning shield to the fight to ignore those particular attacks and score faster hits.

I think those kinds of choices add a lot to how fun a game is to speedrun, even if there is technically always a "best" choice that experts and TASers will use every time.

[baconman]

Even if there is a 'best sequence'... the fun is in figuring that stuff out. Any kind of gameplay optimization is like that, and no matter how casual your game is, it will have people who enjoy it for the sake of optimization.