TASVideos

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

Submission #3882: Quibus's MSX Hunchback in 04:12.53

Console: MSX Home Computer System
Game name: Hunchback
Game version: unknown
ROM filename: HUNCH.CAS
Branch:
Emulator: openMSX 0.9.1
Movie length: 04:12.53
FrameCount: 15133
Re-record count: 338
Author's real name: Manuel Bilderbeek
Author's nickname: Quibus
Submitter: Quibus
Submitted at: 2013-03-06 22:11:52
Text last edited at: 2013-03-13 20:25:09
Text last edited by: Ilari
Download: Download (73113 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:

The Game

This is Hunchback, a 16kB MSX conversion by Ocean of the 1983 arcade game. It was released on tape, which makes this probably makes it also the very first submission of a tape based game.

From http://www.arcade-history.com/?n=hunchback&page=detail&id=1154 we learn the following...

Description

The player takes on the role of the eponymous bell-ringer, Quasimodo, in his quest to rescue the beautiful Esmeralda from the tower of the castle fortress.

To reach Esmeralda, Quasi must run and jump through a number of screens - each representing part of a castle wall - to reach the tower and complete his rescue. Each screen presents the player with a different set of platform-based obstacles. These range from spear-toting guards, to ramparts and fiery chasms (the latter of which is cleared by carefully timed jumps onto and off a constantly swinging rope).

Most of the game's screens also feature projectiles - in the form of fireballs and arrows - that must be avoided. Contact with either a projectile or guard will result in Quasi falling from the castle wall, resulting in the loss of a player life.

To complicate matters further, each screen must be completed within a strict time limit. This takes the form of an enemy guard climbing the castle walls; if the guard reaches the top of the wall, he will walk towards Quasi to burn the Hunchback with his torch. If Quasi rings the bell before the guard has scaled the wall, a bonus score is rewarded. If five screens are completed without a life being lost, a 'Super Bonus' is awarded.

Once completed, the game starts over with a much higher level of difficulty and tighter time limits.

Scoring

Scoring points is based on how quickly you can finish a round, although there is no actual on-screen indication as to how much bonus time is left. No points are awarded for merely jumping over obstacles. The best way to achieve a high score is to complete five consecutive screens without losing a life; at the end of each stage a bell is awarded, and once five bells are collected in this way, a Super Bonus worth between 10,000 and 30,000 points is awarded.

The TAS

So, as the last paragraph explains, the score of each stage is also directly telling you how well you TASed the stage. Now, that's comfy :) This means the TAS also aims for the highest score.

The goal is to rescue Esmeralda in the shortest possible time (implying also the maximum score). After rescuing her (at the end of the 15th screen), the game will repeat itself (see above), so that's where I stopped.

Tricky of this game to be played optimally is optimizing the combination of jumping over the ramparts (with guards using spears) and at the same time avoiding the obstacles. In some stages you see a slight hiccup in the jump... This is an intentional delay in order to avoid the obstacles in the most optimal way (with more entertainment than simply stopping walking...).

Furthermore, to make the run a bit more entertaining, I jump a lot, because the game features such a funny bouncy-bouncy sound effect. So, whenever possible, the player is bouncy-bouncy. Other entertainment features are very close shaves, even when not necessary. No time was wasted on entertainment, though.

Tape game

So, indeed, it's a tape game. It means that the total run time calculated by the site will include the loading time. And the loading time can be different, depending on when you type the loading command (auto typed by openMSX in this case) and how exactly you recorded the game on the tape. For this run, I use the CAS format, which contains the actual tape data, which openMSX converts to the actual sound signal of the tape on the fly. (These are the sounds you hear during loading.) That conversion can be done with several baud rates. For emulator convenience, the baudrate that openMSX uses is higher than normal (2760 baud). Normal games either use 1200 or 2400 baud. Anyway, all of this means that when someone wants to improve the run, we should not include the loading time of the game in the comparison of the achieved time.

Last words...

Well, enjoy the run... I did enjoy creating it. And oh darn, it wasn't easy....

Here's a video showing the run (after loading the game):


(Link to video)


feos: Accepting for Vault.
Ilari: Fun loading times...

Ilari: Submission file made compatible with vanilla openMSX 0.9.1.


Similar submissions (by title and categories where applicable):