Jump to content
The Dark Mod Forums

Looking and listening through a keyhole


grayman

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

 

  • 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.

Link to comment
Share on other sites

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 by chakkman
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 


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 :D

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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

 

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D)

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

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 :D)

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...