Slam doors open while running

[snatcher]

In the light of a post by Obsttorte, I am opening a dedicated topic for discussion:

Quote

While we are talking about frobbing there is something else that came to my mind. Interacting with doors when running away from the guards (yes, not all of us ghost) is extremely clumsy sometimes. I like to propose that the door behaviour differs if the player is running when frobbing a door in a manner that

• when opening the door it gets opened faster, but propagates a suspicious sound upon doing so
• when closing the door, the closing is in addition delayed. This would mimic that player closes the door behind himself. Note that player interaction via frob is limited to what the player has in front of himself, whereas irl you can easely slam a door close behind you.

This would make the approach of running away, including the usage of tools like the flashbomb, much more useful as compared to just quickloading, which is, in all honesty, currently the best strategy under almost all circumstances.

I thing there is a gain for gameplay here, and the changes should be minor. But I would like to get some feedback, just in case I have overseen an important aspect.

 

Some thoughts of mine, trying to keep existing mechanics in mind:

• The feature should work with regular, standard doors only: avoid sliding / custom / fancy-opening doors...
• Locked doors will stop you to a halt, obviously.
• The door-opening animation must be way faster, obviously.
• Because doors can open towards you, we will probably have to make doors frobable before their time (when running).
• Forget, at least for now, about "slamming doors close" when running. Not only it is difficult to achieve with the mouse and keyboard but it would make AI following you look clumsy (unless they learn to slam doors as well).
• Let's not think about "slam door sounds" for now. Current sounds perhaps work just fine.

And now the fun stuff:

• To keep things simple, slamming a door open would make AI react just like if a heavy object was thrown to a non-carpeted floor in that point.
• AI that is right behind that door gets pushed away (if the door opens towards them, that is). What's important here is that nearby AI get out of your way. We can further elaborate the idea:
  • On duty: AI gets pushed and fall to the floor but stand up right after OR AI gets pushed and goes into "flash-bomb" mode.
  • Civilians: Random possibility for civilians to remain permanently knocked out on the floor?
  • Undead: I don't know. Zombies get torn to pieces?

Discuss!

Edited June 17, 2022 by snatcher

[Obsttorte]

33 minutes ago, snatcher said:

The feature should work with regular, standard doors only: avoid sliding / custom / fancy-opening doors...

Agreed. Wouldn't make much sense on sliding doors anyways, I guess. Another thing to take into account is the size.

33 minutes ago, snatcher said:

The door-opening animation must be way faster, obviously.

That's no problem, it isn't an animation, the doors just rotate.

33 minutes ago, snatcher said:

Because doors can open towards you, we will probably have to make doors frobable before their time (when running).

I disagree here. You cannot open a door faster if it opens towards you. And I fairly doubt players expect this behaviour. In addition, if it only works if the doors open in the direction you are running to it adds a nice little detail both towards the importance of the opening direction for the mapper (beyond aesthetical or logical reasons) and towards the things the player has to consider when keeping track of possible escape routes.

33 minutes ago, snatcher said:

Forget, at least for now, about "slamming doors close" when running. Not only it is difficult to achieve with the mouse and keyboard but it would make AI following you look clumsy (unless they learn to slam doors as well).

I again disagree. The idea was that you frob the open door before passing through it but it starts closing with a minor delay, so it doesn't block you. And compared to the player the ai is intented to be clumsy (they have the bigger weapons in return).

33 minutes ago, snatcher said:

Let's not think about "slam door sounds" for now. Current sounds perhaps work just fine

I think we already have those, or at least sounds we could utilize for this (heavy object falling on wood for example).

33 minutes ago, snatcher said:

To keep things simple, slamming a door open would make AI react just like if a heavy object was thrown to a non-carpeted floor in that point.

The sound can be propagated by the door itself. No issue here.

33 minutes ago, snatcher said:

AI that is right behind that door gets pushed away

Here things get problematic. We had the idea of pushing away the ai in the past, and I created a working prototype. But this is far from perfect.

For the rest: I would not like to add anything that requires new animations or that allows the player to turn doors into weapons. Pushing away ai might anyways be something we scrap, because as far as my original intention has gone it is more about making the whole process of "escaping through a door and shutting it behind you while fleeing" less clumsy and not to outweight a possible player disadvantage that imho doesn't exist.

[snatcher]

4 minutes ago, Obsttorte said:

I disagree here. You cannot open a door faster if it opens towards you. And I fairly doubt players expect this behaviour. In addition, if it only works if the doors open in the direction you are running to it adds a nice little detail both towards the importance of the opening direction for the mapper (beyond aesthetical or logical reasons) and towards the things the player has to consider when keeping track of possible escape routes.

Good point. So it would only work if the door opens in the direction you are running, otherwise: wrong way, mate. Simple, and it prevents other issues. I like it.

 

8 minutes ago, Obsttorte said:

For the rest: I would not like to add anything that requires new animations or that allows the player to turn doors into weapons. Pushing away ai might anyways be something we scrap, because as my original intention has gone it is more about making the whole process of "escaping through a door and shutting it behind you while fleeing" less clumsy and not to outweight a possible player disadvantage that imho doesn't exist.

Fair enough. If anyone is behind that door, or opening the door: wrong way, mate.

[snatcher]

(Always while running) If a door opens in the opposite direction, instead of opining the door the same we could hear a "uh" sound. Not sure if I want that door opening given the case.

Edited June 17, 2022 by snatcher

[Wellingtoncrab]

Sounds potentially cool - I would probably make the “bash door” mechanic a more intentional button combination than simply how quickly a player is moving when they do a frob action as this seems likely to misinterpret the players intentions at some point - I’d be cautious especially since this could result in an alerted ai and that subsequent frustrated reflexive leap towards the quickload key. Maybe like how when you press the use item button while dragging a body to shoulder it you could do this while holding frob on a door to “bash” it open?

Also the speed of movers such as doors is currently in the control of the mission author - so the concept of what is “faster” seems like it could potentially differ quite a bit.

 

[Airship Ballet]

Hunt Showdown lets you immediately open doors while running by melee bashing them, easily the most satisfying (and loud) thing to do. Can't do it by accident that way, but I think it'd be less useful in TDM.

[Obsttorte]

6 hours ago, Wellingtoncrab said:

1. Sounds potentially cool - I would probably make the “bash door” mechanic a more intentional button combination than simply how quickly a player is moving when they do a frob action as this seems likely to misinterpret the players intentions at some point - I’d be cautious especially since this could result in an alerted ai and that subsequent frustrated reflexive leap towards the quickload key.
2. Maybe like how when you press the use item button while dragging a body to shoulder it you could do this while holding frob on a door to “bash” it open?
3. Also the speed of movers such as doors is currently in the control of the mission author - so the concept of what is “faster” seems like it could potentially differ quite a bit.

 

1. That's definetely something that needs consideration. The idea was, though, that the door opens faster if the player is running at it. I am not sure if players usually tend to run through the mission all the time.
2. That would go against the intention. It is not about bashing it open for the sake of bashing (the thread title may imply this). The idea is to speed up the progress of getting through a door when fleeing and to be able to close it behind you with a minimal chance of hindering yourself, something that doesn't work well atm. Having to hold the frob button would slow down the progress.
3. I had a factor in mind. So like the door opens 50% faster or twice as fast. This way it would still depend on the settings the mapper applied.

5 hours ago, Airship Ballet said:

Hunt Showdown lets you immediately open doors while running by melee bashing them, easily the most satisfying (and loud) thing to do. Can't do it by accident that way, but I think it'd be less useful in TDM.

Yeah, as mentioned above not my intention. Guessing from the thread title and @snatcher's initial post their seem to be two different ideas existing on what we are talking about, so I would like to clarify.

• My idea that I brought up in the other thread was to 1. allow faster door opening on running (with the downside of creating some noise) and 2. allow to close a door behind you after having ran through by letting the door react delayed to the player frob (so you frob it while it is still in front of you, but once it starts closing you have already passed it)
• The other idea and a gameplay mechanic to be found in quiet some other, mostly more action oriented, games is to slam a door open, normally for the purpose to surprise the enemies inside, get inside fast or to bash away anyone standing directly behind the door and knocking him out. This is NOT what I had in mind.
• Pushing whoever stands behind the door away from it when fast opening so the door doesn't get blocked by the ai is something that might be worth discussing, although I don't consider it necessary.

[snatcher]

2 hours ago, Obsttorte said:

[...] allow to close a door behind you after having ran through by letting the door react delayed to the player frob (so you frob it while it is still in front of you, but once it starts closing you have already passed it)

I don't see any practical use of quickly opening doors other than to allow for a dynamic and exciting run away, chase or pursuit. And in these cases it makes sense that some kind of mess is left behind. Therefore I am not sure doors should close automatically considering:

1. The fact that the door remains open is the natural outcome mainly because the player didn't trigger any action in any other direction. Any different and it will become a game mechanic that players must learn and get used to.

2. Following AI could get stuck by the very first door breaking a dynamic chase too soon

Edited June 18, 2022 by snatcher

[thebigh]

Self-closing doors are very atmospheric if it's a horror themed mission. It can add a bit of subtle scariness to the level.

Other times you may want to close doors because this also shuts the visportals they're in; your frame rates will thank you.

[Obsttorte]

@snatcher@thebighI never mentioned self-closing doors nor is this something I would like to see set as a standard. It's a bit pointless discussing possible gameplay additions if you don't read carefully.

2 hours ago, Obsttorte said:

allow to close a door behind you after having ran through by letting the door react delayed to the player frob (so you frob it while it is still in front of you, but once it starts closing you have already passed it)

I think this statement made it pretty clear that the door is not supposed to close on itself, but to let it react delayed if the player frobs it while running. The whole argumentation behind this (beside gameplay implications) that I brought up in the other thread is that irl you are indeed able to close a door behind you, whereas in TDM you can only interact with things in front of you. This is an unnecessary limitation imho considering that one of the strengths the player has opposed to the ai is his agility. Also note that this will still require some timing from the player, as the intention is not to let the door wait for the player. If he frobs it too soon, he will block himself, too late, and he may miss it (the door will not be frobhilighted anymore once the player presses the frob key). Obviously this requires some fine-tuning.

[thebigh]

I thought it was an interesting tangent to the conversation but OK.

[Airship Ballet]

Yeah, I was going off the thread title, which seems not to be in the spirit of the actual quote in the post. 

I do think bashing doors open is a great dramatic tool that makes the player feel cool, urgent and dynamic, and does have a place in the rare cases you're being pursued without save scumming.

Opening doors faster without bashing is a good idea, and having them close behind you would be handy, but as with anything automatic in games like this a timer would probably be too quick for some people. Maybe auto closing when the player is x units away from the door in any direction after frobbing? It would work either way when being chased, because at present AI stop for a calendar month to open doors.

[Wellingtoncrab]

I understood the intention very clearly and am not coming from a point of confusion regarding the thread title - my point is instead of deciding for the player that since they are running they must want the smash open a door and potentially alert AI they cannot see is to give the player the option to open the door faster in exchange for the added risk whenever they choose.

As the running option does not seem very clean to me when it comes to deciding what a players intentions are, but I am open to being wrong. Areas in TDM can very narrow and serpentine by virtue of needing to be visportaled - to me it seems like players could easily be fleeing but not able to maintain momentum up through a door and I know I usually stop myself before opening one. It just seems likely to me players will experience situations where they won’t get the bash when they want it and will end up doing it when they don’t with this method.

I do also think there is more potential for other interesting uses of a mechanic if you allow it to be accessed from an additional key press when a door is opening. Say we could also give a locked door the spawnarg “forcible” and maybe the player has to choose between finding a key or forcing a door with the new bash mechanic and alerting the guards. 

[Obsttorte]

46 minutes ago, Wellingtoncrab said:

As the running option does not seem very clean to me when it comes to deciding what a players intentions are, but I am open to being wrong.

That's why in return I asked whether players tend to run through missions or when approaching doors. As the game is about sneaking I would guess that most of the time they either move with normal speed upright or crawling fast. Accidently alerting ai should be off the table when you are running around the whole time.

48 minutes ago, Wellingtoncrab said:

It just seems likely to me players will experience situations where they won’t get the bash when they want it and will end up doing it when they don’t with this method.

I see the issue, but I don't understand why you expect it to exist. I have to make a prototype once I find the time, but I consider issues like this unlikely.

49 minutes ago, Wellingtoncrab said:

Say we could also give a locked door the spawnarg “forcible” and maybe the player has to choose between finding a key or forcing a door with the new bash mechanic and alerting the guards.

That's what the lockpicks are meant for, and even those are useless most of the time if the mapper decides so (like they do most of the time). It's is therefore doubtable whether mappers would use this new feature, which they first had to be aware of, and whether players would use this as they can't know which missions uses them and which doors are bashable and which not. This seems to be a huge source of confusion and frustration considering there is almost no gain and we already have, as mentioned, other means for the player to open the door (In thief wooden doors could be opened with the sword and I think this feature exists in TDM, too, although barely used by the mappers).

I am really opposed into implementing something that everyone does as he likes with not much potential gain, considering that something as fundamental as door behaviour should be consistent among missions.

54 minutes ago, Wellingtoncrab said:

I understood the intention very clearly and am not coming from a point of confusion regarding the thread title

You weren't meant btw. My point was that the title by snatcher and the points he brought up implies that he had a different idea of this door opening feature then I had, despite quoting me in the op. I just wanted to clarify what my ideas are as most likely I am the one to implement it, and my experience tought me that most of the opposition I am facing is against stuff I never wanted to add, but that got brought up during the discussion.

 

So to sum things up:

• I'll see if I can setup a test map with a rough proof of concept to illustrate what I mean and to see whether the potential issues you've brought up arose.
• We can further discuss on whether enhancing this feature makes sense, although, as this was originally brought up in a thread dealing with object manipulation, I think is beyond the scope. But others may agree with you, so in the end it is not my decision. We'll see.

[Wellingtoncrab]

Fair enough. I don’t necessarily agree there isn’t room for another method of opening locked doors given how dull lockpicking kind of is and I don’t think it’d be frustrating provided there is no penalty for attempting to force a door that is locked and can’t be forced.

I do agree that it may be beyond the scope of the discussion and that teaching players to do anything new is a potential point of confusion (this includes teaching them this running bash technique and the penalty for it).

I interpreted the thread as wanting feedback to flesh out the idea, but it seems there is something already clearly in mind and it wasn’t my intention to backseat drive - so I will withdraw any further comments.

[Obsttorte]

@WellingtoncrabIt wasn't my intention to discourage you in giving feedback, it is appreciated. But if you give feedback you will get feedback on that, too. And even though I can't be sure as 90% of the interhuman communication is non-verbal, and this part is obviously missing when discussing in a forum, but the last paragraph of yours reads a bit passive-aggressive to me.

I don't think that this is helpful to anyone, especially as I have already stated that the idea of enhancing the feature, for example by allowing to trigger it via other means as described by you is not completely of the table, but requires some additional upvotes. Otherwise I am simple not convinced it is a necessary or a positive addition. But again, I do not decide this on my own.

[stgatilov]

I think you won't get a smooth run anyway, because when a door opens to your side, you often block it accidentally. And avoiding that it quite complicated without forcing animations onto player.

[Wellingtoncrab]

19 minutes ago, Obsttorte said:

last paragraph of yours reads a bit passive-aggressive to me.

Not my intention - as I said I have no desire to backseat drive on your feature if you are at a point you need to prototype it. Ideas are cheap and plentiful but most of us aren’t going to be able to meaningly contribute to implementing them. I was merely saying I wasn’t trying to waste anyones time as it seems like you already have a clear picture what you want to do and I am more interested in seeing that than diluting the concept with more random ideation.

[Obsttorte]

1 hour ago, stgatilov said:

I think you won't get a smooth run anyway, because when a door opens to your side, you often block it accidentally. And avoiding that it quite complicated without forcing animations onto player.

If the door opens to your side, it will behave like always. It is intented to open faster when opening away from you.

45 minutes ago, Wellingtoncrab said:

Not my intention - as I said I have no desire to backseat drive on your feature if you are at a point you need to prototype it. Ideas are cheap and plentiful but most of us aren’t going to be able to meaningly contribute to implementing them. I was merely saying I wasn’t trying to waste anyones time as it seems like you already have a clear picture what you want to do and I am more interested in seeing that than diluting the concept with more random ideation.

Then I misinterpreted that. Sorry.

[stgatilov]

52 minutes ago, Obsttorte said:

If the door opens to your side, it will behave like always. It is intented to open faster when opening away from you.

I don't think such distinction will do any good.
I think it is better to open equally faster regardless of direction. Thief is in a hurry, he pushes or pulls the door with full force to make it open faster.

[snatcher]

Opening a door towards you will not work. At least, organically. You can clearly foresee the problems if you try in-game now. For it to work you must be able to frob it 3, 4, 5 meters ahead of time. Or the door must open in a nano second. Or the door must become transparent to the player. Otherwise you will get stuck. Bottom-line is that it requires an unrealistic gimmick of some kind.

On the contrary, quickly opening doors when doors open in the direction you are going should be pretty easy to implement. the only gimmick, which is realistic, is that the door opens faster not to get you stuck.

I think all we need as a first version of the prototype is:

• You are running, the door isn't locked and it opens in the right direction: open the door faster
• You are running, the door isn't locked and it opens in the opposite direction: Don't open the door! whisper a "damn it" instead (let me decide what to do).

Edited June 18, 2022 by snatcher

[Obsttorte]

@snatcherWhy should it not open into your direction? It does so now. I agree that it will probably not work well and it is also counterintuitive that fast opening would work with a door opening towards the player, but I rather not implement something that restricts the players abilities of interacting with his surroundings compared to how it is now. Especially as the whole idea was the exact opposite.

[snatcher]

I am trying to help and right now I am in mode: "what's the absolute minimum we (you) need to have something that can be considered full".

On your question, you are fleeing in this direction and go for this door. What's the optimal outcome...?

...to prevent the inevitable and keep this new dynamic engaging?

Because, perhaps, on a second thought you'd rather pass and keep going straight.

Edited June 18, 2022 by snatcher

[thebigh]

Yeah... in future I need to be more careful in making sure the doors open the correct way. That one should swing into the little store room, not out into the hallway.

[Obsttorte]

As promised here is the first proof of concept. Currently it doesn't distinguish between the different sides the player is approaching from. Whether it gets added would depend on how your opinions are, as after testing the setup I am undecided on that matter.

https://www.mediafire.com/file/yqu0xf9bx3035pi/fastdoor.pk4/file