Looking and listening through a keyhole

[grayman]

Now that remote cameras work (2.06) and we can hear sounds from a remote scene (2.07), we come to the question of what the mechanic should be to allow the player to look through a keyhole and both see and hear what's on the other side.

 

For reality, you should be able to look through either side of a keyhole.

 

New keyhole model? New keyhole entity that spawns what it needs to see/hear?

 

Discuss!

[grayman]

I suppose there might be some demand for a new player tool that you could toss and receive sight/sound from wherever it comes to rest.

 

Need mechanics/design for that as well, if there's enough interest.

[peter_spy]

IMO we'll need some kind of camera paired with screen overlay and ability to hear what's on the other side of the door. Games using that feature also offer some limited ability to look around.

[Oktokolo]

A small bot disguised as a rat for remote surveilance would be fun. Guards would probably still get suspicious if acting too brave.

 

But keyhole peeping never felt believable for me in any game (maybe because i tried looking through a room door keyhole in real life). So you would need another player tool for that.

We do already have the game mechanic of opening a door slightly to peep into a room though.

And mappers wanting to give the player the opportunity to look into a room through a closed door used embedded glass or grills for that in the past - wich lead to nice looking doors wich gave a much more open feeling to the world as a byproduct.

[RPGista]

I think any sort of digital screen would look off in TDM's environment. I always saw Thief's technology as half mechanical half magical. Their "AI" and processors come from magical means, while their bodies operate as steam punk machines. The cameras dont really connect to a survailance room, they "see" you and know you shouldnt be there and sound the alarm, etc. So we would need to be creative with this added feature. Having said that I see no reason not to have a fiberscope kind of tool, that you can put through the cracks of a door, or under it, and look around.

[Bikerdude]

I would love this gameplay option!

[Obsttorte]

In regards to the mechanic of looking through a keyhole, I always thought that using a similar mechanic to the current listening would be a good idea. So that you lean forward (while crouched, so that your head is at the height of the keyhole roughly) to peek thourgh the keyhole, and if you let go of the lean forward button or if you get attacked, view is returned to normal.

 

This would require altering existing door entities, which would however only be worth the effort if mappers would tend to use them. As they aren't even using combined light entities I'm not sure whether it is really worth the effort to search for a common solution and whether it wouldn't be better to only provide the basics and leave the responsibility up to the mapper.

[peter_spy]

In regards to the mechanic of looking through a keyhole, I always thought that using a similar mechanic to the current listening would be a good idea. So that you lean forward (while crouched, so that your head is at the height of the keyhole roughly) to peek thourgh the keyhole, and if you let go of the lean forward button or if you get attacked, view is returned to normal.

 

I don't know about others, but personally I've never ever used lean forward, neither in any Thief games, nor in TDM. I think relying on this is risky, and I'd suggest more familiar convention, like something already established in other games, e.g. holding a key (RMB, Use item key, etc.).

[nbohr1more]

I'm surprised Obs didn't mention his earlier work...

 

http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page-12

 

[Oktokolo]

I don't know about others, but personally I've never ever used lean forward, neither in any Thief games, nor in TDM. I think relying on this is risky, and I'd suggest more familiar convention, like something already established in other games, e.g. holding a key (RMB, Use item key, etc.).

Leaning forward is pretty usefull in TDM. It eases "purse cutting" and chest looting and often allows grabbing well-lit stuff while staying in the shadows. I sometimes also use it for getting a better view from the high ground.

[Obsttorte]

I'm surprised Obs didn't mention his earlier work...

 

http://forums.thedarkmod.com/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/page-12

 

Well, I thought of it as common knowledge

[Springheel]

This would definitely require some kind of visual element to inform the player about which kinds of doors can be peered through and which can't. Also, the control scheme would need to not get in the way of controlling the door, which probably rules out frobbing.

 

 

[Bikerdude]

This would definitely require some kind of visual element to inform the player about which kinds of doors can be peered through and which can't. Also, the control scheme would need to not get in the way of controlling the door, which probably rules out frobbing.

Could we not change the doors from highlighting to just the handles (like in some AA games), and then place a little popup after the handle is frobbed to offer the player the option of selecting keyhole view.

[Oktokolo]

Could we not change the doors from highlighting to just the handles (like in some AA games), and then place a little popup after the handle is frobbed to offer the player the option of selecting keyhole view.

Lol. Trolling like a boss.

[Bikerdude]

Trolling like a boss.

Not at all, I would genuinely like to see if this could be implemented.

 

As well as a very cool gameplay mechanic, if done right could retroactively work on all previous missions.

[Obsttorte]

Could we not change the doors from highlighting to just the handles (like in some AA games), and then place a little popup after the handle is frobbed to offer the player the option of selecting keyhole view.

Probably not due to how the doors work. It would at least require quiet some changes. I am not a fan of changing the door behaviour for already existing missions. Those missions weren't designed with that possibility in mind and our philosophy always was to not make changes that affect exisiting mission in a way that could "break" them (I am stretching the definition a bit here). Therefore I would suggest adding new entities.

 

Almost all doors as well as windows use atdm:mover_door or atdm:mover_door_sliding. I guess we can in a similar fashion create two additional door entities for rotational/translational opening doors that allow for the peeking. Mappers can than choose whether they wan't that feature or not by the choice of the entity, and mappers who wan't to add the possibility to already existing missions afterwards just need to open the map file in an editor and find/replace the entity class.

[Springheel]

Yes, changing the behaviour of doors in existing missions should not be on the table.

 

It will be up to mappers to decide if this becomes a regular feature going forward. I've never really been a fan of keyhole-peeping features, since there's an inverse relationship between what is useful and what is believable when setting the view angle.

 

Without some kind of visually distinctive marker, however, players will have no way of knowing which doors they can look through and which they can't.

[grayman]

Well, I thought of it as common knowledge

 

Obs, do you have a test map that goes with the video?

 

I'd like to see how that works with the 2.06/SVN camera, and whether the work I'm doing makes it easier to implement what you show (or not).

[Obsttorte]

 

Obs, do you have a test map that goes with the video?

Nope, at least not one designed for that purpose. This was just a proof of concept. I can see if I can find the files and pm them to you. Maybe this weekend. (PM me if you think I may have forgotten).

[grayman]

Thanks

[grayman]

Since we want to maintain normal frobbing of doors and handles, how about this proposal:

 

1 - Create a new entity you can bind to a door, in the spot where you'd normally put the handle plate. This entity uses a model that looks different than the current handle plates. It includes an obvious spot where you'd place the handle, and an obvious over-large keyhole. This entity would look the same--and provide the same functionality--on either side of the door it's bound to.

 

2 - If you crouch in front of one of these things, and you're close enough to the door, you're presented with a screen-filling GUI (like the one Obs used in his proof of concept). You can then see and hear what's on the other side of the door.

 

3 - Moving away from the door or standing up returns you to a normal view.

 

Advantages of this:

 

1 - Retains normal door and door-handle frobbing.

 

2 - Provides a visually different clue that the plate's keyhole can be looked through.

 

3 - Doesn't require leaning.

 

4 - Doesn't affect existing maps where it obviously was never used.

 

 

Comments?

[Obsttorte]

 

3 - Doesn't require leaning.

Why is not requiring to lean an advantage? The player also needs to lean towards the side to listen through a door right now. Wouldn't it be bit inconsistent to do it differently now?!

 

Besides that I am fine with your proposal.

[Springheel]

Since we want to maintain normal frobbing of doors and handles, how about this proposal:

 

1 - Create a new entity you can bind to a door, in the spot where you'd normally put the handle plate. This entity uses a model that looks different than the current handle plates. It includes an obvious spot where you'd place the handle, and an obvious over-large keyhole. This entity would look the same--and provide the same functionality--on either side of the door it's bound to.

 

2 - If you crouch in front of one of these things, and you're close enough to the door, you're presented with a screen-filling GUI (like the one Obs used in his proof of concept). You can then see and hear what's on the other side of the door.

 

3 - Moving away from the door or standing up returns you to a normal view.

 

 

One problem I see is that this has the potential to override player control in a way we try to avoid. There are many reasons why a player might approach a door crouched--like trying to stay hidden while lockpicking it--where they might not wish to be sucked into a gui overlay. Additionally, both moving and standing can increase a player's risk of detection, so it's not the best thing to require them to escape an overlay.

 

Asking the player to lean forward is a much better (though not perfect) option, as it is something players are less likely to do for other reasons. It's also intuitive given our eavesdropping controls--if you lean sideways to put your ear to the door, leaning forward to put your eyes to the keyhold would be a reasonable guess. It's also safer and easier for the player to cancel. It does require players being aware of that option though.

 

The player also needs to lean towards the side to listen through a door right now. Wouldn't it be bit inconsistent to do it differently now?!

 

 

This isn't going to change listening behaviour, is it? Is the player going to be able to see AND hear through the keyhole at the same time?

[Oktokolo]

I am playing crouched over 99% of the time and would therefore prefer having to lean forward into a door to use the new feature.

[Obsttorte]

 

This isn't going to change listening behaviour, is it? Is the player going to be able to see AND hear through the keyhole at the same time?

As far as I understood grayman the default behaviour won't be touched. Leaning sideways allows the player to hear through the door, leaning forward (or whatever else we agree on) will allow the player to see and to hear through the door.