GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 303
Location: Stafford, NY
This is a 1982 game from Games by Apollo - rather mediocre shooting action but with fairly good graphics for an Atari 2600 game as well as a recently discovered kill screen, as shown in this video: Link to video I decided to try this game as my first attempt at a TAS for a couple of reasons: 1. Simple gameplay (like with many Atari 2600 games). 2. The previously-mentioned relatively good graphics for an Atari 2600 game. 3. The claim made back in the day by Games by Apollo that Wabbit has the first human female character in a home video game (at least, one in a G-rated game :P). 4. The kill screen, which not only provides a clean ending point for a potential TAS, but was discovered at a fortuitous time for champions of integrity in maintaining world records. The discovery was made November last year, while debate was raging over the implications of Omnigamer's Dragster TAS. As it turns out, Todd Rogers [url= https://youtu.be/8e-H4sEHB54?t=9m36s]had claimed a score[/url] on Wabbit that the kill screen discovery proved to be completely fake. This means the timing of the kill screen's discovery helped in building the case against Todd Rogers and ought to give a TAS at least some attention it would otherwise not get. What do you guys think of this game though? Is there any potential for a good TAS here? P.S. The only thing this game has to do with Elmer Fudd or Looney Tunes is that it involves "wascally wabbits". Not that it stopped the game's manual writer from shamelessly imitating Elmer Fudd's speech patterns though...
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
For manipulation sake, you want to keep the rabbits on a single side and preferably you want them to come out of the 3 closest holes (which is possible, just time consuming). I think this is a game that is good enough to have a TAS hit the kill screen and it'll land in the vault, that's from my point of view. Best of luck if you're taking this project.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 303
Location: Stafford, NY
WIP V1 TAS that hits the killscreen -> http://tasvideos.org/userfiles/info/46029671199000949 This is a very crude and probably far from optimal effort, but I still decided to put it up here for three different reasons: 1. As a baseline for comparison of a different strategy I want to try out in V2. 2. To get feedback and suggestions for improvements beyond simply needing to learn how to manipulate the rabbit spawns. 3. To illustrate a glitch in the game that seems to have been revealed for the first time in this TAS (because this roughly comparable RTA run on TG doesn't have it). This V1 WIP run is based around the general strategy of, whenever possible, hitting the rabbits after they have grabbed the carrots, as this gets 10 points per rabbit vs. 5 points if you hit them before they grab the carrot. The upside of the strategy is that this means fewer rabbits to hit to get to the required 1,300 points for the killscreen. The downside is that you are still depleting your carrot patch doing this (because the removed carrots aren't replaced when you hit the rabbit) and each "cutscene" to fully replenish the patch costs at least 250 frames (exact amount is RNG-dependant because the "cutscene" can play out differently each time it occurs). V2 WIP will have the strategy of simply hitting rabbits as soon as possible regardless of how many points each one gives. I already suspect for some circumstances it would be faster than the current strategy, but won't know without testing whether it overall is actually faster than the one in V1 due to more rabbits having to be hit using it. I will keep the community updated on this as I work on V2. -------------------------------- Newly Discovered Glitch: If you cross the 1,200 point threshold with any rabbits on screen that normally come from the left side holes and hit them, the rabbits will "moonwalk" to the right edge of the screen and get stuck zipping back and forth in a small area between two right side holes! At the killscreen, they will not despawn but instead will be seen running in place on the right edge of the screen. Doubtless this is linked to what causes the killscreen in the first place and gives a possible idea of why it happens. -------------------------------- Conjectural Killscreen Theory: There are 10 holes on the screen, alternating left and right as you go down from the top. (Why the alternating pattern? The limitations of the system - look up "Venetian Blinds trick" to get a better idea of why.) Let's assume that behind each hole, on the edge of the screen, is an invisible (colored to match the background) rabbit sprite facing toward the center of the screen. The programming to control the movements of the rabbits would then go something like this: * Look up RNG value to determine which row(s) will spawn a rabbit. * Set an "in use" flag for the chosen rows (so that the game won't try to spawn more than one rabbit on a row at a time). * Start the rabbit moving by having its sprite be redrawn a certain X distance from its previous value each frame (lets call it VX for brevity's sake), that value being determined some way from the player's current score. * When rabbit sprite meets or exceeds a certain X value (corresponding to the center of the hole on screen), it changes color to become visible and collision is turned on. * Redraw rabbit "moving" by the VX value for each frame, checking for collision conditions afterward. (The illusion of movement is enhanced by constantly cycling the sprite through several poses every fourth or fifth frame.) * If X value of rabbit sprite is > or = X value of carrot sprite, set rabbit X value = carrot X value, despawn carrot sprite, flip rabbit sprite and continue previous movement by VX. * If X value of rabbit sprite is = X value of player shot, freeze rabbit's X position, change sprite to "hit" state by turning off collision detection (and blinking colors), and flip sprite if not already previously flipped. After this, continue previous movement by VX. * When rabbit sprite reaches previous X value corresponding to the center of the hole it "came out of", turn off collision (if not already done so) and recolor sprite to background colors again. * Flip sprite, stop movement and clear "in use" flag when edge of screen is reached by invisible sprite to prepare for next rabbit spawn. This loop of programming above would be followed each time a rabbit is sent out by the game, and works until you get to 1,100 points. Once you hit that score, you start to have problems (presumably related to the previous score rollover). At 1,100 points, the rabbit sprites will cycle back and forth within a range of X values each frame, the middle value of this range moving "normally" (although at a slower speed than before the score hit 1,100). This could be caused by the movement routine trying to make the rabbit appear in two different places at once. At 1,200 points, the movement routine seems to break down completely and rabbits will only appear for a few frames outside the right side holes. The VX value ends up set so that all rabbits will travel to the right side of the screen and stay cycling within a certain range of that side of the screen, even rabbits that "shouldn't be over there". And finally at 1,300 points you have the killscreen. VX in this case would somehow be set to zero for all active rabbits, which means they would never move from the right side of the screen and will remain permanently unhittable. At this point the code is stuck in an unresolvable loop and all you can do is turn the game off. Apologies for the long post, but the rabbits getting stuck makes things a little more interesting to watch toward the end, and I hope I can keep it in the final product. (All depends on RNG, of course...)
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 303
Location: Stafford, NY
OK, so after doing work on WIP V2 I've discovered several more things that, unfortunately, make this a more annoying game to TAS then at first look: * You can manipulate rabbit spawns by waiting frames, similar to what Samsara did in Riddle of the Sphinx. I was able to get a better starting position this way, but doing anything more beyond that would be a tedious trial-and-error process that might not even get me what I want (i.e. never miss rabbits at all). * The alternate strategy does save frames, but only if you have all three rabbits going at once. Otherwise, the original strategy is faster. * In the Three Rabbits mode of gameplay, each rabbit will spawn in one of three different "zones", and only one rabbit will be spawned per "zone". These "zones" consist of the top three rows, middle four rows and bottom three rows respectively. If there aren't any carrots in a "zone", rabbits will not spawn there until a patch is repopulated. This limits how effective luck manipulation can be in a TAS. * At the 1,100 point mark of V2, I ran headlong into a glitch similar to this one that killed the game too early. Without yet knowing how to manipulate my way around it, that means further TAS work is on hold until I can figure that out. I am also at this point wondering if Lua scripting would be able to help with the trial-and-error of the spawn manipulation. If anyone that knows scripting sees this message and thinks it will, feel free to PM me. EDIT 2/15/19: I am intending to go ahead with this project anyways, but currently I am waiting until the next release of BizHawk to start, which will incorporate a recent update to HMOVE behavior in the A2600 core that will most likely affect sync if I try to import a TAS started in a previous version.
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...