Controller assignment and input remapping for games (and some apps) (pre-development)
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Input Control

Give users control over input.

If you're working on a game jam, quick, drop this library in! Otherwise, quick, drop this library in!


  • Provide a clean API for receiving controls.

    • Without using a library, I've found it works fairly well to have a Controller object with properties for the available controls and subclasses like KeyboardController and GamepadController that provide an update method.

      • A CoupledController can be used to support both keyboard and gamepad, good for single-player games with hard-coded controls.

      • I've also used an AIController for NPCs, which works well. An AIController generally needs access to the entity it's controlling and the world/level/room it resides in. (If you have several entities with AI, you might want separate Controller classes for each or you might want to simply handle the AI in the entities' regular update/step.)

    • We'd support arbitrary controls and controllers though, so it would probably always use something like the equivalent of a CoupledController although with sometimes only one sub-controller. And it probably doesn't make sense to have the properties directly on the object.

  • Allow high level assignment of controllers (keyboard/mouse, gamepads etc.) to players
  • Allow remapping of individual keyboard, mouse, gamepad, and other inputs.

  • Allow deferring to other means of control such as touchscreen controls for mobile devices (which could be handled by a library.)

  • Support mobile-device-as-a-controller, a la node-virtual-gamepads or nunchuck.js

  • Support multiplayer, local and networked. I don't have much experience doing networked multiplayer games. When I did, it helped to have a Controller that I could serialize and deserialize, to sync up inputs between clients rather than just velocities and such. I used a server-side Controller that received input from a client over the network.

  • Provide a clean API for rendering controls as text, icons, or both, for use in menus, HUDs, sign posts in game worlds, etc.

    • In a local multiplayer game, you need to show the controls for both/all players. (Sometimes they're the same, i.e. multiple controllers of the same type, but you can't guarantee this.)
    • You should have full control over the text displayed, and should be able to handle it intelligently. “Press up to jump” should be “Press W to jump” if that's what the jump control is configured as. “Use left and right to move around”, “Use the left analog stick to move around”, “Use the arrow keys or WASD to move around, or plug in a controller”
  • Provide modular UI:

    • The base of the UI would be an abstract model of the interface. Could use Redux or similar.

    • Icon sets / themes could go in modules, with the option to create a custom theme, or render whatever you want based on a descriptor.

      • Something like {type: "stick", name: "left-stick", pressed: true, stickX: 0, stickY: 0} (and other types like key, button, directional-button or dpad-button, maybe the whole dpad; maybe stickX/stickY should just be x/y so it can be the same for the dpad)

      • It would be nice to have dynamic icons for analog sticks. (For instance you might want to indicate the player should move the stick in a circular motion or back and forth)

        • We could even have a light API for animating the descriptors

          • Based on higher level descriptors, something like {type: "stick", name: "left-stick", animation: "counterclockwise", t: 0.5}

          • Or multiple methods, more like .animateCircularMotion()

      • Icons should indicate their physical appearance if known or render them however you want.

      • All button icons should have a normal and pressed state.

    • Provide a basic GUI with React or d3 or similar. We might want to render straight to a canvas, but we could still leverage the DOM behind the scenes for accessibility.

    • Provide a basic VR GUI with a-frame

  • It should be incredibly easy to integrate. With this library, there should be no excuse not to allow users to configure their controls.

The easier it is, the more devs will adopt it; the more games that have it, the more users can enjoy it, (and then more people will see it, and want it and ask for it, and PR for it and get it, and enjoy it.)

There are theoretical benefits to having a shared system:

  • Familiarity: if users recognize that the UI works in the same ways as in other games, they can pick it up and use it faster; they should appreciate the consistency (assuming the UI is done well, but it should basically be done best; after all...)
  • Concerted development: improvements to the library go to all the games that use it! (Open source FTW)
  • As well as simply all the features that wouldn't make sense for any one game to implement unless it's a core gameplay conceit, like using a phone as a controller (and perhaps as a lightsaber in a Star Wars game). Or undo/redo. Come on, no game is gonna implement undo/redo. But ideally tho, ideally, on an ideal situation, they would. And a library can.

Yeah, so -

  • ease for the dev
  • power to the player
  • useful features you'd never bother to implement yourself (or hadn't even thought of)
  • consistency and solidity
  • and long term benefits across games to adoption.

It's a piece of cake, or at your choice, pie (heck, maybe even some pie menus?) with some ice cream thrown in there for FREE - that's the goal. Summed up in terms of food.