TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #4526: dwangoAC's C64 C64anabalt in 21:25.22

Console: Commodore 64
Game name: C64anabalt
Game version: unknown
ROM filename: C64anabalt_Encore.crt
Branch:
Emulator: BizHawk 1.9.1
Movie length: 21:25.22
FrameCount: 64421
Re-record count: 4283
Author's real name: Allan Cecil
Author's nickname: dwangoAC
Submitter: dwangoAC
Submitted at: 2014-12-26 10:04:30
Text last edited at: 2015-01-13 05:21:18
Text last edited by: dwangoAC
Download: Download (11342 bytes)
Status: published
Click to view the actual publication
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:
Note: This C64 game was initially misidentified as an NES game because the site did not yet recognize Commodore 64 submissions (...which was sort of not the first time I've caused that problem either, but I digress). The issue has since been corrected.

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 its maximum (as defined by reaching decimal value 800 at system bus address 0019) at which point the building generation code can no longer keep up. As Aqfaq pointed out the player hit an average running speed of 111 mp/h (180 km/h). At the fastest speed high jumps have to be predicted because the landing point isn't even visible on screen. It's possible to slow down by hitting various different obstacles such as crates and chairs (which drops the speed from 800 to 550) but since this is a TAS and we're all about speed here I worked hard to never do that.

The building generation code can do a number of interesting things wrong, but the game holds up surprisingly well. Here are some of the patterns I noticed:

- The front portion of a building can go missing, usually in a stair-like fashion from upper left to lower right off the bottom of the screen

- An entire building, save for a small pillar at the very beginning, can go entirely missing, leaving empty grey space

- Layers of building consisting of rooftop, grey strips, window sections, and sometimes even portions of a crane can cause glitched sections that are either barely passable or completely impassable

- Immediately after one of these sections, there is always either an office building you can run through, a crane, a falling building, or a falling detonator (as in, whatever follows these glitched sections is always different than a normal building) Sometimes, glitched sections have the lower building portions replaced with glitched tiles

I originally believed that the glitched sections were completely impassable, but it *is* possible to manipulate different building sections into appearing by altering jumping patterns several seconds (read: several buildings) earlier. What I encountered the first time I worked on this game was a behavior where it appeared that the upcoming buildings could not be changed because I hadn't backed far enough back, and that lack of testing was largely due to the difficulties with savestates at the time (as in, the complete lack of them... :) I was very relieved to discover that I could always one way or another change the future building layouts to be passable, although I regret that some of the more interesting constructions can't appear in the TAS because they are impassable (often because a full-height office building with the windowed sections generated with the windows in an inaccessible place).

The game starts out at a reasonable clip but within a couple of minutes the speed maxes out and I keep it there for the remainder of the game until reaching the agreed-upon ending of the game when the distance counter overflows from 99999m to m000m. Along the way there are some very notable sections of incredibly tricky through-building maneuvers (although there are also long stretches of nothing interesting happening other than running very, very fast - how many energy drinks did this guy consume, anyway?) I like the area around 26,000 meters and several other points too numerous to mention where it's possible to go right through the glitched buildings, sometimes even leading directly into windows and office buildings. I'm also a huge fan of the very end of the movie where I do the seemingly impossible and jump clear over an office building you should normally only be able to jump through. I end movie input as early as possible on the final jump and the counter rolls over to m000m as the player character soars over the final office building and plummets to his inevitable death (although he makes a clean exit between the buildings, so I'm holding out hope he somehow survived).

I'd like to take a moment to thank paulko64, the talented Commodore 64 game designer who ported this game, for participating in the forums and providing valuable insight the first time I submitted this game. I'd also like to thank Saxxon for his contributions to the C64 core and his recent improvements to savestate handling, without whose efforts I'd still be violating site standards attempting to TAS this using virtual machine snapshots. Finally, I should note that my brother-in-law assisted in the making of this TAS in between family obligations over Christmas and finished most of the movie between ~20,000m and ~30,000m as well as ~70,000m to ~80,000m - it's always a success when new people can be introduced to the art of Tool-Assisted Speedruns.

Note: The Commodore 64 core of BizHawk is technically unfinished but thanks to the aforementioned efforts on the part of Saxxon it is now suitable for many purposes. Specifically, saving and loading a state will not crash or cause a desync as it did before, although as of 1.9.1 there is still an issue where it's possible to get savestates beyond the end of the movie. This should be fixed in the next release thanks to assistance from Adelikat; in the meantime, it's possible to work around the issue by recording a few minutes forward and restoring a much earlier savestate first, although I opted to compile from source to bypass the issue altogether; the movie syncs in 1.9.1, so have no fear.

So, go grab the freely-available ROM and give this faithful port of a great game a shot! I hope this run is accepted (even if it's Vaulted) as I think this is a fantastic port of a fantastic game that deserves the attention and I hope you enjoy this run.


Mothrayas: Judging!

Mothrayas: Delaying judgment pending proper site implementation of Commodore 64 movies made in (experimental) C64Hawk.

Nach: I added support, so undelaying.

Mothrayas: C64Hawk is an experimental emulator, and is therefore prone to certain games or things not working, and the emulator is not guaranteed to improve. It does seem to work fine enough to run certain types of games, with usable movie recording and savestate functionality, so that movies like this can be made and played back. So essentially, it does conform to the basic standards of an emulator that can be accepted for publications on this site. It's similar to emulators like pcsx-rr and FBA-rr in that sense, in that games might not be guaranteed to run nor movies be guaranteed to be stable, but as long as the emulation and tools work to reasonable extent, movies using the emulator can be published to the site.

Bottom line: C64hawk movies are in a bit of a "try at your own risk" status, where games or movies might not work and emulation issues might put a halt to a run.

That said, accepting this run to the Vault. Viewer feedback was somewhat positive but the repetitiveness makes it fall short of making it to Moons, and the ending point as it is has been established as being the ending point for runs of this game.

Spikestuff: A certain lemon is providing the files. Publishing for the lemony encoder.


Similar submissions (by title and categories where applicable):