Artificial or not, if it makes it more entertaining, why not allow it?
Entertaining or not, changing gameplay speed should be banned completely.
If you think that original gameplay speed in some specific TAS is too slow, youtube already has speed up feature 1,25x, 1,5x and 2x for this purpose.
I show you how deep the rabbit hole goes.
Current projects: NES: Tetris "fastest 999999" (improvement, with r57shell)
Genesis: Adventures of Batman & Robin (with Truncated); Pocahontas; Comix Zone (improvement); Mickey Mania (improvement); RoboCop versus The Terminator (improvement); Gargoyles (with feos)
This sounds like changing gameplay speed should be banned from Vault.
I'd rather ban it from Moons as well. It's an artificial way of creating "entertainment" and may often result in sound effects going off at the wrong times etc.
Artificial or not, if it makes it more entertaining, why not allow it?
If people don't like it in certain cases, then it obviously will fail the "more entertaining" threshold.
My reasoning for this is simple: It lowers the barrier of entry to Moons from "What features interesting gameplay" to "What games am I able to increase the gameplay speed in".
As Archanfel said, YouTube features the ability to increase speed of a video. This is no different from that.
I don't want to see submissions that raise the framerate of their game just to avoid Vault by making it "more entertaining". I'd much rather see games run at their intended speeds.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
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.
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)
I'm late to the party, but I'd like to throw in my two-cents' worth. My apologies in advance about my limited understanding of current video hardware, or if others have already covered some of this ground:
Short version
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.
Long version
TASses are supposed to be "Superhuman" runs of games, as if the player had perfect reflexes, knowledge and strategies. And the only way to be superhuman is to compare to a human. Often criticism of TASses comes from the false view that the emulators act like game genies, giving runners access to moves and bonuses not available to regular runners. Allowing emulator-only benefits would legitimize this opinion.
Whatever the decision, it needs to be consistent with the DOS TAS limitations. There's a reason why we run DOS TASses on emulated 286/386/486 hardware. It would be against the spirit to emulate a quad-core i7 playing those games just to get an advantage. Linux TASses should either have to meet the same standard when it comes to hardware limitations, or all hardware limitations should be removed.
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?
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?
It would depend on the scope of the update. If it’s a new edition of the game (e.g. a remake/sequel) I’d say yes. If it’s merely a patch or a “classics” rerelease, I’d say no.
Too many pages, will read again.
My inital idea is based on my life experience on how OS and PC malfunctioning can alter gameplay, from Blur slowly overheating my GPU up to a point that the game logic started changing (apart from ending gameplay with only vertices/white lines were rendered and PC turned off itself).
Obviously this is dangerous as fuck, but if I could do it in real life, then..
So nevermind, list of wishes without dangers:
I would love the opportunity to able to customize the periherals of PC to
1. Ability to completely freeze cpu (or atleast pause from OS side, similar to J2ME game suspends while KVM wants to do it)
2. Ability to use arbitrary OR at least known manufactured resolutions.
3. Ability to slowdown/fasten up cpu core speeds to manipulate FPS
And here we are, there are many hundreds or even thousands of PC gamed that runs as fast as possible, so even the duration of the frames are inconsistent.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
I don't know of any games with glitches that require very low FPS for the whole duration of the run, but I am familiar with a number of games that require very low FPS just for the duration of exploiting a glitch, which is usually only a couple of frames long and doesn't pose much watchability issue.
Getting the low framerate just on the part where the glitching needs to happen, if the game itself does not support capping the framerate to something so low, would require external means of lowering the framerate. If we are talking about an emulated environment (as is most usually the case with TASes), it would require for the runner to manually lower the emulated speed of the emulated hardware for the duration of that glitch.
I doubt that would be acceptable in any way, not under current rules nor probably ever, because it goes against the spirit of TASing (runs shouldn't abuse the emulator itself to make the game glitch. And how would you even theoretically achieve this in the original hardware, without some sort of external software or something?)
The only way I could theoretically envision this happening is if, rules permitting, the emulator is set to emulate a really slow and old computer, which runs the game like molasses (and this slow running speed is what allows that glitch).
I don't know of any games with glitches that require very low FPS for the whole duration of the run, but I am familiar with a number of games that require very low FPS just for the duration of exploiting a glitch, which is usually only a couple of frames long and doesn't pose much watchability issue.
Getting the low framerate just on the part where the glitching needs to happen, if the game itself does not support capping the framerate to something so low, would require external means of lowering the framerate. If we are talking about an emulated environment (as is most usually the case with TASes), it would require for the runner to manually lower the emulated speed of the emulated hardware for the duration of that glitch.
I doubt that would be acceptable in any way, not under current rules nor probably ever, because it goes against the spirit of TASing (runs shouldn't abuse the emulator itself to make the game glitch. And how would you even theoretically achieve this in the original hardware, without some sort of external software or something?)
The only way I could theoretically envision this happening is if, rules permitting, the emulator is set to emulate a really slow and old computer, which runes the game like molasses (and this slow running speed is what allows that glitch).
Some games have methods of adjusting framerate in the middle of the game.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
More to my point, as YaLTeR said, such a low frame rate wouldn't be done for the entire video; it would last only a handful of frames
And how exactly are you going to achieve that?
(You seem to be assuming that the game itself supports natively lowering the framerate. I'm not making that assumption. I'm making the assumption that the framerate is lowered by emulating a really slow computer. Which would mean that the entire run would have to be run at a glacial framerate.)
by nature of the fact every frame costs so much time.
Playing speed of modern games does not depend on the framerate. It doesn't matter if you are running at 120fps or at 12fps, the gameplay speed (eg. running speed, animations, etc.) will still be the same. It's just that with a lower framerate the game "jumps ahead" by bigger steps.
So with such a game a very low framerate would ostensibly not cost any time. It would just make the run a slideshow.
Getting the low framerate just on the part where the glitching needs to happen, if the game itself does not support capping the framerate to something so low, would require external means of lowering the framerate. If we are talking about an emulated environment (as is most usually the case with TASes), it would require for the runner to manually lower the emulated speed of the emulated hardware for the duration of that glitch.
I doubt that would be acceptable in any way, not under current rules nor probably ever, because it goes against the spirit of TASing (runs shouldn't abuse the emulator itself to make the game glitch. And how would you even theoretically achieve this in the original hardware, without some sort of external software or something?)
Well, you could argue that as opposed to a console (at least old ones), a PC game runs inside an OS that is not entirely dedicated to run the game, so there will be fluctuations of the game framerate depending on what is the OS doing. Could we draw a line between acceptable fluctuations and going from 0.1 fps to 1000 fps ?
Joined: 8/28/2018
Posts: 75
Location: United States
Warp wrote:
Doomsday31415 wrote:
More to my point, as YaLTeR said, such a low frame rate wouldn't be done for the entire video; it would last only a handful of frames
And how exactly are you going to achieve that?
The methods that TAS's use in various games to affect the frame rate are not relevant here. All that matters is that there are situations where a TAS would optimally use a different frame rate.
Playing speed of modern games does not depend on the framerate. It doesn't matter if you are running at 120fps or at 12fps, the gameplay speed (eg. running speed, animations, etc.) will still be the same. It's just that with a lower framerate the game "jumps ahead" by bigger steps.
So with such a game a very low framerate would ostensibly not cost any time. It would just make the run a slideshow.
And in such a case the pros and cons would have to be weighed on a case-by-case basis.
I'm not saying that there should be a blanket rule allowing everything no matter what. I'm saying there shouldn't be a blanket rule forbidding everything no matter what.
Banning the use of a glitch on the grounds that it could potentially harm run entertainment - ignoring situations where it would not necessarily harm run entertainment, and could even enhance it - seems like a poor way to make a ruling.
The methods that TAS's use in various games to affect the frame rate are not relevant here. All that matters is that there are situations where a TAS would optimally use a different frame rate.
Your main counter-argument to my objection was precisely that, paraphrasing, "the run would simply lower the framerate only on the part that's necessary to trigger the glitch (running at a normal framerate otherwise)". In order for that to be a valid counter-argument, you would have to demonstrate that runs could do exactly that, without resorting to abusing the emulator itself, with input that doesn't go to the game, but to the emulator.
I would find that kind of run to be equally preposterous as, for example, that one Minecraft speedrunning category where the runner alt-tabs to Windows, launches the task manager, kills the game from there, and then re-launches it. That's so far removed from actually playing the game that it isn't even funny.
(In general, I detest at a principle level the idea of using external means to affect the game, rather than purely in-game input. If everything were allowed, nothing would stop someone from eg. alt-tabbing to Windows and hex-editing the savefile of the game. Or running a custom program that affects the game's behavior somehow, such as deliberately glitching it. Deliberately and actively lowering the speed of the computer (real or emulated) to a ridiculous extent in order to affect the game, falls fully into this same category.)
I'm not saying that there should be a blanket rule allowing everything no matter what. I'm saying there shouldn't be a blanket rule forbidding everything no matter what.
There are already blanket rules forbidding all kinds of things (such as cheat codes, and abusing emulator bugs). I don't see why it should be so problematic in this case.
TheProJamer wrote:
Banning the use of a glitch on the grounds that it could potentially harm run entertainment
I'm not advocating the banning of any glitch. I'm questioning the extents to which the game ought to be affected from the outside to change its behavior.
Joined: 8/28/2018
Posts: 75
Location: United States
Warp wrote:
I would find that kind of run to be equally preposterous as, for example, that one Minecraft speedrunning category where the runner alt-tabs to Windows, launches the task manager, kills the game from there, and then re-launches it. That's so far removed from actually playing the game that it isn't even funny.
You mean like pressing reset on the console to corrupt save data?
There are plenty of platforms outside of PC where interference outside the game's control results in gamebreaking glitches. Whether or not you personally find them to be "preposterous" is, again, irrelevant. That is for the community and ultimately the judges to decide.
Warp wrote:
There are already blanket rules forbidding all kinds of things (such as cheat codes, and abusing emulator bugs). I don't see why it should be so problematic in this case.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Warp wrote:
Deliberately and actively lowering the speed of the computer (real or emulated) to a ridiculous extent in order to affect the game, falls fully into this same category.
Where does ridiculous extent start exactly?
Doomsday31415 wrote:
Didn't know TAS times are also listed on that site of "the speedrunning community as a whole". I was under impression them and us are totally different communities with totally different rules and totally different reasons behind them. Are you arguing we're obliged to have 11 branches for SMW just because some other community embraces them? Also, how many rules does RTA community borrow from us in return?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I think this topic has some parallels with the decision on difficulty switches in #5928: MrWint's A2600 Barnstorming "no collisions" in 00:32.41. There's no way to reasonably argue that an FPS change is a form of input, but I still think there's an important ruling in here:
feos wrote:
And games are supposed to handle it the way they want.
The fact of the matter, especially with modern games, is that when something is to run on a wide spectrum of hardware, it needs to accommodate for that. When games don't do that because they were expected to run on a single refresh value, the implementation is faulty, or it wasn't future proofed for higher refresh rates, it becomes an inherent fault with the game; i.e., a glitch.
This is fundamentally different from other extra-game modifications because the game is obligated to read and interpret the properties of a monitor or graphics card simply as a part of being graphical software. That's just what it does. If it wants to display something, it absolutely needs to communicate with the display, directly or indirectly. That's the same way it is for input. If you want to exist on multiple platforms, you need to poll input in a way that works on the machine. Just like with video, this is generally done with drivers, but it's still something that needs to be done to even work as a game. On the other hand, accounting for hacked data is not a fundamental part of making a game. Yes, plenty of developers try to prevent this, it isn't required to make a game actually work. The argument that makes this analogy only really holds in a field of corn.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Alright, so let's recap.
Default framerate
For all games, default framerate configured from the replay environment or within the game itself should be 60, or default preset in the game.
If there are compelling reasons not to use 60 or default framerate, it can be set to other common values like 30, 50, 100, 120, and others.
Optional framerate
For games whose gameplay speed changes along with framerate, changing it from common default discussed above is not allowed.
For all other games, uncommon framerate is allowed to be set only if it enables some technique your movie relies on. Still try not to use unfairly high or low framerate: choose the value that works for you and still deviates from defaults the least.
For games that don't allow changing framerate during play, changing it from the replay environment during play is not allowed. Set it before playing.
Complaints, additions?
Also, how do we handle vsync and whatever fps it would use? I feel that vsync should be on by default, and environment should use the default framerate for it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 8/28/2018
Posts: 75
Location: United States
feos wrote:
Didn't know TAS times are also listed on that site of "the speedrunning community as a whole". I was under impression them and us are totally different communities with totally different rules and totally different reasons behind them.
Of course the TAS times aren't listed on an RTA site; if you want those, you come here. Could it help bring the TAS and RTA communities together if there was a single site that had sections for both? Perhaps, but there isn't one right now.
As far as different rules are concerned, most of those differences stem from necessity. For example, a TAS is far easier to make with an emulator, which is exactly why they are typically not allowed in RTA, yet preferred to make a TAS.
feos wrote:
Are you arguing we're obliged to have 11 branches for SMW just because some other community embraces them? Also, how many rules does RTA community borrow from us in return?
The speedrunning community is quite large, and while obviously there's no obligation for one site to consider what happens on another, it would be beneficial to everyone involved if there wasn't any unnecessary things driving the TAS subset of that community away from the RTA subset. This works both ways, of course. I am aware that there are a ton of people that see a TAS as nothing more than "cheating".
However, there are also a lot of people, speedrunners and their fans, who look to what TAS can do for inspiration and guidance. Many new tricks are found when making TAS's of games, and sometimes those tricks can be applied to RTA as well. When someone is looking to see just how far a particular category in a game can go, a TAS is the definitive answer if it exists.
And now we get to the main reason I think it would be wise for TASVideos to include more than they do today. When someone is searching for the TAS of a specific category, should they search on YouTube or TASVideos? Maybe they search on Google for it. If it's not on TASVideos but is on YouTube (because, for example, it was rejected or never submitted for not being optimal), that person will watch it on YouTube and never look at TASVideos.
Furthermore, let's imagine a scenario where the only TAS of a category is a non-optimal TAS that is on TASVideos, and the person looks at it and thinks "I can do better than that". That might encourage them to make their own, better TAS of it. Then maybe they'll do another TAS, and so on. It's much less daunting to improve a run with clear flaws than to make a TAS of a new game or a highly optimized game.
These are not just hypothetical scenarios. In fact, the latter was an autobiography, so it was pretty easy to come up with. I highly doubt I am the only person who got into TASing after seeing an outdated or lackluster TAS and wanting to improve it.
I understand that one of the core tenants of TASVideos is "we want our content to look impressive, entertaining, superhuman". I also understand that not every branch in the world is going to be entertaining or unique. But ceding TAS mindspace to YouTube and the like simply because a TAS uses some in-game code or because there are already similar TAS's on the site seems like a poor choice to grow the site and the TAS community.
Deliberately and actively lowering the speed of the computer (real or emulated) to a ridiculous extent in order to affect the game, falls fully into this same category.
Where does ridiculous extent start exactly?
Rather obviously it can't be a hard cut-off point, where framerate X fps is ok, but framerate X-1 fps is ridiculous.
I would say that, especially with 3D games, 20fps starts being a bit on the low end (although still acceptable; after all, IIRC, Ocarina of Time runs at that framerate), 10fps starts being very low, and 1fps is already well into the completely ridiculous area.
Are you arguing we're obliged to have 11 branches for SMW just because some other community embraces them?
This question wasn't for me, but I'm going to butt in anyway:
Obliged? No. But personally I actually wouldn't mind. If the RTA community doesn't mind, why should we? I have for long been of the opinion that we are too conservative when it comes to run categories for a given game. There's really no need. It's not like we are running out of some kind of quota. (In fact, some time ago I suggested a complete redesign of the site that would allow lots of categories for a game, just like speedrun.com does.)
A "blanket rule" does not mean "Holy Scripture, written in stone, forever immutable, no exceptions allowed nor discussed". It's a general rule of thumb (albeit a rather strong one) that usually holds for the vast majority of cases, and thus can quite safely be taken as the default ruling, but does not rule out the possibility of rare exceptions if there are very good reasons for them.
Such a rule needs to exist because being free to abuse in-game codes can easily make some games trivial, and tool-assisted speedrunning isn't about showcasing trivial walkthroughs that have no challenge.
(Personally I would also ban the exact same effects even if they are being achieved through glitching rather than by entering the actual code, the reasoning for this ban being exactly the same.)
Joined: 8/28/2018
Posts: 75
Location: United States
Warp wrote:
Doomsday31415 wrote:
Whether or not you personally find them to be "preposterous" is, again, irrelevant. That is for the community and ultimately the judges to decide.
You make it sound like I'm not part of the community.
Sorry, that wasn't my intention. You're free to like or dislike gamebreaking glitches or cheats as much as anyone else, voting and commenting accordingly on submissions, but your personal preference shouldn't be the basis for how the site handles the case in general. Of course, the same goes for me.
Warp wrote:
A "blanket rule" does not mean "Holy Scripture, written in stone, forever immutable, no exceptions allowed nor discussed".
Can you really look at the beginning of this thread and say that having a blanket rule did not interfere with discussion of the merits of the submission?
Regarding the rest of what you said, your two posts seem to contradict each other... after all, it was the RTA community that decided that using IGC was allowed in a separate category. Could you clarify?
