Scope: Engine feature
Code: Engine repo
Wiki doc: Engine - Input Bindings
Issue tracker: Engine
Ideas / todo: Trello
Curator: Needed
Our approach to input bindings so far has pretty much been finding a single new key when we need one. I think it is about time we get more organized on strategy there
We have a great system for actually binding keys complete as-is, although it primarily covers the engine and leaves modules to sort of fend for themselves, first module loaded with a particular key binding gets it.
So recently @Florian was nice enough to add a key for permanently toggling between run & walk. The PR was done while we were still discussing on IRC what the ideal key would actually even be, and it shows
Instead I think we should look at a keyboard and think about what kinds of actions we actually want where, and what keys we want to exclude for internationalization reasons. I dug up an image real quick focused on WASD and finger range from there:
This keyboard layout doesn't seem quite right to me, but then that just illustrates the added challenge of the task on an international stage (I can't remember the last time I saw the "Gr" part on an Alt key, or a two-row-high Enter key)
From looking at a few different keyboards we can probably permanently disqualify some keys. On the image above the | \ key is by the left shift, on mine it is the top half of the Enter key instead. The ~ tilde key is my top left (together with our troubled 'grave' console key), but is over by Enter on this one. And the Windows keys are just right out!
Can some of our good people with alternative keyboards or layouts link some images and suggest what keys we might want to avoid? Here are some initial thoughts on what we might want to do where and what to avoid:
It focuses on documentation and a neat possible addition to the input config screen: Showing a visual keyboard schematic that matches what the user has + highlights individual keys appropriately. A Game of Dwarves had that and I thought it looked great. Shouldn't be too hard to ship with a few common keyboard schematics, maybe we can even auto-detect some language variants and prepare for them?
Related topics:
Code: Engine repo
Wiki doc: Engine - Input Bindings
Issue tracker: Engine
Ideas / todo: Trello
Curator: Needed
Our approach to input bindings so far has pretty much been finding a single new key when we need one. I think it is about time we get more organized on strategy there
We have a great system for actually binding keys complete as-is, although it primarily covers the engine and leaves modules to sort of fend for themselves, first module loaded with a particular key binding gets it.
So recently @Florian was nice enough to add a key for permanently toggling between run & walk. The PR was done while we were still discussing on IRC what the ideal key would actually even be, and it shows
Instead I think we should look at a keyboard and think about what kinds of actions we actually want where, and what keys we want to exclude for internationalization reasons. I dug up an image real quick focused on WASD and finger range from there:
This keyboard layout doesn't seem quite right to me, but then that just illustrates the added challenge of the task on an international stage (I can't remember the last time I saw the "Gr" part on an Alt key, or a two-row-high Enter key)
From looking at a few different keyboards we can probably permanently disqualify some keys. On the image above the | \ key is by the left shift, on mine it is the top half of the Enter key instead. The ~ tilde key is my top left (together with our troubled 'grave' console key), but is over by Enter on this one. And the Windows keys are just right out!
Can some of our good people with alternative keyboards or layouts link some images and suggest what keys we might want to avoid? Here are some initial thoughts on what we might want to do where and what to avoid:
- Console key on the grave / accent key is problematic on some European keyboards (even if a typical convention), we've talked about that in the past. What about moving it to F1? That's currently a debug key but that can be moved. Then we can blacklist grave (or make that the default alternate)
- In general should we reserve the function keys for "system" like interactions, like console, debug, and take screenshot? That's mostly the case currently, with a few open keys and the behavior tree editor (F5) looking out of place (although if it is only available for debug / content creation it might fit there)
- Keys near WASD (yellow above) are usually considered high importance for keys you need fast. Q and E feel great where they are, for instance. Should we reserve most the remainder for other important engine / basic stuff? Keeping in mind some modules for us would be engine features elsewhere (like inventory or combat). I think of those modules as the Iota collection (used to call them mode zero) as per the new Distro fun (still under dev)
- Run and crouch toggles: We've got the fairly standard Shift for temp switch to walk/run while pressed and Ctrl for crouching (which doesn't really do much yet). We've got a perma walk/run toggle on Caps Lock now which should probably be a blacklisted key. Perma crouch could be a thing too. Should the perma toggles be considered important enough for a default home like X/C or similarly adjacent keys? How about an auto-run key?
- Chat is currently T and we should probably reserve Y for some form of team chat? Fairly typical
- Inventory is currently I, which seems awfully far away. I liked how it was on E in Minecraft (at least with whatever version I played last) although that might be too close (and taken, anyway). If we predict the eventual use for a Character screen could we use C for that (typical) plus V for inventory (adjacent - seems a good fit)? Or should those be the same screen? We could include an alternative default so it is both I + V
- Anything obvious to reserve Z or X for? What are they typically used for? How about reserving something for important creature interaction commands, like attack or retreat?
- Run and crouch toggles: We've got the fairly standard Shift for temp switch to walk/run while pressed and Ctrl for crouching (which doesn't really do much yet). We've got a perma walk/run toggle on Caps Lock now which should probably be a blacklisted key. Perma crouch could be a thing too. Should the perma toggles be considered important enough for a default home like X/C or similarly adjacent keys? How about an auto-run key?
- Keys in or near red above are somewhat close to WASD but not super convenient. Should we perhaps consider leaving most of them open for high priority or common module keys that could overlap between different gameplay setups?
- G is craft-in-hand for Throughout the Ages. Could that perhaps be a convention for "in-hand crafting" in different gameplay settings, so also the key for TerraTech (currently U)? And if both are active (unlikely) find a way to combine them? IMHO most crafting should be delegated to block-based workstations anyway
- B is the BlockPicker, which should probably be an Iota module, but is not likely to be always enabled (more of a creative mode thing to avoid in most survival type gameplay).
- J is Journal, which is a great common use module several different types of gameplay can share easily
- The wasteland of keys to the right of the red keys aren't conveniently accessible - uncommon stuff would probably go there best, lots of open space for module specialties.
- For instance H is currently "Hide HUD" but that's a pretty valuable key for such a rarely needed action. Move to P maybe? ("photo" key?). Or a function key? Maybe F11 would be even better with F12 taking screenshots
- M toggles the minimap when enabled. That seems a good location for a toggle as it is out of the way and rarely needed, but if we introduce a "normal" full screen type map that's a little distant. Maybe Tab could a full map when the console isn't up (in which case Tab would auto-complete). That's fairly typical of mapping.
- O is for the Oreon menu in MasterOfOreon, and another good example (out of the way, rarely needed)
- Even further right Home/End seem great choices for increase/decrease view distance
- For instance H is currently "Hide HUD" but that's a pretty valuable key for such a rarely needed action. Move to P maybe? ("photo" key?). Or a function key? Maybe F11 would be even better with F12 taking screenshots
- Should we include any common options or encourage use of a modifier key + letter? Should engine + Iota + common module actions like craft-in-hand favor straight letters and Alt + letter be more reserved and recommended for one-off module needs? Lowers likelihood of conflicts
- Entirely alternate modes like a top-down strategic view ("Observer View"?) as opposed to first person may entirely throw away all the usefulness of the above observations. Should we perhaps support different key sets for different situations like that? How many situations are likely, if any, beyond first person / third person and top-down strategic? If we only have two should we simply add a whole third column that'll be active in top-down? That column would have to differ from the primary and alternative columns as it could overlap with their settings (rather than overwrite). It probably also would only include a subset of possible keys (like only the primary letter/number area, but not function keys)
It focuses on documentation and a neat possible addition to the input config screen: Showing a visual keyboard schematic that matches what the user has + highlights individual keys appropriately. A Game of Dwarves had that and I thought it looked great. Shouldn't be too hard to ship with a few common keyboard schematics, maybe we can even auto-detect some language variants and prepare for them?
Related topics:
- Primary mouse usage. Do we stick with current or open up more options with the right button? What about modifier keys (Alt?) + mouse clicks? Impact on our keyboard convention? Old thread linky
- Handling key input better between different modules, especially conflicts. We've got gameplay modules available now that might help. Old thread linky
- Support a way for modules to override some engine/iota keys if they know they won't be used? Entirely different gameplay settings
- Entirely alternative input options - joystick, leap motion, oculus rift (head turning), macro keys, etc
- Hardening the game better for when you have an existing config.cfg but a newer version of the game comes with changed or new hot keys?
Last edited:
