Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Left-Drag MouseLook feels backwards. (unlike all FPSs) #16

Open
kenlane33 opened this issue Jul 11, 2022 · 7 comments
Open

Left-Drag MouseLook feels backwards. (unlike all FPSs) #16

kenlane33 opened this issue Jul 11, 2022 · 7 comments

Comments

@kenlane33
Copy link

  • Left-Drag MouseLook feels Up/Dn and Left/Right backwards. (unlike all FPSs)

  • Right-Drag should also work for MouseLook & WASD activation (Roblox-ers & Unity-ers expectation)

@yoshikiohshima
Copy link
Contributor

Thanks for a comment. The architecture allows to plug in a different interaction so it is a matter of writing one, and people should be able to use a different style depending on the type of the world.

@MarkusGaelli
Copy link

But why using a default contrary to the expectations of users, me included?

@codefrau
Copy link
Member

codefrau commented Aug 20, 2022

But why using a default contrary to the expectations of users, me included?

Because what we have is not FPS-style "mouse look" which typically does not require holding a mouse button, but rather mobile-style "drag the world" – try it on your phone and you might find that it does feel quite natural.

I agree that proper mouse look is what some people expect so it absolutely should be available, but it's far from being the only obvious choice of mapping pointer motion to world navigation.

@yoshikiohshima
Copy link
Contributor

Yeah, maybe that we can make the default go the opposite from what we provide. In the above I wrote that I mentioned that "depending on the type of the world" but it can even be per avatar setting in the same world.

@codefrau
Copy link
Member

IMHO just flipping the direction is not enough.

With actual mouse look, you can navigate 360 degrees: it's a specialized two-handed navigation mode where one hand controls movement (forwards/backwards/sideways using WASD or arrow keys) and the other hand moves the mouse to control the direction. That requires pointer-capture, the mouse pointer is hidden, so your avatar movement is not limited by the movement of the pointer on the screen.

That is a different mode from when we use our on-screen joystick, which controls both forward/backward and direction change. Using the joystick is mutually exclusive with changing the view angle using mouse-drag, you cannot perform both at the same time, since you only have one mouse pointer.

I'm not sure if the two can coexist or if that would have to be a per-device setting.
Alternatively we could do something similar to multiblaster: pressing WASD would get you into mouse look mode, capture the pointer, and hide the joystick and other UI elements, until you press ESC which would get out of that mode and show those elements again.

IMHO the actual current UX issue is that we implemented WASD navigation without mouse-look, and people are mistaking drag-the-world for that.

@yoshikiohshima
Copy link
Contributor

The behavior at least now different from the time this issue was discussed last time. Let us know how it feels now (on different devices).

@kenlane33
Copy link
Author

Different behaviors for mobile & desktop make sense.
Finger drag for turn on mobile is quite nice.
Standard FPS for desktop/mouse is quite nice.
The tricky bit is that some users may use a laptop trackpad and most solutions give up on detecting that nuance.
Perhaps an options to adjust the behavior into localStorage universally might help?

One note on "mouse/cursor lock":
Once the mouse is down for a desktop, mouse style FPS, it is desirable & common for the cursor to "lock" and disappear as the user continues to turn. Otherwise a 180 degree turn is impossible without repeated mouse up/down/drag cycles.
Example of lock: https://threejs.org/examples/?q=pointer#misc_controls_pointerlock
I would propose (unlike this demo) something more akin to Roblox where the mouse must be continuously down for FPS mouse look to function (like is currently working).

It is still, however desirable to have the cursor "lock" while the mouse is down so FPS desktop can be used continuously without a mouse down/up/drag/down cycle throughout.

Tricky bits / trade offs:
Prevents a drag & drop action in the UI.
Also, a bit of care needs to be taken to avoid absorbing all down, then up, click events.
This means perhaps that a minimum drag distance would need to be detected before hiding & locking the cursor.
On mouse up, the cursor could come back where it had been on initial down, perhaps? Or the center.
There is quite a bit of logic & option in FPS controls!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants