Input Mapping/Remapping

[odecay]

Support for mapping of inputs to keyboard/controller buttons via a menu/saved + loaded from a settings asset.

• Setup the data ( i.e. structs/enums ) necessary for the input map. The idea is to map raw control events such as keyboard and gamepad to something like a GameInput event in terms of the actual actions that can be taken in game. Implement Input Mapping #52
• Create a thin storage abstraction that works for web and desktop Storage abstraction #79
• "Controller Settings" menu for editing input map. #87

[zicklag]

loaded from a settings asset.

Just an implementation note, we probably want the default mappings stored in an asset, and then have a thin storage layer over Filesystem on native and browser local storage on web that we use for when a user changes the mappings and their data needs to be stored.

That storage layer can be used for storing player progress like what level they're on and similar stuff.

[odecay]

I don't know much about browser local storage but I was thinking it might need special attention, glad to hear you already have thoughts about it. Thin storage layer sounds useful and progress saving also sounds like something we should have.

[zicklag]

I think this is the next thing I should work on after #11 get's finished up with #50, can you assign it to me?

My plan so far is:

moved to issue description

[zicklag]

It looks like this input plugin is pretty well designed, so I'll try that out and see how it goes: https://github.com/Leafwing-Studios/leafwing-input-manager.

[odecay]

Yeah I was going to suggest Leafwing input manager, It seems like that will take care of the first part of defining actionlike enums and mapping controls. 👍

[zicklag]

@odecay I ran into a Bevy problem detecting DPad inputs, and I opened a PR to fix it, but obviously if that PR is going to be merged it will be into Bevy 0.8.0-dev, so we can't just use it without switching to Bevy from git.

I am going to be working on getting analog sticks working with leafwing-input-manager, so that could save us from needing DPad support for now, though.

Either way that brought up a question, what's our "policy" for crate dependencies right now. Are we fine using dependencies from git if we have to? For instance, if I add support for analog sticks in leafwing-input and they aren't ready to do a crates.io release yet, are we good just continuing with a git dependency?

[odecay]

I feel like it should be fine to use git dependencies especially if it is blocking us from supporting something, with the goal to move back to release deps when the newer version is released.

[zicklag]

Just got a storage abstraction working in the browser, now I just need to implement it for native, which should be easy.

[zicklag]

Storage abstraction is ready! #79

Now I'll work on the settings menu and allowing you to configure input mappings.

[odecay]

This is done, anything else on top of what we have should be considered as improvements.