Pause Ahead is a freeware Windows game (download) about pause glitch abuse. No, really, I'm serious.
The game concept was inspired by a tweet by Molydeux which says: "What if the pause button was a weapon? Until developers think outside the box we’re going downhill.".
The game was developed by Askiisoft in 48 hours for MolyJam 2012, and later improved and enhanced into its homonymous widely more known Flash version [dead link removed].
Game objectives
- Emulator used: Hourglass-r81
- Completing game in the lowest real-time possible
- Genre: platform
Comments
Optimizing the pausing power was everything I had to make this TAS. When used, the enemies, the time limit, the player speed and acceleration will keep still until you press again the key. Also, spikes will become unharmful. This game is all about timing. Pausing in the wrong instant may result in getting stuck into the spikes or an enemy, and thus, dying.
Level 1
Well.
Level 2
Pause used to get straight to the exit.
Level 3
"Magically moving saws" faced, no need to pause.
Level 4
Thanks to the pause power, the "Guys borrowed from Bowser" didn't even notice my presence.
Level 5
A very simple level desined to make the player discover the magic.
Level 6
Quite hard level for causal play... but not for TASing.
Level 7
This is where the challenge actually started. In order to save some frames, I had to plan the route a bit.
Level 8
The initial time limit in this level is 2 seconds. The only way to beat the level, is to use the pause power to stop time, a lot. This actually forces you to spend more real time, because you don't have enough time to gain maximum speed after every turning. I touched the first two walls in order to decelerate istantly, even if this forced me to walk longer. I arrived just in time to the hourglass, which adds 20 seconds.
Level 9
2 seconds left again. Some more route planning was necessary to optimize completion time.
Epilogue
I combined jump with pause in order to stop input earlier. This resulted in a better real-time, in exange to in-game time.
Possible improvements
Maybe a frame or two can be saved during the last 3 levels, but I doubt it.
Suggested screenshot
I think this is the most explanatory screen, because shows the most memorable part of the game, that is the moment most players realize what's the game about. Also, it doesn't show the ugly early enemy graphics.
feos: Synced, judging...
feos: This run was really challenging to judge. Pause Ahead looks like a serious game, not a mere teaser of its successor, the Flash version, even though if feels like one. But this aspect wasn't the reason of my decision, neither was this run's optimality.
The real problem here is that Hourglass can't dump sound effects for this game. This sounds like a minor issue, but let's have a detailed look at all the complexity of the problem.
We've already had a Windows game submission rejected only because Hourglass can't dump any audio for it. After it was judged, FractalFusion posted, that if a stable method to provide an encode with no av desync is found, such runs might have an exception in our policy, Play Games That Are Emulated Well.
And indeed, both Warp and Pause Ahead are the games whose movies are short and can be dumped so that their audio syncs with their video. But when it comes to an exception in the policies, it becomes really hard to sort out.
We have a few ways to resolve this situation, where only the lack of easy encoding method is what leads to rejection.
- Ignore and keep rejecting such runs. This is not the most pleasant option, but it feels stable and has no technical downsides.
- Accept runs that require some work to get their audio dumped. This leads to further issues:
- If we keep accepting them all, we can end up in a situation when a long run is submitted, and no encoder can dump its audio fully without av desyncs, or without too much extra work to make it sync.
- If we only accept them on a case-by-vase basis, we end up in a situation where a run such as described above can not be encoded by those of the publishers/encoders/users who are available at the moment, but then after it's rejected, a user who can encode it shows up. And we kinda have to unreject it again.
So it all still ends up totally dependent on volunteers, and we can not guarantee we have those every time.
Moreover, even if we have the volunteers, once you rely on a method that involves live recording of the audio stream as the movie is being replayed in the emulator, you have no control over how well it goes. The game, the emulator, the OS can randomly have minor lags during the process. This leads to those lags present in the final audio stream. If it's just a progressing av desync, it can be fought, but if it's a floating av desync, you won't wish on your enemy to deal with it! Because there's literally no way to really make sure it's matching the intended audio output perfectly, at any point in time. For the record, .kkapture would dump it properly, but doesn't work with Hourglass, because Hourglass doesn't actually output any media content, it forces the games to do that.
This problem could be avoided if a run is short enough, but again, there's no stable and easy to handle way to work around this, especially for a longer run. So we had a staff discussion about this problem, and the absolute majority thinks we should not start accepting such runs without the perfectly stable ways to dump AVI of them.
So the policy remains unbent, and this run is rejected. Thanks for your attention.