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!

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

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.

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.

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.

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.

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:

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.

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.

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.

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...