TASVideos

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

Submission #5992: klmz's NES Formation Z in 01:51.9

Console: Nintendo Entertainment System
Game name: Formation Z
Game version: JPN PRG1
ROM filename: Formation Z (J) (PRG1) [!].nes
Branch:
Emulator: FCEU 0.98.28 (converted for FCEUX)
Movie length: 01:51.9
FrameCount: 6725
Re-record count: 5624
Author's real name: K.H.
Author's nickname: klmz
Submitter: klmz
Submitted at: 2018-06-14 08:00:34
Text last edited at: 2018-06-26 13:42:30
Text last edited by: Stovent
Download: Download (1450 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:
Formation Z is a sideway auto-scrolling shooting game in which the player controls a robot character that can transform into a jet to "DESTROY ALIENS WEAPON".

The scrolling speed of the screen can be changed according to the state of the character, and bosses may only appear when certain conditions are met, which allows the length of the gameplay to vary a lot. The jet form advances much faster than the robot form, however the speed varies depending on the height of the flight. Fuel is usually lacked in casaul gameplay and requires replenishing, but not in this run. Actually, no fuel replenishment is needed even if the player advanced at maximum speed all the time without abusing deaths, thanks to a glitch.

Originally, this run was deathless (see below) and intended for April Fools' Gruefood 2014 as a satire on the bias against usage of deaths to save time in Arcade TASes. However TASVideos.org then changed the movie rules to allow pure speed-oriented runs for the Vault Tier, invalidating that purpose. The author then decided to abuse deaths in the run, which merely helps to skip a game event. This run was soon completed with 6725 input frames.

But in the end, this run has turned out to be suited for a different irony. Hurrah!

(Link to video)

Game objectives

  • Ends the game?!?!
  • Emulator used: FCEU 0.98.28 (converted for FCEUX)
  • Aims for fastest input time
  • Abuses programming errors in the game
  • Allows deaths to save time
  • Manipulates luck

Does this game have an ending?

After the final boss spaceship is destroyed and before the game loops, a splash screen with the clear text:

     CONGRATULATON
     BONUS YOUR ENERGY
     TRY AGAIN
is displayed to the player. This might be leading to a debate on whether this screen is a legitimate presentation of an ending as there is no mention of words like "COMPLETE", "ACCOMPLISH", "WIN", "VICTORY", "END" or "FIN". "CONGRATULATON" is not even an English word. Further more, both of the "BONUS YOUR ENERGY" and "TRY AGAIN" pieces suggest that the gameplay can continue, which is endless.

That is to say, whether this run reaches a valid ending point can be questioned and the fate of it is now at the mercy of the Judge(s). The author is desperately seeking authoritative guidance on how to avoid such bad situations with possible submissions (if any) in the future.

Comments

Fastest Advance Speed

Jet advances the fastest when no clouds or walkable ground comes into scrolling. Seas don't affect it. The final void space slows it down but there is nothing to do.

Weaker Charged Shot

Release B button for at least 1 frame after a charged shot is out, and the shot will vanish after hitting anything. Just used in this run for fun.

Jumping on the Sea

The game allows the robot to walk on the "beginning part" of the sea so a new player can take time to react when the character dashes off the land onto the sea. It is glitchy that the walkable part of the sea is repeated every 256 pixels, so the character can land on it saving some precious fuel over the sea. The safe zone is relatively small considering the high speed, and a jump will span more than 256 pixels. To maximize fuel-saving, consecutive jumps are used in this run.

Enemies Spawn

Every kind of lesser enemies and bosses spawns according to some very complicated rules. Basically new kinds of enemy waves and bosses only appear when there are no lesser enemies (inlcuding their projectiles) are on screen and some timer and scrolling contions are met. And the exact configuration of the lesser enemies can be manipulated according to the PRNG, which is affected by the gamepad input.

As the goal of this game is to destroy the bosses, they are manipulated to appear as fast as possible. Enemy waves are be abused to align the timings of the conditions for the bosses. Some noticeable examples:

  • Right before the final boss appears, an enemy projectile is kept on screen to adjust the timings.

Screen Wrap

As in many 8-bit games, the player's shots can hit targets on the opposite edges of the screen. The first boss is destroyed on the top edge of the screen with a charged shot downwards diagonally. This is faster than to fly through its barrage, which blocks charged shots, to have a close-range shot.

Death Warp

By suciding when the first boss is destroyed, the gameplay will continue on the "moon" stage and the cutscene that the character flies up to outer space will be skipped.

Perish Together, or Not

Our heroic robot didn't perish together with the final boss. It survived as the count of rest lives indicated. This "heroic-but-pointless sucide" was originally meant for the satire as mentioned above.

Other Comments

Thanks to mtvf1 for the encode!


feos: This game does recognize that you've completed all its unique levels. It literally congratulates you with a splash screen. This is the same scenario as with Ghosts'n'Goblins or Arcade Punch Out. Even if the difficulty keeps increasing, the fact that we've beaten the final boss is explicitly acknowledged by the game, so it's enough for us.

As for the tier, it's a tough decision, because I really enjoyed the run, but the audience was not so sure. So I either accept this to Vault and it never sees the light of day whatsoever (I mean it won't get rated), or I accept it to Moons and see whether people actually like it, hate it, or are indifferent about it. After all, there's rarely clear idea what tier a run needs to go to after only looking at the submission feedback for such simplistic games. I either have to make a magical guess about its future rating feedback, predict it beforehand, and decide the tier based on this non-existent data (which somehow completely disregards and outweighs submission feedback), or go out of my way and explicitly call for this rating data, to then base the tier decision on it with at least some reason.

I pick the second option. I accept this to Moons in order to get some rating. Because I believe the amount of current submissions in the workbench distracts the audience from providing exhaustive feedback on any of the runs.

Stovent: Processing...


Similar submissions (by title and categories where applicable):