Time for a new update of the SDA rules

ktwo

Edit history:

ktwo: 2016-04-09 12:32:03 pm

ktwo: 2016-04-01 01:54:21 pm

ktwo: 2016-03-29 10:52:48 am

ktwo: 2016-03-26 04:23:24 pm

2016-03-25 05:14:55 am

Maybe somewhat overdue, but attached to this post is a draft of an update of the SDA rules (the current rule set can be found on https://kb.speeddemosarchive.com/Rules). First of all, while quite a bit of text has been changed, there is nothing drastically new in there. It's mostly clarifications and taking into account rule discussions on the forum since the last update, which probably dates back quite a while.

Someone reading this might wonder if there is really a need to keep updating the rules instead of just adhering to the "game communities' rules". The answer is that there are some rules that are sda-specific and are not planned to be changed. For example not hosting runs done on unofficial emulators or runs that don't meet the site's audio and video quality requirements. Another important reason is that many of the submitted runs are for games with very small or no communities. A generic set of rules will obviously never cover every single game out there, but hopefully at least a significant portion of them. Assuming the majority of games can be covered by the generic rules, it's easier to focus on the exceptions when they occur.

Feel free to come with suggestions to the text (either by posting in this thread or pm:ing any of the admins directly).

Edit: The rules have been updated in the knowledge base (link above).

Thread title:

Maybe somewhat overdue, but attached to this post is a draft of an update of the SDA rules (the current rule set can be found on https://kb.speeddemosarchive.com/Rules). First of all, while quite a bit of text has been changed, there is nothing drastically new in there. It's mostly clarifications and taking into account rule discussions on the forum since the last update, which probably dates back quite a while.

Someone reading this might wonder if there is really a need to keep updating the rules instead of just adhering to the "game communities' rules". The answer is that there are some rules that are sda-specific and are not planned to be changed. For example not hosting runs done on unofficial emulators or runs that don't meet the site's audio and video quality requirements. Another important reason is that many of the submitted runs are for games with very small or no communities. A generic set of rules will obviously never cover every single game out there, but hopefully at least a significant portion of them. Assuming the majority of games can be covered by the generic rules, it's easier to focus on the exceptions when they occur.

Feel free to come with suggestions to the text (either by posting in this thread or pm:ing any of the admins directly).

Edit: The rules have been updated in the knowledge base (link above).

Ekelbatzen

2016-03-25 06:52:55 am

Looks good to me so far, the "ending point" section just seems a bit to contradict the current ending point for my Timeshift speedrun (that you also verified) and is still in the publishing process.

"When control is lost, even if that's long after the final battle" it says in the draft, but in my run the time currently stops when the boss is defeated. I can still move a little and shoot at nothing while waiting 30 seconds for the boss to explode and fall.
The RPG rule would apply here ("we use the frame the hit points of the final hit on the final boss shows up")
(kind of), but Timeshift is really not an RPG.

IsraeliRD

Edit history:

IsraeliRD: 2016-03-25 07:11:29 am

2016-03-25 07:09:34 am

Dragon Power Supreme

Some games, Timeshift for one, are treated as exceptions. I made it clear for ktwo when he wrote and indeed it's in the draft. You had to see every time he came up with something, I'd pop in a "but these games don't follow this and this", so he wrote what would work for a lot of games, and noted the rest are special cases.

Timeshift's timing falls to this special case rule where timing actually ends on boss defeat.

kwinse

Edit history:

kwinse: 2016-03-25 01:55:35 pm

2016-03-25 01:55:17 pm

Spotted a typo:

Quote from Draft:

Some games have timed minigames that can be competed in isolated from the rest of the game.

"isolated" -> "isolation"?

gammadragon

2016-03-26 03:20:36 am

Might be magic...

Looks great to me too. I have some minor suggestions and corrections in addition to those listed above. Apologies if any of these seem nitpicky, that wasn't the intention when I started. I've hidden them below so they don't take over the page.

Quote from Draft:

We have grouped the categories into three groups, ”segmentation”, ”completion percentage” and ”addtional category tags”.

addtional -> additional

Quote from Draft:

SDA accepts both speedruns done in a single sitting or in multiple segments, recorded over a longer time period.

I feel as though the word "both" could be removed from this sentence? Maybe change it to: "SDA accepts speedruns completed either in a single sitting, or in multiple segments recorded over a longer time period."

Quote from Draft:

Single segment with resets: You are allowed to save and resume in a single segment run as long as it is part of the same game session, this will add the with resets tag to your run.

It feels like the comma in this sentence should be replaced with a full stop (period).

Quote from Draft:

(for instance, no status affects or equipment carry over between levels)

affects -> effects

Quote from Draft:

If you wish to discuss the 100% defintion for a game that's not mentioned in that thread

defintion -> definition

Quote from Draft:

low%: Whereas the 100% category aims to complete a game as fully as possible, the goal of a low% run is the opposite of that: Beat the game using as few resources as possible.

Whereas -> "Where" or "While" ?

Quote from Draft:

Addtional category tags

Addtional -> Additional

Quote from Draft:

Multiplayer runs are considered as a separate category to single player runs. The more players you are, the more things can be done at the same time

"The more players you are" -> "The more players you have"

Quote from Draft:

For claritification, this is a cooperative category to beat the game, with its programmed puzzles and enemies, as quickly as possible

claritification -> clarification

Quote from Draft:

Runs with warps are essentially treated as runs with large-skps, described above.

large-skps -> large-skips

Quote from Draft:

Below follows the general outline for how timing is done on sda

sda -> SDA

Quote from Draft:

It's not possible to cover every imaginable situation though, so there are still be many games that will have to be treated as special cases

"so there are still be many games that will have to be treated as special cases" -> "so there will still be many games that must be treated as special cases"

Quote from Draft:

Having camera control (for example Half-Life), but no means of impacting the character's movement, is not considered gain of control for the purpose of sda-timing.

sda-timing -> SDA timing

Quote from Draft:

In that case, both types of runs can be hosted on the site side-by-side

runs -> run

Quote from Draft:

Once a speedruns has been published on SDA

speedruns -> speedrun

Looks great to me too. I have some minor suggestions and corrections in addition to those listed above. Apologies if any of these seem nitpicky, that wasn't the intention when I started. I've hidden them below so they don't take over the page.

[hidden="Suggestions"]

[quote="Draft"]We have grouped the categories into three groups, ”segmentation”, ”completion percentage” and ”addtional category tags”.[/quote]
addtional -> additional

[quote="Draft"]SDA accepts both speedruns done in a single sitting or in multiple segments, recorded over a longer time period.[/quote]
I feel as though the word "both" could be removed from this sentence? Maybe change it to: "SDA accepts speedruns completed either in a single sitting, or in multiple segments recorded over a longer time period."

[quote="Draft"]Single segment with resets: You are allowed to save and resume in a single segment run as long as it is part of the same game session, this will add the with resets tag to your run.[/quote]
It feels like the comma in this sentence should be replaced with a full stop (period).

[quote="Draft"](for instance, no status affects or equipment carry over between levels)[/quote]
affects -> effects

[quote="Draft"]If you wish to discuss the 100% defintion for a game that's not mentioned in that thread[/quote]
defintion -> definition

[quote="Draft"]low%: Whereas the 100% category aims to complete a game as fully as possible, the goal of a low% run is the opposite of that: Beat the game using as few resources as possible.[/quote]
Whereas -> "Where" or "While" ?

[quote="Draft"]Addtional category tags[/quote]
Addtional -> Additional

[quote="Draft"]Multiplayer runs are considered as a separate category to single player runs. The more players you are, the more things can be done at the same time[/quote]
"The more players you are" -> "The more players you have"

[quote="Draft"]For claritification, this is a cooperative category to beat the game, with its programmed puzzles and enemies, as quickly as possible[/quote]
claritification -> clarification

[quote="Draft"]Runs with warps are essentially treated as runs with large-skps, described above.[/quote]
large-skps -> large-skips

[quote="Draft"]Below follows the general outline for how timing is done on sda[/quote]
sda -> SDA

[quote="Draft"]It's not possible to cover every imaginable situation though, so there are still be many games that will have to be treated as special cases[/quote]
"so there are still be many games that will have to be treated as special cases" -> "so there will still be many games that must be treated as special cases"

[quote="Draft"]Having camera control (for example Half-Life), but no means of impacting the character's movement, is not considered gain of control for the purpose of sda-timing.[/quote]
sda-timing -> SDA timing

[quote="Draft"]In that case, both types of runs can be hosted on the site side-by-side[/quote]
runs -> run

[quote="Draft"]Once a speedruns has been published on SDA[/quote]
speedruns -> speedrun

[/hidden]

LotBlind

2016-03-26 08:07:29 am

"Rules are necessary to ensure fair and equal competition among players" and also to have defaults that simplify things.

When I click on the FAQ link it tells me it's opening a "application/octet-stream (77 bytes)".

I recently asked about monitoring RAM values as you play... should it be mentioned that's also no-go under "game modification" or something? Emphasize it's during the runs you can't do it, but outside of them do whatever you need.

ktwo

2016-03-26 04:22:09 pm

I admit that the draft in the first post hadn't gone through a spell or grammar check, so thanks for pointing out the typos. I have corrected those in the attached file plus a few more.

I think the timing has always been a bit of a black box here, so for me it was important to at least try to describe the "spirit" of the timing methods being used (more than just "SDA-timing is based on character control"). I'm not familiar with why there has been made an exception for Timeshift. If there is some underlying logic that's not reflected in the current text, then it's no problem to change. But if it's just a random exception, then it should be covered by the general disclaimer at the start of the timing section.

LotBlind, I changed the "game modification" rule into "interacting with the game" to cover both passive (like RAM-watch) and active (like the crooked cartridge trick) methods. Let me know what you think.

Crow!

Edit history:

Crow!: 2016-03-28 09:46:23 am

2016-03-28 09:46:00 am

What's that gemma?

"Right here in the SDA knowledge base" seems like it's supposed to be a link.

Some commas and articles would help this sentence:
"... or the possibility to use for example keyboard as input device." -> "... or the possibility to use, for example, a keyboard as an input device."

This list:
"...such as the Game Boy Player for Game Cube, Virtual Console, or GameTap"
is weird. I'd use "and" instead of "or", I'd use the definite article "the" for each element on the list, and I'd specify the context for each element rather than only for the GBP. So, something like:
- "... the Game Boy Player for the Game Cube, the Virtual Console for Nintendo games, and the GameTap for [insert what runs the gametap, I've never heard of it]."

In the DosBox section, I'd add "for playing and recording those games". "on a modern system" might not even be required.

I'm not a fan of the policy outlined in the flash carts section. I think allowing them is inconsistent with the philosophy behind the rest of the SDA rules.

The "Interacting with the game" section is organized in an unnecessarily complicated way. Things could be made more consistent like this:
- "This rule covers both passive methods (such as RAM-watch) and active methods (such as removing or altering a game disc/cartridge/file while the game is running.)"

I don't understand what "- Game mods (defined as requiring the original game in order to play)" means.

The "adult content" bit seems to run counter to the ruling on Leisure Suit Larry: Love for Sail, but whatever. Maybe add the word "excessive" or something?

This rule:

Quote:

Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before.

seems like a bad idea. It is very common for things that seem irrelevant to actually speed up or slow down a run, or for something that seems beneficial or detrimental to actually be the opposite. Besides, it makes the run no longer a single, complete run.

In the any% definition, the word "Beating" should not be capitalized.

In the low% definition, I'd replace "will obsolete" with "can obsolete". There was recently a game in the Metroid Prime series (I forget which one) that had a low% run rejected even though it had a lower % than the incumbent because the run wasn't up to SDA's standards, and it created some drama because the rules seemed to suggest that the runner should have gotten accepted automatically.

I think the sentence "For clarification, this is a cooperative category to beat the game, with its programmed puzzles and enemies, as quickly as possible." adds more confusion rather than more clarification. I'd just remove it altogether.

There should be colons after the "Starting Point" and "Ending Point" titles.

The first two sentences regarding IGT vs RT here:
"For some speedruns, the route and strategies depend on whether the in-game timer or real-time is used. In that case, both types of run can be hosted on the site side-by-side."
are quite clear and can stand alone. The rest of the bullet point is confusing and unnecessary.

I'd add a comma here: The obsoleted run will still be available on archive.org, though.

Hope this helps,
Crow!

"Right here in the SDA knowledge base" seems like it's supposed to be a link.

Some commas and articles would help this sentence:
"... or the possibility to use for example keyboard as input device." -> "... or the possibility to use, for example, a keyboard as an input device."

This list:
"...such as the Game Boy Player for Game Cube, Virtual Console, or GameTap"
is weird.  I'd use "and" instead of "or", I'd use the definite article "the" for each element on the list, and I'd specify the context for each element rather than only for the GBP.  So, something like:
-  "... the Game Boy Player for the Game Cube, the Virtual Console for Nintendo games, and the GameTap for [insert what runs the gametap, I've never heard of it]."

In the DosBox section, I'd add "for playing [b]and recording[/b] those games".  "on a modern system" might not even be required.

I'm not a fan of the policy outlined in the flash carts section.  I think allowing them is inconsistent with the philosophy behind the rest of the SDA rules.

The "Interacting with the game" section is organized in an unnecessarily complicated way.  Things could be made more consistent like this:
- "This rule covers both passive methods (such as RAM-watch) and active methods (such as removing or altering a game disc/cartridge/file while the game is running.)"

I don't understand what "- Game mods (defined as requiring the original game in order to play)" means.

The "adult content" bit seems to run counter to the ruling on Leisure Suit Larry: Love for Sail, but whatever.  Maybe add the word "excessive" or something?

This rule:
[quote]Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before.[/quote]seems like a bad idea.  It is very common for things that seem irrelevant to actually speed up or slow down a run, or for something that seems beneficial or detrimental to actually be the opposite.  Besides, it makes the run no longer a single, complete run.

In the any% definition, the word "Beating" should not be capitalized.

In the low% definition, I'd replace "will obsolete" with "can obsolete".  There was recently a game in the Metroid Prime series (I forget which one) that had a low% run rejected even though it had a lower % than the incumbent because the run wasn't up to SDA's standards, and it created some drama because the rules seemed to suggest that the runner should have gotten accepted automatically.

I think the sentence "For clarification, this is a cooperative category to beat the game, with its programmed puzzles and enemies, as quickly as possible." adds more confusion rather than more clarification.  I'd just remove it altogether.

There should be colons after the "Starting Point" and "Ending Point" titles.

The first two sentences regarding IGT vs RT here:
"For some speedruns, the route and strategies depend on whether the in-game timer or real-time is used. In that case, both types of run can be hosted on the site side-by-side."
are quite clear and can stand alone.  The rest of the bullet point is confusing and unnecessary.

I'd add a comma here: The obsoleted run will still be available on archive.org[b],[/b] though.

Hope this helps,
Crow!

TheMG2

2016-03-28 09:58:35 am

Quote:

In the low% definition, I'd replace "will obsolete" with "can obsolete". There was recently a game in the Metroid Prime series (I forget which one) that had a low% run rejected even though it had a lower % than the incumbent because the run wasn't up to SDA's standards, and it created some drama because the rules seemed to suggest that the runner should have gotten accepted automatically.

It was metroid prime 1 and I was there. There wasn't really any drama. That runner was fine with the rejection. The run has since been beaten by multiple hours.

The only "drama" I remember was that someone that does not run mp1 low% said that mp1 true low% was too difficult to get up to standards and that people should stick to old low% for submissions. They were then corrected that the true low% just needed time and effort put into it, and improvements would come (and they have by quite a significant margin).

Though I think it should be written to say "Will obsolete assuming it meets other SDA standards." or something.

[quote]
In the low% definition, I'd replace "will obsolete" with "can obsolete".  There was recently a game in the Metroid Prime series (I forget which one) that had a low% run rejected even though it had a lower % than the incumbent because the run wasn't up to SDA's standards, and it created some drama because the rules seemed to suggest that the runner should have gotten accepted automatically.
[/quote]

It was metroid prime 1 and I was there. There wasn't really any drama. That runner was fine with the rejection. The run has since been beaten by multiple hours.

The only "drama" I remember was that someone that does not run mp1 low% said that mp1 true low% was too difficult to get up to standards and that people should stick to old low% for submissions. They were then corrected that the true low% just needed time and effort put into it, and improvements would come (and they have by quite a significant margin).

Though I think it should be written to say "Will obsolete assuming it meets other SDA standards." or something.

puwexil

Edit history:

puwexil: 2016-03-28 12:52:01 pm

2016-03-28 12:45:56 pm

Professional Second Banana

Quote from Crow!:

I'm not a fan of the policy outlined in the flash carts section. I think allowing them is inconsistent with the philosophy behind the rest of the SDA rules.

The problem I see with banning flash cart runs in the rules is that it's unenforceable - in probably 99% of cases the end product is completely indistinguishable from an original cart (assuming the runner doesn't record the ROM selection menus and doesn't use savestates or some other special feature that wouldn't be allowed by site rules anyway). As long as there's no evidence that flash carts aren't accurate enough or offer some unfair advantage (unlike PC-based console emulators, which have way too much potential for both of those issues to ever belong on SDA), I think we should just allow them similarly to DOSbox being allowed for older PC games.

presjpolk

2016-03-28 04:47:47 pm

HELLO!

Puwexil's right with respect to most flash carts, I'd say. In a few cases they aren't accurate but it'll stick out in verification when they're not.

For platforms like FDS, where the actual disks are themselves dying, allowing FDSStick is rather important.

mike89

Edit history:

mike89: 2016-03-28 07:25:14 pm

2016-03-28 07:24:41 pm

SEGA Junkie

Quote from Crow!:

This rule:

Quote:

Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before.

seems like a bad idea. It is very common for things that seem irrelevant to actually speed up or slow down a run, or for something that seems beneficial or detrimental to actually be the opposite. Besides, it makes the run no longer a single, complete run.

I'm not exactly a great fan of this rule myself, but it's worth noting that it's been in the rules for as long as SDA has been around. (Or at least in response to some run that had redone segments? Not entirely sure.)

Crow!

Edit history:

Crow!: 2016-03-28 09:39:33 pm

2016-03-28 09:39:09 pm

What's that gemma?

Is the "redo middle segments even if it makes the run inconsistent" rule being utilized on any runs currently hosted on the site? If so, I guess it might be hard to remove, but if not, this is as good a time as any to get rid of it.

gyre

2016-03-28 11:27:34 pm

Flash carts aren't really accurate enough. They almost universally implement SRAM access too quickly and emulate support chips just accurately enough to make the game playable. It's a fairly subtle effect. Fewer lag frames interspersed everywhere - although you can sometimes spot it with RPGs when saving. More dramatic effects can happen when intentionally stressing the cart like with early Tourian entry in Super Metroid due to the faster memory timings. Simple games without lag (e.g., Super Mario Bros) don't have a problem and generally compare well with emulator timings too.

I don't really know how to stop it if people submit without disclosing they used a flash cart. If someone wants to cheat, they can cheat better than any verifier is going to be able to detect if they're smart about it. The rules are more for people who aren't trying to be deceptive.

ktwo

2016-03-29 10:52:02 am

A new version attached. It's based on the feedback since the last version, so no major changes.

It's possible that some of the links in the pdf don't work, but I'll make sure they'll be checked once copied over to the knowledge base.

Crow!, thanks a lot for all the comments. Here are replies to what has not changed in the new version:

* The three examples of official emulators are easily found through google. I therefore thought it was better to remove the mention of the GameCube rather than trying to describe the other ones.

* I'm far from an advocate of flashcarts, but like Puwexil said, many times it will be indistinguishable if one has been used (and I'm even aware of one recent case that has passed all the quality checks and gotten the green light). I think the way it's phrased right now ("if any differences would be discovered in the future, applicable runs can be expected to be removed from the site") sends a signal that it's not something that is encouraged, but still acceptable, assuming it behaves "identical" to a real cart.

* Regarding game mods, this is an example of what that description referred to: https://forum.speeddemosarchive.com/post/penumbra_necrologue__june_11_2015.html
I'm going to immediately say that I haven't really looked at this situation other than very superficially so it's probably my fault if the wording is contradicting what was stated in that thread.

* I'm not sure what your actual argument against segmentation discontinuities is. Is it because it's visually unappealing or because of legitimacy concerns of the end product? One specific issue I can think of could be the possible altering of rng. So first you record a segment until you get a favorable seed for the next segment. At a later stage, you go back and optimize the segment, but without having to worry about the rng seed for the upcoming segments. However, that is already covered in the wording, by saying that you're not allowed to get any benefits later in the game from the discontinuity. It would admittedly require pretty good game knowledge for someone else to point out if it's the case though. I guess it could be added that this has to be used with extreme caution on segments within levels because of the risk of manipulating the rng?

Just to put all the cards on the table and avoid a situation where it might look like I have been trying to hide something, I should mention that I have recently submitted a run that contains several segmentation discontinuities of this kind (but I'm sure that they had no impact on how the run played out)...

Quote from gyre:

If someone wants to cheat, they can cheat better than any verifier is going to be able to detect if they're smart about it. The rules are more for people who aren't trying to be deceptive.

Completely agree.

A new version attached. It's based on the feedback since the last version, so no major changes.

It's possible that some of the links in the pdf don't work, but I'll make sure they'll be checked once copied over to the knowledge base.

Crow!, thanks a lot for all the comments. Here are replies to what has not changed in the new version:

* The three examples of official emulators are easily found through google. I therefore thought it was better to remove the mention of the GameCube rather than trying to describe the other ones.

* I'm far from an advocate of flashcarts, but like Puwexil said, many times it will be indistinguishable if one has been used (and I'm even aware of one recent case that has passed all the quality checks and gotten the green light). I think the way it's phrased right now ("if any differences would be discovered in the future, applicable runs can be expected to be removed from the site") sends a signal that it's not something that is encouraged, but still acceptable, assuming it behaves "identical" to a real cart.

* Regarding game mods, this is an example of what that description referred to: https://forum.speeddemosarchive.com/post/penumbra_necrologue__june_11_2015.html
I'm going to immediately say that I haven't really looked at this situation other than very superficially so it's probably my fault if the wording is contradicting what was stated in that thread.

* I'm not sure what your actual argument against segmentation discontinuities is. Is it because it's visually unappealing or because of legitimacy concerns of the end product? One specific issue I can think of could be the possible altering of rng. So first you record a segment until you get a favorable seed for the next segment. At a later stage, you go back and optimize the segment, but without having to worry about the rng seed for the upcoming segments. However, that is already covered in the wording, by saying that you're not allowed to get any benefits later in the game from the discontinuity. It would admittedly require pretty good game knowledge for someone else to point out if it's the case though. I guess it could be added that this has to be used with extreme caution on segments within levels because of the risk of manipulating the rng?

Just to put all the cards on the table and avoid a situation where it might look like I have been trying to hide something, I should mention that I have recently submitted a run that contains several segmentation discontinuities of this kind (but I'm sure that they had no impact on how the run played out)...

[quote="gyre"] If someone wants to cheat, they can cheat better than any verifier is going to be able to detect if they're smart about it.  The rules are more for people who aren't trying to be deceptive.[/quote]
Completely agree.

Attachment:

SDA rules update - draft_v1.2.pdf

puwexil

2016-03-29 11:38:21 am

Professional Second Banana

For the section on death abuse, I'd recommend replacing the words "commit suicide" with "die intentionally" or something similar - it's a more accurate description of what is being done (death abuse in many cases is done by allowing enemies or stage hazards to kill the character), and I could see the word "suicide" being offensive to certain people.

For the multiplayer section, I'd clarify that any runs that use a multiplayer option within the game will be classified as a multiplayer run, even if the same runner is controlling all of the inputs (ie 1p2c runs).

For the warps section, I think it wouldn't hurt to define what warps mean for us (ie developer-intended shortcuts that allow significant portions of the game to be skipped, like Warp Zones in Super Mario Bros.). Alternatively, we could just merge warps in with the section on 'large-skips', since they're effectively the same for categorization purposes, and we normally like to avoid getting into developer intent.

LotBlind

2016-03-30 08:56:01 am

Quote from Crow!:

This rule:

Quote:

Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before.

seems like a bad idea. It is very common for things that seem irrelevant to actually speed up or slow down a run, or for something that seems beneficial or detrimental to actually be the opposite.

Besides, it makes the run no longer a single, complete run.

I think what you're mostly thinking of is RNG manipulation isn't it, not cheating per se? The runner may have inadvertently enabled some combination of drops (as per some Zelda games) that cannot be obtained in a single-segment run.

However, if you remove the rule, you're automatically lowering the factual quality of segmented runs if the only way to improve a middle segment is to land on exactly the same ammunition or such - with some games this is a reasonable requirement to have, but with others not really. And with something like a shooter (genre I'm more familiar with), we can easily establish whether or not the discrepancies were significant.

In toto, the rule might sometimes be too permissive, sometimes spot-on. Maybe it should be revised to emphasize needing to be sure or being able to prove that you're not changing the "timeline" with your inserted segments (include notes about it?), and you should keep your old segments safe just in case.

As for which games currently have this - again I point at certain (probably multiple) FPS runs I remember seeing, maybe Unreal, Jedi Outcast... Which games do you think the rule might not fit well out of existing or potential ones?

"Not an intact, whole run" - Yeah, but this is simply too anal for the runners, and the alternative is worse runs.

[quote="Crow!"]This rule:

[quote]Note however that it's allowed for an SDA-submission to have discrepancies between two segments as long as none of it is to your advantage. This gives you the possibility to later redo segments that are in the middle of the run even in games where it's virtually impossible to end a segment with the exact same stats as before.[/quote]seems like a bad idea.  It is very common for things that seem irrelevant to actually speed up or slow down a run, or for something that seems beneficial or detrimental to actually be the opposite.

Besides, it makes the run no longer a single, complete run.
[/quote]

I think what you're mostly thinking of is RNG manipulation isn't it, not cheating per se? The runner may have inadvertently enabled some combination of drops (as per some Zelda games) that cannot be obtained in a single-segment run.

However, if you remove the rule, you're automatically lowering the factual quality of segmented runs if the only way to improve a middle segment is to land on exactly the same ammunition or such - with some games this is a reasonable requirement to have, but with others not really. And with something like a shooter (genre I'm more familiar with), we can easily establish whether or not the discrepancies were significant.

In toto, the rule might sometimes be too permissive, sometimes spot-on. Maybe it should be revised to emphasize needing to be sure or being able to prove that you're not changing the "timeline" with your inserted segments (include notes about it?), and you should keep your old segments safe just in case.

As for which games currently have this - again I point at certain (probably multiple) FPS runs I remember seeing, maybe Unreal, Jedi Outcast... Which games do you think the rule might not fit well out of existing or potential ones?

"Not an intact, whole run" - Yeah, but this is simply too anal for the runners, and the alternative is worse runs.

Crow!

2016-03-30 09:36:52 am

What's that gemma?

My speedrunning interest is largely with old RPGs, where the point of segmenting is often to manipulate the RNG, and even something as simple as changing the data in OTHER save files can change the way the RNG gets seeded. Redoing a segment in the middle of a run like that with ANY inconsistency is almost never going to result in a complete run that could ever be replicated in the proper order.

I suppose that in games where "segmented" runs are effectively just individual level tables strung together, the rule makes sense. But as soon as I noticed that ammo or money or experience or whatever stop lining up properly from segment to segment, I for one would stop taking a run I was watching seriously.

sebastian

Edit history:

sebastian: 2016-03-31 09:19:38 pm

2016-03-31 09:18:21 pm

I would suggest allowing officially approved emulators, even if they are not official.
One example is this for megaman games: http://store.steampowered.com/app/363440/
In some such emulators, there are cheat options enableable in the menu (god mode and such). If the emulator contains such a option, the runner should be required to show that such options are turned off. If theres options in the menu to bind keys to like turbo or such "cheaty", same should be done here, shown that its unbound or bound to a unavailable key (in case its not possible to unbind it).
Same prerequistes as flashcarts, eg only if the run is "indistinguishable" from a native run.

About saving/loading:
I don't know if its still that saves add 0,5 seconds to the time in the draft because that is not mentioned.

But if its still 0,5 seconds per save, then I would suggest instead changing so loads adds 0,5 seconds to the time, regardless of if the load happens automatically because player fails a critical mission (for example losing a object required to progress) and the game senses that its not possible to finish the game in this state, dies, or if the player actually does a manual load.

The advantage of making so loads count 0,5 seconds instead of saves count 0,5 seconds, is that you don't need to differentiate between autosaves/checkpoints and manual saves/quicksaves. Then any use of a save would count against the runner.
The second reason, is that its not always visible if the user is saving, and also its normally not visible if its a autosave or a manual save, but its guranteed to be visible if player is loading. I think a runner shouldn't need to explain every autosave checkpoint, especially in longer games where there can be quite a few.

About DOSBox, I think that a exception to requiring "Settings from official DOSBox bundles of the games" should be made if the "official settings" are not available freely, and would require a repurchase of the game to obtain. Then I think the nearest "freely avaiable settings that are fair" should be allowed.

About bundled controllers:
Here I think its unneccessary strict. I think it should be permitted to use all features available on all official controllers, even if the controllers were made available later on as a purchaseable addon. With official controller, it should strictly count the following:
-All bundled controllers that was released with a new original console, regardless of manufacturer.
-All controllers made by the same manufacturer(s) as the original console system or any of its bundled controllers.

About Virtualization:
Why forbid Wine? I think its better to allow Wine, but ONLY if it does play enough similiar to not affect comparisation (like with Flashcarts) and does not allow unfair advantage.
Generally, this means only games with a "green" status on Wine's official page, but sometimes even yellow/red games can run fine in singleplayer mode, where the red/yellow status is because of a nonfunctioning MP mode (all information is normally given on Wine's page whats exactly is affected).

The reason is that I think that people that does not have the money to buy licenses for Windows, should be allowed to Wine instead. Using a hardware virtualization still requires a original license for the original operating system.
(And in some cases, actually, licenses does not even activate on virtualized enviroments, so wine is actually the only option if you cannot obtain native hardware to the OS in question. This will be the case with for example XP, where Microsoft will be shutting down activation of XP in late 2018-2020 or something, and all XP copies will be impossible to activate without using a crack, thus only already-installed copies will be allowed to run)

I think that any type of PC virtualization should be allowed, regardless of its wine, DOSBox, Virtual PC or whatever, but:
The same prerequises as flashcart is applied, eg the game does not play significantly different to a natively run game, and that a run can be taken down if the gameplay is deemed to play differently as a natively run game.

I would suggest allowing officially approved emulators, even if they are not official.
One example is this for megaman games: http://store.steampowered.com/app/363440/
In some such emulators, there are cheat options enableable in the menu (god mode and such). If the emulator contains such a option, the runner should be required to show that such options are turned off. If theres options in the menu to bind keys to like turbo or such "cheaty", same should be done here, shown that its unbound or bound to a unavailable key (in case its not possible to unbind it).
Same prerequistes as flashcarts, eg only if the run is "indistinguishable" from a native run.

About saving/loading:
I don't know if its still that saves add 0,5 seconds to the time in the draft because that is not mentioned.

But if its still 0,5 seconds per save, then I would suggest instead changing so loads adds 0,5 seconds to the time, regardless of if the load happens automatically because player fails a critical mission (for example losing a object required to progress) and the game senses that its not possible to finish the game in this state, dies, or if the player actually does a manual load.

The advantage of making so loads count 0,5 seconds instead of saves count 0,5 seconds, is that you don't need to differentiate between autosaves/checkpoints and manual saves/quicksaves. Then any use of a save would count against the runner.
The second reason, is that its not always visible if the user is saving, and also its normally not visible if its a autosave or a manual save, but its guranteed to be visible if player is loading. I think a runner shouldn't need to explain every autosave checkpoint, especially in longer games where there can be quite a few.

About DOSBox, I think that a exception to requiring "Settings from official DOSBox bundles of the games" should be made if the "official settings" are not available freely, and would require a repurchase of the game to obtain. Then I think the nearest "freely avaiable settings that are fair" should be allowed.

About bundled controllers:
Here I think its unneccessary strict. I think it should be permitted to use all features available on all official controllers, even if the controllers were made available later on as a purchaseable addon. With official controller, it should strictly count the following:
-All bundled controllers that was released with a new original console, regardless of manufacturer.
-All controllers made by the same manufacturer(s) as the original console system or any of its bundled controllers.

About Virtualization:
Why forbid Wine? I think its better to allow Wine, but ONLY if it does play enough similiar to not affect comparisation (like with Flashcarts) and does not allow unfair advantage.
Generally, this means only games with a "green" status on Wine's official page, but sometimes even yellow/red games can run fine in singleplayer mode, where the red/yellow status is because of a nonfunctioning MP mode (all information is normally given on Wine's page whats exactly is affected).

The reason is that I think that people that does not have the money to buy licenses for Windows, should be allowed to Wine instead. Using a hardware virtualization still requires a original license for the original operating system.
(And in some cases, actually, licenses does not even activate on virtualized enviroments, so wine is actually the only option if you cannot obtain native hardware to the OS in question. This will be the case with for example XP, where Microsoft will be shutting down activation of XP in late 2018-2020 or something, and all XP copies will be impossible to activate without using a crack, thus only already-installed copies will be allowed to run)

I think that any type of PC virtualization should be allowed, regardless of its wine, DOSBox, Virtual PC or whatever, but:
The same prerequises as flashcart is applied, eg the game does not play significantly different to a natively run game, and that a run can be taken down if the gameplay is deemed to play differently as a natively run game.

IsraeliRD

Edit history:

IsraeliRD: 2016-04-01 06:46:05 am

2016-04-01 06:46:00 am

Dragon Power Supreme

Quote from sebastian:

I don't know if its still that saves add 0,5 seconds to the time in the draft because that is not mentioned.

Manual saves have not penalised by 0.5 seconds for a couple years now.

ktwo

2016-04-01 01:53:54 pm

New version attached.

puwexil, I added your suggestions.

I also changed the wording a bit to highlight the rng issue when re-doing segments in the middle of a run.

sebastian, here are a couple of replies to your comments:

* I didn't take part in the discussion when it was decided to open up for DOSBox submissions and I admit that I'm not familiar enough with the topic to give specific replies to your suggested alternatives. However, in general, I don't think SDA is going in a direction of accepting more and more emulation. Especially when the games are already readily available for SDA-submissions by using other platforms or software (even though these options might be more expensive).

* About the controllers, are you saying that for example auto-fire should be allowed for NES-games because there were certain official controllers released with that feature? If not, can you give a specific example of what you think should be included, but is not covered with the current wording?

Attachment:

SDA rules update - draft_v1.3.pdf

Elipsis

2016-04-02 12:50:35 pm

Is there any ruling on whether or not all game times are still going to be rounded down to the nearest second? Reason being, as IsraeliRD knows all too well, I've got a run out there that is 0 seconds according to this convention.

Personally, I think this practice should be eliminated for games where records are being broken by fractions of a second.

LotBlind

2016-04-03 09:58:11 am

"It will in practice often be difficult to determine if this results in an advantage for the player or not. Re-doing segments where the rng seeds impact future segments is therefore not allowed on SDA."

I'd mark it RNG in caps (it's an acronym after all) and probably highlight it too. I guess this is an okay wording. There will be cases where yes, you've affected the RNG in a way that's not exactly the same as before but it's something that could to all ends and purposes have happened with the route of your choice and nearly identical execution, i.e. it's based on exact frame counts or something. We obviously mostly mean turn-based games and those where the manipulations are more... discrete in nature. Maybe change to this?

"It will in practice often be difficult to determine if this results in an advantage for the player or not. Any redoing of segments where the changes distinctly affect RNG in the future segments is therefore not allowed on SDA (mostly turn-based games and those with a very simple seeding algorithm)."

Make what you will of that.

Re. rounding game times down - is there any reason why we couldn't stop rounding them whenever either the run time is lower than something or the first actual submission comes in that saves less than 1 second (and actually gets accepted). That can't be more than a handful of games.

"It will in practice often be difficult to determine if this results in an advantage for the player or not. Re-doing segments where the rng seeds impact future segments is therefore not allowed on SDA."

I'd mark it RNG in caps (it's an acronym after all) and probably highlight it too. I guess this is an okay wording. There will be cases where yes, you've affected the RNG in a way that's not exactly the same as before but it's something that could to all ends and purposes have happened with the route of your choice and nearly identical execution, i.e. it's based on exact frame counts or something. We obviously mostly mean turn-based games and those where the manipulations are more... discrete in nature. Maybe change to this?

"It will in practice often be difficult to determine if this results in an advantage for the player or not. Any redoing of segments where the changes distinctly affect RNG in the future segments is therefore not allowed on SDA (mostly turn-based games and those with a very simple seeding algorithm)."

Make what you will of that.

Re. rounding game times down - is there any reason why we couldn't stop rounding them whenever either the run time is lower than something or the first actual submission comes in that saves less than 1 second (and actually gets accepted). That can't be more than a handful of games.

ktwo

2016-04-09 12:30:52 pm

I've updated the rules page in the knowledge base now (https://kb.speeddemosarchive.com/Rules). This doesn't mean it's set in stone though. If you continue to have comments, feel free to post them here.

LotBlind, I changed the wording of that phrase to "in a noticeable way".

I've alerted IsraeliRD about the comments about timing, in case he wishes to add his thoughts on those questions.

IsraeliRD

2016-04-10 10:21:59 am

Dragon Power Supreme

atm we don't have support for stopping the rounding down thing (anyone wants to code it in?), but SDA does recognise games where improvements are down to frames, and we accept frame-based improvement to existing runs.