Come posso gestire diversi layout di tastiera?

Diciamo che ho un gioco che utilizza i controlli WASD su un layout QWERTY. Cercare di usare questi controlli su, diciamo, un layout Dvorak non è l'ideale (equivalente a <A:Hsu QWERTY). Ovviamente, vorrei usare gli stessi tasti fisici di QWERTY ( ,aoesu DVORAK).

Ho escogitato alcune possibili soluzioni:

• Forza l'utente a usare QWERTY
  • ovviamente non ideale, soprattutto per utenti internazionali
• Cambia scorciatoie in base al layout della tastiera (WASD ->, aoe)
  • mi costringe a creare mappe di layout per ogni layout supportato (automatizzabile)
  • più semplice per l'utente se ci sono più scorciatoie rispetto a WASD
• Forzare l'utente a definire autonomamente le scorciatoie
  • Più flessibile
  • Fastidioso se ci sono molte scorciatoie
  • Può essere utilizzato insieme alla seconda opzione
• Usa codici chiave hardware
  • coerente tra le tastiere?

Come viene gestito questo tipo di cose?

Ascolta i codici di scansione. Il modo in cui ciò avviene dipende dal tuo sistema operativo, che non hai elencato. Su Windows, puoi ottenere lo scancode per un determinato codice di chiave virtuale da WM_KEYDOWN e dagli amici usando MapVirtualKey . I codici di scansione si basano sulla chiave fisica e non sono interessati dal layout.

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

Quindi sì, come diceva Nicol Bolas, puoi e dovresti permettere agli utenti di aggirarlo. Ma farlo funzionare subito non è difficile e i tuoi utenti lo apprezzeranno.

Nota che stai (probabilmente) gestendo l'immissione dei caratteri in modo errato, come la stragrande maggioranza degli sviluppatori di giochi. Assicurarsi che per il testo, si usi sempre WM_CHAR (o l'equivalente su altri sistemi operativi) anziché utilizzare WM_KEYDOWN per l'immissione di testo. È del tutto errato supporre che quando si preme il tasto 'a' si debba inserire una 'a' in un controllo di immissione del testo, a causa dell'uso di Dead Key in alcuni layout. Puoi anche supportare IME (o equivalente del sistema operativo) per i mercati dell'Asia orientale che hanno molti più caratteri di quanti possano ragionevolmente adattarsi a una tastiera e che necessitano di un'interfaccia utente speciale per digitare. Gestire l'IME in un gioco è una seccatura (gestirla del tutto è una seccatura), ma secondo me vale la pena aumentare l'appeal del tuo prodotto su un insieme di mercati molto più ampio. Ancora una volta, WM_KEYDOWN non deve mai essere usato per il testo, mai.

Dovresti sempre dare al giocatore la possibilità di cambiare le assegnazioni delle chiavi. Ecco come viene "di solito gestito": lascia che il giocatore li cambi. Alcuni giocatori imposteranno la tastiera su QWERTY quando giocano, perché è quello che si aspettano molti giochi. Alcuni li lasceranno impostati sulla tastiera corrente e si affideranno alla possibilità di cambiare i tasti.

Nel caso in cui non sia possibile ascoltare i codici di scansione (come ad esempio quando si sviluppa un gioco in flash) è possibile creare un'associazione di tasti che funzioni per il maggior numero possibile di layout. La maggior parte dei layout di tastiera sono molto simili, con poche eccezioni.

I layout di tastiera secondo ISO 9995 (che è la maggior parte) sono disposti in questo modo:

Fondamentalmente i tasti neri sono sicuri da usare.

La maggior parte dei giochi a budget elevato (quelli con un distributore internazionale) funzioneranno immediatamente, usando ZQSD invece di WASD per layout azerty. Un gioco decente introdurrà anche il layout nel primo livello, altri lo faranno scoprire al giocatore attraverso la schermata di personalizzazione. La strategia di implementazione può essere rilevata chiedendo al sistema operativo di cambiare layout. O il gioco utilizza scancodes (posizioni) internamente e li mappa su keycodes (simboli) quando mostra finestre di dialogo e prompt di configurazione; oppure utilizza codici chiave internamente e rileva il layout all'avvio o al primo avvio.

La prima strategia (scancodes internamente) è più solida, ma richiede un po 'di attenzione per evitare che l'astrazione coli. Ricordare di rimappare gli scancodes ai keycode quando si presentano le chiavi all'utente (in tutorial, prompt e finestre di dialogo di personalizzazione). Avrai comunque bisogno di guardare i codici chiave quando prendi l'inserimento di testo (lasciando ad esempio un giocatore digitare il proprio nome). Se hai bisogno di gestire più testo di quello, guarda usando il supporto per l'immissione di testo della piattaforma, che è al di fuori della sfera di un motore di gioco (gestisce chiavi morte, blocco maiuscole, copia-incolla, metodi di input avanzati ...).

Quando si esegue il porting di un gioco che non ha mai usato scancodes (che non è il caso di un motore decente, poiché gli scancodes sono anche più vicini all'hardware e più veloci), l'altra strategia potrebbe essere più pratica. È possibile mappare gli scancodes ai keycode usando le funzioni SDL2 SDL_GetKeyFromScancode e SDL_GetScancodeFromKey o equivalenti specifici della piattaforma. Se si utilizza anche il loop degli eventi SDL2, tali funzioni rimarranno accurate su tutti gli switch di layout. Evita funzioni come GetKeyboardLayout () su Windows; non vi è alcuna garanzia che sarete in grado di trovare il layout in un elenco noto.