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é?
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.
la source
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 source
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.
la source