[DENIED] Mouse Plugin + Pointer Lock API Update

Some of you might already know the following problem.

You're trying to play a 2D shooting game made with Construct, you see an enemy approaching from the edge of the window aaaaaaand your cursor is off-screen.

Believe it or not, there is actually a way to prevent this from happening and the solution is called: Pointer Lock API*

Why does Construct not support this feature yet?

The simple answer is, it does... but not officially. There is THIS unmaintained and broken plugin but this really shouldn't be the solution.

Mouse locking is a common feature available in both native and web based game-engines and Construct 2/3 should support this too.

I know it probably won't be a high priority feature on the ToDo list but I'd appreciate if it could be a priority at all.

Ashley without keeping you away from working on C3 for too long, would you consider updating the mouse plugin with the Pointer Lock API soon?

*More information can be found

HERE.

The API looks like it's designed for 3D games. For 2D games I'm not clear what the benefit is. You can already go in to fullscreen mode to prevent the mouse cursor leaving the window. There are downsides too: if you hide the real cursor and display it in-game, it has a higher latency so will feel laggier, so it's better to simply change the real cursor with one of the existing actions. Additionally for security reasons you can't just claim pointer lock right off the bat, you have to gain permission for it in a user gesture. It then makes it harder to close the game or multitask, since you are locked inside the game until you exit pointer lock, which I think is slightly obnoxious for casual gaming, especially in a browser.

For 2D games I'm not clear what the benefit is. You can already go in to fullscreen mode to prevent the mouse cursor leaving the window.

As the post states, especially 2D shooters would benefit from this, preventing the user from aiming off-screen (in windowed mode) or go off-screen on multi-screen setups (in fullscreen mode) because browsers don't have an "exclusive fullscreen" feature available yet.

There are downsides too: if you hide the real cursor and display it in-game, it has a higher latency so will feel laggier, so it's better to simply change the real cursor with one of the existing actions.

I'd appreciate your example regarding this. When testing this feature with the demo, I couldn't notice a high latency at all.

Additionally for security reasons you can't just claim pointer lock right off the bat, you have to gain permission for it in a user gesture.

Not a big deal, pretty much all features which alter user inputs or perform major actions on the web (even fullscreen) require permissions of some sort.

Please note that this isn't a requirement inside NW.js at all and the most more advanced games are being developed for that platform.

It then makes it harder to close the game or multitask, since you are locked inside the game until you exit pointer lock, which I think is slightly obnoxious for casual gaming, especially in a browser.

Just deactivate the lock when the user pauses the game or is inside a menu, also not a big deal.

Ashley I'm sure we both could come up with 100+ reasons for/against this feature but I'd appreciate a simple yes or no.

I'd really like to know if I need to get a 3rd party on board or can count on Scirra to add this feature sooner or later.

I think pointer lock should be a standard feature considering how useful it is for games.

I think it is weird when us devs have to feel like we need to get Scirra's permission for developing a game our own way. I know it is Scirra's engine, but why does it feel like you're limiting our options here by trying to convince us we don't need it?

The pointer lock plugin was very useful to me when I had been using it. I haven't used it recently, but if it is broken, then that sucks. We need this feature. Maybe not a high priority, but it is very useful and good to have. If scirra doesn't implement it, then I would hope someone else creates a working plugin.

I think the best way to prevent aiming offscreen when windowed is to go fullscreen, and avoiding aiming off-screen when fullscreen in a multi-monitor setup with some tradeoffs, is enough of a niche to leave to third-party addons.

To see the latency of in-game rendering, simply set a sprite to the mouse position every tick. If you move the mouse around fast you'll see the sprite is not exactly under the mouse, it's a couple of frames behind. Serious players are sensitive to such added latency and would probably prefer to see the real cursor instead. Regular gamers can always spot when a game renders its own cursor rather than using the OS one, and they usually criticise this.

Additionally pointer lock changes the way mouse input is received: the cursor no longer has an X, Y position on screen. Instead you receive delta-X and delta-Y (i.e. the change only). IIRC tracking these is not consistent with normal mouse movement, because the delta values are raw input, and the OS normally applies some acceleration/smoothing/other processing to mouse input to make cursor movements more usable. So this will either break conditions like "mouse is over object" (because there is no longer a real cursor position), or emulating them will have a weird unprocessed motion on the mouse cursor (because the OS no longer processes it in the usual way) and will throw off users since aiming the mouse accurately is more difficult with unfamiliar motion response. Neither of these issues matter for 3D games, since you look around rather than move a cursor.

So as with pretty much any technology, it's not a case of "technology X will magically fix problem Y!", it's a different set of tradeoffs which are for some purposes better, and for others, worse. The tradeoffs of pointer lock are optimised for 3D games. You can prevent the mouse leaving the window area, but it makes any visible cursor laggy, and makes aiming harder. If you want to ignore the downsides and use pointer lock anyway, third-party addons can cover it.

3rd parties are required as usual, got it. Don't get me wrong, I appreciate knowing about possible downsides but again, I'm not really up for a long debate when it comes to implementing basic features into Construct 2/3 that other engines already support for years.

Obviously the following is my personal opinion but it's really frustrating from a developers side to see that more time is being invested into coming up with reasons against implementing certain things, instead of implementing them (at some point) and satisfying current and future customers.

Gotta find someone who is willing to fix and remove broken features of that 3rd party plugin...

Anyway, thanks for responding to this topic.

Hello Everyone!

If you're interested in native-like pointer locking for your projects and games, no need to wait anymore.

Feel free to click the link and download a new stable and enhanced mouselocking plugin.

also asked here

TheRealDannyyy

could I ask.... What is the possibility of a C3 port ?