Gamepads, gamepads & gamepads

Sidetracking extravaganza with gamepads this past week. Originally started a check to make sure that using a gamepad was working well when solving a particular puzzle. While doing this, I noticed a bug with the gamepad and started to work on fixing it.

This led to taking a thorough review and improvement tour of the gamepad implementation.

Three out of seven different controllers used while testing.

Good to have been a gamer for many years... I managed to search the house and find seven different controllers. Oldest models being a Playstation 2 replica from Logitech, SNES controller replica (8BitDo) and a XBox 360 controller. The most modern I (kids rather, but don't tell them) had was a XBox Series X controller and a Nintendo Switch Pro.

Thanks to browsers having a quite solid Gamepad API, most gamepads work as intended even though there is no 100% standard set for what a gamepad sends as input. Unfortunately different browsers have some variations, meaning a gamepad can be perfect in a browser based on Chromium, while half-working in FireFox. As I build the game using Electron, which is Chromium based, I am only worried about making sure it works as intended for it.

List of improvements

First change I made was adding a prompt for the user to select what type of button layout the gamepad has that was connected. Gamepads do not directly have a value that says "I am this type of gamepad". They do have a device string that contains something about manufacture and the model, but in a way where you essentially would have to compile a long list of string for each gamepad and use that to automate assignment. I decided that simply asking would be the most foolproof and quickest way to implement.

This prompt is only shown the first time a new gamepad sends input. Next time you play the game, the first gamepad used will be the gamepad for player one and the type of gamepad will be retrieved from the stored gamepad profile.

While all gamepads connected get assigned to a player, they can all be used to navigate the menus. If the current gameplay is only for one player, then all gamepads can be used to control the player. Only when doing a hotseat multiplayer activity will the different gamepads be limited to different players. In fact you can, if you want, use the keyboard to control part of the player, one gamepad for something and another for something else, and then to go full mental and use the touch controls as well. Neat and a good waste of time!

Gamepads now have icons for their buttons, previously it was only text that said what button had been configured.

Xbox gamepad to the left, PS gamepad to the right.

Icons and configuration auto updates based on the last gamepad used. So if the gamepad configuration window is open, like shown above, the settings are directly updated to match the current gamepad used.

Final improvement was how the game handles a disconnected gamepad. If a gamepad is disconnected, the game will wait for one of two events to occur. Either that the missing gamepad re-connects, and then will be re-assigned to the player that had it previously. Or, that a new gamepad connects and that gamepad will then be assigned to the player missing a gamepad.

Now I really should get back to moving the actual game forward in its development.