Tweaking Input Bindings

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
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 :D

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:

HighlightedKeyboard.png


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?
  • 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
  • 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)
I've also added a little Trello board for this topic as an experiment. It is pretty tiny and may not be worth it in this case but I'm playing around with different ways to organize and thought I'd throw it in there.

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?
I'm hoping for some discussion on the topic then a decision on a convention we can put in the wiki so we have some guidance available. Some features are for later development as needed (like a third column for alternative game view, or fancy letter-highlighted keyboard schematics). Might be a good dev meeting topic.
 
Last edited:

Florian

Active Member
Contributor
Architecture
I agree that we should give the inventory a more prominent key. Since "E" is in use we could go for "R"

I also think that we should at least provide the user with the option to active things with the right mouse button.

Putting the UI hiding on hotkey F11 is a good idea.

We might want to let walking prevent you from falling of a cliff, so that we have less states. It might be more fun also while building if you don't get slowed down so much while construting at dangerous hights.

Are the page up/down buttons already in use? We could use them for increasing and decreasing view distance. It seems to be more natural than using "home" and "end".

About modules overriding engine keys: They can do that already by listing for the corresponding key event on a higher priority than normal. We might however want to lower the default event processing priority for the default handlers to the lowest priority.
 

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
I really like the idea of sorting out non-game key functions to the function keys - makes a nice convention and is easy to remember.

The key set concept (probably combined with a key manager) could server two purposes. The one you mentioned is totally different game modes/game experiences, the other one are different keyboard layouts. It would be interesting to see if we can come up with a concept where a mod can introduce a character screen to open for some key press which is just specified over the type of window to open (some key CHARACTER_WINDOW which is mapped to 'c' by default). That way the user can change the key bindings once and the changes will be used by modules automatically. We probably still need to offer the ability to change/override key bindings.
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Walking off edges - that should IMHO be included in crouch/sneak like in other games (like MC). Normal walking/running will go off edges all day long, but start moving carefully/sneaky and you'll stick on edges.

Page up/down - I'd save those for scrolling in chat / console / UI screens, honestly (do we have pgup/pgdn in chat yet?). Admittedly home/end work for chat/console too. Feels more like selection keys somehow to me :geek:

Modules overriding engine - maybe, but first challenge is even getting a key assigned :D Currently first one there gets it!

An additional layer of abstraction via key set could be cool. Gets me back to that generic "crafting in hand" key :)
 
Top