Mille coups : Comment le système d'entrée événementiel Unity alimente les contrôles dans Backyard Baseball 2026
Ceci est le deuxième d'une série d'articles de blog par Mega Cat Studios où ils partagent leur expertise Unity et leurs solutions pour les défis de développement de jeux commerciaux dans le monde réel. Dans ce billet, Matthew Wojtechko explore comment tirer parti du package événementiel Input System d’Unity pour améliorer la réactivité et réduire les sondages inefficaces.
Lire le premier billet de la série: Scaling Unity workflows: Leçons tirées des projets de taille moyenne à grande
La saisie est souvent la première chose que nous implémentons lorsque nous commençons un jeu, et pour cause: Si vous ne pouvez pas déplacer un personnage ou naviguer dans un menu, rien d’autre n’a d’importance. Cependant, le code de saisie "just get it working" a l'habitude de devenir permanent. Ce qui commence comme quelques simples lignes de sondage peut tranquillement devenir une base de code fragile qui s'effondre lorsque de véritables exigences, comme des contrôles reliables ou Multiplayer local, arrivent.
Chez Mega Cat Studios, nous sommes passés d'une vérification image par image constante (sondage) à un flux de travail événementiel. Si nous développons les QTE pour les réactions jumpscare dans Five Nights at Freddy’s: Into the Pit ou Multiplayer local pour Backyard Baseball 2026, tirer parti du pack Unity Input System permet de maintenir un gameplay réactif et maintenable.
Des fonctionnalités comme les suivantes deviennent pénibles à prendre en charge si elles ne sont pas à l'esprit pendant la programmation de l'entrée:
- Plusieurs périphériques d'entrée (clavier, contrôleur, tactile)
- Contrôles contraignants
- Navigation UI qui ne combat pas les entrées de gameplay
- Multiplayer local
- Un gameplay sensible au timing
Dans ce billet, nous allons expliquer comment nous utilisons le système de saisie pour résoudre ces problèmes. En cours de route, nous parlerons d’architecture – ce qui permet à nos projets d’évoluer et ce qui tend à s’effondrer sous son propre poids.
Le système de saisie d’Unity a évolué. Nous aussi.
Quand Unity a sorti le nouveau système d'entrée en 2020, il ne s'agissait pas seulement d'une cure de jouvence pour les anciennes fonctions Input.GetAxis et Input.GetButtonDown. Il s’agit d’une approche fondamentalement différente de l’entrée, axée sur les événements, les appareils et l’intention des joueurs. Voici les concepts fondamentaux que nous avons internalisés.
Actions
Les actions sont les éléments constitutifs. Dans Backyard Baseball 2026, ça ressemble à ça :
- Les Action Maps représentent les contextes d'entrée.
- Gameplay
- Menus
- Outils de débogage/développeur
- Les actions sont l’intention du joueur:
- Swing
- Glissière
- Base de vol
- Confirmer
- Annuler
Notre code de jeu parle à l'intention, pas aux appareils. Peut-être que le lecteur appuie sur la barre d'espace. Ou peut-être qu'ils tapent sur le bouton croix d'une manette PlayStation. Quoi qu’il arrive, notre code joueur doit seulement se soucier du moment où l’action « Swing » est effectuée. Ce niveau d'abstraction nous facilite la vie.
Reliures
Les liaisons sont les mappages périphérique-action concrets qui nous permettent de gérer plusieurs schémas de contrôle sans complexité supplémentaire. Une seule action peut réagir à plusieurs entrées de plusieurs appareils.
C'est ainsi que nous pouvons prendre en charge les configurations clavier + souris, contrôleur, tactile et accessibilité sans ramifier notre code dans l'oubli. Nous pouvons facilement rattacher les actions dans l'éditeur et à l'exécution. Nous approfondirons ce sujet dans une section ultérieure.
Réactivité
La contribution traditionnelle repose sur le sondage :
if (Input.GetButtonDown("Swing Bat"))
{
SwingBat();
}
C’est simple, mais cela lie la détection d’entrée à la boucle de trame. Si l'entrée est pressée et relâchée plus rapidement que le framerate, elle peut ne jamais être vue.
Pour les jeux qui reposent sur des réactions rapides, comme ceux des genres combat, rythme et plateforme de précision, des entrées incohérentes peuvent ruiner l'expérience. Et même pour les matchs à rythme lent, laisser tomber une entrée peut être dévastateur si c'est à un moment critique, comme lorsque le frappeur prend ce swing très important dans Backyard Baseball 2026.
Le système de saisie est conçu autour des événements. Vous vous abonnez une fois, et Unity vous avertit lorsque la saisie a lieu. Cela réduit les frais généraux du processeur, simplifie la logique et fait des entrées manquées un problème. Des appuis et relâchements sur les boutons aux changements de valeur d'axe, tout est en file d'attente, de sorte que les entrées ne se perdent jamais. Même à des fréquences d'images variables ou à des niveaux de vitesse de sous-fréquence d'images, ces événements sont traités dans l'ordre et livrés de manière fiable à vos rappels.
Le résultat ? Entrée qui bat mille.
Multiplayer local
Multiplayer local est un domaine où le système d'entrée fournit un avantage majeur par rapport à l'ancien gestionnaire d'entrée.
Avec le composant PlayerInput et les schémas de contrôle:
- Chaque joueur obtient sa propre instance d'action.
- Les appareils peuvent être appariés dynamiquement.
- Clavier divisé, contrôleurs multiples ou configurations hybrides « fonctionnent simplement ».
Fait important, les contrôles des joueurs sont isolés par conception. Fini l'indexation des périphériques ou les conflits de saisie entre les joueurs. Ce fut un énorme avantage pour l’équipe Mega Cat lorsque nous avons mis en place la coopérative de canapés dans Backyard Baseball 2026.
Si le Multiplayer local est même une possibilité pour votre projet, commencer par le package Input System pourrait vous éviter beaucoup de retravail par la suite.
Parfois, les développeurs continuent à utiliser le sondage même en utilisant le système de saisie. Il y a une certaine allure à taper simplement dans Keyboard.current.spaceKey.isPressed sans se soucier d'aucune autre configuration. Cela peut convenir pour certains projets, mais gardez à l’esprit que si vous construisez sur le long terme, l’abonnement à des rappels d’actions d’entrée est la meilleure approche.
Structure pour échelle
La lecture de la saisie est facile. Le véritable défi est de créer l'architecture qui intègre les entrées dans différents menus, modes de jeu et systèmes de gameplay.
Voici les modèles que nous avons utilisés sur plusieurs jeux expédiés:
- Contextes d'entrée distincts : Au minimum, la plupart des projets bénéficient des avantages suivants:
- Carte de gameplay – mouvement du joueur, combat, interactions
- Carte UI – navigation, confirmer/annuler, défilement
- Carte de débogage – raccourcis uniquement pour le développement comme les bascules de console ou la mise à l’échelle du temps
Pourquoi est-ce important ? Pour éviter les fuites d'entrée. Si vous ne séparez pas les contextes, il est beaucoup plus difficile d’éviter les cas de bord où, par exemple, appuyer sur la barre d’espace confirme un menu et fait sauter le lecteur. Action Maps nous permet d'activer et de désactiver explicitement des contextes d'entrée entiers lorsque l'état du jeu change. Cela rend les fuites d'entrée pratiquement un problème.
- Central Input Manager : Alors que le système de saisie prend en charge les InputActionReferences par objet, un grand projet bénéficie d'un gestionnaire de saisie unique faisant autorité. Un bon gestionnaire d'entrées généralement:
- Active et désactive les Action Maps
- Abonne aux rappels de saisie
- Gère les changements de périphériques
- Agit comme la frontière entre la logique d'entrée et de gameplay
Voici un exemple simple:
public class GameInputManager : MonoBehaviour
{
public PlayerInput playerInput;
public PlayerController player;
private void OnEnable()
{
playerInput.actions["Jump"].performed += OnJump;
playerInput.actions["Shoot"].performed += OnShoot;
}
private void OnDisable()
{
playerInput.actions["Jump"].performed -= OnJump;
playerInput.actions["Shoot"].performed -= OnShoot;
}
private void OnJump(InputAction.CallbackContext context)
{
Player.Jump();
}
private void OnShoot(InputAction.CallbackContext context)
{
Player.Shoot();
}
}
Dans beaucoup de nos bases de code, nous avons une classe personnalisée pour l'entrée de jeu qui contient des fonctions qui vous permettent d'enregistrer et de radier les rappels en fournissant à peine plus qu'une touche de chaîne. Nous ajoutons également un système de priorité qui nous permet d'arrêter d'écouter certaines entrées dans des scénarios spécifiques, tels que les contextes d'entrée mentionnés ci-dessus. Utiliser ce gestionnaire pour brancher l'entrée du joueur ressemble à ceci:
InputManager.Register(“Swing”, Priority.Character, SwingBat);
Les GameObjects contrôlés en entrée sont découplés de la logique d'entrée qui les contrôle. Cela rend le refactoring plus tard dans le processus moins coûteux, tout en simplifiant le code pour les développeurs qui travaillent avec.
Adoptez le rebinding
Les commandes reliables ne sont plus une caractéristique de luxe. Ils sont attendus pour l’accessibilité, la diversité des appareils et l’expérience utilisateur de base.
Beaucoup d'entre nous chez Mega Cat Studios avons implémenté le rebinding avec le gestionnaire d'entrées hérité, donc nous savons à quel point c'était douloureux (et c'est peut-être la raison de plus de quelques cheveux gris dans nos moustaches). Heureusement, le pack Input System nous offre cette fonctionnalité presque gratuitement.
InputActionRebindingExtensions.PerformInteractiveRebinding() fait le gros du travail; tout ce que nous devons faire est de le câbler dans le code du jeu. Nous le faisons généralement avec deux scripts qui divisent les préoccupations entre le frontend et le backend:
- RebindsManager
- Gère l'opération en cours de sorte qu'une seule action est en cours de réunification à la fois
- Désactiver les rappels lors de la rebinding
- Contient la référence de l'action d'entrée
- RebindActionUI
- Gère l'interaction pour démarrer et terminer l'opération
- Attaché à chaque panneau UI qui remappe l'entrée
« Au départ, nous n'avions pas de gestionnaire pour cela, donc le script de l'interface utilisateur seul gérait à la fois l'interaction et l'opération de rebind », explique Sofia Nacional, développeuse sur Backyard Baseball 2026. « Cela n’a pas évolué et a permis d’avoir plusieurs opérations actives de rebind en même temps. »
Une bonne organisation des entrées sur le backend donne aux joueurs plus de liberté pour personnaliser les choses sur le frontend, aussi. Prenons l'exemple des contextes de saisie. Dans un match de baseball, les actions des joueurs se déroulent dans des phases distinctes : frappe, lancer, mise en jeu et course de base. Ainsi, dans notre jeu, un joueur est autorisé à lier le bouton à la fois à «swing bat» et à «steal base» parce que ces deux actions ne se produisent jamais dans le même scénario. Les contextes d'entrée permettent d'autoriser facilement les bonnes liaisons dupliquées tout en empêchant celles qui posent problème et qui provoqueraient le déclenchement de plusieurs actions d'entrée.
L'entrée est un système
La plus grande erreur des équipes est de traiter l'entrée comme un détail de mise en œuvre plutôt que comme un système de jeu de base. L'entrée affecte tout: sensation de gameplay, convivialité de l'interface utilisateur et maintenabilité à long terme. Si vous prototypez ou expédiez quelque chose de petit, vous risquez de vous en tirer avec des sondages scattershot enfouis dans votre MonoBehaviors. Mais si votre jeu doit évoluer, vous avez besoin de quelque chose de robuste.
En tant que développeurs de jeux vidéo, nous travaillons pour le joueur ; c’est notre travail de lui donner les outils pour faire son travail correctement ! En adoptant une architecture événementielle, nous n'optimisons pas seulement le code, nous protégeons nos jeux contre les bugs qui contrarient le contrôle des joueurs et leur offrons la meilleure expérience possible.