Temporary notice: This is a C64 game that was completed in ~1:37 but it is currently misidentified because the site does not yet recognize Commodore 64 submissions (...this is sort of not the first time I've caused this problem either, but I digress).

C64anabalt is an official conversion of Canabalt for the Commodore 64 (in cartridge form). Canabalt is the game that defined the endless runner genre and has an awesome soundtrack that was extremely faithfully ported to the C64's SID sound chip. The game controls consist of a single jump button to alter the height of the player's suit-clad character (who runs right for great justice from an unseen terror at an ever increasing pace).

In this TAS, I run right while avoiding any obstacles that might slow the character down until the speed increases to the point that the game hits a killscreen. If I had hit even a single obstacle the speed would have slowed down substantially, but as Aqfaq pointed out the player hit an average running speed of 111 mp/h (180 km/h). The speed increases to a point that high jumps have to be predicted because the landing point isn't even visible on screen. Toward the end I had to specifically manipulate building layouts that were simpler than earlier sections in order to avoid having to slow down. Eventually, the speed increases to the point that strange things start happening such as conspicuously missing chunks of buildings before the game finally hits an impassable killscreen. (Input could be stopped a few frames earlier by not demonstrating various effects on the player after reaching the killscreen such as zipping around the screen and becoming embedded in walls but I think it's better this way; stopping input as soon as you land on the final platform would end input earlier but the player just stops forever and you don't get to see the game over screen.)

Note: The Commodore 64 core of BizHawk is unfinished and is currently not suitable for any purpose, express or implied. Specifically, any attempt to save or load a state will crash or cause a desync, as will stopping the movie, reloading it, and continuing recording. However, if you save a movie with no savestates and then replay it, it will replay perfectly every time. I went to great lengths (including hex editing and even compiling BizHawk from source) to try to find a way to fix the savestate problems to TAS this game correctly, but to no avail. I finally resorted to the same trick ais523 employed when he used the rerecording framework I created in his NetHack "Fastest Death" run - I put the emulator in a virtual machine and used the VM's savestates instead. It worked, although I wouldn't recommend it; I would have greatly preferred figuring out a way to fix the emulator as this solution felt dirty and wasn't particularly efficient. As a consequence the rerecord count of 1 is technically accurate, but the actual attempts on this through my various testing are probably in the low thousands.

But don't let those challenges stop you - go grab the freely-available ROM and give this faithful port of a great game a shot! With any hope, the added exposure of this submission will spur the Commodore 64 core developers for BizHawk into action. :) I hope you enjoy this run.

Noxxa: Added YouTube module.

Noxxa: Claiming for judgment.

Noxxa: Let's start off by saying that this is a nice and well-executed run of a nice game. However, there are a number of issues with it.

First off, the emulator for the system (C64Hawk) is incomplete in multiple ways. Emulation itself is quite incomplete - the game itself is emulated well enough, but the BIOS emulation has a few issues, at least in that it displays just a blue screen, instead of blue text on a darker blue background. It works, but it still obviously would need some work.

As a TASing platform, it also has some big problems, not the least of which being that savestates do not work in the emulator. That is really significant, as savestates are one of the core features of any TAS-capable rerecording emulators. The way dwangoAC made this run using a virtual machine was a creative solution, and it can work as a workaround, but it is still not really a good solution, as was admitted in the submission text. It's a dubious case, but I don't think we are ready yet to approve it as an emulator, considering its current inability to properly create TASes with it.

Next, the run has another issue, which in my opinion is an even bigger factor: its goal choice. The glitch showcased in this run is referred to as a "kill screen" in that it unavoidably turns the game unwinnable. I disagree with this definition however, as unlike most kill screens, there is no preset criteria where it is triggered; this is unlike e.g. Pac-Man's kill screen on the 256th level, Duck Hunt's kill screen on the 100th level, and Donkey Kong's kill screen on whichever level causes its death timer to overflow. In fact, due to the way the glitch is triggered in this game - through running at maximum speed combined with some randomness - it actually is possible to avoid the kill screen entirely through slowing down, which, in my mind, defeats the point of a kill screen. Instead, I'd opt to call this a "crash", as it more unpredictably puts an end to the game. However, "fastest crash" - while it has been done for multiple April Fools' or joke submissions - is not an acceptable category, as it does not constitute finishing the game. It only really shows off how the buildings can glitch out and impede further progress.

I'm rejecting this run for the above reasons.

As to what would make an acceptable category for an endless game like this - I'd be more inclined to think of a "maximum score" run to be the best way to run it, in the same vein as other endless games like Tetris. While the game's distance counter technically does not stop, it does have a maximum distance accounted for by the game, at 99999m. It would take much longer than this short run, so one would have to see if entertainment can be kept up over the course of the run. If it does, it would be great.