Input Handling

Click here to download example code.

This is a complete example that you can run. It will print all input activity to the console.

Bevy supports the following inputs:

• Keyboard (detect when keys are pressed or released)
• Character (for text input; keyboard layout handled by the OS)
• Mouse (relative motion, buttons, scrolling)
  • Motion (moving the mouse, not tied to OS cursor)
  • Cursor (absolute pointer position)
  • Buttons
  • Scrolling (mouse wheel or touchpad gesture)
• Touchscreen (with multi-touch)
• Gamepad (Controller, Joystick) (via the gilrs library)

Sensors, like accelerometers and gyroscopes, are not supported yet.

For most input types (where it makes sense), Bevy provides two ways of dealing with them:

• by checking the current state via resources (input resources),
• or via events (input events).

Some inputs are only provided as events.

Checking state is done using resources such as Input (for binary inputs like keys or buttons), Axis (for analog inputs), Touches (for fingers on a touchscreen), etc. This way of handling input is very convenient for implementing game logic. In these scenarios, you typically only care about the specific inputs mapped to actions in your game. You can check specific buttons/keys to see when they get pressed/released, or what their current state is.

Events (input events) are a lower-level, more all-encompassing approach. Use them if you want to get all activity from that class of input device, rather than only checking for specific inputs.

Input Mapping

Bevy does not yet offer a built-in way to do input mapping (configure key bindings, etc). You need to come up with your own way of translating the inputs into logical actions in your game/app.

There are some community-made plugins that may help with that: see the input-section on bevy-assets. My personal recommendation: Input Manager plugin by Leafwing Studios.

It may be a good idea to build your own abstractions specific to your game. For example, if you need to handle player movement, you might want to have a system for reading inputs and converting them to your own internal "movement intent/action events", and then another system acting on those internal events, to actually move the player. Make sure to use explicit system ordering to avoid lag / frame delays.