Official 2009 Rules Reworking Discussion [locked]

2009-06-16 07:49:46 am

imo, the save penalty shouldn't take effect unless there are more segments than there are level/map transitions.

For every save afterward, institute a progressively larger save penalty.

Example:
A game has 25 levels. After the 25th segment, add .5 seconds, 1 second, 1.5 seconds, and so on.

Lag.Com

2009-06-16 09:33:43 am

sda loyalist

Quote from ExplodingCabbage:

lag, there are some tricks whose odds are simply too low for this to be viable.

...then do a segmented run. You'll notice I didn't ban them?

ExplodingCabbage

2009-06-16 09:40:23 am

Quote from Carcinogen:

imo, the save penalty shouldn't take effect unless there are more segments than there are level/map transitions.

For every save afterward, institute a progressively larger save penalty.

Example:
A game has 25 levels. After the 25th segment, add .5 seconds, 1 second, 1.5 seconds, and so on.

This still has the (serious, IMO) flaw that dex pointed out that it's impossible to determine whether a decision at the start of the run to use an extra segment to pull off a trick saving, say, 8 seconds, is justified until you've reached the end of the run and found how many segments you needed for the rest of it.

65

2009-06-16 12:45:12 pm

3) If you really want to restrict segmenting, why not use something like "no more than five segments per minute"? Feel free to replace five with whatever number you feel is justified. Might be a bit arbitrary, but it circumvents the "penalty" issue, keeps micromanagement (or at least introduces a strategic element for using it) at bay and keeps the time closer to the real time while still having the option to segment often through the hard parts when necessary. It doesn't tie the runners' hands too much but it prevents ridiculous segment counts people seem to find to be the biggest issue.

If you think this still ties the runners' hands too much you could have a small penalty for each save more than the suggested amount, like 2 or so seconds.

__sdfg

2009-06-16 05:14:23 pm

D:

(3) I like the idea of segmenting only at each level break/autosave point. Yes, it's still somewhat arbitrary, but it seems like less of a random guess to me than imposing a half- or one- or two-second penalty for each quicksave. I can't think of any other way to restrict segmenting that better emphasizes the game's design, at least.

I also think there should be a separate category for segmenting as much as you want - if the game lets you do it, it's legitimate - but I don't expect creating even more categories to be a popular opinion. Given the choice, I'd rather see single-segment vs. restricted segmenting than single-segment vs. infinite segmenting.

Spider-Waffle

(user is banned)

Spider-Waffle

Edit history:

Spider-Waffle: 2009-06-17 03:26:32 am

2009-06-17 03:21:27 am

Don't think! feeeeeal

>>>Actually, I agree with Spider-Waffle on this (Shocked). I think that using one segment per level in games where the benefits of segmenting mid-level are very small is a good thing, and forcing runners to break up their segments to 'improve' their runs by not recognising that it's a good thing is a shame. I'll say this with one caveat, though - if a run already has SS, segmented and IL categories, don't allow a segmented-per-level category as well because that would be too similar to IL. (Indeed, for some games where levels don't affect each other, that's all that IL is). However where there exists no sensible IL category, it would be fairer on runners of such games to allow a one-segment-per-level category (and wouldn't create more categories than games that already have SS, segmented and IL anyway).

As an example, I was really strongly opposed to Groobo segmenting lab in his Quake II run because Quake games have a history of runs doing one segment per level and breaking from this tradition - especially to obsolete Q2DQ2, which was one segment per level - would have made the run feel invalid. He didn't segment, which IMO was the right call, but this should be reflected in SDA's categories.

Edit: Another example is the Call Of Duty 4 run on PC. It would've been totally retarded to use manual saves in that, since there's no tricks on show and as such the whole thing that makes the run good is the show of skill, which would've been destroyed by manual segmenting. Yet as the rules stand now, a heavily segmented run could (easily) beat it. Seeing as runners are already informally imposing these rules on themselves, I think SDA should either officially declare it a Bad Thing and reaffirm that runners should always use manual saves where possible if it allows a faster time, or make these informal rules official by way of a new category where applicable.<<<

Mike said he thought it was totally arbitrary. I really don't think that's the case. If it was an inane arbitrary category I wouldn't think it was a good idea either. When the game its self is broken up into segments already, as is the case with many such games, it only feels natural to have category where runners can compete with one segment per map/level. I think it's drastically different than SS and the current segmented categories. Just having SS or segmented clearly doesn't seem to be enough for many runners/communities. Many communities have already spoken about what they want by trying to enforce unsaid rules within themselves as to only allow one segment per map/level. I hate the idea that nothing is stopping someone from beating their segmented runs with lots of segmentation in one map/level, but people's own morals/ideals. What if someone comes along that doesn't find it amoral to beat their run, and thinks the whole community is simply stupid for not segmenting their runs further and developing a liking to one segment per map/level. If there's whole communities which adhere to this unspoken rule even though they don't have to, there must be something inherently good about it, and I feel that that is that game its self is segmented, and thus it's easy for a viewer to understand and appreciate that each segment within the game was done all at once by the runner.

Think if quake was part of SDA, myself or someone else could go beat all the magnificent displays of skills that are the in the quake runs through mass segmentation by the current SDA rules. I mean just think about this. This one segment per map/level rule has worked so well for the quake community. I think SDA should learn from its ancestor and take a page out of their book. It really just makes a lot of sense and doesn't seem arbitrary or unnecessary or troublesome.

About scripting now: I believe that scripting can add a lot to human displays of skills in speedruns, which most people have a hard time understanding. I also feel that scripting can also detract from human displays of skills in speedruns. I feel that the second belief most have an easy time understanding so I won't try to illustrate it.

To show that scripting has a lot to add to speedrunning in terms showing human displays of skill I'll use the game HL2, or its engine, source, as an example. The nature of speed jumping in this game is such that it's absolutely imperative that you jump as soon as possible after hitting the ground (this is also the case with many other games with speed jumping). If you jump .01 seconds after hitting the ground your speed jumping will be many TIMES slower than someone that can jump .001 seconds after hitting the ground. Now if the game makers themselves had designed this game with even slightest inkling to make it suitable for speedrunning they would have built in an auto-jump feature like quake, I believe the first fps to have a jump feature, did. (why all FPSes didn't follow suit with the fine example quake put forth, I'm not sure, but I blame valve, I also blame valve for all FPSes using terrible wasd controls instead of much superior esdf controls that quake had as default, effectively lowering the skill potential of most FPS gamers, but that's a separate rant). Very unfortunately for speedrunners and people that like to watch to watch speedruns, HL2 has no such feature and forces the gamers themselves to come up with the most effective way to jump as soon as they hit the ground. This was found by the HL2 speed running community and it was a simple AHK script. This simple script was a SAVIOR to the HL2 speedrunning community and to the millions of people who like to watch HL2 speedruns. Now there is also an infinite number of other ways a runner could achieve a similar effect with hardware, some more effective than others and effectiveness varying GREATLY. It seems obvious to me that it is vastly superior to have the savior to HL2 speedrunning be a simple script that everyone can use and use to the same effectiveness, than be it hardware such as mouse wheels or turbo controllers that EVERYONE CAN'T USE as these devices are not made freely available to everyone and a really good one would mostly likely require the runner to create it through his own means.

It seems pretty clear to me that for the sake of speedrunning how well your method of spamming the jump command is is a DETERRENT from speedrunning in the sense of showing entertainment and human skill for millions of viewers, and the actual gaming done by the runners themselves. Let’s say for example the simple AHK script was banned, now let's say the best HL2 speedrunner in the world then resorts to using his mouse wheel which lets him jump 10 times a second. A much less skilled speedrunner with his own custom made hardware would on certain parts be able to make speedruns which were many TIMES faster than the most skilled gamer. While the parts requiring actual skill would look much worse, the parts where he only needed reasonable skill and good hardware he'd be many TIMES faster. Now HL2 speedrunning would largely be a display of hardware rather than skill. I believe this illustrates how scripting can put the focus of speedrunning on human skill rather than something else.
I think out of game scripting such as AHK should be allowed as part of the separate scripting category but with restrictions. I feel it should only be allowed for turbo effects or something so simple you could NEVER tell the player had used a script for it, such as reassigning keys.

Now for games which include scripting built into them designed by the makers for the gamers to use to play their game, I really can’t see how you could ever argue that these in game scripts shouldn’t be allowed or were meant to be used ever. I think separating runs into using scripts and not using scripts works quite well and I really can’t see any problem with it. Everyone gets what they want. That’s not to say that in the interest of speedrunning being a display of human skill there shouldn’t be some sort of restrictions put on in-game scripts.

I think the restrictions should be as specific and as objective as possible while doing their intended job which is to allow scripts which can enhance speedrunning as a display of human skill and only boycott scripts which are strictly or unnecessarily detracting from speedrunning as a display of human skill. I think for starters there needs to be some sort of restriction on the amount of time a script takes to execute. You might also want a restriction on scripting as a replacement for aiming. It also might be necessary to have a committee which decides if a script has crossed the line in terms of strictly detracting from the speedrun as a display of human skill. And if a runner isn’t sure whether or not his script would be allowed he could run it by the committee first. It would probably also be helpful to include example scripts of as many different types as possible saying which are accepted and which aren't so runners can compare their scripts to the example scripts to see if they're accepted or not.

I noticed some people were in favor of turbo controllers in separate categories. Here’s my thread about that: http://speeddemosarchive.com/forum/index.php/topic,7571.60.html A lot of other people seemed to agree with my opinion on the matter. I think DRybes said it best in post at the top of page 5. I would offer to beat the X-men mutant apocalypse speedrun by a significant time if it would instate such a category. For me it just comes down to simple realization that gameplay is vastly superior on certain games with turbo abilities, like HL2 or x-men mutant apocalypse, and if the game makers were more keen on how to make their game better or more suitable for speedrunning they would have built in the turbo function.

>>>Actually, I agree with Spider-Waffle on this (Shocked). I think that using one segment per level in games where the benefits of segmenting mid-level are very small is a good thing, and forcing runners to break up their segments to 'improve' their runs by not recognising that it's a good thing is a shame. I'll say this with one caveat, though - if a run already has SS, segmented and IL categories, don't allow a segmented-per-level category as well because that would be too similar to IL. (Indeed, for some games where levels don't affect each other, that's all that IL is). However where there exists no sensible IL category, it would be fairer on runners of such games to allow a one-segment-per-level category (and wouldn't create more categories than games that already have SS, segmented and IL anyway).

As an example, I was really strongly opposed to Groobo segmenting lab in his Quake II run because Quake games have a history of runs doing one segment per level and breaking from this tradition - especially to obsolete Q2DQ2, which was one segment per level - would have made the run feel invalid. He didn't segment, which IMO was the right call, but this should be reflected in SDA's categories.

Edit: Another example is the Call Of Duty 4 run on PC. It would've been totally retarded to use manual saves in that, since there's no tricks on show and as such the whole thing that makes the run good is the show of skill, which would've been destroyed by manual segmenting. Yet as the rules stand now, a heavily segmented run could (easily) beat it. Seeing as runners are already informally imposing these rules on themselves, I think SDA should either officially declare it a Bad Thing and reaffirm that runners should always use manual saves where possible if it allows a faster time, or make these informal rules official by way of a new category where applicable.<<<

Mike said he thought it was totally arbitrary.  I really don't think that's the case.  If it was an inane arbitrary category I wouldn't think it was a good idea either.  When the game its self is broken up into segments already, as is the case with many such games, it only feels natural to have category where runners can compete with one segment per map/level.  I think it's drastically different than SS and the current segmented categories.  Just having SS or segmented clearly doesn't seem to be enough for many runners/communities.  Many communities have already spoken about what they want by trying to enforce unsaid rules within themselves as to only allow one segment per map/level.  I hate the idea that nothing is stopping someone from beating their segmented runs with lots of segmentation in one map/level, but people's own morals/ideals.  What if someone comes along that doesn't find it amoral to beat their run, and thinks the whole community is simply stupid for not segmenting their runs further and developing a liking to one segment per map/level.  If there's whole communities which adhere to this unspoken rule even though they don't have to, there must be something inherently good about it, and I feel that that is that game its self is segmented, and thus it's easy for a viewer to understand and appreciate that each segment within the game was done all at once by the runner.

Think if quake was part of SDA, myself or someone else could go beat all the magnificent displays of skills that are the in the quake runs through mass segmentation by the current SDA rules.  I mean just think about this.  This one segment per map/level rule has worked so well for the quake community.  I think SDA should learn from its ancestor and take a page out of their book.  It really just makes a lot of sense and doesn't seem arbitrary or unnecessary or troublesome.

About scripting now:  I believe that scripting can add a lot to human displays of skills in speedruns, which most people have a hard time understanding.  I also feel that scripting can also detract from human displays of skills in speedruns.  I feel that the second belief most have an easy time understanding so I won't try to illustrate it.

To show that scripting has a lot to add to speedrunning in terms showing human displays of skill I'll use the game HL2, or its engine, source, as an example.  The nature of speed jumping in this game is such that it's absolutely imperative that you jump as soon as possible after hitting the ground (this is also the case with many other games with speed jumping).  If you jump .01 seconds after hitting the ground your speed jumping will be many TIMES slower than someone that can jump .001 seconds after hitting the ground.  Now if the game makers themselves had designed this game with even slightest inkling to make it suitable for speedrunning they would have built in an auto-jump feature like quake, I believe the first fps to have a jump feature, did.  (why all FPSes didn't follow suit with the fine example quake put forth, I'm not sure, but I blame valve, I also blame valve for all FPSes using terrible wasd controls instead of much superior esdf controls that quake had as default, effectively lowering the skill potential of most FPS gamers, but that's a separate rant).  Very unfortunately for speedrunners and people that like to watch to watch speedruns, HL2 has no such feature and forces the gamers themselves to come up with the most effective way to jump as soon as they hit the ground.  This was found by the HL2 speed running community and it was a simple AHK script.  This simple script was a SAVIOR to the HL2 speedrunning community and to the millions of people who like to watch HL2 speedruns.  Now there is also an infinite number of other ways a runner could achieve a similar effect with hardware, some more effective than others and effectiveness varying GREATLY.  It seems obvious to me that it is vastly superior to have the savior to HL2 speedrunning be a simple script that everyone can use and use to the same effectiveness, than be it hardware such as mouse wheels or turbo controllers that EVERYONE CAN'T USE as these devices are not made freely available to everyone and a really good one would mostly likely require the runner to create it through his own means.

It seems pretty clear to me that for the sake of speedrunning how well your method of spamming the jump command is is a DETERRENT from speedrunning in the sense of showing entertainment and human skill for millions of viewers, and the actual gaming done by the runners themselves.  Let’s say for example the simple AHK script was banned, now let's say the best HL2 speedrunner in the world then resorts to using his mouse wheel which lets him jump 10 times a second.  A much less skilled speedrunner with his own custom made hardware would on certain parts be able to make speedruns which were many TIMES faster than the most skilled gamer.  While the parts requiring actual skill would look much worse, the parts where he only needed reasonable skill and good hardware he'd be many TIMES faster.  Now HL2 speedrunning would largely be a display of hardware rather than skill.  I believe this illustrates how scripting can put the focus of speedrunning on human skill rather than something else.
I think out of game scripting such as AHK should be allowed as part of the separate scripting category but with restrictions.  I feel it should only be allowed for turbo effects or something so simple you could NEVER tell the player had used a script for it, such as reassigning keys.

Now for games which include scripting built into them designed by the makers for the gamers to use to play their game, I really can’t see how you could ever argue that these in game scripts shouldn’t be allowed or were meant to be used ever.  I think separating runs into using scripts and not using scripts works quite well and I really can’t see any problem with it.  Everyone gets what they want.  That’s not to say that in the interest of speedrunning being a display of human skill there shouldn’t be some sort of restrictions put on in-game scripts.

I think the restrictions should be as specific and as objective as possible while doing their intended job which is to allow scripts which can enhance speedrunning as a display of human skill and only boycott scripts which are strictly or unnecessarily detracting from speedrunning as a display of human skill.  I think for starters there needs to be some sort of restriction on the amount of time a script takes to execute.  You might also want a restriction on scripting as a replacement for aiming.  It also might be necessary to have a committee which decides if a script has crossed the line in terms of strictly detracting from the speedrun as a display of human skill.  And if a runner isn’t sure whether or not his script would be allowed he could run it by the committee first.  It would probably also be helpful to include example scripts of as many different types as possible saying which are accepted and which aren't so runners can compare their scripts to the example scripts to see if they're accepted or not.

I noticed some people were in favor of turbo controllers in separate categories.  Here’s my thread about that:  http://speeddemosarchive.com/forum/index.php/topic,7571.60.html  A lot of other people seemed to agree with my opinion on the matter.  I think DRybes said it best in post at the top of page 5.  I would offer to beat the X-men mutant apocalypse speedrun by a significant time if it would instate such a category.  For me it just comes down to simple realization that gameplay is vastly superior on certain games with turbo abilities, like HL2 or x-men mutant apocalypse, and if the game makers were more keen on how to make their game better or more suitable for speedrunning they would have built in the turbo function.

ChewyChase

2009-06-17 04:34:45 am

Hmmm...

Just an idea, maybe divide the site's runs up if this is gonna happen, one half can be TAS with scripts, turbopads, hax whatever the heck you want and the other half can be the skill and real stuff that I personally enjoy more. I've always seen this place as the reliable source for REAL skilled speedruns and not scripted/etc.

that's obviously not happening though so my opinion is to stay current here and ban and obsolete all scripted and otherwise similar speedruns, because if this place is about authenticity and verification, then that's got to go. I understand the goal of obtaining the fastest possible, but at the same time with scripts the fastest possible has almost no meaning anyway.

the entertainment/skill debate is one in the same, as it's been said, it depends on what entertains you. But this shouldn't be about 'entertainment', that's what other places are/have been for. It's been runs by the players, the humans, and not their scripts. However, if it's going to be switched to a no holds barred state, then I think there should at least be jurisdiction between the 'pure' and the tool assisted ones, but you can still report the fastest times for each category... just add a column for TAS right next to the 'old rules' times, and if anyone was concerned about getting more runs then that can certainly happen with this setup. That, and with this, you don't need as much verification for TAS runs, so less additional work is created.

Just an idea, maybe divide the site's runs up if this is gonna happen, one half can be TAS with scripts, turbopads, hax whatever the heck you want and the other half can be the skill and real stuff that I personally enjoy more. I've always seen this place as the reliable source for REAL skilled speedruns and not scripted/etc.

that's obviously not happening though so my opinion is to stay current here and ban and obsolete all scripted and otherwise similar speedruns, because if this place is about authenticity and verification, then that's got to go. I understand the goal of obtaining the fastest possible, but at the same time with scripts the fastest possible has almost no meaning anyway.

the entertainment/skill debate is one in the same, as it's been said, it depends on what entertains you. But this shouldn't be about 'entertainment', that's what other places are/have been for. It's been runs by the players, the humans, and not their scripts. However, if it's going to be switched to a no holds barred state, then I think there should at least be jurisdiction between the 'pure' and the tool assisted ones, but you can still report the fastest times for each category... just add a column for TAS right next to the 'old rules' times, and if anyone was concerned about getting more runs then that can certainly happen with this setup. That, and with this, you don't need as much verification for TAS runs, so less additional work is created.

Beenman500

2009-06-17 08:30:03 am

Joke of all trades

maybe you could have a "low" segment and "high" segment count for each game, so if i do pokemon red in 3 segments, it is a seperate catogary to one done in 20 segments, deciding the breakpoints would be tricky though, so rather that deciding them, base it on a run that is alreasy done on that game, and if one doesn't exist then it is irrelevent.

eg.
someone submits a run done in 25 segments that is accepted

a run is also submited that is done in less than square root 25 (=5) is a seperate catogory...

so people who do lots of segments arn't punished, and those who feel it is too abusive of a game, can make there own run with less.

N.B.: 25 segment run is faster

Serris

2009-06-17 12:43:57 pm

How about remaking the idea of "single-segment" runs? The whole point of this category is greater challenge and a more impressive display of skill, so I see no reason to ban saving & quitting and save warping as long as it's done in a "single session" - which would also be an example of a more appropriate-sounding name for the "new" category. If anyone insists on keeping the current form of "single-segment" runs, just make "single session" yet another category.

Sorry if this was already addressed in here, I didn't really follow the thread.

arkarian

2009-06-17 12:53:35 pm

gamelogs.org

Quote from beenman500:

maybe you could have a "low" segment and "high" segment count for each game, so if i do pokemon red in 3 segments, it is a seperate catogary to one done in 20 segments

how about we quit making new categories? there's already too many.

ExplodingCabbage

2009-06-17 12:57:21 pm

Serris: I'm opposed to the idea of 'single session' runs, at least for the games that I know. Part of the challenge of Single Segment runs for many games is needing to execute all the tricks in one run. Allowing the runner to save before a hard trick and attempt it over and over till they succeed would trivialise them, and single session runs of such games would just be badly-executed segmented runs with some botched attempts of tricks thrown in.

There may be some games for which it is appropriate but I don't really see much if any value being added by introducing the category.

arkarian

2009-06-17 01:01:09 pm

gamelogs.org

sounds like he was just talking about being able to save warp in ss runs, not actually attempt tricks numerous times.

Serris

2009-06-17 01:33:48 pm

Quote from Arkarian:

sounds like he was just talking about being able to save warp in ss runs, not actually attempt tricks numerous times.

Yes. Sorry if my post was confusing.

ExplodingCabbage

Edit history:

ExplodingCabbage: 2009-06-17 02:50:52 pm

2009-06-17 02:43:49 pm

So you'll allow or disallow reloading saves in SS runs depending upon the purpose for which it is done? That sounds too arbitrary to me. Why should one be allowed and not the other?

I suppose a case can be made that if the load menu is entered immediately after saving, the run is still Single Segment in a way that a run that continues for a couple of seconds after saving (to attempt a trick) isn't, and by demanding that runners immediately enter the menu after saving an objective distinction can thus be made. I wouldn't be heavily opposed to some conditioned rule allowing such reloading in SS runs. That said, I suspect many would say it'd be too complicated or too arbitrary a rule. And I'm still not in favour of such a rule just because I see the lack of save warping as one of the features of a SS run and think it adds to them.

Manocheese

2009-06-17 02:47:09 pm

Yes, a cucco riding the ground.

Quote from Spider-Waffle:

About scripting now: I believe that scripting can add a lot to human displays of skills in speedruns, which most people have a hard time understanding. I also feel that scripting can also detract from human displays of skills in speedruns. I feel that the second belief most have an easy time understanding so I won't try to illustrate it.

To show that scripting has a lot to add to speedrunning in terms showing human displays of skill I'll use the game HL2, or its engine, source, as an example. The nature of speed jumping in this game is such that it's absolutely imperative that you jump as soon as possible after hitting the ground (this is also the case with many other games with speed jumping). If you jump .01 seconds after hitting the ground your speed jumping will be many TIMES slower than someone that can jump .001 seconds after hitting the ground. Now if the game makers themselves had designed this game with even slightest inkling to make it suitable for speedrunning they would have built in an auto-jump feature like quake, I believe the first fps to have a jump feature, did. (why all FPSes didn't follow suit with the fine example quake put forth, I'm not sure, but I blame valve, I also blame valve for all FPSes using terrible wasd controls instead of much superior esdf controls that quake had as default, effectively lowering the skill potential of most FPS gamers, but that's a separate rant). Very unfortunately for speedrunners and people that like to watch to watch speedruns, HL2 has no such feature and forces the gamers themselves to come up with the most effective way to jump as soon as they hit the ground. This was found by the HL2 speed running community and it was a simple AHK script. This simple script was a SAVIOR to the HL2 speedrunning community and to the millions of people who like to watch HL2 speedruns.

Let's suppose that Super Mario 64 is a PC game and one can write scripts for it. And let's say I'm trying to do a run, but I suck at the Bowser battles. They just kill my run almost every time, no matter how well I was doing before I got to Bowser. If I made a script to do the Bowser battles for me, I could get a cleaner, faster run because I wouldn't have to worry about Bowser screwing me up. This script would be my savior.

Now replace SM64 with HL2 and Bowser with "speed jumping" and you have your argument. Is a run that uses tools faster? Yes. Is it easier to make? Yes. Does it have a place on SDA? No. The people who are against scripts aren't saying that speed running is easy. It's hard, and part of what makes it hard is that a runner must take the bad with the good in a game and go fast anyway. If the difficulty of this jumping trick makes running harder, you just have to live with that. Like I said in your turbo controller topic, using tools to play any part of a game for you is what defines a TAS. Overcoming the difficulty of a game and still going fast is what defines a real speed run.

Quote from Spider-Waffle:

Now there is also an infinite number of other ways a runner could achieve a similar effect with hardware, some more effective than others and effectiveness varying GREATLY. It seems obvious to me that it is vastly superior to have the savior to HL2 speedrunning be a simple script that everyone can use and use to the same effectiveness, than be it hardware such as mouse wheels or turbo controllers that EVERYONE CAN'T USE as these devices are not made freely available to everyone and a really good one would mostly likely require the runner to create it through his own means.

It seems pretty clear to me that for the sake of speedrunning how well your method of spamming the jump command is is a DETERRENT from speedrunning in the sense of showing entertainment and human skill for millions of viewers, and the actual gaming done by the runners themselves. Let’s say for example the simple AHK script was banned, now let's say the best HL2 speedrunner in the world then resorts to using his mouse wheel which lets him jump 10 times a second. A much less skilled speedrunner with his own custom made hardware would on certain parts be able to make speedruns which were many TIMES faster than the most skilled gamer. While the parts requiring actual skill would look much worse, the parts where he only needed reasonable skill and good hardware he'd be many TIMES faster. Now HL2 speedrunning would largely be a display of hardware rather than skill. I believe this illustrates how scripting can put the focus of speedrunning on human skill rather than something else.

This is the risk every PC runner takes by choosing to run a game where not everyone has the exact same machine. Allowing tools to be used may alleviate the problem slightly, but as far as the quality and reputation of the site are concerned, it would be jumping out of the frying pan and into the fire.

Quote from ExplodingCabbage:

So you'll allow or disallow reloading saves in SS runs depending upon the purpose for which it is done? That sounds too arbitrary to me. Why should one be allowed and not the other?

I think he just gave save warping as an example of one reason you might save and quit during a "single-session" run.

[quote="Spider-Waffle"]About scripting now:  I believe that scripting can add a lot to human displays of skills in speedruns, which most people have a hard time understanding.  I also feel that scripting can also detract from human displays of skills in speedruns.  I feel that the second belief most have an easy time understanding so I won't try to illustrate it.

To show that scripting has a lot to add to speedrunning in terms showing human displays of skill I'll use the game HL2, or its engine, source, as an example.  The nature of speed jumping in this game is such that it's absolutely imperative that you jump as soon as possible after hitting the ground (this is also the case with many other games with speed jumping).  If you jump .01 seconds after hitting the ground your speed jumping will be many TIMES slower than someone that can jump .001 seconds after hitting the ground.  Now if the game makers themselves had designed this game with even slightest inkling to make it suitable for speedrunning they would have built in an auto-jump feature like quake, I believe the first fps to have a jump feature, did.  (why all FPSes didn't follow suit with the fine example quake put forth, I'm not sure, but I blame valve, I also blame valve for all FPSes using terrible wasd controls instead of much superior esdf controls that quake had as default, effectively lowering the skill potential of most FPS gamers, but that's a separate rant).  Very unfortunately for speedrunners and people that like to watch to watch speedruns, HL2 has no such feature and forces the gamers themselves to come up with the most effective way to jump as soon as they hit the ground.  This was found by the HL2 speed running community and it was a simple AHK script.  This simple script was a SAVIOR to the HL2 speedrunning community and to the millions of people who like to watch HL2 speedruns.[/quote]

Let's suppose that Super Mario 64 is a PC game and one can write scripts for it. And let's say I'm trying to do a run, but I suck at the Bowser battles. They just kill my run almost every time, no matter how well I was doing before I got to Bowser. If I made a script to do the Bowser battles for me, I could get a cleaner, faster run because I wouldn't have to worry about Bowser screwing me up. This script would be my savior.

Now replace SM64 with HL2 and Bowser with "speed jumping" and you have your argument. Is a run that uses tools faster? Yes. Is it easier to make? Yes. Does it have a place on SDA? No. The people who are against scripts aren't saying that speed running is easy. It's hard, and part of what makes it hard is that a runner must take the bad with the good in a game and go fast anyway. If the difficulty of this jumping trick makes running harder, you just have to live with that. Like I said in your turbo controller topic, using tools to play any part of a game for you is what defines a TAS. Overcoming the difficulty of a game and still going fast is what defines a real speed run.

[quote="Spider-Waffle"]Now there is also an infinite number of other ways a runner could achieve a similar effect with hardware, some more effective than others and effectiveness varying GREATLY.  It seems obvious to me that it is vastly superior to have the savior to HL2 speedrunning be a simple script that everyone can use and use to the same effectiveness, than be it hardware such as mouse wheels or turbo controllers that EVERYONE CAN'T USE as these devices are not made freely available to everyone and a really good one would mostly likely require the runner to create it through his own means.

It seems pretty clear to me that for the sake of speedrunning how well your method of spamming the jump command is is a DETERRENT from speedrunning in the sense of showing entertainment and human skill for millions of viewers, and the actual gaming done by the runners themselves.  Let’s say for example the simple AHK script was banned, now let's say the best HL2 speedrunner in the world then resorts to using his mouse wheel which lets him jump 10 times a second.  A much less skilled speedrunner with his own custom made hardware would on certain parts be able to make speedruns which were many TIMES faster than the most skilled gamer.  While the parts requiring actual skill would look much worse, the parts where he only needed reasonable skill and good hardware he'd be many TIMES faster.  Now HL2 speedrunning would largely be a display of hardware rather than skill.  I believe this illustrates how scripting can put the focus of speedrunning on human skill rather than something else.[/quote]

This is the risk every PC runner takes by choosing to run a game where not everyone has the exact same machine. Allowing tools to be used may alleviate the problem slightly, but as far as the quality and reputation of the site are concerned, it would be jumping out of the frying pan and into the fire.

[quote="ExplodingCabbage"]So you'll allow or disallow reloading saves in SS runs depending upon the purpose for which it is done? That sounds too arbitrary to me. Why should one be allowed and not the other?[/quote]

I think he just gave save warping as an example of one reason you might save and quit during a "single-session" run.

ExplodingCabbage

2009-06-17 03:10:31 pm

Quote from Manocheese:

I think he just gave save warping as an example of one reason you might save and quit during a "single-session" run.

No, he clarified immediately before my last post that he was referring specifically to save warping, or at least to tricks directly involving saving rather than using saves to reattempt a hard part of a run.

BTW, not in reply to you but your quoting Spider-Waffle's post reminded me - custom-made controllers shouldn't be allowed, nor should controllers with macro features, since these potentially allow external scripting and thus TASes.

Manocheese, I can appreciate your views on the issue of scripting for turbo effects. I really don't know whose side I'm on. On the one hand, I can see spamming the mousewheel as part of a run, and I think that when runners do crazy things like plugging in five USB mice and spinning the mousewheels with their feet to keep up constant input it adds something to the run. On the other hand, I can see why people like Spider-Waffle would argue that the very possibility that runners would have to resort to such things, and the fact that on PC they're possible and turbo-scripts aren't letting you do anything a human can't do, is a reason to just allow them. The fact that they can't be detected is also possibly a point in favour of allowing them.

Thus my view is just to allow them, and allow runners to choose to not use them and write in their comments 'I decided not to use turbo scripts for this run because I don't agree with them. If you're going to obsolete the run, please have the respect to do likewise, or if you are going to use turbo scripts make sure you obsolete the run by virtue of it being better in other ways, and not just because of the scripts. If you do obsolete the run just by using turbo scripts, SDA will probably still accept the run but you'll be a total douchbag.' This should be enough to allow both sides what they want without creating unfairness.

[quote="Manocheese"]I think he just gave save warping as an example of one reason you might save and quit during a "single-session" run.[/quote]

No, he clarified immediately before my last post that he was referring specifically to save warping, or at least to tricks directly involving saving rather than using saves to reattempt a hard part of a run.

BTW, not in reply to you but your quoting Spider-Waffle's post reminded me - custom-made controllers shouldn't be allowed, nor should controllers with macro features, since these potentially allow external scripting and thus TASes.

Manocheese, I can appreciate your views on the issue of scripting for turbo effects. I really don't know whose side I'm on. On the one hand, I can see spamming the mousewheel as part of a run, and I think that when runners do crazy things like plugging in five USB mice and spinning the mousewheels with their feet to keep up constant input it adds something to the run. On the other hand, I can see why people like Spider-Waffle would argue that the very possibility that runners would have to resort to such things, and the fact that on PC they're possible and turbo-scripts aren't letting you do anything a human can't do, is a reason to just allow them. The fact that they can't be detected is also possibly a point in favour of allowing them.

Thus my view is just to allow them, and allow runners to choose to not use them and write in their comments 'I decided not to use turbo scripts for this run because I don't agree with them. If you're going to obsolete the run, please have the respect to do likewise, or if you are going to use turbo scripts make sure you obsolete the run by virtue of it being better in other ways, and not just because of the scripts. If you do obsolete the run just by using turbo scripts, SDA will probably still accept the run but you'll be a total douchbag.' This should be enough to allow both sides what they want without creating unfairness.

Spider-Waffle

(user is banned)

2009-06-17 03:47:38 pm

Don't think! feeeeeal

>>>On the other hand, I can see why people like Spider-Waffle would argue that the very possibility that runners would have to resort to such things, and the fact that on PC they're possible and turbo-scripts aren't letting you do anything a human can't do, is a reason to just allow them. The fact that they can't be detected is also possibly a point in favour of allowing them.

Thus my view is just to allow them, and allow runners to choose to not use them and write in their comments 'I decided not to use turbo scripts for this run because I don't agree with them. If you're going to obsolete the run, please have the respect to do likewise, or if you are going to use turbo scripts make sure you obsolete the run by virtue of it being better in other ways, and not just because of the scripts. If you do obsolete the run just by using turbo scripts, SDA will probably still accept the run but you'll be a total douchbag.' This should be enough to allow both sides what they want without creating unfairness.<<<

Well the great thing is that scripted and non-scripted runs have separate categories, so you don't even have to worry about a scripted run beating your non-scripted run. Everyone gets what they want with this.

>>>On the other hand, I can see why people like Spider-Waffle would argue that the very possibility that runners would have to resort to such things, and the fact that on PC they're possible and turbo-scripts aren't letting you do anything a human can't do, is a reason to just allow them. The fact that they can't be detected is also possibly a point in favour of allowing them.

Thus my view is just to allow them, and allow runners to choose to not use them and write in their comments 'I decided not to use turbo scripts for this run because I don't agree with them. If you're going to obsolete the run, please have the respect to do likewise, or if you are going to use turbo scripts make sure you obsolete the run by virtue of it being better in other ways, and not just because of the scripts. If you do obsolete the run just by using turbo scripts, SDA will probably still accept the run but you'll be a total douchbag.' This should be enough to allow both sides what they want without creating unfairness.<<<

Well the great thing is that scripted and non-scripted runs have separate categories, so you don't even have to worry about a scripted run beating your non-scripted run.  Everyone gets what they want with this.

ExplodingCabbage

2009-06-17 03:53:09 pm

Quote from Spider-Waffle:

Well the great thing is that scripted and non-scripted runs have separate categories

I've never understood why this was. Surely prior to dex demonstrating the power of scripts for TASing, which happened like two days ago, there was never any major difference between the categories? A few silly things like your 180-turn scripts and bunnyhopping scripts don't consitute sufficient difference to justify another category, IMO. And if we're going to put restrictions on what scripting is allowed, any justification for having two categories will surely disappear.

Kabuto

2009-06-17 03:57:28 pm

My opinions:

1) Keep the existing runs that violate newer rules but mark them as such. Deciding whether a new run obsoletes an "illegal" old run should be up to the verifiers, the new run must not lack skill compared to the old run.

2) Remove references to Radix in the rules as that info might rather confuse new visitors ("who the heck is that?"). A history of rules, including change list and motivations might serve as a better substitute.

3) IMHO the penalty should be 1 second + whatever amount of time the game skips (MDK PC e.g. skips 0.5 to 1 seconds). According to FAQ the penalty applies when the player manually saves instead of when the player loads a save that was done manually, right?

Related, what about save+load dependent glitches? MDK PC again, loading a save will cause all timed bombs to explode instantly, letting runners skip an additional 2.5 seconds. While AFAIK this is permitted (and thus endorsed) by the current ruleset I don't really like this because people who know MDK will not realize what's going on when the bomb explodes almost instantly due to the invisible save+load.

4) + 5) + in response to Spider-Waffle: even permitting scripts to simplify things that aren't a sequence of different buttons is a difficult case. MDK again, it's possible to assign mouse movement to player movement. While moving a player with the mouse in a 1st person shooter is usually pointless, in the case of MDK it has the advantage of giving 2.5 times the speed possible with keys only. So why not use AHK to bind some keys to otherwise unused mouse axes to effectively gain 2.5 times the original speed with WASD, effectively making this already fast-paced game almost uncontrollable?

I like the idea of permitting save warping within a SS run as it avoids backtracking.

My opinions:

1) Keep the existing runs that violate newer rules but mark them as such. Deciding whether a new run obsoletes an "illegal" old run should be up to the verifiers, the new run must not lack skill compared to the old run.

2) Remove references to Radix in the rules as that info might rather confuse new visitors ("who the heck is that?"). A history of rules, including change list and motivations might serve as a better substitute.

3) IMHO the penalty should be 1 second + whatever amount of time the game skips (MDK PC e.g. skips 0.5 to 1 seconds). According to FAQ the penalty applies when the player manually saves instead of when the player loads a save that was done manually, right?

Related, what about save+load dependent glitches? MDK PC again, loading a save will cause all timed bombs to explode instantly, letting runners skip an additional 2.5 seconds. While AFAIK this is permitted (and thus endorsed) by the current ruleset I don't really like this because people who know MDK will not realize what's going on when the bomb explodes almost instantly due to the invisible save+load.

4) + 5) + in response to Spider-Waffle: even permitting scripts to simplify things that aren't a sequence of different buttons is a difficult case. MDK again, it's possible to assign mouse movement to player movement. While moving a player with the mouse in a 1st person shooter is usually pointless, in the case of MDK it has the advantage of giving 2.5 times the speed possible with keys only. So why not use AHK to bind some keys to otherwise unused mouse axes to effectively gain 2.5 times the original speed with WASD, effectively making this already fast-paced game almost uncontrollable?

I like the idea of permitting save warping within a SS run as it avoids backtracking.

Lag.Com

2009-06-17 04:01:14 pm

sda loyalist

Well, some of us always understood that a script can do what humans cannot, because, uh, we've watched TASs? Speedrunning should by limited by what is possible for a human to do. The issue about varying hardware is an almost entirely PC-related one. I'm not sure what solution I would give. I hate scripts, personally. They blur the line way too much.

The line must be drawn, HERE!

Serris

2009-06-17 04:13:02 pm

Sorry, it seems I made it even more confusing. It's really just about saving/quitting/reloading if it's faster to do so, that includes saving & quitting & reloading / saving & reloading / whatever (depending on the game's save system) after a failed attempt at something if it enables you to retry that part faster. There's no difference to current SS runs except that you're allowed to make full use of the save system - your failed attempts count against you (just make sure they do - by timing the run manually if reloading resets the in-game timer) and if you waste too much time the run will probably be rejected. It's not like you're not allowed to make mistakes in SS runs as it is. It's useless to go into any more detail - it needs to be dealt with on a case-by-base basis, just like many other things, and it's supposed to be like that. All but the most basic rules only get in the way of making more reasonable decisions. This is just about removing the bit of the rules that state "save & quit = segmented", or at least make another category that allows it.

Spider-Waffle

(user is banned)

2009-06-17 04:16:59 pm

Don't think! feeeeeal

>>>Let's suppose that Super Mario 64 is a PC game and one can write scripts for it. And let's say I'm trying to do a run, but I suck at the Bowser battles. They just kill my run almost every time, no matter how well I was doing before I got to Bowser. If I made a script to do the Bowser battles for me, I could get a cleaner, faster run because I wouldn't have to worry about Bowser screwing me up. This script would be my savior.

Now replace SM64 with HL2 and Bowser with "speed jumping" and you have your argument.<<<

Not at all, you see a turbo script is very different from a script which plays a section of a game for you and I highlighted these points in my arguments. I'll reiterate. For one scripts which play significant sections of games entirely for you should be banned by SDA rules as they are with quake since these scripts are strictly detracting from the display of human skill for the localized section of the speedrun for which they are used. Another reason is a turbo script can be emulated with greatly varying degrees of success with hardware which is accepted and legal. Another point I made is that if the game was designed with any inkling of speedrunning in mind there would already be a built in auto-jump feature and I'm sure you'll find that the vast majority of HL2 gamers would easily agree on this. Another point I made was that the turbo script COMPLETELY fixes a HUGE problem with HL2 speedrunning, that being speedruns being a display of hardware rather than human skill. Your script CREATES a problem, that being speedruns being a display of scripting rather than human skill.

Your argument falls short on all these points. I think your trying to cling to your preconceived ideology about scripting and it's keeping closed minded to how scripting can greatly benefit speedrunning as a display of human skill. This I believe is the problem with most people opposed to scripting. I appreciate their concerns of how scripting can detract from speedrunning as a display of human skill and do feel it is necessary to restrict scripting to prevent this.

>>>Let's suppose that Super Mario 64 is a PC game and one can write scripts for it. And let's say I'm trying to do a run, but I suck at the Bowser battles. They just kill my run almost every time, no matter how well I was doing before I got to Bowser. If I made a script to do the Bowser battles for me, I could get a cleaner, faster run because I wouldn't have to worry about Bowser screwing me up. This script would be my savior.

Now replace SM64 with HL2 and Bowser with "speed jumping" and you have your argument.<<<

Not at all, you see a turbo script is very different from a script which plays a section of a game for you and I highlighted these points in my arguments.  I'll reiterate.  For one scripts which play significant sections of games entirely for you should be banned by SDA rules as they are with quake since these scripts are strictly detracting from the display of human skill for the localized section of the speedrun for which they are used.  Another reason is a turbo script can be emulated with greatly varying degrees of success with hardware which is accepted and legal.  Another point I made is that if the game was designed with any inkling of speedrunning in mind there would already be a built in auto-jump feature and I'm sure you'll find that the vast majority of HL2 gamers would easily agree on this.  Another point I made was that the turbo script COMPLETELY fixes a HUGE problem with HL2 speedrunning, that being speedruns being a display of hardware rather than human skill.  Your script CREATES a problem, that being speedruns being a display of scripting rather than human skill.

Your argument falls short on all these points.  I think your trying to cling to your preconceived ideology about scripting and it's keeping closed minded to how scripting can greatly benefit speedrunning as a display of human skill.  This I believe is the problem with most people opposed to scripting.  I appreciate their concerns of how scripting can detract from speedrunning as a display of human skill and do feel it is necessary to restrict scripting to prevent this.

Spider-Waffle

(user is banned)

2009-06-17 04:31:44 pm

Don't think! feeeeeal

>>>4) + 5) + in response to Spider-Waffle: even permitting scripts to simplify things that aren't a sequence of different buttons is a difficult case. MDK again, it's possible to assign mouse movement to player movement. While moving a player with the mouse in a 1st person shooter is usually pointless, in the case of MDK it has the advantage of giving 2.5 times the speed possible with keys only. So why not use AHK to bind some keys to otherwise unused mouse axes to effectively gain 2.5 times the original speed with WASD, effectively making this already fast-paced game almost uncontrollable?<<<

Wouldn't this be noticeable though. I said allow 3rd party scripting in a separate category but only for turbo functions (as these can be done with hardware and serve a great benefit to speedrunning) and things which you could NEVER tell they did. The last mainly because I think it's counter productive to ban something which you will NEVER be able to detect, as this gives a great disadvantage to honest players which adhere to the rules, while STRICTLY rewarding dishonesty.

>>>4) + 5) + in response to Spider-Waffle: even permitting scripts to simplify things that aren't a sequence of different buttons is a difficult case. MDK again, it's possible to assign mouse movement to player movement. While moving a player with the mouse in a 1st person shooter is usually pointless, in the case of MDK it has the advantage of giving 2.5 times the speed possible with keys only. So why not use AHK to bind some keys to otherwise unused mouse axes to effectively gain 2.5 times the original speed with WASD, effectively making this already fast-paced game almost uncontrollable?<<<

Wouldn't this be noticeable though.  I said allow 3rd party scripting in a separate category but only for turbo functions (as these can be done with hardware and serve a great benefit to speedrunning) and things which you could NEVER tell they did.  The last mainly because I think it's counter productive to ban something which you will NEVER be able to detect, as this gives a great disadvantage to honest players which adhere to the rules, while STRICTLY rewarding dishonesty.

Manocheese

2009-06-17 05:48:59 pm

Yes, a cucco riding the ground.

Quote from Spider-Waffle:

For one scripts which play significant sections of games entirely for you should be banned by SDA rules as they are with quake since these scripts are strictly detracting from the display of human skill for the localized section of the speedrun for which they are used.

ANY script detracts from a display of human skill. The jump script you are talking about is far worse than the example I gave of a Bowser script because it takes care of a critical element of the game--movement--for you throughout the entire game. I really don't see how you think that doing that shows skill. Yes, some skill is required even with the script, but more skill is required without it.

Quote from Spider-Waffle:

Another point I made is that if the game was designed with any inkling of speedrunning in mind there would already be a built in auto-jump feature and I'm sure you'll find that the vast majority of HL2 gamers would easily agree on this. Another point I made was that the turbo script COMPLETELY fixes a HUGE problem with HL2 speedrunning, that being speedruns being a display of hardware rather than human skill. Your script CREATES a problem, that being speedruns being a display of scripting rather than human skill.

No game is perfect. If you want to speed run a game, you have to live with its flaws, in this case the lack of auto-jump. If your way to do that is to make a script to play part of the game for you, TASVideos is calling your name. SDA should not.

[quote="Spider-Waffle"]For one scripts which play significant sections of games entirely for you should be banned by SDA rules as they are with quake since these scripts are strictly detracting from the display of human skill for the localized section of the speedrun for which they are used.[/quote]

ANY script detracts from a display of human skill. The jump script you are talking about is far worse than the example I gave of a Bowser script because it takes care of a critical element of the game--movement--for you throughout the [i]entire[/i] game. I really don't see how you think that doing that shows skill. Yes, some skill is required even with the script, but more skill is required without it.

[quote="Spider-Waffle"]Another point I made is that if the game was designed with any inkling of speedrunning in mind there would already be a built in auto-jump feature and I'm sure you'll find that the vast majority of HL2 gamers would easily agree on this.  Another point I made was that the turbo script COMPLETELY fixes a HUGE problem with HL2 speedrunning, that being speedruns being a display of hardware rather than human skill.  Your script CREATES a problem, that being speedruns being a display of scripting rather than human skill.[/quote]

No game is perfect. If you want to speed run a game, you have to live with its flaws, in this case the lack of auto-jump. If your way to do that is to make a script to play part of the game for you, TASVideos is calling your name. SDA should not.

Smilge

2009-06-17 06:00:20 pm

Sorry to butt in, but this seems like an appropriate place to ask:

Are these new rules, specifically the segment penalty, going to be enforced retroactively? I'm working on a run right now, and if the segment penalty is bumped to 2 seconds or more, I would make fewer segments in my run than if it stays the same or is abolished.