If it is emulating hardware that a normal human would use at time of game release, it's OK. If it's emulating hardware that is not available to a normal human (i.e. no super computers), or came out after the game was released, it's not.
One question I'd ask to clarify your view - if the game has been updated since then, can hardware used at the time of its most recent update be emulated?
Is there a ruleset that could be decided upon that disallows running games tied to CPU speed at rates higher than intended, but still allows free framerate manipulation below that limit (and above for games that don't apply)? That seems like the best solution.
My suggestion from the Towerfall Ascension thread should work. In brief:
* If a game's speed increases asymptotically with higher FPS (e.g. because it lets you put in inputs faster and certain tricks are more efficient, but the game tries to run physics at a framerate dependent speed so running at 1bil FPS doesn't make the game finish in under seconds e.g.), then raising the FPS is OK. (Additionally, future TASes are not required to run at the same FPS. Time lost purely because of setting the FPS to a different value is not counted, similar to how time lost purely because of changing regions or languages is not counted.)
* If a game's speed increases unbound with higher FPS (like a DOS game that gets 2x as fast every time you double cycle speed) then raising the FPS is not OK. Use some meaningfully defined default (like the game's default FPS if it has one, or how fast the game would run on typical machines when the game was released if it does not)
The stat system seems to be based on old school (1st and 2nd edition) D&D. The stats are Strength, Dexterity, Constitution, Intelligence, Wisdom and Charisma, And normally vary in the range 3-18 (the result of rolling 3d6). However, Fighters have a mechanic called ‘exceptional strength’ where their strength can range from 18/01 to 18/99. This post explains it well: https://rpg.stackexchange.com/questions/59638/how-does-fighter-strength-work-in-advanced-dungeons-dragons-2nd-edition-and-ba
Many old roguelikes and RPGs based their stat system on D&D, which is why this weird vestigal mechanic crops up in unexpected places, like Angband and Nethack.
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?
