- A video game is audio/visual. It presents its content on some electronic device in audio and/or video form.
- A video game is interactive. It requires repeated user input to progress.
- A video game poses a virtual task. It requires the player to accomplish some in-game job.
- User input is transformative. Which set of suggested in-game choices you make determines optimality level of your play.
- A video game is finite. It has an objective end point, or a community vetted one. Note that this definition is strictly for TASVideos, and is not meant to objectively define a video game in all contexts.
I've always felt like Standard was missing a goal for something along the lines of "forgoes the use of one common glitch", where the movie can still feature many glitches of various severity, but omits one particular one that would otherwise be repeated throughout the movie.
It could be as obvious as Zelda 2's L+R glitch or as subtle as this run shooting things outside of window bounds just as long as the core gameplay is noticeably and meaningfully changed.
I think a big problem here though is that we run the risk of overpopulating a game with similar branches, which as much as I tend to think "What's the issue with adding more branches?" these days, it wouldn't really make sense to have "any%", "any% that uses a movement glitch but foregoes major skips", "any% that uses major skips but foregoes a movement glitch", and "any% that doesn't use any glitches" all alongside each other. Even in the case of this game, I'm wondering whether or not it actually makes sense to have "any% that uses no window bounds and a level skip glitch" and "any% that uses the level skip glitch but stays within bounds" alongside each other. Were someone(stuff) to make a version that foregoes both, would that be a separate branch as well? I think we might have to make it a sort of nebulous thing where we can accept any of these kinds of branches as standard, but depending on the game and the glitches there may be cases where we have to figure out what branches are worth keeping published together and what branches might have to go to Alternative or Playground.
and collect this one instead (which costs you 88 frames of detour)
I compared gameplay more closely, and it looks like you make better decisions, so your movie is still faster overall, but there's definitely room for more. And I personally prefer the SMS version because it has the benefit of a bigger screen (and presence of in-game HUD) while not having any obvious shortcomings.
After the Summoning Salt video showing the level skip bug, I decided to start with Trax's disassembly and take it further. I've made a complete disassembly of Contra with proper labels which allows for modification without breaking jumps and branching. It includes supplemental documentation, diagrams, lua scripts, and tooling to build the rom. This code is on github at https://github.com/vermiceli/nes-contra-us/
I probably have the originals on an old hard drive, if you want them.
I've always felt like Standard was missing a goal for something along the lines of "forgoes the use of one common glitch", where the movie can still feature many glitches of various severity, but omits one particular one that would otherwise be repeated throughout the movie. #7874: GMP's GC Prince of Persia: Warrior Within "zipless" in 24:56.15 is a great example of this in recent memory, though I'm sure there's many others that also fit the description.
While not necessarily applicable to these two TASes, I feel that it's worth talking about the limitations of off-screen mouse input in the official Flash Player, as this seems to have been the main argument used for allowing it. While you can indeed click things before they appear within the regular bounds of the screen in Adobe's offline Flash Player, you can't really do so along diagonals. Expanding the window in two dimensions at once merely causes Flash to expand things up to fill in the gap. So while it's possible to click things that are off-screen in one dimension, it's not possible to do so for things off-screen in both at once. It's also not possible to see anything beyond the normal bounds, at least in the games I tested.
That being said, I am still not against the idea of having these as two separate branches. While I can't say I find its usage here to fall under the category of a "major skip glitch"...I would prefer it if TASers had the option to submit movies that specifically choose not to exploit this kind of thing. It feels...cheap? Unintended? Unentertaining? It's hard for me to pinpoint anything in my gut reaction that makes for a coherent point here, and it seems the few of those who have participated in discussions about this agree on accepting it, but I'd very much prefer to be able to keep making TASes that choose not to use it, without such things being treated as an "optimisation error" or "not in an entertaining enough movie". Frankly, the most I've been able to see myself using this is choosing a female worker in the Papa's games where a male worker would otherwise be faster to select. Perhaps L+R/U+D is worth considering in this discussion as well, if it's considered a rather similar issue to this.
Option B - The technique is used to save major amounts of time by directly interacting with gameplay in some way, either allowing for glitches that lead to major skips or significantly skipping intended waiting sections as happens here. [...] As for option B, it absolutely should be a separate branch. My initial thought would be to put both branches in Standard, with the one using off-screen clicks as the baseline, since I believe that's how it currently works with L+R input in older console games? Though doing it another way may be more practical, I'm rather new to the site and don't yet fully understand the decision-making behind how the branches and classes are structured.
Waiting for these two to finish their dialogue and run out:
My initial impression was that off-screen shooting only skips the waiting time, and the change is not visible to the viewer anyway. But there's also an argument that the wait is skipped by shooting, in a shooting game, so it's a direct part of normal gameplay.
So the main question is, do we make this a new branch or do we obsolete [4923] Flash Sniper Assassin 3 "inbound mouse" by Spikestuff in 02:37.50? If new branch, then what's the defining criterion? There's no visible difference so it can't go to Alternative, but maybe results of the off-screen shooting can be considered a major skip glitch, hence making both movies go to Standard alongside each other? If the argument is that glitchless can be a new standard branch, both movies abuse a glitch that skips some levels due to fast shooting (tho I'd personally be interested in a glitchless branch).
As far as I'm aware, the precedent has typically been to only accept one ACE category, maybe a second for playaround. I could see there being different branches for different releases of a game in cases where there's significant vanilla gameplay difference but for a branch whose goal is basically to trigger the credits as fast as possible using any means (and any version) necessary? I don't really see a reason for it, it should just obsolete the NTSC run, imho.
This submission is an interesting stress test of the rules in regards to how trivial something can be while still being acceptable for publication.
Read the screen as an array of tests: XX-YYYY where XX is the byte precharged onto PPU open bus, and YYYY is how many loop iterations it look before PPU open bus changed its contents. Each loop is 15 CPU cycles
and it does nothing.Language: luamemory.registerexecute(0xBD29, function() local script_ptr = memory.readbyte(0x99) if 0x2000 <= script_ptr and script_ptr <= 0x3FFF then print(string.format( "%d: $%04X $%04X $%02X", emu.framecount(), script_ptr, 0x2000 + (script_ptr % 8), memory.readbyte(script_ptr) )) end end)
You can compare the tricks and see the improvement.
I obsoleted the original run (or... whatever you want to call it) based off of genuine improvement.
Even the ROM with the identification given in the SMS publication runs at 50 FPS no matter where I source it from.
Gameplay must be accurate to hardware Running 50Hz PAL games in 60Hz NTSC mode (and vice versa) is also not allowed, save for a couple exceptions:
- Sega Master System games with an official release in Brazil can use NTSC mode, due to Brazil's PAL-M being functionally identical to NTSC.
I do wonder if the PAL-M scenario here created any loopholes of gain with Brazil SMS vs. NTSC Game Gear, i.e. if they adjusted the ROM at all to run better at 50 fps (higher walk speeds, etc.), it could be illegitimately faster on the PAL-M port.