Bevy Version: | 0.9 | (outdated!) |
---|
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)
- 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.