- From: Ted Mielczarek <ted@mielczarek.org>
- Date: Wed, 2 Nov 2011 12:35:00 -0400
- To: Sangwhan Moon <smoon@opera.com>
- Cc: "public-webevents@w3.org Group WG" <public-webevents@w3.org>
On Tue, Nov 1, 2011 at 6:03 PM, Sangwhan Moon <smoon@opera.com> wrote: > I agree. But the very fact that the input data is between the mentioned input > devices (Joystick, Gamepad, and Racing wheels) are getting more and more > aligned, I think it makes sense to group them into a single specification that > can cover all three. Note that as I've stated here before, the "Gamepad API" is named so simply because it was the least-bad option. I originally referred to it as the "Joystick API", since that's historically what I've called game controllers (and what most APIs still use to refer to them), but that confused people into thinking it was only targeted at joysticks (like for flight simulators). The plan is to support basically anything that falls into the USB HID game controller class. Gamepads, joysticks, and wheels are all in this class. Our current planned spec will expose buttons and axes, which should cover a large part of the useful input from these devices. Further updates will probably expose accelerometers and vibration and other things. We do want to draw a line between these types of devices and things like the Wiimote's pointer motion or the Kinect. Clearly these are both "game controllers", but they're quite different from the existing set of gamepads/joysticks/etc, and I imagine APIs interfacing with them would want to be different. In addition, there are a wide variety of gamepads made by a wide variety of manufacturers, while Wiimotes and Kinect are currently single-vendor technologies. It feels much more high-value right now to spec out access to that large market of well-known devices, rather than try to invent APIs for fairly new technology that is not as well-established. -Ted
Received on Wednesday, 2 November 2011 16:35:36 UTC