A simple but robust input-action manager for Bevy: intended to be useful both as a plugin and a helpful library.
Inputs from various input sources (keyboard, mouse and gamepad) are collected into a common
ActionState on your player entity, which can be conveniently used in your game logic.
The mapping between inputs and actions is many-to-many, and easily configured and extended with the
InputMap components on your player entity. A single action can be triggered by multiple inputs (or set directly by UI elements or gameplay logic), and a single input can result in multiple actions being triggered, which can be handled contextually.
This library seamlessly supports both single-player and local multiplayer games! Simply add the
InputManagerBundle to each controllable entity, and customize the
AssociatedGamepad values appropriately.
- Create an enum of the logical actions you want to represent, and implement the
Actionliketrait for it.
- Add the
- Add the
InputManagerBundleto your player entity (or entities!).
- Configure a mapping between your inputs and your actions by modifying the
InputMapcomponent on your player entity.
- Read the
ActionStatecomponent on your player entity to check the collected input state!
Running your game
cargo run. This repo is set up to always build with full optimizations, so there's no need for a
--release flag in most cases. Dynamic linking is enabled to ensure build times stay snappy.
To run an example, use
cargo run --example_name, where
example_name is the file name of the example without the
This repository is open to community contributions! There are a few options if you'd like to help:
- File issues for bugs you find or new features you'd like.
- Read over and discuss issues, then make a PR that fixes them. Use "Fixes #X" in your PR description to automatically close the issue when the PR is merged.
- Review existing PRs, and leave thoughtful feedback. If you think a PR is ready to merge, hit "Approve" in your review!
Any contributions made are provided under the license(s) listed in this repo at the time of their contribution, and do not require separate attribution.
- Use doc tests aggressively to show how APIs should be used. You can use
#to hide setup code from the doc tests, but use this sparingly.
- Unit test belong near the code they are testing. Use
#[cfg(test)]on the test module to ignore it during builds, and
#[test]on the test functions to ensure they are run.
- Integration tests should be stored in the top level
testsfolder, importing functions from
cargo test to run all tests.
The CI will:
- Ensure the code is formatted with
- Ensure that the code compiles.
- Ensure that (almost) all
- Ensure all tests pass on Windows, MacOS and Ubuntu.
Check this locally with:
cargo run -p ci
cargo test --workspace
To manually rerun CI:
- Navigate to the
- Use the dropdown menu in the CI run of interest and select "View workflow file".
- In the top-right corner, select "Rerun workflow".
Documentation is handled with standard Rust doc strings. Use
cargo doc --open to build and then open the docs locally.