Important to note, this TAS uses a hidden input combination that is not given to you anywhere in the game which skips the waiting period where Bowser's back is hurt.
Is this expected to be a problem for acceptance? It doesn't sound like it gives any gameplay advantage or change the route (contrast with the GT code in Super Metroid for example).
Oh, I thought of a good one. How about super hard Shmup bosses? In particular, Dodonpachi Saidaioujou’s Inbachi, possibly the hardest boss in an arcade game.
There is only one known clear, and it’s on the XBOX360 version:
Link to video
Annoyingly, it is possible to create a replay by playing it back, taking control at some point and saving the new replay, and the new replay remains valid for leaderboards. So we do not know if this is TAS or unassisted. But given the circumstances (no proof of unassistance and no other clears) it’s probably TAS.
So, this thread hasn't updated in a couple years, but having recently finished my second DOS TAS, this game was next on my wishlist of games to TAS. Should I start my own thread, or start making replies here?
I have downloaded the game, and am currently troubleshooting how to get it running, because I get a message saying I need 2K more memory (even after trying to up the memory in the JPC parameters), or I can run it without SoundBlaster emulation, which is a travesty because the in-game sounds are *hilarious*.
Reuse the existing thread is the policy around here! Good luck, i am looking forward to a TAS of this game.
Nice job with the submission text. It amuses me that in these other games we're worried about arbitrarily high FPSes making the game faster, but here higher FPSes patch all the tricks out, lol
Can this be clarified further? It is also possible to beat gen 1 pokemon RTA with the save corruption glitch. Is the TAS route not equal to the RTA route?
* The above points all assume the game gets asymptotically faster with higher FPS. If it gets faster with no bound with higher FPS, then allowing TASes to use whatever FPS is obviously absurd - it would be like DOS TASing at arbitrary CPU cycles.
I was curious as to how this might relate to DOS CPU cycle settings. The CPU cycle limit rule was brought into place to make sure emulator speed settings were not set above what a normal human would be playing at when the game was released. Similarly, I think FPS settings shouldn't be allowed to be set higher than the hardware limitations of the video devices available when the game was released. If it was possible to for a normal human to play at 1,000 FPS (with the appropriate hardware) when the game was released, then this should be allowed. If this is something that can only be done because of the emulator or because better technology came out later, then it should not.
I think another thing to consider here is that most DOS games get arbitrarily (as opposed to asymptotically) fast as you increase their FPS, rather than having things happen at about the same speed, but smoother and responding to input more often. Because nothing interesting happens from a TAS perspective when you speed a DOS game up faster than it would 'reasonably' be played at, this motivates the rule to cap DOS CPU cycle settings at a 'reasonable' value.
The argument of using hardware limitations is an interesting one though, and worth considering.
How about Dustforce?
'A Linux port was released as part of the Humble Indie Bundle 6.'
So it should be TASable with libTAS, and it is already extremely well explored under TAS conditions (same as Celeste and Super Meat Boy).
Since feos is looking for thoughts on how variable FPS games should be handled in the rules, here are my thoughts:
* It should not be required to run the game above whatever its default FPS is (or a reasonable default if the game doesn't specify one, such as 60), even if running it faster makes the run faster.
* If a TAS is submitted at a certain FPS, and later an improved TAS is submitted at a higher FPS, the second TAS should only be accepted if it has improvements that are not related to simply increasing the FPS and following an identical route. (This is similar to how improvements based entirely on non gameplay frame saves like improved loading times are not considered valid.)
* Conversely, if an improved TAS is submitted at a lower FPS, and it only loses time to the FPS being lower, and is otherwise faster due to new tricks/routing, it should be acceptable. (If a trick is only possible at higher FPSes and the trick is now foregone causing a time loss, though, I think -that- should count as being suboptimal and cause a rejection. So the FPS must be at least high enough for all fastest tricks in the run to be possible, and as long as the run optimization/quality increases agnostic to the chosen FPS besides that, the improvement is acceptable.)
* The above points all assume the game gets asymptotically faster with higher FPS. If it gets faster with no bound with higher FPS, then allowing TASes to use whatever FPS is obviously absurd - it would be like DOS TASing at arbitrary CPU cycles. In such cases, increasing FPS above the reasonable default (60 or whatever) should be banned. (Side question - does this now mean judges are obliged to research how FPS affects all mechanics and tricks of the game, or should the submitter's research be considered good enough?)
Now that Linux TASes are accepted to the site, we have an interesting corner case: Some games (like Towerfall Ascension) run at arbitrary FPSes, and get asymptotically faster the higher the FPS is (you can make tighter turns, some tricks speed up asymptotically, etc). If a TAS of such a game is submitted that adds no new strategy but merely goes faster by setting the FPS higher and copying the route, would this TAS be accepted or rejected and why?
The seaquest emulator bug is elaborated upon here: http://tasvideos.org/forum/viewtopic.php?t=15266
I think the Paperboy bug is that the starting layout of houses isn't reproducible on console due to differences in uninitialized RAM values?
Do you want just runs that are invalid due to emulator glitches, or also runs that are invalid because if they were submitted today, they wouldn’t be eligible to vault due to changes in e.g. what counts as completing the game?
the fact that that run requires toggling the difficulty switches mid run feels TAS-y (like u+d/l+r stuff) so it isn't even a demonstration of what maxed out human play can do.
The 2600's difficulty settings were physical switches on the outside of the console deck, so yes, they could be changed at any time. A few games even used them as additional controls, e.g. Space Shuttle.
Ah, didn't realize they were intended as mid-game input sometimes!
Not a wide list to play. Is there any 3D games compatible with libTAS? Does Steam Play work?
Jazzpunk is 3D! Everything else confirmed to work seems to be 2D (well, Fez is 2.5D...)
Steam probably won't work, because it says 'Also, Steam games won't work because Steam messes up with our code injection, so you must check if a drm-free version of the game exists.'.
