Re: [w3c/gamepad] On-screen gamepads (Issue #210)

I see two general approaches to supporting on-screen gamepads: allow sites to configure the system's built-in on-screen gamepad overlay, or create a virtual gamepad and feed it with inputs provided by the site.

Configuring the system's built-in on-screen gamepad would enable better parity with platform-specific apps but would complicate the implementation on OSes where there is no built-in on-screen gamepad or the OS does not support the same level of configuration.

The virtual gamepad approach gives sites more flexibility in arranging the on-screen controls and more consistency across platforms and browsers. It would also potentially enable other use cases like polyfill support for hardware gamepads that are currently unsupported by the browser.

With either approach, the site would gain the ability to vibrate the device by playing a vibration effect on the Gamepad object representing the on-screen gamepad. Currently, Gamepad API uses the [gamepad user gesture](https://w3c.github.io/gamepad/#dfn-gamepad-user-gesture) as a consent signal and does not expose any gamepad information or capabilities until the user has interacted with a gamepad. This would be insufficient in the virtual gamepad approach since the site would have the ability to simulate a user gesture without user interaction. For user consent we would likely require some additional user prompt before connecting the virtual gamepad. Even if we are configuring an overlay we would still need user consent before enabling the overlay since it's drawn on top of the page content.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/210#issuecomment-2164171276
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/210/2164171276@github.com>