Change game.buttons to use kb-bindings module #96
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes game.buttons to use kb-bindings - which is based on and compatible with @chrisdickinson's kb-controls, but takes it a step further than providing a polling interface, also adding events and reconfigurable bindings.
This functionality is very useful to add here since it allows the game to centrally control the keyboard handling, consistently enabling/disabling capturing as pointer lock is attained/released and providing a unified interface for managing bindings.
Previously, non-polling kb handling code would register its own event handlers on the DOM, for example from @maxogden's voxel-hello-world:
which works, but if you're typing 'R' in a text control (etc.), the event handler is still executed, so it needs to hook into attain/release interact itself.. which gets messy quickly, plus, the above handler still hardcoded the specific keybinding. With kb-bindings in voxel-engine, you can register a descriptive binding name (e.g. 'pov' — to optionally let the user rebind it with kb-bindings-ui), then listen for the appropriate events (which are only sent if enabled, so they don't interfere with modal widgets), and it it all works well.
There may be other solutions to these problems than changing
game.buttons
outright. I also experimented with adding akb_module
option to voxel-engine, allowing users to pass in their own kb module, but this was problematic since it cannot be JSON-serialized (similar problem to GH-95). If kb-controls itself chrisdickinson/kb-controls#4 grows these features, that would be an option too, but I think events is probably out of the scope of kb-controls (hence a more expansive module, kb-bindings). Or if voxel- could be rearchitected somehow so that voxel-engine wouldn't depend on kb-, instead vice versa (or not at all?), allowing modules to be easily swapped in or out (similar to gl- vs three.js as @shama describes in voxel/issues#4) with fewer interdependencies, but I'm not sure exactly how that would work (open to suggestions); though at least the change in this PR was sufficient for my purposes =) (currently using in ~8 voxel modules)