How do you like your doors to function?

[EstrangeNS]

Been working on a game for 6 months now and cant personally decide on which door function to use. What do you guys like?

Open a door by looking at it and pressing a button
or
Open a door by being close enough to it and pressing a button.

They both have their benefits and drawbacks.

EDIT:
Guess i need to clarify.

The game is first-person.
You walk up to the door and become close enough to open it.

Now do you have to be looking at the door to open it or can you be facing slightly to the right but still be able to open the door?
In developer terms. Collision-based door interaction or vision hit-based?

EDIT2 BETTER EXAMPLE EDITION:
Currently (bc I was being lazy and needed it out of the way real quick) my doors have a collision box attached and when you enter the collision box, input (pressing e) to be able to open the door becomes active.
My question (which I'm realizing wasn't explained too well bc I'm not good at that kind of stuff.) is should I switch to a line trace (which would shoot out in front of the player and stop before going so far that interaction would be unrealistic.) to detect the door and allow input, or stick with the collision box system? Im using Unreal Engine btw.

I like the collision system bc it allows the player to close doors behind them without having to turn around and open them without directly looking at them which feels realistic.
I like the line trace method bc it allows you to have doors that are close together and not have them both open when you're trying to open one (Example: two doors on either side of a corner, the collision boxes overlap in the middle.).

EDIT 3 CONCLUSION EDITION:
I've decided on a mix of sorts. It's going to be used for all detection and interaction, not just doors.
Simply put, I'm going to detect if said actor is on screen(check if rendered), then check if the distance is at arm's length, then add a preference that always chooses the closes actor (and maybe even the actor that's closest to the center of the screen).
This will avoid the awkwardness of trying to hit small objects with the line trace at the center of the screen.
Also, I think I might add an icon that appears on the actor to signify what actor you'll be interacting with when you press E.
Thank you all for commenting and voting! helped a bunch. I'll see you when the game releases, or if I need input again.

 

[Tompte]

I don't understand the question. You're not giving us much information. What kind of game are we talking about? Is looking at something and pressing a button a normal way to interact with it?

From a game design perspective you should open the door whenever the player shows clear intent to open the door. I'd argue looking at a door is not the same as wanting to open it, though it would depend on the game.

 

[EstrangeNS]

Guess i need to clarify.

The game is first-person.
You walk up to the door and become close enough to open it.

Now do you have to be looking at the door to open it or can you be facing slightly to the right but still be able to open the door?
In developer terms. Collision-based door interaction or vision hit-based?

 

[Tompte]

I see.
In that case, what Xanado said.

 

[Rafster]

Near the door

 

[Saki_Sliz]

Depending on the engine you are using, it probably has a ray trace feature. Raytracing (not the rendering technique) you would use for either distance checking or visibility checking (you would have to make a mesh of the ground and obstacles). If not, or you can't figure out how to get it to work how you want it, rather than implement your own raytracing, which is a pain, it is simpler to do a proximity code. I recommend making a static parent class (I'm assuming C# but should also work with C++ if you are using UE), where each child call's a parent static method (function) to register each door as it is made (built as the level is loaded and started), and use the parent class as a door manager, which simply collects all the refences to children in an array, and does a loop through them to check proximity (I'm amssuing you don't have massive levels with 100's of doors, if you did you would have to break the world into grids and only do calculations in a grid to better optimize the parent class's update behavior).

You would still use a proximity check no mater what, because only the doors near by you want to check for things like, vision, which you can just bullshit by doing a dot product with the camera vector and the (camera position-door position) vector, and set a limit (0.5 = 45 degree from center of vision). And since you have a refence to the child, you can instruct the child to 'glow' to indicate if the door is in range of activation.

Vision and button to be tactile (immersive)
Proximity and automatic for speed and less cumbersome.
Vision and automatic (no button) tends to be annoying since you are always looking around.
vision and automatic but with proximity as well tends to be pretty balanced and natural, but wierds people out (how does the door know I'm looking at it, this can break immersion, and gets in the way if in combat you have to back up into the door.)

Is this tarkov where you want opening doors to be stressful (immersive), or do you want to focus on the FPS aspect (doors are automatic and proximity based). you could jump back in forth between combat mode and story mode parts of the game.

 

[RedPillBlues]

Will always be the best doors

 

[EstrangeNS]

Depending on the engine you are using, it probably has a ray trace feature. Raytracing (not the rendering technique) you would use for either distance checking or visibility checking (you would have to make a mesh of the ground and obstacles). If not, or you can't figure out how to get it to work how you want it, rather than implement your own raytracing, which is a pain, it is simpler to do a proximity code. I recommend making a static parent class (I'm assuming C# but should also work with C++ if you are using UE), where each child call's a parent static method (function) to register each door as it is made (built as the level is loaded and started), and use the parent class as a door manager, which simply collects all the refences to children in an array, and does a loop through them to check proximity (I'm amssuing you don't have massive levels with 100's of doors, if you did you would have to break the world into grids and only do calculations in a grid to better optimize the parent class's update behavior).

You would still use a proximity check no mater what, because only the doors near by you want to check for things like, vision, which you can just bullshit by doing a dot product with the camera vector and the (camera position-door position) vector, and set a limit (0.5 = 45 degree from center of vision). And since you have a refence to the child, you can instruct the child to 'glow' to indicate if the door is in range of activation.

Vision and button to be tactile (immersive)
Proximity and automatic for speed and less cumbersome.
Vision and automatic (no button) tends to be annoying since you are always looking around.
vision and automatic but with proximity as well tends to be pretty balanced and natural, but wierds people out (how does the door know I'm looking at it, this can break immersion, and gets in the way if in combat you have to back up into the door.)

Is this tarkov where you want opening doors to be stressful (immersive), or do you want to focus on the FPS aspect (doors are automatic and proximity based). you could jump back in forth between combat mode and story mode parts of the game.

Currently (bc I was being lazy and needed it out of the way real quick) my doors have a collision box attached and when you enter the collision box, input (pressing e) to be able to open the door becomes active.
My question (which I'm realizing wasn't explained too well bc I'm not good at that kind of stuff.) is should I switch to a line trace (which would shoot out in front of the player and stop before going so far that interaction would be unrealistic.) to detect the door and allow input, or stick with the collision box system? Im using Unreal Engine btw.

I like the collision system bc it allows the player to close doors behind them without having to turn around and open them without directly looking at them which feels realistic.
I like the line trace method bc it allows you to have doors that are close together and not have them both open when you're trying to open one (Example: two doors on either side of a corner, the collision boxes overlap in the middle.).

 

[Jofur]

I'd say go with the Raycast method. Using a collider works better for third person games(though even then you'd probably want to make sure the camera/character is also facing it), but for first person it would be awkward. Partly because pretty much no first person games do it, but also because it might create unexpected behaviors. For example if the player wants to talk to a person but they keep opening a door instead because the character was close to it.

Taking half a second to turn around and close a door isn't gonna annoy anyone.

 

[EstrangeNS]

I'd say go with the Raycast method. Using a collider works better for third person games(though even then you'd probably want to make sure the camera/character is also facing it), but for first person it would be awkward. Partly because pretty much no first person games do it, but also because it might create unexpected behaviors. For example if the player wants to talk to a person but they keep opening a door instead because the character was close to it.

Taking half a second to turn around and close a door isn't gonna annoy anyone.

Yeah, I've decided on a mix of sorts. It's going to be used for all detection and interaction, not just doors.
Simply put, I'm going to detect if said actor is on screen(check if rendered), then check if the distance is at arm's length, then add a preference that always chooses the closes actor (and maybe even the actor that's closest to the center of the screen).
This will avoid the awkwardness of trying to hit small objects with the line trace at the center of the screen.
Also, I think I might add an icon that appears on the actor to signify what actor you'll be interacting with when you press E.
Thank you all for commenting and voting! helped a bunch. I'll see you when the game releases, or if I need input again.

 

[Saki_Sliz]

Currently (bc I was being lazy and needed it out of the way real quick) my doors have a collision box attached and when you enter the collision box, input (pressing e) to be able to open the door becomes active.
My question (which I'm realizing wasn't explained too well bc I'm not good at that kind of stuff.) is should I switch to a line trace (which would shoot out in front of the player and stop before going so far that interaction would be unrealistic.) to detect the door and allow input, or stick with the collision box system? Im using Unreal Engine btw.

I like the collision system bc it allows the player to close doors behind them without having to turn around and open them without directly looking at them which feels realistic.
I like the line trace method bc it allows you to have doors that are close together and not have them both open when you're trying to open one (Example: two doors on either side of a corner, the collision boxes overlap in the middle.).

That works as well.

For me, it sounds like you are asking what people prefer, and that's fine.

However, if it's my project, I worry about details like, how I want to present the game, what is the vibe or the feeling. is it FPS mechanic, or is it strongly FPS combat focused, and even if its combat focused, what kind of experience do I want the players to have, how important are doors (how dangerous is it to open a door). the more dangerous the door is the more of a proccess I would make it to open a door, to emphasize the door, but if you are just running aronud shooting people on a larger map, door's aren't that special, and I'd just do a velocity and proximity check (the door only opens if it looks like your character is running towards it and get near, opening with enough time depending on character speed).

Yeah, I've decided on a mix of sorts. It's going to be used for all detection and interaction, not just doors.
Simply put, I'm going to detect if said actor is on screen(check if rendered), then check if the distance is at arm's length, then add a preference that always chooses the closes actor (and maybe even the actor that's closest to the center of the screen).
This will avoid the awkwardness of trying to hit small objects with the line trace at the center of the screen.
Also, I think I might add an icon that appears on the actor to signify what actor you'll be interacting with when you press E.
Thank you all for commenting and voting! helped a bunch. I'll see you when the game releases, or if I need input again.

sounds good, good luck!

 

[Jofur]

Yeah, I've decided on a mix of sorts. It's going to be used for all detection and interaction, not just doors.
Simply put, I'm going to detect if said actor is on screen(check if rendered), then check if the distance is at arm's length, then add a preference that always chooses the closes actor (and maybe even the actor that's closest to the center of the screen).
This will avoid the awkwardness of trying to hit small objects with the line trace at the center of the screen.
Also, I think I might add an icon that appears on the actor to signify what actor you'll be interacting with when you press E.
Thank you all for commenting and voting! helped a bunch. I'll see you when the game releases, or if I need input again.

I'm not overly familiar with UE, but isn't there some way to do the Unity equivalent of a "SphereCast"? I.E rather than shooting our ray you are shooting out a sphere and as soon as it collides with something it's a hit. It's what I usually use in situations like these, that or I just make the colliders around interactable objects larger.

You must be registered to see the links