Replies: 5 comments 17 replies
-
The WASD-movement scheme is a good example of where physical keys makes sense. These keys are not picked because the characters they represent but rather their position on the keyboard. On my dvorak layout that maps to the characters ",aoe". Same goes for "grid hotkeys" in games like starcraft where they keys are selected to form a grid that maps to the order in the UI. Contrast with the regular mnemonic keybinds where the "Build" action would be triggered by the B-key. |
Beta Was this translation helpful? Give feedback.
-
I'll copy my response to a similar thought, thank you for replying! I appreciate the idea of having controls be layout-agnostic by using physical locations, but there's a reason most games don't do this, right? It's very confusing as a user when you press a key and it uses the binding you set for some different seemingly unrelated key because it just happens to map that way from your layout to US QWERTY. Basically, if the key label in-game or even in the options menu says And if you're doing some sort of thing where you change the way the controls are shown based on the selected and/or detected layout, you could just use action mapping for that layout to begin with since you've already done the hard work of mapping one layout to another. |
Beta Was this translation helpful? Give feedback.
-
I'd like to see more justification before we devote effort to a custom keyboard layer/spec. The new winit api is based closely on the W3C spec which, though not perfect, is well specified, well documented, and has excellent cross platform support. I also don't see the problem with using physical keys by default, so long as logical keys are an option. Most games use keys like "wasd" where the position is more important. It's good default behavior for new users. If logical keys are hard to use, that's something I'd be interested in hearing more about. We should fix that. But currently I don't see why that would require implementing a custom keyboard layer. |
Beta Was this translation helpful? Give feedback.
-
A side note: the difference between the logical and the physical mappings only exists for the international layouts with the Latin-based alphabets. Whereas the keyboards for Greek, Cyrillic, Arabic and other non-Latin scripts almost always (to the point where not having one is a rare edge-case) physically include the English-US QWERTY layout. And for the users of these layouts it only makes sense if the physical keybinds are used, because else they have to switch to the English layout. Imagine then having a chat or some other form of a text input in a game: the users of these keyboards would have to switch back and forth from the English-US layout (to use the game) to their language layout (to write the messages/other text). Moreover: the existing tradition is that the keys are not even rendered in the target language, but are labelled according to the English-US QWERTY layout. That is, if a prompt in Russian asks to press |
Beta Was this translation helpful? Give feedback.
-
I think it's really important to distinguish between the developer and player concerns. The developer wants any default control schemes to be layout-agnostic. So if a game has a set of default key bindings, what's important is the way those keys are physically laid out, not the characters they emit when pressed.1 The developer can't know all layouts the player could have but they can be sure that key positions are mostly consistent. It wouldn't make any sense to define a set of default key bindings for every possible logical layout (that are just going to physically match the QWERTY one) when keyboards physically have almost no variation. Position just happens to be expressed as QWERTY key position because it's the most common printing. It's just a convention. (edit: More intuitive than just numbering all the keys.)
Keyboards really don't stray far from this layout. ANSI/ISO differences are minute, and a developer really only has to account for full-size keyboards and 80% (no numpad) keyboards. Most games don't even have that many actions to bind. The player... also wants control schemes to be layout-agnostic. Well, they want them to just work. They don't care if the app accomplishes it by using physical keys or using layout-defined keys and a default for each layout. They also want the key displayed on screen to be the one they expected to see. I think using physical key is the more robust way to accomplish these goals since it means the player can their change keyboard layout in-game without worry. If the player wants to see the physical key, the app doesn't have to do anything. If they want to see the layout-defined character, the app can take the physical key, turn it into an OS scancode, and ask the OS for the character it currently represents (Windows, macOS, Linux). Like that, the developer could make one default control scheme and the player wouldn't have to mentally translate. Everyone's happy. I think that might be the solution you're looking for.
(edit) I don't think actions should be totally ignored. If an app's code only sees actions like I think it's also worth mentioning that @alice-i-cecile has talked about wanting to upstream
It's not that simple. Logical key events aren't just Latin characters. A logical key event could be almost any Unicode character as well as a non-character (dead) key. I doubt we want to deal with that or case-sensitivity or Unicode normalization.
I'm curious how you came to these conclusions. The broader game development ecosystem is full of examples of preferring physical keys, whether or not the game's UI displays the layout-defined character. Unity says
SDL2 says (emphasis mine)
Steam Input says (emphasis mine)
Godot 4.0 added physical keys to their API to fix long-standing issues with different keyboard layouts breaking in-game bindings. So the case for preferring physical key location is very well-supported.2 Footnotes
|
Beta Was this translation helpful? Give feedback.
-
As of 0.13, Bevy primarily uses physical keys when reading input via
KeyCode
(which is the recommended method sinceButtonInput<Key>
isn't fully supported and is a bit unergonomic due to theCharacter
variant). This makes things very rough for anyone not using a US QWERTY keyboard.As an example, I use a Nordic layout and I have no idea which
KeyCode
to use to map my+
key. I could, of course, look it up, but I should not have to do that. There are also cases where layouts have different amounts of keys, or where it's not clear how to map the physical positions of the keys due to variations in how the layout is staggered, the size of keys, etc.I am aware this change was brought on by changes to winit, but ideally Bevy would have its own design spec in terms of keyboard input, and how winit is used is an implementation detail. The goal of this thread is to gather ideas and thoughts on what an RFC for a keyboard input spec would look like. I'm no expert on this by any means, so anyone who has experience with this is very much encouraged to share any ideas you might have.
These are some of the points I think are important to address:
A
anda
are not meaningfully different, and having them be different if the user is holding shift (common thing for games) is unnecessarily annoying for the developer to deal with. I think modifyingis_just_pressed
and friends to include something like aignore_capitals
parameter is a decent compromise, but there may be more to this than meets the eye. I'd love more thoughts on this!Beta Was this translation helpful? Give feedback.
All reactions