Looking and listening through a keyhole

[duzenko 659]

I would be happy with an eye pictogram below the door handle, maybe shining or pulsating color.

[Springheel 4645]

A light-beam doesn't make much sense to me if the room beyond is dark and might be hard to see if the player is in a bright area. Also wouldn't look great while the door is moving.

Floating icons definitely do not suit our minimalist HUD design.

 

Something could be done to the lockplate texture during frob-- a pulsing frob effect or making the keyhole itself outlined or something. This would alert the player to something unusual about the lock. Maybe a large keyhole that itself pulses or translates softly--if done right it could look like subtle movement visible through the keyhole.

 

It would require a separate lockplate entity with a unique texture, however, and mappers would be limited to using that entity. It's also not intuitive how mappers would apply the same indicator to other places they might want to use this behaviour, like cracks between boards or something.

 

b - position yourself in front of the door, looking at the door

 

c - crouch

 

 

One other thing...what if it's an especially tall door, or the mapper wants to use the same behaviour for a broken window or something higher? There would be no intuitive reason to crouch in those cases. Would it be possible to trigger the behaviour as long as the player is leaning forward, facing the entity, and his head is within X of the entity?

[grayman 2974]

A light-beam doesn't make much sense to me if the room beyond is dark and might be hard to see if the player is in a bright area. Also wouldn't look great while the door is moving.

Floating icons definitely do not suit our minimalist HUD design.

Agreed.

 

Something could be done to the lockplate texture during frob-- a pulsing frob effect or making the keyhole itself outlined or something. This would alert the player to something unusual about the lock. Maybe a large keyhole that itself pulses or translates softly--if done right it could look like subtle movement visible through the keyhole.

Can these effects be handled by the materials used in the model, so there's no code support?

 

It would require a separate lockplate entity with a unique texture, however, and mappers would be limited to using that entity.

That's the plan. Skins could be used for variability. We shouldn't use existing models because those have already been used in released missions and could cause confusion if reused for the new keyhole.

 

It's also not intuitive how mappers would apply the same indicator to other places they might want to use this behaviour, like cracks between boards or something.

 

One other thing...what if it's an especially tall door, or the mapper wants to use the same behaviour for a broken window or something higher? There would be no intuitive reason to crouch in those cases. Would it be possible to trigger the behaviour as long as the player is leaning forward, facing the entity, and his head is within X of the entity?

The intent was for door keyholes, so the code support looks for the new keyhole entity bound to a door. Since handles and handle plates are usually waist high, it makes sense that the player should be crouched and leaning against the door when looking through the keyhole. Crouching allows me to differentiate between leaning forward against a door to overhear what's on the other side and crouch-leaning against a door to see what's on the other side.

 

Looking through cracks and broken windows: there's no visible entity for the player to see, so I'm not sure how he knows he can "see through".

 

The behavior can be changed to handle tall doors. I'll look into generalizing it to handle doors of any size.

 

In my not-yet-written specs for Arcturus, was going to ask for a single model that provides a handle plate for both sides of the door and that the plates fit a door that's 4 units thick, since that's the size of most doors.

 

Should we handle doors that are thicker/thinner than that? That would require a model for each thickness. I don't want to go to a "single plate on each side" design because it's twice as much work for a mapper and adds twice as many entities.

[Springheel 4645]

Can these effects be handled by the materials used in the model, so there's no code support?

 

 

Yes, materials can create unique frob-effects, and presumably the plate would froblight along with the door.

 

Looking through cracks and broken windows: there's no visible entity for the player to see, so I'm not sure how he knows he can "see throug

 

 

True. It would be up to mappers to do something to let players know about that. Interestingly, T4 used light shafts for this exact purpose.

 

Since handles and handle plates are usually waist high, it makes sense that the player should be crouched and leaning against the door when looking through the keyhole.

 

 

Even on regular-sized doors, there could be situations where the player might be closer to the lockplate while standing--like a door at the top of some stairs.

 

 

Crouching allows me to differentiate between leaning forward against a door to overhear what's on the other side and crouch-leaning against a door to see what's on the other side.

 

 

Can't the code differentiate between a forward lean and a sideways lean? They are different keystrokes after all.

 

Currently the player can listen through doors while crouched, can't they? We don't want to remove that ability.

 

Should we handle doors that are thicker/thinner than that? That would require a model for each thickness. I don't want to go to a "single plate on each side" design because it's twice as much work for a mapper and adds twice as many entities.

 

 

That's a tricky one.

 

I think the best option is to provide both--a two-sided one that can be used by default, and single ones that can be used by mappers who know what they're doing. I'm assuming that's just a visual difference, and has no impact on how the entity itself works?

[grayman 2974]

For a non-keyhole "peek" ...

 

• Provide "keyhole" entity models that are a crack or a hole or whatever.
• Put a spawnarg on the entity that says what it is: keyhole, crack, hole, whatever (or get this from the model used), and use a different mask on the screen presentation of what the player sees. (Can't show a keyhole if we're looking through a crack.)
• Mapper highlights the entity any way he chooses, if at all. Anything beyond texture effects is not provided by the code.

 

For closeness to the entity ...

 

• Just implemented requiring the player's eyes being within "x" units of the entity origin.

 

Leaning ...

 

• Yes, we can tell the difference between leaning forward/left/right. Leaning forward lets you peek; the others do not.
• Leaning players hear what's on the far side of the door/broken wall/broken window.
• Atm this requires leaning against a door. I'd have to change that to leaning against a door OR leaning in the vicinity of a keyhole entity, since with cracks it's not given that a door is involved.

[Springheel 4645]

 

• Yes, we can tell the difference between leaning forward/left/right. Leaning forward lets you peek; the others do not.
• Leaning players hear what's on the far side of the door/broken wall/broken window.
• Atm this requires leaning against a door. I'd have to change that to leaning against a door OR leaning in the vicinity of a keyhole entity, since with cracks it's not given that a door is involved.

 

 

 

Does leaning forward let you hear through a door currently? I've actually never tried it.

 

In the current implementation, is it the new entity that triggers your ability to hear on the other side, or is it just using the default (assuming the above is true) leaning behaviour ?

 

If the latter, I don't think it necessary to let the player hear through cracks in a wall, unless it's easy to do.

[grayman 2974]

Yes, leaning forward lets you hear.

 

No, the keyhole entity is not required.

[chakkman 389]

Sorry if that already has been asked (or replied): Do you plan on implementing something similar to Dishonored? In the sense of, when you spy through the keyhole, you can move the "camera" up, down, left and right to some degree? Of course only as much as the visible area spying through a keyhole would allow. Would be really great, as a simple single view angle might be a bit restrictive, and wouldn't let you see much.

Edited September 23, 2018 by chakkman

[grayman 2974]

Sorry if that already has been asked (or replied): Do you plan on implementing something similar to Dishonored? In the sense of, when you spy through the keyhole, you can move the "camera" up, down, left and right to some degree? Of course only as much as the visible area spying through a keyhole would allow. Would be really great, as a simple single view angle might be a bit restrictive, and wouldn't let you see much.

 

I wasn't.

 

Obs' proof of concept allowed for this, but the keyhole mask warped to the point where it didn't look right to me.

 

I'd like to be able to allow for mouse movement as you describe w/o warping the mask.

 

I'll investigate.

[grayman 2974]

It looks like we're moving toward a generalized listen/peek entity that can be used on doors or cracks, with different models and spawnargs for different situations.

 

This is more complex than I'd envisioned, but I think it's possible.

[Springheel 4645]

Yes, leaning forward lets you hear.

 

No, the keyhole entity is not required.

 

I see. So the extra functionality provided by the new entity is just the visual component?

 

If so, I would leave the entity as entirely visual. In the majority of cases, mappers will use it on entities that are already doors, or that can easily be turned into doors, which would provide the sound functionality by default.

 

If mappers want to use it in cases that are not easily turned into doors (ex. cracks in a stone wall) no sound is provided (there's no particular reason why someone should expect to hear through a crack in a wall).

 

If mappers are using it in unconventional ways (eg, non-keyhole ways) it is up to them to provide a visual clue to the player to indicate where it is possible to look through. A light shaft is one possibility.

[Obsttorte 1504]

 

Obs' proof of concept allowed for this, but the keyhole mask warped to the point where it didn't look right to me.

Well, the warp could always be made more restrictive. But I think in general it is to be expectable that you have a bigger fov when looking through a keyhole straight ahead instead of angled.

 

Yes, leaning forward lets you hear

Never noticed that either, and I am not sure whether it makes much sense. I always thought of the sideway leaning as if I would put my ear against the door letting me hear what's on the other side better, not just the fact that my head is closer to the door.

 

I don't see how banging my forehead against a door will help me hearing what's on the other side

[grayman 2974]

I don't see how banging my forehead against a door will help me hearing what's on the other side

 

Yeah, you're right. Makes no common sense.

 

I double-checked 2.06 and leaning forward against a door does let you hear what's on the other side. I thought that's what the code was saying when I read it.

 

Do we want to do away with that from 2.07 onward? I don't see how it would harm existing missions.

[Springheel 4645]

As I recall, eavesdropping by leaning was a happy accident. Leaning actually moved the player's ear to the other side of the door naturally, giving us the functionality we wanted without doing anything. We didn't specifically set it up that way, so presumably it just worked regardless of which type of lean was being used. All of our documentation says you have to lean to the side though, so I don't think it would hurt anything in existing missions to remove it. What would that do to your feature design though?

[grayman 2974]

The code moves the ear beyond the door, after checking to see if there's space out there. If it were just relying on ear position, you'd only hear what's on the near side.

Removing forward leaning listening is simple.

I would still provide forward leaning listening when peeking through a keyhole, though.

[Springheel 4645]

That sounds like the most robust solution.

[Abusimplea 168]

Maybe, having to decide whether listening (sidelean ear against door) or looking through the keyhole (forwardlean to get eye closer to keyhole) would not be that bad. It makes sense that you can't have your ear and your eyes touching the door at the same time.

Also, you could listen for guards entering your room while looking into another room.

[grayman 2974]

You're going to hear what's on your side of the door as well as what's on the other side of the door.

[grayman 2974]

Since we're expanding the concept of a keyhole you can see/listen through to include wall cracks, I don't want to call the new entity "func_keyhole".

 

My first thought was "func_peephole", but that sounded a bit low-class, so would folks like to make suggestions on what the new entity should be?

 

Thanks.

[VanishedOne 546]

func_spyhole? https://en.wiktionary.org/wiki/spyhole

[Obsttorte 1504]

func_surveyor

func_interceptor

func_watcher

 

Basically anything that avoids the word "hole" (as I imagine sooner or later someone will bind it to an ai's hip and call it func_asshole )

[grayman 2974]

[Dragofer 1416]

func_surveyorBasically anything that avoids the word "hole" (as I imagine sooner or later someone will bind it to an ai's hip and call it func_asshole )

German humour right there.

 

Something I haven't seen yet is discussion of what happens if the door is open? Might make most sense to only enable peeking if the door is i.e. less than 10% open, to simplify the coding.

[grayman 2974]

German humour right there.

 

Something I haven't seen yet is discussion of what happens if the door is open? Might make most sense to only enable peeking if the door is i.e. less than 10% open, to simplify the coding.

 

I expect that the keyhole will act the same whether the door is open or closed, except I don't have to create a second listening position on the far side of the door.

 

I can double-check this after I have a new name for the entity.

[Abusimplea 168]

If you could use it to emulate a spy cam that allows peeping into far away locations, it could be called "func_spycam" - else "func_peephole" is a fine and descriptive name (especially if used on bathroom doors *g*).

Edited September 29, 2018 by Abusimplea