Como lidar com diferentes layouts de teclado?

Digamos que eu tenho um jogo que usa controles WASD em um layout QWERTY. Tentar usar esses controles em, digamos, um layout Dvorak não é ideal (equivalente ao <A:HQWERTY). Obviamente, eu gostaria de usar as mesmas chaves físicas que o QWERTY usaria ( ,aoeno DVORAK).

Eu vim com algumas soluções possíveis:

• Forçar o usuário a usar QWERTY
  • obviamente não é o ideal, especialmente para usuários internacionais
• Alterar atalhos com base no layout do teclado (WASD ->, aoe)
  • me obriga a fazer mapas de layout para cada layout suportado (automatizável)
  • mais fácil para o usuário se houver mais atalhos do que apenas WASD
• Forçar o usuário a definir os próprios atalhos
  • Mais flexível
  • Irritante se houver muitos atalhos
  • Pode ser usado em conjunto com a segunda opção
• Use códigos de chave de hardware
  • consistente nos teclados?

Como esse tipo de coisa geralmente é tratado?

Ouça os códigos de digitalização. Como isso é feito depende do seu sistema operacional, que você não listou. No Windows, você pode obter o scancode para um determinado código de chave virtual de WM_KEYDOWN e amigos usando o MapVirtualKey . Os códigos de digitalização são baseados na chave física e não são afetados pelo layout.

Leia rapidamente http://www.altdevblogaday.com/2011/10/02/i-never-managed-to-go-left-on-first-try/ .

Então, sim, como Nicol Bolas disse, você pode e deve permitir que os usuários resolvam isso. Mas apenas fazê-lo funcionar imediatamente não é difícil e seus usuários irão apreciá-lo.

Observe que você (provavelmente) está lidando com a entrada de caracteres incorretamente, como a grande maioria dos desenvolvedores de jogos. Certifique-se de que, para o texto, você sempre use WM_CHAR (ou o equivalente em outros sistemas operacionais) em vez de usar WM_KEYDOWN para entrada de texto. É completamente errado supor que, quando a tecla 'a' é pressionada, você deve inserir um 'a' em um controle de entrada de texto, devido ao uso de Dead Keys em alguns layouts. Você também pode oferecer suporte ao IME (ou equivalente ao SO) para mercados do Leste Asiático que possuem muito mais caracteres do que cabem razoavelmente em um teclado e precisam de interface do usuário especial para digitar. Lidar com o IME em um jogo é uma dor (lidar com isso é uma dor), mas, na minha opinião, vale a pena aumentar o apelo do seu produto para um conjunto de mercados muito, muito maior. Novamente, WM_KEYDOWN nunca deve ser usado para texto, nunca.

Você deve sempre dar ao jogador a capacidade de alterar suas principais atribuições. É assim que é "geralmente tratado": deixe o jogador alterá-los. Alguns jogadores colocam o teclado em QWERTY quando jogam, porque é o que a maioria dos jogos espera. Alguns os deixarão configurados no teclado atual e dependerão da capacidade de alterar as teclas.

No caso de você não conseguir ouvir códigos de verificação (como por exemplo, ao desenvolver um jogo em flash), é possível criar uma ligação de chave que funcione para o maior número possível de layouts. A maioria dos layouts de teclado é muito semelhante, com apenas algumas exceções.

Os layouts de teclado que seguem a ISO 9995 (a maioria) são organizados da seguinte maneira:

Basicamente, as teclas pretas são seguras de usar.

A maioria dos jogos de grande orçamento (aqueles com um distribuidor internacional) funcionará imediatamente, usando o ZQSD em vez do WASD para layouts de azerty. Um jogo decente também apresentará o layout no primeiro nível, outros deixarão o jogador descobri-lo através da tela de personalização. A estratégia de implementação pode ser detectada solicitando ao sistema operacional que troque de layout. O jogo usa scancodes (posições) internamente e mapeia-os para códigos-chave (símbolos) ao mostrar diálogos e avisos de configuração; ou usa códigos de chave internamente e detecta o layout na inicialização ou no primeiro lançamento.

A primeira estratégia (scancodes internamente) é mais robusta, mas requer um pouco de cuidado para impedir que a abstração vaze. Lembre-se de remapear scancodes para keycodes ao apresentar as chaves ao usuário (em tutoriais, avisos e caixas de diálogo de personalização). Você ainda precisará procurar códigos de acesso ao receber entrada de texto (permitindo que um player digite seu nome, por exemplo). Se você precisar manipular mais texto do que isso, use o suporte à entrada de texto da plataforma, que está fora do alcance de um mecanismo de jogo (lida com chaves inoperantes, capslock, cópia-colagem, métodos de entrada avançados ...).

Ao portar um jogo que nunca usou scancodes (o que não acontece com um mecanismo decente, já que os scancodes também estão mais próximos do hardware e mais rápidos), a outra estratégia pode ser mais prática. É possível mapear scancodes para códigos-chave usando as funções SDL2 SDL_GetKeyFromScancode e SDL_GetScancodeFromKey ou equivalentes específicos da plataforma. Se você também usar o loop de eventos SDL2, essas funções permanecerão precisas nas opções de layout. Evite funções como GetKeyboardLayout () no Windows; não há garantia de que você poderá encontrar o layout em uma lista conhecida.