Action maps d'Unity Input System : contextes, control schemes et remappage persistant

Nommer les intentions avant les touches

Le code de gestion des entrées est plus facile à maintenir lorsque le gameplay exprime une intention, comme interagir, diriger ou confirmer. Une touche physique n'est qu'une manière parmi d'autres d'exprimer cette intention. Commencez par une courte liste d'intentions et déterminez lesquelles doivent être disponibles en même temps. Cela évite qu'un raccourci de menu reste par erreur une commande de déplacement après un changement d'interface.

Distinguer les couches

Une action représente une intention d'entrée, un binding la relie à des contrôles, et une action map regroupe les actions qui peuvent être activées ensemble. [1] Les control schemes associent des groupes de bindings à des exigences en matière de périphériques ; ils ne remplacent pas votre politique de contextes de gameplay. [2] Ces concepts correspondent à Input System 1.14. Séparez les noms de contexte des noms de périphérique, afin que les joueurs à la manette et ceux au clavier puissent accéder au même état de jeu.

Confier la responsabilité à un seul composant

Laissez un unique propriétaire de contexte décider quelles maps de gameplay et d'interface sont actives. Les autres composants consomment les actions au lieu d'activer chacun de leur côté des maps concurrentes. Avec PlayerInput, utilisez les actions propres à ce joueur ; plusieurs composants peuvent disposer de copies privées d'un même asset d'actions. [3] Consignez les transitions de map au même titre que les transitions de pause et de prise de contrôle (possession), afin de pouvoir reproduire un problème d'entrée à partir d'une courte trace d'événements.

Exemple : manœuvrer une grue de chargement

Un personnage marche jusqu'à une grue et s'installe dans son siège. Désactivez la map de marche, activez la map de la grue et conservez une action de pause choisie délibérément. Quitter le siège inverse cette transition. Un stick de manette et des bindings clavier expriment tous deux l'intention de déplacement de la grue, sans modifier le code de gameplay de celle-ci. Pendant un écran de remappage, suspendez l'action concernée et indiquez quel binding est en cours de modification. Définissez l'annulation, rejetez les contrôles non autorisés, traitez les conflits selon une politique visible et restaurez l'état voulu des maps à chaque sortie possible. Testez la sortie de l'écran par le bouton d'annulation ainsi que par la fermeture de l'ensemble du menu.

Persistance et limites

Les surcharges de bindings peuvent être sérialisées avec SaveBindingOverridesAsJson et restaurées avec LoadBindingOverridesFromJson. [2] Stockez ces données dans le système de sauvegarde de votre choix et prévoyez un moyen de revenir aux valeurs par défaut. Versionnez les paramètres lorsque les bindings livrés changent, car une ancienne surcharge peut ne plus correspondre à la disposition voulue. Testez deux joueurs locaux, la reconnexion des périphériques, les contrôles maintenus pendant un changement de map et des sessions de remappage répétées. Un chemin de binding correct ne prouve ni que le bon joueur possède le périphérique, ni que la map est activée, ni que l'interface affiche le binding effectif.

Sources

1. Input System 1.14: Actions — Unity Technologies.
2. Input System 1.14: Action bindings — Unity Technologies.
3. Input System 1.14: Player Input component — Unity Technologies.