Submission #9490: Darkman425's O2 Showdown in 2100 A.D. in 01:09.22

Odyssey 2
Showdown in 2100 A.D.
BizHawk 2.10
4157
60.05645306588193
707
PowerOn
Showdown in 2100 A.D. (USA).bin
USA
add9a7cfac93608db1845e49f3594964
Submitted by Darkman425 on 1/20/2025 4:32 PM
Submission Comments

FLASHING WARNING

The screen abruptly changes colors when a bullet bounces off of anything. This bouncing also tends to be fairly rapid. There's also rapid color flashing at the end of the movie for the victory fanfare. Viewer discretion is advised.

Introduction

Showdown is a 1979 game developed by Ed Averett and published by Magnavox for their Odyssey2 console. The goal of the game is pretty simple. As one of the gunmen the player has to successfully hit the opposing gunman, controlled either by another player or the computer, with a bullet to score a point. Whoever scores 10 points first wins. Complicating matters are the technicolor trees in the way. When a bullet hits the trees, the bullet's trajectory bounces off in another direction. The bullet travels and bounces until it either hits a gunman or the vertical walls of the arena.
Right now I had the urge to TAS a few short games to start off 2025 with some sort of drive. My original plan was to try to do one of those "end inputs really early and let the game solve itself" but the initial tests failed for reasons that will be explained after the other game mechanics. I'm glad I did make a more "proper" TAS since there's some interesting quirks that had to be considered.

Run notes

  • Emulator used: BizHawk 2.10
    • O2Hawk core
  • Genre: shooting
  • Single player mode, player 2 side

Game mechanics

Starting a game
When starting a game, the computer doesn't immediately start. This is because for a certain period of time the game is trying to detect any inputs from the controllers to determine if there's another player present at that controller. This does mean that the computer can fight another computer if no inputs are detected on either controller after getting into the game. Note that this period allows for a player fighting against the CPU to move before they're active, giving an opportunity to shoot them for essentially free point.
Player side advantage
When a gunman shoots, the bullet comes from the upper half of the sprite. Due to player positions, this means that the player 2 side has a starting advantage as they don't have to walk up as far to get an opportunity to shoot the other gunman. I take advantage of this uneven balance to speed up getting points by playing on the player 2 side.
Double KO and CPU positioning
It's possible for both players to get shot in the same round. This counts as a point for both players. This happens once but I try to avoid having the CPU shoot as every gunshot creates a frame of lag. The main way to avoid the CPU shooting is to get out of their vertical range check. This also gives the player 2 side a lag reduction advantage as the player 1 side always has to cross that range to get a clean shot on the other gunman.
Frame rules
Shooting is roughly on a frame rule where the game detects if the shoot button is pressed in frame intervals. This is also affected by moving, where the game will sometimes skip a shoot check if a player is moving their gunman on the screen. This does limit when and where the fastest possible positions to shoot are done.
Unused strat: convincing the CPU gunman to shoot themselves
Bullets will bounce off trees in many directions. As bullets also don't care who they hit, it's very easy for a gunman to shoot themselves accidentally by having it bounce off a tree wrong. This was my initial plan for a "shortest input" TAS of the game but I ran into complications. Doing this on the player 1 side eventually resulted in the CPU gunman walking up to the other one, causing them to overlap and the CPU gunman never getting in position to shoot their gun again until the other one moves. Doing this on the player 2 side resulted in the CPU gunman going into an endless movement loop due to their pathfinding. Maybe starting the game on a later frame or ending inputs after a certain amount of shots could work out, but at that point I decided on fastest time to reach the ending victory sequence.

Suggested screenshot

Frame 2547, where there's a bullet bouncing around next to player 2 while the CPU player is in the middle of falling down.
Last Edited by Darkman425 4 hours ago
Page History Latest diff List referrers