Re: [w3c/gamepad] spec vibrationActuator gamepad extension (#68)

Thanks for the comments!

I agree, a canPlayEffectType method would work well and would allow the actuator type to be removed. I can definitely see the actuator type becoming an issue, especially with actuators that can reasonably be classified as multiple types. Done.

Regarding haptic vs vibration naming, I chose vibrationActuator for the Gamepad member name because it should be limited only to effects that vibrate the whole device. Rumble is common enough that I think it's worth having an explicit member to signal the capability rather than hiding it in a hapticActuators array. But, I expect we will eventually also want an array to cover other types of vibration and other types of actuators. I left it out only because it's not useful yet and would unnecessarily complicate the spec.

For instance, Xbox One trigger rumble is a vibration effect that independently vibrates one element on the gamepad. I think it would be appropriate to expose these as separate actuators in a hapticActuators array and define a canonical haptics mapping in the Standard Gamepad. (I'd prefer this over adding "quad-rumble") Similarly, if you have dual Joy-Cons or a Switch Pro controller, LRA vibration effects can be independently controlled between the two hands. I'd rather expose left and right GamepadHapticActuators that each control one Joy-Con than add a "stereo-switch-lra" effect type.

In that context, does it make more sense that the vibration-focused actuator would be vibrationActuator, and the more general collection would be hapticActuators? Calling it "vibrationActuator" has one more benefit that I find appealing, "vibration" is more obviously connected to rumble effects so I expect developers will try it first.

This API is likely not sufficient for waveform-based haptics. It should be possible to upload an effect to the device independently of playing the effect. The waveform data might be large and uploading it could incur a delay or use battery power. And because the storage of such effects isn't infinite, it should also be possible to query if an effect will fit and discard effects from the device once they are no longer needed. The use case I think of is a vibration effect based on an audio track. Each effect is a unique segment of the audio and can be discarded immediately after playing, but multiple effects can be buffered in advance for smooth playback with no gaps.

It's probably not sufficient for joysticks with directional haptics that react to the stick's position and velocity, either. I haven't thought about these too much, IMO this joystick-specific feature is not sufficiently gamepad-like to worry about here. It would be better if we could support these legacy devices through Web USB.

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