making accessible games part 1
it’s easier than you think!
Hey everyone!! This is Part 1 of a series in making your games accessible to a wider audience! This part is about Rebindable Controls, an extremely powerful accessibiltiy feature that is beneficial not only to all players, but also to you! Read on for more information!
Part 1: Rebindable Controls
The first and potentially most powerful tool in our accessiblity arsenal is giving the player the ability to redefine their own controls. Doing this will allow your players to adjust the layout to suit their own personal preferences; for players with limited mobility, this can change a game from being entirely unplayable to perfectly finishable. Rebindable controls also have the added benefit of allowing your game to work with almost any peripheral (given that the platform or operating system recognizes it first, of course), and can even lead to more interesting meta-playstyles in your game’s community, such as advanced speedrunning techniques (e.g, using the mousewheel to jump in Portal allows speedrunners to more easily time perfect jumps to maintain extremely high velocities).
Implementing this on a technical level usually means decoupling your controller input from your controls in your engine of choice. Most modern game engines already do this, but it’s quite a simple process if not. Essentially, you’ll want to implement something like the Command pattern - some good reading on this is available here: Game Programming Patterns: Command
From a design perspective, it is usually sufficient to allow the player to select a game command from a menu, and then perform the new input they would like to attach to it. However, in some games, there are chorded inputs (holding one or more buttons to modally change the behaviour of other buttons) and input sequences that still may not be possible to perform with modifies control layouts. Inversely, there may not be enough inputs on the peripheral of choice to allow the player to bind all inputs, and so it may be important to allow players to create and remove chorded inputs themselves. Valve’s Steam Controller has the ability to do this for any game that is run through Steam’s client - and indeed, Steam supports this behaviour even on non-Steam controllers. Of course, Steam’s platform is only available for Windows, Mac, and Linux machines, and so it is wise to include this functionality in your game if you plan on distributing on other platforms or storefronts.
There are additional considerations for designers, however; it may not be clear from the outset what the context of a given command in your game may be. It is hard to know which button to map to a command without knowing how often that command will be used, and if it is intended to be used in conjunction with other commands (e.g, an Attack command will be used very frequently in a variety of conditions in a hack-and-slash action game, alongside other commands like Block or Jump). It is, therefore, a good idea to include some of this information while the controls are being modified.
Additionally, some players may not be able to navigate your menus to reach the rebinding controls in the first place - you may therefore find it useful to ask the player to bind their menu-navigation controls during the first launch of your game.
Relatedly, your players will also benefit from being able to rebind inputs during tutorial sequences. Many first-person games allow the players the choice to invert the camera during this stage, but there is no substantial reason why the player could not also choose to rebind the Jump button after encountering its tutorial.
Rebindable controls will also impact the interaction of any quick-time events (QTEs) in your game, and so these should be used sparingly and have an input properly associated to them - e.g, if your game requires the player to perform a finishing move on a boss character, add a separate control for this called “Finisher” or “Mortal Blow”, etc. It is my belief that QTEs during cut-scenes are an accessibility hurdle that do not contribute meaningfully to the gameplay experience and should be replaced. If a scene in your game demands player input for an action that is not within their usual repetoire and outside the context of gameplay (e.g, missing HUD, during what appears to be a story cutscene segment), redesign this encounter. Either involve the player with gameplay, or allow the scene to play out.
Rant about QTEs aside, let’s look at what having rebindable controls can do for you as a developer! Decoupling input from ingame actions gives you the ability to do things like simulate inputs by directly calling the functions that the input mapper usually does. Naturally this is great if you want to have a replay or rewind-time mechanic! Not to mention, simulated inputs are extremely powerful when writing networked multiplayer games - it’s a little out of the scope of this blog post, but to put it simply you can use simulated inputs to rewind and play back player state when you receive information over the network that represents a change of the game state a few milliseconds ago. This is one of the key ways to mitigate the effects of latency, and it’s basically bundled in free with the work already done to support rebindable controls! This layer of indirection is also invaluable if you want to have local multiplayer, as it lets you re-use the same player code but attach different inputs trivially. And, I’m sure, there are other invaluable byproducts of making your game eminently playable by a large swathe of people!