¿Cómo puedo manejar diferentes diseños de teclado?

Digamos que tengo un juego que usa controles WASD en un diseño QWERTY. Intentar usar estos controles en, por ejemplo, un diseño Dvorak no es ideal (equivalente a <A:HQWERTY). Obviamente, me gustaría usar las mismas teclas físicas que usaría QWERTY ( ,aoeen DVORAK).

He encontrado algunas soluciones posibles:

• Forzar al usuario a usar QWERTY
  • obviamente no es ideal, especialmente para usuarios internacionales
• Cambiar accesos directos basados ​​en la distribución del teclado (WASD ->, aoe)
  • me obliga a hacer mapas de diseño para cada diseño compatible (automatizable)
  • más fácil para el usuario si hay más atajos que solo WASD
• Forzar al usuario a definir atajos por sí mismo
  • Mas flexible
  • Molesto si hay muchos atajos
  • Se puede usar junto con la segunda opción
• Usar códigos de hardware
  • consistente a través de teclados?

¿Cómo se maneja generalmente este tipo de cosas?

Escuche los códigos de escaneo. Cómo se hace esto depende de su sistema operativo, que no enumeró. En Windows, puede obtener el código de escaneo para un código de clave virtual dado de WM_KEYDOWN y sus amigos utilizando MapVirtualKey . Los códigos de escaneo se basan en la clave física y no se ven afectados por el diseño.

Lea rápidamente http://www.altdevblogaday.com/2011/10/02/i-never-managed-to-go-left-on-first-try/ .

Entonces sí, como dijo Nicol Bolas, puede y debe permitir que los usuarios lo solucionen. Pero hacer que funcione de inmediato no es difícil y sus usuarios lo apreciarán.

Tenga en cuenta que (probablemente) está manejando mal la entrada de caracteres, como la gran mayoría de los desarrolladores de juegos. Asegúrese de que para el texto, siempre use WM_CHAR (o el equivalente en otros sistemas operativos) en lugar de usar WM_KEYDOWN para la entrada de texto. Es completamente erróneo suponer que, cuando se presiona la tecla 'a', debe ingresar una 'a' en un control de entrada de texto, debido al uso de Dead Keys en algunos diseños. También puede admitir IME (o el equivalente del sistema operativo) para los mercados de Asia oriental que tienen muchos más caracteres de los que caben razonablemente en un teclado y necesitan una IU especial para escribir. Manejar IME en un juego es una molestia (manejarlo en absoluto es una molestia), pero en mi opinión vale la pena aumentar el atractivo de su producto para un conjunto de mercados mucho, mucho más grande. Nuevamente, WM_KEYDOWN nunca se utilizará para texto, nunca.

Usted debe siempre dar al jugador la posibilidad de cambiar sus asignaciones de teclas. Así es como se "maneja habitualmente": deje que el jugador los cambie. Algunos jugadores configurarán su teclado en QWERTY cuando jueguen porque eso es lo que la mayoría de los juegos esperan. Algunos los dejarán configurados en su teclado actual y dependerán de la capacidad de cambiar las teclas.

En el caso de que no pueda escuchar los códigos de escaneo (como, por ejemplo, al desarrollar un juego flash), puede hacer un enlace de teclas que funcione para la mayor cantidad de diseños posible. La mayoría de los diseños de teclado son muy similares, con solo algunas excepciones.

Los diseños de teclado que siguen a ISO 9995 (eso es todo) están organizados así:

Básicamente, las teclas negras son seguras de usar.

La mayoría de los juegos de gran presupuesto (aquellos con un distribuidor internacional) funcionarán de fábrica, usando ZQSD en lugar de WASD para diseños de azerty. Un juego decente también introducirá el diseño en el primer nivel, otros permitirán que el jugador lo descubra a través de la pantalla de personalización. La estrategia de implementación se puede detectar pidiéndole al sistema operativo que cambie de diseño. O bien el juego usa códigos de escaneo (posiciones) internamente y los asigna a códigos de teclas (símbolos) cuando muestra cuadros de diálogo y mensajes de configuración; o utiliza códigos clave internamente y detecta el diseño en el inicio o en el primer inicio.

La primera estrategia (códigos de escaneo internamente) es más sólida, pero requiere un poco de cuidado para evitar que la abstracción se filtre. Recuerde reasignar códigos de escaneo a códigos clave cuando presente claves al usuario (en tutoriales, indicaciones y diálogos de personalización). Aún tendrá que mirar los códigos clave al tomar entrada de texto (permitiendo que un jugador escriba su nombre, por ejemplo). Si necesita manejar más texto que eso, mire usando el soporte de entrada de texto de la plataforma, que está fuera del alcance de un motor de juego (maneja teclas muertas, bloqueo de mayúsculas, pegado de copia, métodos de entrada avanzados ...).

Al portar un juego que nunca usó códigos de escaneo (que no es el caso con un motor decente, ya que los códigos de escaneo también están más cerca del hardware y más rápido), la otra estrategia podría ser más práctica. Puede asignar códigos de escaneo a códigos clave utilizando las funciones SDL2 SDL_GetKeyFromScancode y SDL_GetScancodeFromKey , o equivalentes específicos de la plataforma. Si también usa el bucle de eventos SDL2, esas funciones seguirán siendo precisas en todos los conmutadores de diseño. Evite funciones como GetKeyboardLayout () en Windows; no hay garantía de que pueda encontrar el diseño en una lista conocida.