Comment gérer différentes dispositions de clavier?

Disons que j'ai un jeu qui utilise des contrôles WASD sur une disposition QWERTY. Essayer d'utiliser ces commandes sur, disons, une disposition Dvorak n'est pas idéal (équivalent à <A:HQWERTY). Évidemment, je voudrais utiliser les mêmes clés physiques que celles utilisées par QWERTY ( ,aoesur DVORAK).

J'ai trouvé quelques solutions possibles:

• Forcer l'utilisateur à utiliser QWERTY
  • évidemment pas idéal, surtout pour les utilisateurs internationaux
• Modifier les raccourcis en fonction de la disposition du clavier (WASD ->, aoe)
  • m'oblige à créer des cartes de disposition pour chaque disposition prise en charge (automatisable)
  • plus simple pour l'utilisateur s'il y a plus de raccourcis que simplement WASD
• Forcer l'utilisateur à définir lui-même les raccourcis
  • Plus flexible
  • Ennuyeux s'il y a beaucoup de raccourcis
  • Peut être utilisé conjointement avec la deuxième option
• Utiliser des codes clés matériels
  • cohérente entre les claviers?

Comment ce type de chose est-il généralement traité?

Écoutez les codes de numérisation. La manière de procéder dépend de votre système d'exploitation, que vous n'avez pas répertorié. Sous Windows, vous pouvez obtenir le code scancode pour un code de clé virtuelle donné auprès de WM_KEYDOWN et de ses amis en utilisant MapVirtualKey . Les codes de numérisation sont basés sur la clé physique et ne sont pas affectés par la disposition.

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

Alors oui, comme l'a dit Nicol Bolas, vous pouvez et devez laisser les utilisateurs contourner ce problème. Mais le faire fonctionner tout de suite n'est pas difficile et vos utilisateurs l'apprécieront.

Notez que vous traitez (probablement) mal la saisie de caractères, comme la grande majorité des développeurs de jeux. Assurez-vous que pour le texte, vous utilisez toujours WM_CHAR (ou l'équivalent sur d'autres systèmes d'exploitation) plutôt que d'utiliser WM_KEYDOWN pour la saisie de texte. Il est tout à fait faux de supposer que lorsque vous appuyez sur la touche «a», vous devez saisir un «a» dans un contrôle de saisie de texte, en raison de l'utilisation de touches mortes sur certaines dispositions. Vous pouvez également prendre en charge IME (ou équivalent OS) pour les marchés d'Asie de l'Est qui ont beaucoup plus de caractères que ce qui peut raisonnablement tenir sur un clavier et ont besoin d'une interface utilisateur spéciale pour taper. Manipuler IME dans un jeu est une douleur (la manipuler est une douleur), mais cela en vaut la peine, à mon avis, d'augmenter l'attrait de votre produit sur un ensemble beaucoup plus large de marchés. Encore une fois, WM_KEYDOWN ne doit jamais être utilisé pour du texte.

Vous devez toujours donner au joueur la possibilité de modifier ses affectations clés. C'est ainsi que cela est "généralement géré": laissez le joueur les changer. Certains joueurs règlent leur clavier sur QWERTY lorsqu'ils jouent à des jeux, car c'est ce que la plupart des jeux attendent. Certains les laisseront réglés sur leur clavier actuel et compteront sur la possibilité de changer les touches.

Dans le cas où vous ne pouvez pas écouter les codes de scan (comme par exemple lors du développement d'un jeu flash), vous pouvez créer une liaison de touches qui fonctionne pour autant de mises en page que possible. La plupart des dispositions de clavier sont très similaires, à quelques exceptions près.

Les dispositions de clavier suivant ISO 9995 (c'est le plus) sont disposées comme suit:

Fondamentalement, les touches noires sont sûres à utiliser.

La plupart des jeux à gros budget (ceux avec un distributeur international) fonctionneront prêts à l'emploi, en utilisant ZQSD au lieu de WASD pour les mises en page azerty. Un jeu décent introduira également la disposition au premier niveau, d'autres laisseront le joueur la découvrir à travers l'écran de personnalisation. La stratégie de mise en œuvre peut être détectée en demandant au système d'exploitation de changer de disposition. Soit le jeu utilise des scancodes (positions) en interne, et les mappe sur des codes-clés (symboles) lors de l'affichage des boîtes de dialogue et des invites de configuration; ou il utilise des codes clés en interne et détecte la mise en page au démarrage ou au premier lancement.

La première stratégie (scancodes en interne) est plus robuste, mais nécessite un peu de soin pour empêcher l'abstraction de fuir. N'oubliez pas de remapper les scancodes aux codes clés lors de la présentation des clés à l'utilisateur (dans les didacticiels, les invites et les boîtes de dialogue de personnalisation). Vous devrez toujours regarder les codes clés lors de la saisie de texte (en laissant un joueur taper son nom par exemple). Si vous avez besoin de gérer plus de texte que cela, envisagez d'utiliser la prise en charge de la saisie de texte de la plate-forme, qui ne relève pas du moteur de jeu (gère les touches mortes, le verrouillage des majuscules, le copier-coller, les méthodes de saisie avancées…).

Lors du portage d'un jeu qui n'a jamais utilisé de scancodes (ce qui n'est pas le cas avec un moteur décent, car les scancodes sont également plus proches du matériel et plus rapides), l'autre stratégie pourrait être plus pratique. Vous pouvez mapper des scancodes à des codes clés à l'aide des fonctions SDL2 SDL_GetKeyFromScancode et SDL_GetScancodeFromKey , ou des équivalents spécifiques à la plate-forme. Si vous utilisez également la boucle d'événements SDL2, ces fonctions resteront précises sur tous les commutateurs de disposition. Évitez les fonctions comme GetKeyboardLayout () sous Windows; il n'y a aucune garantie que vous pourrez trouver la mise en page dans une liste connue.