Amnesia: The Dark Descent

André

Edit history:

André: 2015-12-24 08:47:40 am

2015-12-24 08:45:42 am

Main Work!!!

I'm trying to re pick up the game up the last few days, I've been practicing Any% with resets, I'm doing ok, the new tricks are way easier that I though, even more reliable than some old strats(Nave coming out of Choir and Sewer new clip), the new morgue clip is like a miracle, the oob morgue was so hard because of the door clip back in so we weren't using it, but thanks to the new clip on the corner, it's also pretty easy.

Here's where I have problem, the new "realiable" strat from Choir, I can't do it at all, it remind me of the one Apjjm used in his run, even if this one has a setup, I tried it for 45 minutes and haven't succeed a single time and came close only once, like am I getting the setup correct? I stick to the pillar move with small hits looking completely down and hit until I'm aligned to the corner of the kind of corner step on the pillar and I jump and as I jump I shift+W and mash jump as I land.

Otherwise I restarted SS 100% because I can't segmented, I don't have the patience to do a perfect run, in 100% I though I found the glitch of history where when I grabbed the last note in archives where I kind of fall to the ground and the cinematic about the orb start, as I fell I went to the door and opened it before the cinematic start, when I was out of archives, my speed was incredibly faster, I looks as if I was stuck in the ground, so I said, that's it, the dream, but the trouble is I can't tab nor crouch, so I can't glitch out and I can't use item, so I can't continue the run like this. I tried to exploit this for a good 3 hours and couldn't find a way. But overall, the run is also going ok. I might restart to stream soon, haven't stream in like 3 years xD .

I'm trying to re pick up the game up the last few days, I've been practicing Any% with resets, I'm doing ok, the new tricks are way easier that I though, even more reliable than some old strats(Nave coming out of Choir and Sewer new clip), the new morgue clip is like a miracle, the oob morgue was so hard because of the door clip back in so we weren't using it, but thanks to the new clip on the corner, it's also pretty easy.

Here's where I have problem, the new "realiable" strat from Choir, I can't do it at all, it remind me of the one Apjjm used in his run, even if this one has a setup, I tried it for 45 minutes and haven't succeed a single time and came close only once, like am I getting the setup correct? I stick to the pillar move with small hits looking completely down and hit until I'm aligned to the corner of the kind of corner step on the pillar and I jump and as I jump I shift+W and mash jump as I land.

Otherwise I restarted SS 100% because I can't segmented, I don't have the patience to do a perfect run, in 100% I though I found the glitch of history where when I grabbed the last note in archives where I kind of fall to the ground and the cinematic about the orb start, as I fell I went to the door and opened it before the cinematic start, when I was out of archives, my speed was incredibly faster, I looks as if I was stuck in the ground, so I said, that's it, the dream, but the trouble is I can't tab nor crouch, so I can't glitch out and I can't use item, so I can't continue the run like this. I tried to exploit this for a good 3 hours and couldn't find a way. But overall, the run is also going ok. I might restart to stream soon, haven't stream in like 3 years xD .

ShadowDraft

2015-12-24 01:41:27 pm

Get over here!

Good luck getting all the tinderboxes André Cheesy

André

2015-12-24 02:58:27 pm

Main Work!!!

Quote from ShadowDraft:

Good luck getting all the tinderboxes André Cheesy

Doesn't include Tinderbox
-Notes
-Journal
-All Puzzles
-Good ending(Agripa's end)

Nosferatu

2016-01-08 05:24:26 am

I made a few setup videos for maps that haven't been explained in a while.

Nave 3:

Cells:

Chancel 2:

These were some of the last maps I could think of that had difficult tricks that weren't explained in videos within the past few years.

RabzZ

2016-01-18 02:21:06 pm

Insta clip from Cistern to the Sewers. Well, I HAVE practiced it so i earn it haha
Later that day i died 3 times in my run and still 1 sec off my PB. There is potential at least ^^

Teravortryx

2016-01-30 11:03:17 pm

Here is a collection of some interesting things that happened while I was making my segmented run of the game. Enjoy:

ShadowDraft

2016-02-01 11:59:17 am

Get over here!

Yeah Amnesia can be quite brutal sometimes Cheesy

Gantor

2016-03-07 09:08:15 pm

First of all, I have changed my name from SavageDreamLord to Gantor. I came up with SDL 20 years ago when trying to find a hotmail username that wasn't taken. It doesn't sound as cool now as it did in high-school, and my friends call me Gantor anyways.

To the point, pursuant to a discussion I had with some other runners, I have spent the last week working on a better definition for "glitchless". Here is my proposition:

I will preface this by saying that I do not think that a single universal set of standards can be made to define exactly what is and is not a glitch. These are just my personal thoughts. Please let me know what you think.

Definitions:
A glitch is an error in the code of a game that causes unintended results when certain conditions are met.
I have identified four factors that come into play for any given action that the player takes:
1. The input of the player.
2. The circumstance of the game.
3. The intended output.
4. The actual output.
The actual output of a given input and circumstance is predetermined. There may be factors and variables that the player can not see such as the current state of the RNG, but this is part of the circumstance. Identical input and circumstance will always give identical results. This may be stated as an equation: Input + Circumstance = Output. Taken together, any given combination of Input, Circumstance, and Output, can be defined as a discrete unit called a "Strat". I realize that this way of stating things may seem obvious or silly, but please bear with me.
Errors in the game will affect the output. I have worked as a low-level programmer, and I can attest that there are infinite ways for these glitches to creep into a codebase. Very roughly speaking, I would like to separate these errors into engine errors and design errors. I am using a rather narrow definition of "design". In this context, I am speaking about the "front-end" of the game, all of the data about the levels, textures, sound, and so forth; essentially everything about the game that gets plugged into the engine. Design, as I have defined it here, can also be thought of as the input of the developers.
Engine errors are the result of the game engine not performing as intended. For example, when we use a pile of rocks to clip through the ceiling and out of bounds, this is an engine error. The design of the level is not flawed; there is no hole that we are fitting through. The engine is incorrectly processing the circumstances. Design errors are the result of the design of the game not performing as intended. For example, when we jump on the lip of the cistern wall to access the morgue without going through the control room, this is a design error. The engine is correctly processing the circumstances; we can fit on the ledge with a well-timed jump and duck. When the level was designed, this strat was most likely simply either not anticipated or not thought to be possible.

Glitches:
Now that I have laid the groundwork, I would like to discuss what strats should and should not be considered glitches. There are five categories of strats that I believe are important to discuss here.
1. Intended strat utilizing no errors in design nor engine.
These are the baseline. We are doing what the developer intended and no errors are being generated. This is clearly not a glitched strat. A feature should be considered an error when, if given sufficient time and resources, the developers would eliminate it.
2. Intended strat utilizing errors in design or engine.
This is a more complicated scenario. There are times when errors are introduced but the developer either likes them or mistakes them for correct processing or the glitch existed in a previous version and gets retconned. Does this actually happen? Yes, all the time. Some examples may be found here: http://www.gamefaqs.com/top10/2563-the-top-10-glitches-that-became-features
Such errors should clearly not be considered glitches.
3. Unintended strat utilizing no errors in design nor engine.
Strats in this category are, almost by definition, unhelpful, or neutral at best. If such actions were helpful, they could be justified as errors in design. For example, if I decide to run thrice clockwise around every pillar I come across, this is clearly not the intended route, but not an error either. This is simply the result of my free will as a gamer. Strats are not, by my working definition, necessarily good or helpful.
4. Unintended strat utilizing no errors in design but errors in engine.
This category of strats is nearly the definition of glitching. I could give many examples, but I expect this categorization to go uncontested.
5. Unintended strat utilizing errors in design but not in engine.
This is the most problematic category, however, after much careful consideration, I do not believe that this category should count as glitching. As I have shown in category 2, utilizing an error does not necessarily constitute glitching. As I have shown in category 3, the fact that the developer did not anticipate or intend the strat does mean that it necessarily constitutes glitching. So why do I advocate for the exploitation of engine errors being considered glitches, but not design errors? The distinction lies in two factors.

Intuition & Intent:
First of all, errors of the engine are typically obviously unintentional, whereas errors of design are typically not so clear. In the examples given above, one could easily argue that the developers knew that Daniel could fit onto the ledge in the cistern and meant for that to be used as a strat for especially clever or daring gamers. It is much harder to argue that they intended for the player to clip out of bounds and jump across the invisible geometry.
It is tempting at this juncture to argue that intent is the crux of the matter. And it is an important determining factor, but not the defining one.
Allow me to extend this way of thinking to other games. Imagine that in Super Mario Bros. there were enemies and obstacles spaced out in a certain level such that a skilled player could bounce from one to the next, getting many 1-ups and completing the stage very quickly. Would this be considered a glitch? Clearly not. But what if the designer came out and said that this strat was not foreseen and an unintentional error of the design of the level? It could be called an exploit sure, but not really a glitch. The same could be said for any given strat. What if it was claimed that Mario was not intended to move faster when the B button was held? Stated intent can only go so far. And so I fall back upon the nature of the error.
It is necessary to point out that, for many games there is a clear distinction between the engine and the design. Everyone knows that there are several common engines upon which games may be developed. However, for many other games, there is no clear distinction. The back-end and front-end were developed together and grew into a single mass of code and it would be impossible to cleanly extricate either component. Such cases are more complicated.
But not all hope is lost. If the nature of the strat is not clear, then I would employ a sort of "reasonable man standard". Would a casual player of the game who was unfamiliar with the strat and saw it for the first time think that they were seeing a glitch? If a strat is intuitive, it is not likely to be seen as a glitch.

My Criteria:
Based upon the above premises, I have devised the following criteria for a strat to be considered a glitch:
1. The strat must not have been intended. If it can be shown to be intended by the developers then it is not a glitch. Whereas a strat being demonstratively unintended does not necessarily make it a glitch.
2. The strat must exploit the engine rather than the design of the game.
3. If and only if the above criteria are ambiguous, then the strat must appear to be an exploit of the engine to casual players of that game.

Amnesia Strats:
Allow me to apply these criteria to some questionable strats:
1. Vertical boosting is an unintended exploit of the engine and therefore a glitch.
2. The control room skip is an error of design and therefore not a glitch.
3. Barrel armor is ambiguous. I think that it is intuitive that holding up a large object blocks attacks. It is also easy to argue that this is intentional behavior. I would say not a glitch.
4. Horizontal boosting is an unintended exploit of the engine and therefore a glitch. However, I would make a concession here as it is very difficult to avoid. Provided that no more setup is performed besides jumping in particular places, I would say that this single glitch should be allowed in glitchless runs.
5. Using monsters to break through barriers in Storage and Cell Block North is ambiguous. I emailed Frictional Games to ask if this was intentional but have had no reply. At first blush it appears to be a glitch because it seems both unintentional and unintuitive. But what is going on here? My programmer's intuition tells me that this is probably a piece of creative level design to make up for shortcomings in the engine. I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints. This would mean that using a grunt to break the barricade is simply using an unintended source of damage. Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error. It is an unintended use of an intended mechanic. If it was discovered that this was instead caused by a stack overflow, or a rounding error, or similar, then I would label it a glitch, but as I define it, I would not currently call it one.

To reiterate, these are simply my personal thoughts. Please let me know what you think.

First of all, I have changed my name from SavageDreamLord to Gantor.  I came up with SDL 20 years ago when trying to find a hotmail username that wasn't taken.  It doesn't sound as cool now as it did in high-school, and my friends call me Gantor anyways.

To the point, pursuant to a discussion I had with some other runners, I have spent the last week working on a better definition for "glitchless".  Here is my proposition:

[hidden]
I will preface this by saying that I do not think that a single universal set of standards can be made to define exactly what is and is not a glitch.  These are just my personal thoughts.  Please let me know what you think.

Definitions:
A glitch is an error in the code of a game that causes unintended results when certain conditions are met.
I have identified four factors that come into play for any given action that the player takes:
1. The input of the player.
2. The circumstance of the game.
3. The intended output.
4. The actual output.
The actual output of a given input and circumstance is predetermined.  There may be factors and variables that the player can not see such as the current state of the RNG, but this is part of the circumstance.  Identical input and circumstance will always give identical results.  This may be stated as an equation:  Input + Circumstance = Output.  Taken together, any given combination of Input, Circumstance, and Output, can be defined as a discrete unit called a "Strat".  I realize that this way of stating things may seem obvious or silly, but please bear with me.
Errors in the game will affect the output.  I have worked as a low-level programmer, and I can attest that there are infinite ways for these glitches to creep into a codebase.  Very roughly speaking, I would like to separate these errors into engine errors and design errors.  I am using a rather narrow definition of "design".  In this context, I am speaking about the "front-end" of the game, all of the data about the levels, textures, sound, and so forth; essentially everything about the game that gets plugged into the engine.  Design, as I have defined it here, can also be thought of as the input of the developers.
Engine errors are the result of the game engine not performing as intended.  For example, when we use a pile of rocks to clip through the ceiling and out of bounds, this is an engine error.  The design of the level is not flawed; there is no hole that we are fitting through.  The engine is incorrectly processing the circumstances.  Design errors are the result of the design of the game not performing as intended.  For example, when we jump on the lip of the cistern wall to access the morgue without going through the control room, this is a design error.  The engine is correctly processing the circumstances; we can fit on the ledge with a well-timed jump and duck.  When the level was designed, this strat was most likely simply either not anticipated or not thought to be possible.

Glitches:
Now that I have laid the groundwork, I would like to discuss what strats should and should not be considered glitches.  There are five categories of strats that I believe are important to discuss here.
1. Intended strat utilizing no errors in design nor engine.
These are the baseline.  We are doing what the developer intended and no errors are being generated.  This is clearly not a glitched strat.  A feature should be considered an error when, if given sufficient time and resources, the developers would eliminate it.
2. Intended strat utilizing errors in design or engine.
This is a more complicated scenario.  There are times when errors are introduced but the developer either likes them or mistakes them for correct processing or the glitch existed in a previous version and gets retconned.  Does this actually happen?  Yes, all the time.  Some examples may be found here: http://www.gamefaqs.com/top10/2563-the-top-10-glitches-that-became-features
Such errors should clearly not be considered glitches.
3. Unintended strat utilizing no errors in design nor engine.
Strats in this category are, almost by definition, unhelpful, or neutral at best.  If such actions were helpful, they could be justified as errors in design.  For example, if I decide to run thrice clockwise around every pillar I come across, this is clearly not the intended route, but not an error either.  This is simply the result of my free will as a gamer.  Strats are not, by my working definition, necessarily good or helpful.
4. Unintended strat utilizing no errors in design but errors in engine.
This category of strats is nearly the definition of glitching.  I could give many examples, but I expect this categorization to go uncontested.
5. Unintended strat utilizing errors in design but not in engine.
This is the most problematic category, however, after much careful consideration, I do not believe that this category should count as glitching.  As I have shown in category 2, utilizing an error does not necessarily constitute glitching.  As I have shown in category 3, the fact that the developer did not anticipate or intend the strat does mean that it necessarily constitutes glitching.  So why do I advocate for the exploitation of engine errors being considered glitches, but not design errors?  The distinction lies in two factors.

Intuition & Intent:
First of all, errors of the engine are typically obviously unintentional, whereas errors of design are typically not so clear.  In the examples given above, one could easily argue that the developers knew that Daniel could fit onto the ledge in the cistern and meant for that to be used as a strat for especially clever or daring gamers.  It is much harder to argue that they intended for the player to clip out of bounds and jump across the invisible geometry.
It is tempting at this juncture to argue that intent is the crux of the matter.  And it is an important determining factor, but not the defining one.
Allow me to extend this way of thinking to other games.  Imagine that in Super Mario Bros. there were enemies and obstacles spaced out in a certain level such that a skilled player could bounce from one to the next, getting many 1-ups and completing the stage very quickly.  Would this be considered a glitch?  Clearly not.  But what if the designer came out and said that this strat was not foreseen and an unintentional error of the design of the level?  It could be called an exploit sure, but not really a glitch.  The same could be said for any given strat.  What if it was claimed that Mario was not intended to move faster when the B button was held?  Stated intent can only go so far.  And so I fall back upon the nature of the error.
It is necessary to point out that, for many games there is a clear distinction between the engine and the design.  Everyone knows that there are several common engines upon which games may be developed.  However, for many other games, there is no clear distinction.  The back-end and front-end were developed together and grew into a single mass of code and it would be impossible to cleanly extricate either component.  Such cases are more complicated.
But not all hope is lost.  If the nature of the strat is not clear, then I would employ a sort of "reasonable man standard".  Would a casual player of the game who was unfamiliar with the strat and saw it for the first time think that they were seeing a glitch?  If a strat is intuitive, it is not likely to be seen as a glitch.

My Criteria:
Based upon the above premises, I have devised the following criteria for a strat to be considered a glitch:
1. The strat must not have been intended.  If it can be shown to be intended by the developers then it is not a glitch.  Whereas a strat being demonstratively unintended does not necessarily make it a glitch.
2. The strat must exploit the engine rather than the design of the game.
3. If and only if the above criteria are ambiguous, then the strat must appear to be an exploit of the engine to casual players of that game.

Amnesia Strats:
Allow me to apply these criteria to some questionable strats:
1. Vertical boosting is an unintended exploit of the engine and therefore a glitch.
2. The control room skip is an error of design and therefore not a glitch.
3. Barrel armor is ambiguous.  I think that it is intuitive that holding up a large object blocks attacks.  It is also easy to argue that this is intentional behavior.  I would say not a glitch.
4. Horizontal boosting is an unintended exploit of the engine and therefore a glitch.  However, I would make a concession here as it is very difficult to avoid.  Provided that no more setup is performed besides jumping in particular places, I would say that this single glitch should be allowed in glitchless runs.
5. Using monsters to break through barriers in Storage and Cell Block North is ambiguous.  I emailed Frictional Games to ask if this was intentional but have had no reply.  At first blush it appears to be a glitch because it seems both unintentional and unintuitive.  But what is going on here?  My programmer's intuition tells me that this is probably a piece of creative level design to make up for shortcomings in the engine.  I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints.  This would mean that using a grunt to break the barricade is simply using an unintended source of damage.  Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error.  It is an unintended use of an intended mechanic.  If it was discovered that this was instead caused by a stack overflow, or a rounding error, or similar, then I would label it a glitch, but as I define it, I would not currently call it one.

To reiterate, these are simply my personal thoughts.  Please let me know what you think.

[/hidden]

ShadowDraft

2016-03-08 08:51:35 am

Get over here!

Quote:

Amnesia Strats:
Allow me to apply these criteria to some questionable strats:
1. Vertical boosting is an unintended exploit of the engine and therefore a glitch.
2. The control room skip is an error of design and therefore not a glitch.

Yes.

Quote:

3. Barrel armor is ambiguous. I think that it is intuitive that holding up a large object blocks attacks. It is also easy to argue that this is intentional behavior. I would say not a glitch.

No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.

Quote:

4. Horizontal boosting is an unintended exploit of the engine and therefore a glitch. However, I would make a concession here as it is very difficult to avoid. Provided that no more setup is performed besides jumping in particular places, I would say that this single glitch should be allowed in glitchless runs.

There's no guarantee to avoid this boost, I agree.

Quote:

5. Using monsters to break through barriers in Storage and Cell Block North is ambiguous. I emailed Frictional Games to ask if this was intentional but have had no reply. At first blush it appears to be a glitch because it seems both unintentional and unintuitive. But what is going on here? My programmer's intuition tells me that this is probably a piece of creative level design to make up for shortcomings in the engine. I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints. This would mean that using a grunt to break the barricade is simply using an unintended source of damage. Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error. It is an unintended use of an intended mechanic. If it was discovered that this was instead caused by a stack overflow, or a rounding error, or similar, then I would label it a glitch, but as I define it, I would not currently call it one.

Your intuition is correct. There are hitpoints on those objects. And yes this isn't really a glitch. (By the way this has been known for a while now Cheesy

)

[quote]Amnesia Strats:
Allow me to apply these criteria to some questionable strats:
1. Vertical boosting is an unintended exploit of the engine and therefore a glitch.
2. The control room skip is an error of design and therefore not a glitch.[/quote]

Yes.

[quote]
3. Barrel armor is ambiguous.  I think that it is intuitive that holding up a large object blocks attacks.  It is also easy to argue that this is intentional behavior.  I would say not a glitch.[/quote]

No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.

[quote]4. Horizontal boosting is an unintended exploit of the engine and therefore a glitch.  However, I would make a concession here as it is very difficult to avoid.  Provided that no more setup is performed besides jumping in particular places, I would say that this single glitch should be allowed in glitchless runs.[/quote]

There's no guarantee to avoid this boost, I agree.

[quote]5. Using monsters to break through barriers in Storage and Cell Block North is ambiguous.  I emailed Frictional Games to ask if this was intentional but have had no reply.  At first blush it appears to be a glitch because it seems both unintentional and unintuitive.  But what is going on here?  My programmer's intuition tells me that this is probably a piece of creative level design to make up for shortcomings in the engine.  I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints.  This would mean that using a grunt to break the barricade is simply using an unintended source of damage.  Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error.  It is an unintended use of an intended mechanic.  If it was discovered that this was instead caused by a stack overflow, or a rounding error, or similar, then I would label it a glitch, but as I define it, I would not currently call it one.[/quote]

Your intuition is correct. There are hitpoints on those objects. And yes this isn't really a glitch. (By the way this has been known for a while now :D )

Gantor

Edit history:

Gantor: 2016-03-08 01:55:03 pm

Gantor: 2016-03-08 01:54:08 pm

2016-03-08 01:53:48 pm

Quote:

No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.

I was not aware that this involved clipping, and I agree with your conclusion. Holding up a barrel without clipping into it would not be a glitch however (which is what I thought this referred to embarassed

).

Quote:

There's no guarantee to avoid this boost, I agree.

Teravortryx was able to point me to some fields in the debug data that heavily imply that horizontal boosting is an intended part of the physics engine. However, vertical boosting or jump stacking do not work in the same way and still appear to be unintended glitches.

Quote:

Your intuition is correct. There are hitpoints on those objects. And yes this isn't really a glitch. (By the way this has been known for a while now Cheesy

)

Thank you very much for the feedback! I am still relatively new to both Amnesia and speedrunning and there is a lot to learn.

[quote]
No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.
[/quote]
I was not aware that this involved clipping, and I agree with your conclusion.  Holding up a barrel without clipping into it would not be a glitch however (which is what I thought this referred to :embarassed:).

[quote]
There's no guarantee to avoid this boost, I agree.
[/quote]
Teravortryx was able to point me to some fields in the debug data that heavily imply that horizontal boosting is an intended part of the physics engine.  However, vertical boosting or jump stacking do not work in the same way and still appear to be unintended glitches.

[quote]Your intuition is correct. There are hitpoints on those objects. And yes this isn't really a glitch. (By the way this has been known for a while now :D )[/quote]
Thank you very much for the feedback!  I am still relatively new to both Amnesia and speedrunning and there is a lot to learn.

Teravortryx

2016-03-08 07:23:00 pm

Quote:

3. Barrel armor is ambiguous. I think that it is intuitive that holding up a large object blocks attacks. It is also easy to argue that this is intentional behavior. I would say not a glitch.

No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.

Actually ShadowDraft, you aren't glitching into the barrel. The way the game was made, objects you're holding on to loses collision with you or any other entity. This was intended. Otherwise, you could put the object under you, grab it, and fly with it, which sounds a little bit like SOMA Tongue

(except you also had to exploit a glitch to do it in SOMA)

Also, thanks for submitting my segmented TDD run on Speedrun.com. I would have preferred if you had asked me about it first, but it's fine Smiley

Teravortryx

Edit history:

Teravortryx: 2016-03-09 08:21:48 am

2016-03-08 11:03:04 pm

Alright Gantor.

Quote:

I will preface this by saying that I do not think that a single universal set of standards can be made to define exactly what is and is not a glitch. These are just my personal thoughts.

I completely agree with you there. The same applies for me.

I agree with most of what you said, and I think your criteria was a great attempt to standardize the glitchless category. Your insight on why the Prison North door has hitpoints was interesting. I've never thought of that, but now it totally makes sense.

You categorized both vertical boosting and horizontal boosting as glitches, which I disagree with you on. I would argue that horizontal boosting is definitely not a glitch, and that vertical boosting is ambiguous.

I'll start by explaining the ways the player can normally move. There is player movement which includes walking and sprinting and is relative to the player, and there is force velocity, which is an external force not relative to the player that gets added to your base player movement (walking and sprinting). Some examples of vertical force velocity are jumping and gravity, but what about horizontal force velocity? There are areas in the game where you can get damage boosted horizontally, but what else?

Whenever you try to stand on a slope steep enough, you will slide off of it in the direction of the downwards slope. This is an intended feature of the game, but ironically we can exploit this to help instead of hinder us by sliding off faster by landing on the slope from a height, and also doing some jumps as we land on it and throughout the boost to minimize contact with the ground and therefore preserving our momentum. We are only using intended engine features in unintended ways, therefore horizontal boosting is not a glitch.

Vertical boosting is a bit more tricky. Let's break down what exactly is going on for a vertical boost. First I'll list some facts:

1. The player can jump whenever the bottom of the playermodel is in contact with the ground, no matter how steep, which would mean in special circumstances, you don't have to be on the downwards stroke of a jump to perform another jump, because as long as the slope is steeper than the path Daniel's feet makes doing a sprint jump, his feet can come into contact with the ground while he still has positive force velocity on the Y axis (while Daniel is still moving upwards from the jump).

2. There is no cooldown for jumping. As long as Daniel has floor under him no matter how steep, he can jump every frame.

3. Jumping adds force velocity to the Y axis without removing existing velocity.

Breaking vertical boosting down in this manner makes it a lot less ambiguous, and makes it easier to determine if it's a glitch or not. Is the player jumping while on a slope a glitch? No. (although Frictional made it so you can't jump while on steep slopes in SOMA, jumping on slopes was a feature in HPL2. This is also how vertical boosting was removed from SOMA) Is being able to jump every frame a glitch? No. Is the way the force velocity system adds velocity a glitch? No. Does this mean vertical boosting is definitely not a glitch? Not necessarily. I think spamming jump to get up on a large rock or up a hill easier is definitely not a glitch, however, consider the Pigline boost in Amnesia: A Machine for Pigs. (19m 5s into /watch?v=wD1dV6VqR54 ) It just doesn't seem like getting a jump on the upwards stroke of the initial jump should be possible where two flat planes intersect at a right angle. For that particular boost, the timing of the initial jump is precise, which suggests to me that sometimes the bottom of the playermodel can just barely brush up against a floor and still be able to get jumps off of it. So if the intended jump feature was getting jumps with the entire bottom of the playermodel in contact with the floor, is having the bottom edge of the playermodel brush up against the edge of a floor on the upwards motion of an initial jump and getting a second jump... going too far to not be considered a glitch? Probably.

In conclusion, I think all forms of horizontal boosting are not considered a glitch (as long as we're not exploiting glitches to get the force velocity in the first place which is only possible in AMFP anyways), but a couple forms of vertical boosting can be considered a glitch.

Again, this is just my opinion on a silly and squishy topic. If I got any of my facts wrong or if you disagree with anything I have said, then please let me know and we can discuss it Smiley

Alright Gantor.

[quote]I will preface this by saying that I do not think that a single universal set of standards can be made to define exactly what is and is not a glitch. These are just my personal thoughts.[/quote]
I completely agree with you there. The same applies for me.

[hidden]I agree with most of what you said, and I think your criteria was a great attempt to standardize the glitchless category. Your insight on why the Prison North door has hitpoints was interesting. I've never thought of that, but now it totally makes sense.

You categorized both vertical boosting and horizontal boosting as glitches, which I disagree with you on. I would argue that horizontal boosting is definitely not a glitch, and that vertical boosting is ambiguous.

I'll start by explaining the ways the player can normally move. There is player movement which includes walking and sprinting and is relative to the player, and there is force velocity, which is an external force not relative to the player that gets added to your base player movement (walking and sprinting). Some examples of vertical force velocity are jumping and gravity, but what about horizontal force velocity? There are areas in the game where you can get damage boosted horizontally, but what else?

Whenever you try to stand on a slope steep enough, you will slide off of it in the direction of the downwards slope. This is an intended feature of the game, but ironically we can exploit this to help instead of hinder us by sliding off faster by landing on the slope from a height, and also doing some jumps as we land on it and throughout the boost to minimize contact with the ground and therefore preserving our momentum. We are only using intended engine features in unintended ways, therefore horizontal boosting is not a glitch.

Vertical boosting is a bit more tricky. Let's break down what exactly is going on for a vertical boost. First I'll list some facts:

1. The player can jump whenever the bottom of the playermodel is in contact with the ground, no matter how steep, which would mean in special circumstances, you don't have to be on the downwards stroke of a jump to perform another jump, because as long as the slope is steeper than the path Daniel's feet makes doing a sprint jump, his feet can come into contact with the ground while he still has positive force velocity on the Y axis (while Daniel is still moving upwards from the jump).

2. There is no cooldown for jumping. As long as Daniel has floor under him no matter how steep, he can jump every frame.

3. Jumping adds force velocity to the Y axis without removing existing velocity.

Breaking vertical boosting down in this manner makes it a lot less ambiguous, and makes it easier to determine if it's a glitch or not. Is the player jumping while on a slope a glitch? No. (although Frictional made it so you can't jump while on steep slopes in SOMA, jumping on slopes was a feature in HPL2. This is also how vertical boosting was removed from SOMA) Is being able to jump every frame a glitch? No. Is the way the force velocity system adds velocity a glitch? No. Does this mean vertical boosting is definitely not a glitch? Not necessarily. I think spamming jump to get up on a large rock or up a hill easier is definitely not a glitch, however, consider the Pigline boost in Amnesia: A Machine for Pigs. (19m 5s into /watch?v=wD1dV6VqR54 ) It just doesn't seem like getting a jump on the upwards stroke of the initial jump should be possible where two flat planes intersect at a right angle. For that particular boost, the timing of the initial jump is precise, which suggests to me that sometimes the bottom of the playermodel can just barely brush up against a floor and still be able to get jumps off of it. So if the intended jump feature was getting jumps with the entire bottom of the playermodel in contact with the floor, is having the bottom edge of the playermodel brush up against the edge of a floor on the upwards motion of an initial jump and getting a second jump... going too far to not be considered a glitch? Probably.

In conclusion, I think all forms of horizontal boosting are not considered a glitch (as long as we're not exploiting glitches to get the force velocity in the first place which is only possible in AMFP anyways), but a couple forms of vertical boosting can be considered a glitch.[/hidden]
Again, this is just my opinion on a silly and squishy topic. If I got any of my facts wrong or if you disagree with anything I have said, then please let me know and we can discuss it :)

ShadowDraft

2016-03-09 08:33:31 am

Get over here!

Quote from Teravortryx:

Quote:

3. Barrel armor is ambiguous. I think that it is intuitive that holding up a large object blocks attacks. It is also easy to argue that this is intentional behavior. I would say not a glitch.

No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.

Actually ShadowDraft, you aren't glitching into the barrel. The way the game was made, objects you're holding on to loses collision with you or any other entity. This was intended. Otherwise, you could put the object under you, grab it, and fly with it, which sounds a little bit like SOMA Tongue

(except you also had to exploit a glitch to do it in SOMA)

Also, thanks for submitting my segmented TDD run on Speedrun.com. I would have preferred if you had asked me about it first, but it's fine Smiley

Well I still see it as exploiting the engine rather than design. And you can object hover in all HPL iterations afaik.

Did you not want the segmented run up there? I can remove it if you wish. I just put it up there to update people interested in what's happened with the game after Apjjm made his segmented run.

[quote="Teravortryx"][quote][quote]3. Barrel armor is ambiguous.  I think that it is intuitive that holding up a large object blocks attacks.  It is also easy to argue that this is intentional behavior.  I would say not a glitch.[/quote]
No. Barrel armor is a glitch because you glitch into the object to protect yourself. If you can find a way to make it work without triggering that glitch then I would agree.[/quote]
Actually ShadowDraft, you aren't glitching into the barrel. The way the game was made, objects you're holding on to loses collision with you or any other entity. This was intended. Otherwise, you could put the object under you, grab it, and fly with it, which sounds a little bit like SOMA :P (except you also had to exploit a glitch to do it in SOMA)

Also, thanks for submitting my segmented TDD run on Speedrun.com. I would have preferred if you had asked me about it first, but it's fine :)[/quote]

Well I still see it as exploiting the engine rather than design. And you can object hover in all HPL iterations afaik.

Did you not want the segmented run up there? I can remove it if you wish. I just put it up there to update people interested in what's happened with the game after Apjjm made his segmented run.

Gantor

2016-03-09 03:21:21 pm

Quote from Teravortryx:

Is the player jumping while on a slope a glitch? No.

I agree.

Quote:

Is being able to jump every frame a glitch? No.

I agree.

Quote:

Is the way the force velocity system adds velocity a glitch? No.

I would argue that this particular calculation does work in ways that constitute a glitch. Being able to jump whenever your feet are on the ground is not a glitch, even if that is every frame. The problem is in the additive nature of jump velocity.

When you jump, it propels you upwards by adding a fixed amount of y-axis force and allows gravity to slow your velocity and bring you back to earth. This is normal and natural. Jumping a second time while already airborne can't be allowed so a check is made to ensure that the player's feet are on the ground when a jump is initiated. In theory, this should prevent the player from flying. With no other considerations, this calculation should be fine. In reality, it takes progressively more force to propel a body upwards, but there is no reason to emulate that in the engine if the only way to gain upwards velocity is to jump and you can only do that once at a time.

The case where this becomes problematic is when you are pressing into a slope, it causes your feet to be on the ground in mid-jump which fools the engine into allowing you to jump again ad-infinitum. Even this is not necessarily a glitch. However, since the engine does not appear to take this case into consideration, I am led to believe that it is not an intentional feature of the engine for the player to achieve incredible vertical velocities by repeatedly jumping into a slope. The game design also appears to make no consideration for this mechanic. This, along with it being so unrealistic, and that this behavior was fixed for SOMA (as far as I know), leads me to believe that it is also undesirable in the developer's eyes. An unintended, undesired, feature of the engine is the definition of a glitch.

I must be very careful at this juncture to state that my problem isn't that the mechanic is unrealistic. The developer can make the game with whatever physics that they like. It is that it was not considered and not wanted.

Quote:

The way the game was made, objects you're holding on to loses collision with you or any other entity. This was intended. Otherwise, you could put the object under you, grab it, and fly

It is interesting that they turn off collision on objects when you hold them, and this explains some odd behavior that I have noticed. However, as you note, the reason that collision is turned off is to prevent a glitch that would allow you to fly. It is not to allow you to clip inside of it. So, again, an unintended, undesired feature of the engine.

I do realize that my opinions here makes assumptions based upon the developer's intent. As you said, silly and squishy. Wink

You told me that you would come up with interesting arguments and corner-cases. Well, you are doing a good job and I appreciate it! These are the important questions to ask if we are going to ever get a firm definition of the run.

[quote="Teravortryx"]
Is the player jumping while on a slope a glitch? No.[/quote]I agree.

[quote]Is being able to jump every frame a glitch? No.[/quote]I agree.

[quote]Is the way the force velocity system adds velocity a glitch? No.[/quote]
I would argue that this particular calculation does work in ways that constitute a glitch.  Being able to jump whenever your feet are on the ground is not a glitch, even if that is every frame.  The problem is in the additive nature of jump velocity.

When you jump, it propels you upwards by adding a fixed amount of y-axis force and allows gravity to slow your velocity and bring you back to earth.  This is normal and natural.  Jumping a second time while already airborne can't be allowed so a check is made to ensure that the player's feet are on the ground when a jump is initiated.  In theory, this should prevent the player from flying.  With no other considerations, this calculation should be fine.  In reality, it takes progressively more force to propel a body upwards, but there is no reason to emulate that in the engine if the only way to gain upwards velocity is to jump and you can only do that once at a time.

The case where this becomes problematic is when you are pressing into a slope, it causes your feet to be on the ground in mid-jump which fools the engine into allowing you to jump again ad-infinitum.  Even this is not necessarily a glitch.  However, since the engine does not appear to take this case into consideration, I am led to believe that it is not an intentional feature of the engine for the player to achieve incredible vertical velocities by repeatedly jumping into a slope.   The game design also appears to make no consideration for this mechanic.  This, along with it being so unrealistic, and that this behavior was fixed for SOMA (as far as I know), leads me to believe that it is also undesirable in the developer's eyes.  An unintended, undesired, feature of the engine is the definition of a glitch.

I must be very careful at this juncture to state that my problem isn't that the mechanic is unrealistic.  The developer can make the game with whatever physics that they like.  It is that it was not considered and not wanted.

[quote]The way the game was made, objects you're holding on to loses collision with you or any other entity. This was intended. Otherwise, you could put the object under you, grab it, and fly[/quote]
It is interesting that they turn off collision on objects when you hold them, and this explains some odd behavior that I have noticed.  However, as you note, the reason that collision is turned off is to prevent a glitch that would allow you to fly.  It is not to allow you to clip inside of it.  So, again, an unintended, undesired feature of the engine.

I do realize that my opinions here makes assumptions based upon the developer's intent.  As you said, silly and squishy. ;)  You told me that you would come up with interesting arguments and corner-cases.  Well, you are doing a good job and I appreciate it!  These are the important questions to ask if we are going to ever get a firm definition of the run.

Nosferatu

2016-03-09 07:26:16 pm

So what's everyone's opinion on using the grunt parts in sewers to kill the brute? It doesn't look like that was addressed yet. Damaging monsters with objects is an intended feature, it just normally doesn't let you damage them so rapidly. Since monster health and damaging monsters are both intended features, I'm inclined to think that it wouldn't be considered a glitch. However, the way the brute acts after you kill it certainly looks like glitchy behavior, so I'm not sure...

Secondly, can we grab the 1st orb piece in the transept through the gap in the cabinet door? The texture looks air-tight, but the physics has a gap in-between the door and the wall that you can grab the orb piece through.

Teravortryx

Edit history:

Teravortryx: 2016-03-10 08:12:05 am

Teravortryx: 2016-03-10 08:11:51 am

Teravortryx: 2016-03-10 08:08:58 am

Teravortryx: 2016-03-10 08:07:55 am

Teravortryx: 2016-03-10 08:00:01 am

2016-03-10 07:58:45 am

First of all, I think we all have made the mistake of understanding a strat too well, and then labeling it as a non-glitch. When we break down exactly how a strat works, it can make it easier to determine if it's a glitch or not, but it also shows the true stretchy nature of categorizing the strat, and also the criteria, which allows you to support arguments either way. This is also why counter arguments for each other or ourselves are so important. You're totally right on that Gantor.

I would like to address both using the grunt to break down the Prison North door or the rubble in Storage, and also using the arm to kill the Brute in Sewers. I would categorize both of these strats as glitches, countering two existing arguments.

I'll start with (my understanding of) how the health system works in Amnesia, which Gantor really helped me with. Amnesia has a health system with two subsystems, one of which includes the player's health, ways his health can be depleted, and means of regenerating health. The other subsystem would include the health of doors, barrels, boxes, and monsters, and is used for detecting puzzles being solved or other actions. This is a different system, because the developers didn't intend for the two subsystems to interfere with each other (one exception of this is in the Storage. The explosives can hurt both the player and the rubble, but this interference was intended).

Gantor pointed out that the Prison North door has health, which was intended only to be depleted by solving the puzzles. Extending Gantor's logic, the monsters in the game probably have health which can be depleted by props thrown at them to detect when they get hit, and then get stunned. The monsters getting stunned is completely intentional, because they added an animation for the monster getting stunned, and he also gets immobilized for a bit. However, the monsters were never meant to dip below 0 health, which Frictional games actually tried to prevent by giving the monsters rapid health regeneration all the time (Nos, at least this is what I remember from your silly monster slaying challenge). Without using the two connected pieces flexible arm (I see this as an engine limitation frictional had to work around. Also you can actually fly with the arm since only one of the connected pieces of it loses collision with you, and the other piece can still be stood on while holding it) The second clue, is that the monsters have no death animation, making them visually glitch out and appear to be broken. This also removes the monster's ability to attack, which is the desired result of the strat. With all of this in mind, I would categorize it as a glitch because we are exploiting faulty design of the engine (engine errors) and also Frictional's solutions to engine limitations. They tried and failed to prevent the Grunt from dying (the result of the strat), and on top of all of that, the result just looks glitchy.

Now, moving on to using the Grunt to smack open the Prison North door.

Quote:

I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints. This would mean that using a grunt to break the barricade is simply using an unintended source of damage. Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error.

This is a more obvious case of the two health subsystems mentioned earlier interfering with each other in unintended ways. Gantor, you called this an unintended source of damage, but you then also called it as a design error. However, Frictional tried to isolate the two health subsystems but failed to do it in this case and allowed for cross contamination (kind of like a buffer overflow), so this is a design error in the engine. What we're exploiting is not the design of the levels, we are exploiting design errors in the engine, and therefore exploiting errors in the engine. Glitch.

Finally, for the Transept quick orb piece grab. It's been a while since I've found that, but from what I remember, the texture is not actually airtight (but yeah, you're right. The textures in the game doesn't always have to match up with the physics). I faintly remember being able to see a sliver of the orb through the gap. Even if you couldn't see the orb, it's still a design error since that's the way the physics of the door was made. The gap in the physics between the cabinet door and the hinge is just a design error. Not a glitch. (that was easy Smiley

)

First of all, I think we all have made the mistake of understanding a strat too well, and then labeling it as a non-glitch. When we break down exactly how a strat works, it can make it easier to determine if it's a glitch or not, but it also shows the true stretchy nature of categorizing the strat, and also the criteria, which allows you to support arguments either way. This is also why counter arguments for each other or ourselves are so important. You're totally right on that Gantor.

I would like to address both using the grunt to break down the Prison North door or the rubble in Storage, and also using the arm to kill the Brute in Sewers. I would categorize both of these strats as glitches, countering two existing arguments.

I'll start with (my understanding of) how the health system works in Amnesia, which Gantor really helped me with. Amnesia has a health system with two subsystems, one of which includes the player's health, ways his health can be depleted, and means of regenerating health. The other subsystem would include the health of doors, barrels, boxes, and monsters, and is used for detecting puzzles being solved or other actions. This is a different system, because the developers didn't intend for the two subsystems to interfere with each other (one exception of this is in the Storage. The explosives can hurt both the player and the rubble, but this interference was intended).

Gantor pointed out that the Prison North door has health, which was intended only to be depleted by solving the puzzles. Extending Gantor's logic, the monsters in the game probably have health which can be depleted by props thrown at them to detect when they get hit, and then get stunned. The monsters getting stunned is completely intentional, because they added an animation for the monster getting stunned, and he also gets immobilized for a bit. However, the monsters were never meant to dip below 0 health, which Frictional games actually tried to prevent by giving the monsters rapid health regeneration all the time (Nos, at least this is what I remember from your silly monster slaying challenge). Without using the two connected pieces flexible arm (I see this as an engine limitation frictional had to work around. Also you can actually fly with the arm since only one of the connected pieces of it loses collision with you, and the other piece can still be stood on while holding it) The second clue, is that the monsters have no death animation, making them visually glitch out and appear to be broken. This also removes the monster's ability to attack, which is the desired result of the strat. With all of this in mind, I would categorize it as a glitch because we are exploiting faulty design of the engine (engine errors) and also Frictional's solutions to engine limitations. They tried and failed to prevent the Grunt from dying (the result of the strat), and on top of all of that, the result just looks glitchy.

Now, moving on to using the Grunt to smack open the Prison North door.

[quote]I would guess that hitpoints were assigned to these barricades and applying the solutions to the puzzles depletes those hitpoints. This would mean that using a grunt to break the barricade is simply using an unintended source of damage. Being able to solve a puzzle in an unintended way that does not utilize any errors in the engine is a design error.[/quote]
 This is a more obvious case of the two health subsystems mentioned earlier interfering with each other in unintended ways. Gantor, you called this an unintended source of damage, but you then also called it as a design error. However, Frictional tried to isolate the two health subsystems but failed to do it in this case and allowed for cross contamination (kind of like a buffer overflow), so this is a design error in the engine. What we're exploiting is not the design of the levels, we are exploiting design errors in the engine, and therefore exploiting errors in the engine. Glitch.

Finally, for the Transept quick orb piece grab. It's been a while since I've found that, but from what I remember, the texture is not actually airtight (but yeah, you're right. The textures in the game doesn't always have to match up with the physics). I faintly remember being able to see a sliver of the orb through the gap. Even if you couldn't see the orb, it's still a design error since that's the way the physics of the door was made. The gap in the physics between the cabinet door and the hinge is just a design error. Not a glitch. (that was easy :) )

Gantor

2016-03-12 12:26:18 pm

I have been thinking a lot about the barrier problem and the excellent arguments put up by both ShadowDraft and Teravortryx. I have come to the conclusion that my proposed system has a flaw that lets in much more ambiguity than intended. It seems to me that the most pressing corner cases revolve around the question of whether a strategy is a part of the engine or a part of the design. The arm strat and the barricade strat both seem to be design issues which only exist because of shortcomings of the engine. Since one relies upon the other, is it the proximal or distal cause of the problem that matters? As seen, perfectly valid arguments can be made for both sides with no clear determinant.

Rather than split hairs or start digging through source code to see where exactly a variable lies, I have a new, I hope clearer, schema for your consideration. Rather than dividing between "design" versus "engine" components, what if we separate things into "mechanics" versus "objects"? I hope that this will make the rules a little less squishy so to speak while preserving their spirit.

New Definitions:
An object is a physical or conceptual person, place, or thing. For example, Daniel is an object. Pillars are objects. Levels are made of objects. I think that this should be fairly intuitive for both programmers and non-programmers.
A mechanic is a system that defines the rules of an object. A mechanic may determine where an object can go, what it can do, &c. Don't take this comparison too far, but if objects are the nouns of a game then mechanics are the adjectives.

Rules:
For a strat to be considered a glitch it must:
1. Be unintentional from the designer's viewpoint. Is the strat intuitive? Is there evidence in the game that it was intended to be played that way? An intentional strat is never a glitch.
2. Be undesirable from the designer's viewpoint. The standard for this is that, if given a magic wand that could remove the strat, leaving everything else the same, would the developers have done so? A desired strat is never a glitch.
3. Be unintentional from a mechanical viewpoint. Is an object put into a state that is mechanically unexpected? A strat which at no point puts a property of an object into an unexpected state is never a glitch.
4. Where these standards are ambiguous, a stat is a glitch if it appears to a casual player to put an object into an unexpected state.

Strats:
My new rules do change a few of my personal opinions on allowed glitchless strats in either direction.
1. Vertical boosting - Unintentional and undesirable. Initiating a jump before the vertical momentum from the previous jump has returned to zero increases that property of the object far beyond what is mechanically intended. Glitch.
2. Horizontal boosting - As previously mentioned, there is a lot of evidence that this is intentional while conditionally undesirable. The mechanic puts the object into an expected state. Not a glitch.
3. Control room skip - Unintentional and undesirable. The object violates no rules of the mechanics. Not a glitch.
4. Clipping (including barrel armor) - Unintentional and undesirable. Puts an object into an unexpected state of being inside or going through another solid object. Glitch.
5. Skirting the transcept flashback - Unintentional and undesirable. At no point is an object in a mechanically unexpected state. Not a glitch.
6. Cabinet grabbing - Unintentional and undesirable. This is a design error that is conceptually problematic but not mechanically problematic. How did Daniel get that orb piece out through that tiny gap? It's physically impossible. But since such grabbed objects despawn and are put into the inventory instantly, there is no point at which an object is in an unexpected state. If it clipped through the door, that would be a problem. But it didn't. Not a glitch.
7. Arm Bonking - Unintentional and undesirable. Dealing damage is intentional; depleting enemy hitpoints to zero is unintentional. The enemy object is clearly put into an unexpected state. This is a design error, but it is a mechanical one. Glitch.
8. Barrier Busting - Unintentional and undesirable. This is actually a very similar situation as arm-bonking. Dealing damage to the barrier is intentional, depleting HP to zero is intentional; doing so with a monster is unintentional. However, I don't see any point at which an object's properties are in an unexpected state. The monster deals damage. Damage depletes hitpoints. Depleted hitpoints destroy the barrier. All intentional mechanics that leave objects within their bounds. Not a glitch.

Again, please let me know what you think. Hopefully this will be clearer and close more cans of worms than it opens.

I have been thinking a lot about the barrier problem and the excellent arguments put up by both ShadowDraft and Teravortryx.  I have come to the conclusion that my proposed system has a flaw that lets in much more ambiguity than intended.  It seems to me that the most pressing corner cases revolve around the question of whether a strategy is a part of the engine or a part of the design.  The arm strat and the barricade strat both seem to be design issues which only exist because of shortcomings of the engine.  Since one relies upon the other, is it the proximal or distal cause of the problem that matters?  As seen, perfectly valid arguments can be made for both sides with no clear determinant.

Rather than split hairs or start digging through source code to see where exactly a variable lies, I have a new, I hope clearer, schema for your consideration.  Rather than dividing between "design" versus "engine" components, what if we separate things into "mechanics" versus "objects"?  I hope that this will make the rules a little less squishy so to speak while preserving their spirit.

[hidden]
New Definitions:
An object is a physical or conceptual person, place, or thing.  For example, Daniel is an object.  Pillars are objects.  Levels are made of objects.  I think that this should be fairly intuitive for both programmers and non-programmers.
A mechanic is a system that defines the rules of an object.  A mechanic may determine where an object can go, what it can do, &c.  Don't take this comparison too far, but if objects are the nouns of a game then mechanics are the adjectives.

Rules:
For a strat to be considered a glitch it must:
1. Be unintentional from the designer's viewpoint.  Is the strat intuitive?  Is there evidence in the game that it was intended to be played that way?  An intentional strat is never a glitch.
2. Be undesirable from the designer's viewpoint.  The standard for this is that, if given a magic wand that could remove the strat, leaving everything else the same, would the developers have done so?  A desired strat is never a glitch.
3. Be unintentional from a mechanical viewpoint.  Is an object put into a state that is mechanically unexpected?  A strat which at no point puts a property of an object into an unexpected state is never a glitch.
4. Where these standards are ambiguous, a stat is a glitch if it appears to a casual player to put an object into an unexpected state.

Strats:
My new rules do change a few of my personal opinions on allowed glitchless strats in either direction.
1. Vertical boosting - Unintentional and undesirable.  Initiating a jump before the vertical momentum from the previous jump has returned to zero increases that property of the object far beyond what is mechanically intended.  Glitch.
2. Horizontal boosting - As previously mentioned, there is a lot of evidence that this is intentional while conditionally undesirable.  The mechanic puts the object into an expected state.  Not a glitch.
3. Control room skip - Unintentional and undesirable.  The object violates no rules of the mechanics.  Not a glitch.
4. Clipping (including barrel armor) - Unintentional and undesirable.  Puts an object into an unexpected state of being inside or going through another solid object.  Glitch.
5. Skirting the transcept flashback - Unintentional and undesirable.  At no point is an object in a mechanically unexpected state.  Not a glitch.
6. Cabinet grabbing - Unintentional and undesirable.  This is a design error that is conceptually problematic but not mechanically problematic.  How did Daniel get that orb piece out through that tiny gap?  It's physically impossible.  But since such grabbed objects despawn and are put into the inventory instantly, there is no point at which an object is in an unexpected state.  If it clipped through the door, that would be a problem.  But it didn't.  Not a glitch.
7. Arm Bonking - Unintentional and undesirable.  Dealing damage is intentional; depleting enemy hitpoints to zero is unintentional.  The enemy object is clearly put into an unexpected state.  This is a design error, but it is a mechanical one.  Glitch.
8. Barrier Busting - Unintentional and undesirable.  This is actually a very similar situation as arm-bonking.  Dealing damage to the barrier is intentional, depleting HP to zero is intentional; doing so with a monster is unintentional.  However, I don't see any point at which an object's properties are in an unexpected state.  The monster deals damage.  Damage depletes hitpoints.  Depleted hitpoints destroy the barrier.  All intentional mechanics that leave objects within their bounds.  Not a glitch.
[/hidden]

Again, please let me know what you think.  Hopefully this will be clearer and close more cans of worms than it opens.

Teravortryx

Edit history:

Teravortryx: 2016-03-12 06:44:15 pm

Teravortryx: 2016-03-12 02:07:46 pm

Teravortryx: 2016-03-12 02:04:33 pm

Teravortryx: 2016-03-12 02:03:06 pm

2016-03-12 01:59:06 pm

Good job Gantor, I think you nailed it with your amended criteria. I think most of your categorizations were reasonable, and you cleared up quite a few things for me, especially with providing a better reason why you thought vertical boosting was a glitch.

I guess it's time for me to start running the category Cheesy

(Dang, I guess I'm finally going to have to learn how to do the Choir gap boost. I used to only lose 12 potential seconds by not doing it in any%, but for glitchless, I'm losing about 20 potential seconds. Yikes!)

Teravortryx

Edit history:

Teravortryx: 2016-03-13 08:40:39 pm

2016-03-12 07:13:21 pm

Alright, so apparently Storage is a pain to deal with based on your new criteria/definitions. You have to hop off of a barrel to get on top of the rocks, hope the Grunt's AI doesn't crap out and leave you alone, and dodge his hits from on top of the rock. I'll have to admit that this slightly encouraged me to challenge you again Roll Eyes

Quote:

Clipping (including barrel armor) - Unintentional and undesirable. Puts an object into an unexpected state of being inside or going through another solid object. Glitch.

I am specifically going to be talking about barrel armor, which you included in your strats criteria, so I will assume your criteria fully applies to barrel armor. I don't necessarily disagree that barrel armor is a glitch, but if it is, I think you labeled it as a glitch for the wrong reasons. I will only be addressing the clipping part of barrel armor, since it is where the issue lies with you guys.

First, you said barrel armor was unintentional and undesirable.

Quote:

Rules:
For a strat to be considered a glitch it must:
1. Be unintentional from the designer's viewpoint. Is the strat intuitive? Is there evidence in the game that it was intended to be played that way? An intentional strat is never a glitch.
2. Be undesirable from the designer's viewpoint. The standard for this is that, if given a magic wand that could remove the strat, leaving everything else the same, would the developers have done so? A desired strat is never a glitch.
3. Be unintentional from a mechanical viewpoint. Is an object put into a state that is mechanically unexpected? A strat which at no point puts a property of an object into an unexpected state is never a glitch.
4. Where these standards are ambiguous, a strat is a glitch if it appears to a casual player to put an object into an unexpected state.

When you grab an object, the collision gets disabled with all entities. This was completely intentional, and there is no evidence that it was unintentional. Having the object clip into your playermodel is arguably unavoidable. Try grabbing an object of a reasonable size, and look straight down (or as far down as Daniel can look). Chances are, you just clipped the object into your playermodel. What if you grab a chair, hold it out, and accidentally run into a wall? Chances are, some part of the chair went into some part of your playermodel. Is this a glitch? Here's something else you can try: grab a large object and look straight down so it's in your playermodel. Now let go. What happens? The object gets pushed out of your playermodel slowly. This was also intentional, and was probably added by Frictional to make the physics appear to be more realistic. I guess you can't really say that Frictional intended for players to clip objects into themselves, but they definitely expected it, otherwise they wouldn't have made the objects slowly get pushed out of you when you let go. You said it puts the object into an unexpected state (I just covered this. The behavior was definitely expected by Frictional) of being inside or going through another solid object. Except the object is not solid when you're holding onto it. The collision gets disabled.

Now, with that evidence, let's categorize barrel armor (specifically the clipping aspect) again. Is it unintentional? No. It was indirectly intended. Was it undesirable? It's a direct and obvious side effect of a desired feature which disables the collision when you grab an object, so no. Was it unintentional from a mechanical viewpoint? The object passing through the playermodel was the intended and expected outcome of a change Frictional made to the engine that prevents prop flying. I would say not a glitch.

Alright, so apparently Storage is a pain to deal with based on your new criteria/definitions. You have to hop off of a barrel to get on top of the rocks, hope the Grunt's AI doesn't crap out and leave you alone, and dodge his hits from on top of the rock. I'll have to admit that this slightly encouraged me to challenge you again ::)

[quote]Clipping (including barrel armor) - Unintentional and undesirable. Puts an object into an unexpected state of being inside or going through another solid object. Glitch.[/quote]
I am specifically going to be talking about barrel armor, which you included in your strats criteria, so I will assume your criteria fully applies to barrel armor. I don't necessarily disagree that barrel armor is a glitch, but if it is, I think you labeled it as a glitch for the wrong reasons. I will only be addressing the clipping part of barrel armor, since it is where the issue lies with you guys.

First, you said barrel armor was unintentional and undesirable.

[quote]Rules:
For a strat to be considered a glitch it must:
1. Be unintentional from the designer's viewpoint.  Is the strat intuitive?  Is there evidence in the game that it was intended to be played that way?  An intentional strat is never a glitch.
2. Be undesirable from the designer's viewpoint.  The standard for this is that, if given a magic wand that could remove the strat, leaving everything else the same, would the developers have done so?  A desired strat is never a glitch.
3. Be unintentional from a mechanical viewpoint.  Is an object put into a state that is mechanically unexpected?  A strat which at no point puts a property of an object into an unexpected state is never a glitch.
4. Where these standards are ambiguous, a strat is a glitch if it appears to a casual player to put an object into an unexpected state.[/quote]
When you grab an object, the collision gets disabled with all entities. This was completely intentional, and there is no evidence that it was unintentional. Having the object clip into your playermodel is arguably unavoidable. Try grabbing an object of a reasonable size, and look straight down (or as far down as Daniel can look). Chances are, you just clipped the object into your playermodel. What if you grab a chair, hold it out, and accidentally run into a wall? Chances are, some part of the chair went into some part of your playermodel. Is this a glitch? Here's something else you can try: grab a large object and look straight down so it's in your playermodel. Now let go. What happens? The object gets pushed out of your playermodel slowly. This was also intentional, and was probably added by Frictional to make the physics appear to be more realistic. I guess you can't really say that Frictional intended for players to clip objects into themselves, but they definitely expected it, otherwise they wouldn't have made the objects slowly get pushed out of you when you let go. You said it puts the object into an unexpected state (I just covered this. The behavior was definitely expected by Frictional) of being inside or going through another solid object. Except the object is not solid when you're holding onto it. The collision gets disabled.

Now, with that evidence, let's categorize barrel armor (specifically the clipping aspect) again. Is it unintentional? No. It was indirectly intended. Was it undesirable? It's a direct and obvious side effect of a desired feature which disables the collision when you grab an object, so no. Was it unintentional from a mechanical viewpoint? The object passing through the playermodel was the intended and expected outcome of a change Frictional made to the engine that prevents prop flying. I would say not a glitch.

Gantor

2016-03-12 09:11:22 pm

Quote from Teravortryx:

A solid argument.

Conceded. This specific case of clipping seems intentional and expected, if conceptually problematic.

Teravortryx

Edit history:

Teravortryx: 2016-03-12 11:16:19 pm

Teravortryx: 2016-03-12 10:45:28 pm

2016-03-12 09:58:09 pm

I'm glad you agree Gantor. And not just because I get to do barrel armor in Storage Tongue

, which I just noticed you said was fine in your SGDQ 2016 submission video which seemed contradictory, as your submission was made before I challenged you, but alright. I really hope your submission gets accepted, I think it'll be an amazing run. A lot has changed in TDD ever since the last marathon run of it, and now it's even possible to beat the last marathon run (which used glitches and had a time of 44:30 RT) without using glitches.

I found a couple of improvements to your Wine Cellar route which saves ~10 seconds in total, the second of which I subjectively don't consider a glitch, but might be considered a glitch by your criteria.

I'll attempt to use your criteria to categorize the lock picking strat.

1. The strat is intuitive... but only to a speedrunner who spent a minute figuring out how the strat works. So far it's a glitch.
2. The developers wouldn't really care about removing the strat even if it takes no effort because why would they change something that ain't broke in the first place for a casual player, and only hurts speedrunners? (Not sure if I'm digging too deep) However, that doesn't mean it's desirable. Ambiguous, but still a glitch due to rule 1.
3. Since the physics don't match with the texture mapping, it's to be expected that mechanically something unexpected happens (object passing through textures or object colliding with air). Again not sure, but I guess it's a glitch due to rule 1.

I'd like to hear everyone's thoughts on whether the strat is a glitch or not. I'm also interested in seeing what you think Gantor, since you're the only one who knows the original copy of the criteria. Hopefully my interpretation of the criteria isn't that far off.

I wish you the best of luck on your run getting accepted for SGDQ 2016 Gantor Smiley

I'm glad you agree Gantor. And not just because I get to do barrel armor in Storage :P , which I just noticed you said was fine in your SGDQ 2016 submission video which seemed contradictory, as your submission was made before I challenged you, but alright. I really hope your submission gets accepted, I think it'll be an amazing run. A lot has changed in TDD ever since the last marathon run of it, and now it's even possible to beat the last marathon run (which used glitches and had a time of 44:30 RT) without using glitches.

I found a couple of improvements to your Wine Cellar route which saves ~10 seconds in total, the second of which I subjectively don't consider a glitch, but might be considered a glitch by your criteria.

https://www.youtube.com/watch?v=cWcmUOpyyqQ

I'll attempt to use your criteria to categorize the lock picking strat.

1. The strat is intuitive... but only to a speedrunner who spent a minute figuring out how the strat works. So far it's a glitch.
2. The developers wouldn't really care about removing the strat even if it takes no effort because why would they change something that ain't broke in the first place for a casual player, and only hurts speedrunners? (Not sure if I'm digging too deep) However, that doesn't mean it's desirable. Ambiguous, but still a glitch due to rule 1.
3. Since the physics don't match with the texture mapping, it's to be expected that mechanically something unexpected happens (object passing through textures or object colliding with air). Again not sure, but I guess it's a glitch due to rule 1.

I'd like to hear everyone's thoughts on whether the strat is a glitch or not. I'm also interested in seeing what you think Gantor, since you're the only one who knows the original copy of the criteria. Hopefully my interpretation of the criteria isn't that far off.

I wish you the best of luck on your run getting accepted for SGDQ 2016 Gantor :)

Teravortryx

2016-03-13 12:58:21 pm

I found a better way to do the Choir gap jump, which is based off of Arazath's setup. My success rate with this new method is over 95%, which I'm really satisfied with.

This strat is perfect for glitchless, since it doesn't require rapid jump inputs, and saves more time in glitchless than any%. For the people who already know Arazath's setup, the only thing you need to change is to stop spamming jump on the way down, and only jump after getting the horizontal boost.

I hope you guys find this helpful Smiley

Gantor

2016-03-14 03:37:16 pm

First off, congrats Teravortryx on your run! I still need to go through the video step by step because I know that you are performing several little things more efficiently than I. I really expect that with the new tricks and some practice, we can get this run sub-40!

Quote from Teravortryx:

I just noticed you said was fine in your SGDQ 2016 submission video which seemed contradictory

I stated in the video that the strat was contested. I also held up the barrel rather than clipping into it which I didn't think was problematic.

Quote:

I really hope your submission gets accepted, I think it'll be an amazing run.

Thank you. As you know, I'm not great at talking while running and the commentary in my submission video wasn't great. I misspoke several times and did at least one trick completely wrong. embarassed

But the run itself was still fairly clean for what it was so I hope that the panel can look past some of that. It really is very fun and consistent which is what I think they are looking for.

Quote:

I found a couple of improvements to your Wine Cellar route which saves ~10 seconds in total

The first trick was actually the method that I used when developing that strat. It is faster in theory. But from even that slightly farther distance, the throwing angle is much less forgiving. If you aim high, the box can tumble weird ways and you have to use the barrel next to the door instead which has to be rotated and is slower. If you aim too low, the box clips the railing and tumbles onto the stairs. I was finally able to get a somewhat consistent strategy but positioning myself and the throw was slower than just running down the stairs and it wasn't extremely consistent anyways. Also, running down the stairs gives me the half second I need to get a good angle to throw the box into the door where it needs minimal repositioning. If you can get a strat for a consistent throw from the top of the stairs that actually saves time, please let me know.

Quote:

Glitch criteria

First off, this trick is brilliant. You have no idea how hard I tried to find a way to get through that door without going around it or glitching. I only recently started using the dev-panel so I didn't know how that trigger worked. Well done.
My take on the bottle trick is:
1. It is unintentional. The developers did not intend for bottles to go through doors.
2. I think that you were overthinking this a little. I would say it's undesirable because it is unintuitive to a casual and allows for the puzzle to be solved in an undesired way. I am not assuming that devs would keep tricks that are not obvious in order to allow sweet speedrunning strats, although I like the way you think.
3. The bottle doesn't actually clip through the door model and doesn't go out of bounds. Is it expected behavior for objects to go through textures that are not solid? The wall in the chancel that you can walk through is similar but actually involves going out of bounds. I am still inclined to say that going through a non-solid object isn't unexpected. Mechanically it's similar to walking through particle effects, although from a dev and player standpoint it seems terribly unintuitive and glitchish. So I don't think that it actually would count as a glitch but I'm going to have to put some thought into this one.

Quote:

I found a better way to do the Choir gap jump, which is based off of Arazath's setup. My success rate with this new method is over 95%, which I'm really satisfied with.

Because of the jump-spamming I always assumed that this trick required jump-stacking. Thank you for working out that setup and making that video. I know what I'm spending the rest of my lunch break practicing. Grin

First off, congrats Teravortryx on your run!  I still need to go through the video step by step because I know that you are performing several little things more efficiently than I.  I really expect that with the new tricks and some practice, we can get this run sub-40!

[quote="Teravortryx"]I just noticed you said was fine in your SGDQ 2016 submission video which seemed contradictory[/quote]
I stated in the video that the strat was contested.  I also held up the barrel rather than clipping into it which I didn't think was problematic.

[quote]I really hope your submission gets accepted, I think it'll be an amazing run.[/quote]
Thank you.  As you know, I'm not great at talking while running and the commentary in my submission video wasn't great.  I misspoke several times and did at least one trick completely wrong. :embarassed:  But the run itself was still fairly clean for what it was so I hope that the panel can look past some of that.  It really is very fun and consistent which is what I think they are looking for.

[quote]I found a couple of improvements to your Wine Cellar route which saves ~10 seconds in total[/quote]
The first trick was actually the method that I used when developing that strat.  It is faster in theory.  But from even that slightly farther distance, the throwing angle is much less forgiving.  If you aim high, the box can tumble weird ways and you have to use the barrel next to the door instead which has to be rotated and is slower.  If you aim too low, the box clips the railing and tumbles onto the stairs.  I was finally able to get a somewhat consistent strategy but positioning myself and the throw was slower than just running down the stairs and it wasn't extremely consistent anyways.  Also, running down the stairs gives me the half second I need to get a good angle to throw the box into the door where it needs minimal repositioning.  If you can get a strat for a consistent throw from the top of the stairs that actually saves time, please let me know.

[quote]Glitch criteria[/quote]
First off, this trick is brilliant.  You have no idea how hard I tried to find a way to get through that door without going around it or glitching.  I only recently started using the dev-panel so I didn't know how that trigger worked.  Well done.
My take on the bottle trick is:
1. It is unintentional.  The developers did not intend for bottles to go through doors.
2. I think that you were overthinking this a little.  I would say it's undesirable because it is unintuitive to a casual and allows for the puzzle to be solved in an undesired way.  I am not assuming that devs would keep tricks that are not obvious in order to allow sweet speedrunning strats, although I like the way you think.
3. The bottle doesn't actually clip through the door model and doesn't go out of bounds.  Is it expected behavior for objects to go through textures that are not solid?  The wall in the chancel that you can walk through is similar but actually involves going out of bounds.  I am still inclined to say that going through a non-solid object isn't unexpected.  Mechanically it's similar to walking through particle effects, although from a dev and player standpoint it seems terribly unintuitive and glitchish.  So I don't think that it actually would count as a glitch but I'm going to have to put some thought into this one.

[quote]I found a better way to do the Choir gap jump, which is based off of Arazath's setup. My success rate with this new method is over 95%, which I'm really satisfied with.[/quote]
Because of the jump-spamming I always assumed that this trick required jump-stacking.  Thank you for working out that setup and making that video.  I know what I'm spending the rest of my lunch break practicing.  ;D

Teravortryx

Edit history:

Teravortryx: 2016-03-14 09:56:27 pm

2016-03-14 05:53:25 pm

Quote:

... I also held up the barrel rather than clipping into it which I didn't think was problematic.

Oh, my bad. I guess I recalled wrong then, however I still think there's a chance that the barrel clipped into you just before you died. This just adds to my point about how unavoidable it is to accidentally clip into objects, which is probably another reason why Frictional added the "no collision when grabbed" feature. What's the alternative to accidentally clipping the object inside of you? Having the object accidentally colliding with you, bumping you around, and also making you get caught in doorways because you're also carrying a large object with you, which Frictional probably noticed happening a lot and then decided to remove the annoyance by disabling collision when you hold an object.

As for (low tech) hacking the door with the bottle, on second thought, is not a glitch even using your criteria, which I agree with you on. As we both have said, when Frictional does a poor job matching the texture mapping with the physics, it's expected to either pass through textures or collide with air. If the bottle trick is considered a glitch, then walking past the door by getting right up to the edge of it is also considered a glitch (which it obviously is not) because you are also clipping into the texture.

I think the Chancel wall is a pretty bad example, since there is actually collision (you can't walk back through once you've clipped through, meaning there is actually collision), but just really crappy collision. This is a glitch because the wall can be put into a mechanically unexpected state. It is unexpected that the player can pass through it.

A better example would be some of the walls in the OoB Chamber (sorry, Orb Chamber), where there is absolutely no collision. There is no collision because there is no resistance, you can walk back through, and you don't get any force velocity from walking through them. It looks like Frictional might have forgotten to add physics to them. I don't consider this a glitch, because if Frictional forgot and didn't add collision there, then it would be weird if the wall had stopped you. There are also some small objects in the game that you can pick up which don't have collision either (No, picking them up doesn't give them collision. Wouldn't that be a cool glitch?). Walking right through these objects are also not glitches.

So basically I'm going to start using the bottle trick in runs now.

[quote]... I also held up the barrel rather than clipping into it which I didn't think was problematic.[/quote]
Oh, my bad. I guess I recalled wrong then, however I still think there's a chance that the barrel clipped into you just before you died. This just adds to my point about how unavoidable it is to accidentally clip into objects, which is probably another reason why Frictional added the "no collision when grabbed" feature. What's the alternative to accidentally clipping the object inside of you? Having the object accidentally colliding with you, bumping you around, and also making you get caught in doorways because you're also carrying a large object with you, which Frictional probably noticed happening a lot and then decided to remove the annoyance by disabling collision when you hold an object.

As for (low tech) hacking the door with the bottle, on second thought, is not a glitch even using your criteria, which I agree with you on. As we both have said, when Frictional does a poor job matching the texture mapping with the physics, it's expected to either pass through textures or collide with air. If the bottle trick is considered a glitch, then walking past the door by getting right up to the edge of it is also considered a glitch (which it obviously is not) because you are also clipping into the texture.

I think the Chancel wall is a pretty bad example, since there is actually collision (you can't walk back through once you've clipped through, meaning there is actually collision), but just really crappy collision. This is a glitch because the wall can be put into a mechanically unexpected state. It is unexpected that the player can pass through it.

A better example would be some of the walls in the OoB Chamber (sorry, Orb Chamber), where there is absolutely no collision. There is no collision because there is no resistance, you can walk back through, and you don't get any force velocity from walking through them. It looks like Frictional might have forgotten to add physics to them. I don't consider this a glitch, because if Frictional forgot and didn't add collision there, then it would be weird if the wall had stopped you. There are also some small objects in the game that you can pick up which don't have collision either (No, picking them up doesn't give them collision. Wouldn't that be a cool glitch?). Walking right through these objects are also not glitches.

So basically I'm going to start using the bottle trick in runs now.

Gantor

2016-03-15 01:44:04 pm

Quote:

A better example would be some of the walls in the OoB Chamber (sorry, Orb Chamber), where there is absolutely no collision. There is no collision because there is no resistance, you can walk back through, and you don't get any force velocity from walking through them. It looks like Frictional might have forgotten to add physics to them. I don't consider this a glitch, because if Frictional forgot and didn't add collision there, then it would be weird if the wall had stopped you.

Even if Frictional forgot to add collision there, I would still consider it a glitch. Being out of bounds, even if it is due to a design oversight, is unintentional, undesirable, and mechanically unexpected.

Quote:

There are also some small objects in the game that you can pick up which don't have collision either (No, picking them up doesn't give them collision. Wouldn't that be a cool glitch?). Walking right through these objects are also not glitches.

This is an excellent argument.

I am afraid that any standard that I come up with is doomed to failure because it necessarily relies upon subjective criteria. And if the rules could be made completely firm, we would be following the letter of the law but not the spirit. Since I don't see any way around this, I am running with the current stated criteria also. If we're going to do that then I want to give a fuller explanation in order to build a better definition and clear up any ambiguities.

Programmatically, objects are collections of properties which together define a discrete thing. These properties may include the location, size, texture, velocity, status, and many other characteristics of that thing. It is the engine's job to manipulate these properties, calculate their interactions, and correctly represent their current state. These calculations almost always rely upon these properties being bounded. That means that there is a range of values a property can have which the engine expects. Anything outside of that range will not be handled correctly because it is mechanically unexpected. This situation, when unintentional, is what I have proposed to define as a "glitch". Virtually any property of an object can enter an unexpected "glitched" state. And just because it is easy, doesn't mean it is expected.

Some examples of unexpected states (not necessarily relating to Amnesia):
String limits - Some glitches rely upon setting string values to be longer than intended, or to use unexpected characters.
Negative values - Some values are not generally intended to have negative values such as health, mana, or status.
High values - Other values have upper bounds which are not intended to be exceeded. This includes size, velocity, etc.
Location coordinates - Objects are not generally intended to go outside of the expected range of the level. Also when one solid object intersects with another one, the locations of those objects are contradictory.

For our purposes, the game itself should be seen as an object. It has its own properties which define its state and these properties have expected bounds. Some examples of such properties are number of enemies, current level, filenames, &c. Manipulating these properties outside of their bounds is also glitching. An example of this would be level manipulation where the game is tricked into loading an incorrect level or loading properties of multiple levels simultaneously.

By these criteria, exploits and manipulations that do not ever set values into unexpected ranges are legal. An example of this would be RNG manipulation where legal actions are taken to manipulate future "random" events.

Furthermore, the criteria that a glitch is undesirable by the developer is intended to allow for unexpected interactions that the developer ran with anyways. It assumes that the behavior was known and purposefully left in place. And not only was it not fixed, they would not fix it if given the chance. If a trick contradicts intuitive "as intended" gameplay and there is no further proof that the developer knew about it and wanted it, it should be considered undesirable by these criteria. This could be seen as an extension of the intentional/unintentional criteria, as an unintentional strat that the developer approves of in a way becomes intentional ex post facto when it is left in and developed around

I hope that this has helped to explain things. Please let me know if I am still being ambiguous or unclear.

[quote]A better example would be some of the walls in the OoB Chamber (sorry, Orb Chamber), where there is absolutely no collision. There is no collision because there is no resistance, you can walk back through, and you don't get any force velocity from walking through them. It looks like Frictional might have forgotten to add physics to them. I don't consider this a glitch, because if Frictional forgot and didn't add collision there, then it would be weird if the wall had stopped you. [/quote]
Even if Frictional forgot to add collision there, I would still consider it a glitch.  Being out of bounds, even if it is due to a design oversight, is unintentional, undesirable, and mechanically unexpected.

[quote]There are also some small objects in the game that you can pick up which don't have collision either (No, picking them up doesn't give them collision. Wouldn't that be a cool glitch?). Walking right through these objects are also not glitches.[/quote]
This is an excellent argument.

I am afraid that any standard that I come up with is doomed to failure because it necessarily relies upon subjective criteria.  And if the rules could be made completely firm, we would be following the letter of the law but not the spirit.  Since I don't see any way around this, I am running with the current stated criteria also.  If we're going to do that then I want to give a fuller explanation in order to build a better definition and clear up any ambiguities.

Programmatically, objects are collections of properties which together define a discrete thing.  These properties may include the location, size, texture, velocity, status, and many other characteristics of that thing.  It is the engine's job to manipulate these properties, calculate their interactions, and correctly represent their current state.  These calculations almost always rely upon these properties being bounded.  That means that there is a range of values a property can have which the engine expects.  Anything outside of that range will not be handled correctly because it is mechanically unexpected.  This situation, when unintentional, is what I have proposed to define as a "glitch".  Virtually any property of an object can enter an unexpected "glitched" state.  And just because it is easy, doesn't mean it is expected.

Some examples of unexpected states (not necessarily relating to Amnesia):
String limits - Some glitches rely upon setting string values to be longer than intended, or to use unexpected characters.
Negative values - Some values are not generally intended to have negative values such as health, mana, or status.
High values - Other values have upper bounds which are not intended to be exceeded.  This includes size, velocity, etc.
Location coordinates - Objects are not generally intended to go outside of the expected range of the level.  Also when one solid object intersects with another one, the locations of those objects are contradictory.

For our purposes, the game itself should be seen as an object.  It has its own properties which define its state and these properties have expected bounds.  Some examples of such properties are number of enemies, current level, filenames, &c.  Manipulating these properties outside of their bounds is also glitching.  An example of this would be level manipulation where the game is tricked into loading an incorrect level or loading properties of multiple levels simultaneously.

By these criteria, exploits and manipulations that do not ever set values into unexpected ranges are legal.  An example of this would be RNG manipulation where legal actions are taken to manipulate future "random" events.

Furthermore, the criteria that a glitch is undesirable by the developer is intended to allow for unexpected interactions that the developer ran with anyways.  It assumes that the behavior was known and purposefully left in place.  And not only was it not fixed, they would not fix it if given the chance.  If a trick contradicts intuitive "as intended" gameplay and there is no further proof that the developer knew about it and wanted it, it should be considered undesirable by these criteria.  This could be seen as an extension of the intentional/unintentional criteria, as an unintentional strat that the developer approves of in a way becomes intentional ex post facto when it is left in and developed around

I hope that this has helped to explain things.  Please let me know if I am still being ambiguous or unclear.