Plug in (or press a button on) a gamepad or joystick, and see what happens, above! Maybe something bad... maybe something good. We won't know until you try!
Why do you have to plug in a controller or press a button before this starts working? Answer: to prevent information leaks. You don't want any old web pages collecting information on which joysticks you have plugged in, after all.
Maybe you have thousands of dollars in flight controls and you don't want people to know without you knowing they know, you know? Or maybe you don't want to let advertisers use the state of your system for fingerprinting.
In any case, you have to notify the web page that you're OK with it using your gamepads, either by pressing a button on the pad or by plugging on in after the page has loaded.
Let's dive on in!
You do have support on Edge, Chrome, Firefox, and Opera. Safari has support in version 10.1+. IE can just forget it–you shouldn't be using that legacy browser anyway.
And now for more bad news! Ready?
I found Edge to have some, um, weirdnesses. Sometimes it takes a while after hitting a button for the gamepad to appear. Also I can't seem to get it to show another one of my joysticks at all.
I know you're shocked, but please try to disguise it as enthusiasm. Thanks.
Of course, within each browser there are different levels of compliance. Oh, and the same gamepad might show up in different ways on different browsers.
Ah, the fun of web programming.
Browsers that support gamepads expose a function called navigator.getGamepads() that returns the state of all the connected gamepads in a big array. (Note that sometimes the values in the array are null, representing non-existent gamepads... coughChromecough.)
Once you have the gamepads array, you can iterate through it to get all kinds of information about the connected devices.
When you run that code in the debugger, you should see similar output to this on the debug console:
Inventory connected gamepads output (truncated)Gamepad 0: Index: 0 ID: ©Microsoft Corporation Controller (STANDARD GAMEPAD Vendor: 045e Prod Axes: 4 Buttons: 17 Mapping: standard Gamepad 1: Index: 1 ID: Microsoft SideWinder Precision 2 Joystick (Vendor: 045e Product: 0038 Axes: 6 Buttons: 8 Mapping: Gamepad 2: [null] Gamepad 3: [null]
Of course, unless you happen to have the same controllers as I do and happen to be running the code in the same browser as I am, you'll see different results. Even with the same controllers plugged in, I get different results between Firefox and Chrome.
Note we also test the connected property of the gamepad. I have yet to encounter a case where the gamepad both exists in the array and connected is set to false, but the spec says it can happen.
Did you notice the seemingly-redundant property called index in the gamepad object? Why is there an index that already corresponds to the index in the array returned by getGamepads()?
Turns out that as you connect and disconnect gamepads, the objects in the gamepads array might be shuffled around so that the index property no longer corresponds to the index in the gamepads array!
What this means is that when you're looking for input from a specific gamepad, you have to search for it by its index property. Don't trust that it will necessarily be in the same place in the array returned by getGamepads().
If you unplug a controller and plug it right back in, the browser will make an effort to set its index property to whatever it was before.
Note that the id property, which gives a human-readable representation of what controller is plugged in, varies from browser to browser; the exact format is browser-specific.
But... that's not what we're going to do this time.
I'm not sure the rationale, but I suspect that the designers of the Gamepad API felt that it would be almost always exclusively be used for games and other interactive sites that required frequent rendering, probably in a loop. And if you're going to be rendering a scene 30 times per second, anyway, you're probably going to want to just poll the state of the controllers each frame. Bringing the state in through event handlers would just be messier.
For your game (or whatever—I don't mean to imply you're not serious), you'll probably have an animation loop that uses requestAnimationFrame(), like this:
There are so many different types of gamepads in the world, what is one to do? How do you know which button to hook up to "Fire"?
Well, the designers of the gamepad spec have attempted, with marginal success, to make our lives easier in that regard by defining the Standard Gamepad.
If a browser recognizes a gamepad as basically looking like the one, above, it remaps the buttons and axes into a known pattern with published, common indexes for the various buttons and axes. (The values are in the spec.)
Additionally (and this is important), it sets the .mapping property of the controller to the string "standard". This is how you can tell you have a standard controller at your disposal.
If the mapping property isn't set to "standard", you have a controller that the browser hasn't recognized as standard. What you do next is really up to you, but probably involves either (A) pretending the controller is standard and hoping for the best, (B) giving up and not supporting the controller, or (C) implementing a UI to allow the user to remap the controller.
Option A is the easiest, but will probably produce horrific results. Not recommended. Option B is almost as easy, is at least predictable, and keeps your code simple. Option C is hard to code but is certainly the most flexible.
You might be thinking, "But I have a wired Xbox 360 controller, the most popular gamepad for PCs there is. Surely browsers recognize it as a standard controller."
Definitely maybe! Chrome, for instance, calls it standard. The triggers are exposed as analog buttons, and the D-pad is exposed as digital buttons, just like the spec says. Great news!
But on Firefox for Linux, oh dear. Firefox does not report the controller as standard. The triggers are exposed as axes, as is the D-pad. And the axes for the analog sticks aren't at the same array indexes in the axes array, either.
So if you decide you're going to support the Xbox 360 controller on Chrome and Linux FF, you're going to have your work cut out for you. Might as well do Option C, above, in that case.
This is a bit of a sore point with browsers that implement the gamepad API. It kinda works as intended, but not really.
In theory, the browser should fire off two events on the window object at the appropriate time: gamepadconnected and gamepaddisconnected.
These events have a gamepad property attached to their argument that you can use to determine which gamepad has been hooked up.
In practice, browser support is spotty. On my Chrome for Linux, I get a disconnect event when I connect a gamepad, and no event when I disconnect one. Not so useful.
So instead, since I'm polling for gamepad status every frame anyway, I just poll for connections and disconnections. A not-so-robust way to do this is to simply count the number of connected gamepads in the array and return any changes as a difference.
We can detect connections, see what gamepads are connected, and that's great and all. But eventually you're going to actually want to see which buttons are pressed, and which joysticks are deflected, right?
Let's start with the buttons, since that's a tiny bit more straightforward.
When you get a gamepad from the array, there's a property on it called buttons. This refers to an array of objects that contains information about all the buttons on the gamepad.
Each button object has two notable properties: pressed and value.
pressed is pretty self-explanitory. If the button's pressed, this value is true. If it's not pressed, it's false.
But what does it mean for a button to be "pressed"? Well, if it's a simple switch, then it's either on or off, period. But what about analog buttons like the triggers on the Xbox 360 controller? These can be partially pressed.
In that case, the browser chooses a threshold where if the button is pressed past it, it is reported as pressed, and not otherwise.
And what is that value that is measured against the threshold? It's stored in the value property and goes between 0.0 (not pressed at all) and 1.0 (fully pressed).
(Digital all-or-nothing buttons will set the value to 0.0 or 1.0, and never in between.)
Here's some sample code that reads all the button states on a controller:
On a standard mapped gamepad, the D-pad is exposed as buttons. Otherwise it could be buttons or axes.
On a standard mapped gamepad, the triggers, even if analog, are exposed as buttons. Otherwise they could be buttons or axes.
Similar to the buttons, the axes are available in a property on the gamepad called axes.
Your average analog stick is made up of two axes to make up the x and y coordinates of the joystick position. So a standard-mapped controller will show four axes, two per analog stick.
|Left stick x||0|
|Left stick y||1|
|Right stick x||2|
|Right stick y||3|
Values on the axes run from -1 (up or left) to 1 (down or right), with 0 being neutral.
If the D-pad on a non-standard mapped controller is shown as axes, it will typically show full deflection (-1 or 1) or zero deflection.
Some analog sticks are nice enough to report their position as 0,0 when they're left alone. Others tend to report their positions are, say, 0.0001,-0.0026 when you let them sit at neutral.
Usually the user expects that when he or she lets go of the joystick, all associated motion should cease. So, according to the principle of least astonishment, we should probably assume that very small values coming from the axes should count the same as 0,0.
(Like all rules, there are exceptions to this. But typically a small dead zone is desired.)
Fortunately, this isn't too bad to set up, though there is a bit of remapping going on to smooth out the resultant stick values. For lots more fun and background about that sort of thing, see my blog entry on Transforming Numbers.
And that's what the "Deadzone" checkbox does in the demo at the top of the page.
One more thing you might like to do is clamp the values on the joystick so that they are normalized between different sticks.
What does this mean?
Well, for example, my ancient Microsoft Sidewinder Precision 2 Joystick runs both the x and y axes all the way up to -1,-1 if you push the stick up and left. That's kind of expected, right?
But my Xbox 360 controller only goes to -0.76,-0.76 because the plasting housing around the stick forces the motion into a round shape and won't let it move all the way to -1,-1.
So, for example, if you set the speed of the player character based solely on the joystick axes values, the player would be able to move faster with the Sidewinder than with the 360 controller! That seems decidedly unfair.
One thing we can do is clamp the values at a mathematical circle or radius 1.0 that we place at the center of the stick. Then, assuming all joysticks have at least enough play to reach that circle, they'll all be limited to the same levels.
Also, as a bonus, the length of the maximum deflection in any direction will be equal to 1.0 since that's the radius of the circle we're clamping to.
What we'll do is treat the x and y values from the stick as a 2D vector (x,y) and first take its magnitude, which is a mathy way of saying "its length". If the length of the vector is greater than 1.0, it's outside our circle and needs to be clamped to length 1.0.
How do we clamp it to length 1.0? Fortunately there's a process for doing this: we want to normalize the vector. That is, we'll turn it into a vector pointing the same direction as the original stick vector, except of length 1.0. And we do this by dividing the components of the vector by its magnitude (length).
And this is what the "Clamped" mode is on the demo at the top of the page.
Now get out there and write some games! :)
The demo code at the top of this article is licensed under the MIT open source license.
The remaining code examples in this article are hereby granted to the Public Domain.