WARNING: Obnoxious tape loading noises until 2:29 in the encode.

ENCODING INSTRUCTIONS: This is my first ever submission using BizHawk, which means that this is a lot simpler than every other video I've submitted so far.

ABOUT GAME: Jet Pac (also released as and more commonly known as Jetpac, so feel free to add that as an alt name to the game database) is a 1983 arcade platformer game released for the ZX Spectrum by Ultimate Play The Game, the company that would later become Rare. This game is notable for many reasons; it is one of the finest games for the ZX Spectrum platform, even more remarkable when you consider that it is one of the few such near-exclusives for the platform (only receiving contemporary ports to the Commodore VIC-20 and BBC Micro), being targeted at the potato-tier 16k Spectrum model as opposed to the more popular 48k version, and for being the very first game released by the company at all, coming out of the gate with a smash hit. It is also famous for its appearance as a minigame in Donkey Kong 64, being mandatory for acquiring the Rareware coin and completing the game.

NOTES/GAMEPLAY: When I decided to make this recording based off the game's appearance in the ZX Spectrum wishlist, I was hoping to skip the minutes-long, ear-splitting tape loading sequence by taking advantage of the game's status as one of the few released as a ROM cartridge for the Spectrum Interface 2. However, as I soon learned, ZX Spectrum ROM file dumping conventions are inherently incompatible with TASing guidelines. ROM don't take the form of a dedicated ROM file with a header, but rather as a generic dump of system memory. While this is technically a correct way to go about things, as the Interface 2 merely breaks out the Spectrum's system bus and allows a ROM cartridge to map directly to memory, it means that these .Z80 dumps are identical to a form of emulator savestate, making it not a form of PowerOn. This is worsened by the fact that 99% of .Z80 files are not actual legitimate Spectrum 2 cartridges, of which there were only 10, but working memory dumps of loaded casette games for the convenience of emulator users. Thus, tape version it is.

In the game, you play as Jetman, tasked with building and fueling your rocket in order to explore alien worlds, defending yourself against ambiguous local beings that would fit right in in VVVVVV and collecting various treasures for extra points along the way. The game has 16 unique cycles divided into 4 stages, with the game increasing in difficulty until looping back to the first cycle. For each 4 cycles, you are first tasked with acquiring and dropping 2 rocket parts (with fixed spawn locations) onto your rocket to build it, then fueling it by dropping 5 fuel items to fuel it and liftoff. For the last 3 stages you don't have to rebuild your rocket, just refuel it, and each stage of 4 cycles has a visually unique rocket. Additionally, different enemies appear in each cycle, all with different movement patterns.

If you have a rocket part or fuel tank in hand, then hovering above the rocket will automatically drop it, letting it fall onto the rocket; however, this is extremely slow, so the primary speedrunning strategy is to instead bring the part down to the ground ourselves, using RNG manipulation to try and ensure favorable fuel spawn locations. Walking is much slower than flying with the Jetpac, so we spend the entire game flying, taking advantage of the hover control to maintain a stable altitude when needed. We also avoid using the laser unless absolutely necessary, as it impacts our flight, isn't instant, and in most cases will fail to fire when we try to use it too close to an enemy. While the screen does wrap, enemies spawn at the edges of the screen, and inconvenient enemy spawns mean I am often forced to avoid using the screen wrapping to move and instead stay inside the screen borders. The branch name comes from the RTA speedrunning convention, where the category is named after the number of rockets that the player fuels and launches, with the options being 1 Rocket, 4 Rocket, and 16 Rocket. This recording beats the RTA world record by 4 minutes, and even more when subtracting the tape loading time.

POTENTIAL IMPROVEMENTS: The only potential improvements in the run arise from further micro-optimized movement, shaving off individual frames, and better RNG rolls, being totally indeterminate. Fuel spawns are HIGHLY pseudorandom, with their drop location and time to drop being based off player inputs, but it is EXTREMELY difficult to make cooperate and reads your inputs up to the very last frame before spawning, meaning that you can't just move to try and anticipate a future drop (it will just appear somewhere else). The rerecord count is also HIGHLY deceptive and incorrect, as I spent much more time navigating the movie by seeking using the TASStudio Piano Roll than by loading specific branches. In terms of trivial timesave or fixable mistakes nothing exists, and I thus believe that this recording fulfills the optimization threshold.

nymx: Claiming for judging.

nymx: I'm making the decision to delay this for the author. RNG is not a quick and easy task in this game.

nymx: I've had a hard time, knowing how to handle this situation, but I've come to a conclusion that I think will be accepted across the board.

First off, welcome Technoturnovers. I see that you are very ambitious and enjoying the world of TASing. It's good to see that our community interests you enough to want to participate.

In regards to your submission, my first review revealed some things that I had questions about. If it hadn't been for the discussion thread responses, things would different today. For one, a number of people have supported your work and declared it to be well optimized. Coming from DigitalDuck, who I highly respect and does great work on the ZX Spectrum, I figured that the run was good to go; however, EZGames69 came on the scene...having done previous work that demonstrates the concerns that I had. Even though it was a demo of the first stage...it shows how the control of RNG was precise enough to zip through that round, cutting seconds off. After having a discussion with EZGames69, I got the impression that RNG is quite difficult to change and could be easily forgiven. From my perspective, I have seen that some games are just hard to deal with....and that's just the way it is. For "Jet Pac", it seems that this is quite the monster to overcome. I have personally discovered the dedication it takes to alter a game into being as fast as possible. On particular situation is my very own #7362: nymx's SNES F-Zero in 39:30.36 submission. In this case, it was the combined effort of almost 5 years, eventually requiring a BOT to handle the arduous process. Another case, is sniq's #6381: Sniq's SNES Super Metroid "100%" in 1:01:47.03 submission...where I personally witnessed the creation of this run over multiple years, having a re-record count of 700K+ of manual work.

Some games are just easier to deal with, while others...you just have to dig to figure it out. For this submission, my judgement comes down to one of our rules "Must beat all known times", which has been shown by EZgames69 work. Now I know that he only had two stages solved, but the pattern of optimization is clear...which I am not seeing in this submission. I really wanted this submission to succeed, which is why a few of us were providing you the opportunity and game details to do so. Its a great choice, but we have to consider the optimization. The other concept that I'm measuring this against, is the stress that our publishers are going through. Knowing that it can be improved, i would be doing our staff an injustice by adding more work to their load. Even though EZGames69 may have stopped for now, it is likely to be taken up again soon.

I don't want to be discouraging, but in this case I'm rejecting this submission...based on optimization issues brought up by the community and my own review.