How can I handle different keyboard layouts?

Question

Let's say I have a game that uses WASD controls on a QWERTY layout. Trying to use these controls on, say, a Dvorak layout is not ideal (equivalent to <A:H on QWERTY). Obviously, I'd want to use the same physical keys as QWERTY would use (,aoe on DVORAK).

I've come up with a few possible solutions:

• Force the user to use QWERTY
  • obviously not ideal, especially for international users
• Change shortcuts based on keyboard layout (WASD -> ,aoe)
  • forces me to make layout maps for each supported layout (automatable)
  • easiest for the user if there are more shortcuts than just WASD
• Force the user to define shortcuts themselves
  • More flexible
  • Annoying if there are lots of shortcuts
  • Can be used in conjunction with the second option
• Use hardware keycodes
  • consistent across keyboards?

How is this type of thing usually handled?

Answer 1

Listen for scan codes. How this is done depends on your OS, which you did not list. On Windows, you can get the scancode for a given virtual key code from WM_KEYDOWN and friends by using MapVirtualKey. Scan codes are based on the physical key and are unaffected by layout.

Have a quick read of http://www.altdevblogaday.com/2011/10/02/i-never-managed-to-go-left-on-first-try/.

So yes, as Nicol Bolas said, you can and should let users work around it. But just making it work right out of the box is not hard and your users will appreciate it.

Note that you are (probably) handling character input wrong, like the vast majority of game developers. Make sure that for text, you always use WM_CHAR (or the equivalent on other OSes) rather than using WM_KEYDOWN for text input. It is completely wrong to assume that when the 'a' key is pressed that you should input an 'a' to a text input control, due to the use of Dead Keys on some layouts. You can also support IME (or OS equivalent) for East Asian markets which have far more characters than can reasonably fit on a keyboard, and need special UI to type. Handling IME in a game is a pain (handling it at all is a pain), but worth it in my opinion to increase the appeal of your product to a much, much larger set of markets. Again, WM_KEYDOWN is never to be used for text, ever.

Answer 2

You should always give the player the ability to change their key assignments. That is how it is "usually handled": let the player change them. Some players will set their keyboard to QWERTY when they play games because that's what most games expect. Some will leave them set to their current keyboard and rely on the ability to change the keys.

Answer 3

In the case you can't listen for scan codes (like for example when developing a flash game) you can make a key binding which works for as many layouts as possible. Most keyboard layouts are very similar, with just a few exceptions.

The keyboard layouts following ISO 9995 (that's most) are arranged like this:

Basically the black keys are safe to use.

Answer 4

Most big budget games (those with an international distributor) will work out of the box, using ZQSD instead of WASD for azerty layouts. A decent game will also introduce the layout in the first level, others will let the player discover it through the customisation screen. The implementation strategy can be detected by asking the OS to switch layouts. Either the game uses scancodes (positions) internally, and maps them to keycodes (symbols) when showing configuration dialogs and prompts; or it uses keycodes internally, and detects the layout at startup or on first launch.

The first strategy (scancodes internally) is more robust, but does require a bit of care to prevent the abstraction from leaking through. Remember to remap scancodes to keycodes when presenting keys to the user (in tutorials, prompts and customisation dialogs). You will still need to look at keycodes when taking text input (letting a player type their name for example). If you need to handle more text than that, look at using the platform's text input support, which is outside the purview of a game engine (handles dead keys, capslock, copy-pasting, advanced input methods…).

When porting a game that never used scancodes (which is not the case with a decent engine, since scancodes are also closer to the hardware and faster), the other strategy might be more practical. You can map scancodes to keycodes using SDL2 functions SDL_GetKeyFromScancode and SDL_GetScancodeFromKey, or platform-specific equivalents. If you also use the SDL2 event loop, those functions will remain accurate across layout switches. Avoid functions like GetKeyboardLayout() on Windows; there is no guarantee that you'll be able to find the layout in a known list.