Comment garder visibles les commandes de l'animal et le personnage dans une interface de jeu compacte

Listez les informations et les actions dont le joueur a besoin pendant la boucle de jeu principale. Une première approche utile peut inclure l'animal, une action principale comme le nourrir ou jouer, ainsi qu'un indicateur compact précisant si cette action est disponible. Déplacez les paramètres, les collections et les actions moins fréquentes dans un menu secondaire ou un panneau contextuel temporaire. Il s'agit d'une méthode de conception et non d'une règle absolue : un jeu dont la tâche centrale consiste à choisir parmi plusieurs actions peut nécessiter d'afficher davantage de commandes à la fois.

Définissez une zone visuelle pour le personnage avant d'y intégrer les commandes. Veillez à ce que les éléments essentiels de sa silhouette et de son expression restent bien visibles, et évitez de placer des boutons ou des libellés par-dessus. Si une action nécessite de toucher directement l'animal, laissez cette zone d'interaction dégagée ; si les commandes se superposent à la scène de jeu, assurez-vous qu'elles ne masquent pas la partie du personnage que les joueurs doivent voir. Les recommandations d'Apple en matière de commandes de jeu préconisent de réduire les commandes virtuelles lorsqu'une interaction directe avec les objets du jeu peut suffire (Game controls).

Regroupez les actions fréquentes là où elles sont faciles d'accès, et placez les actions secondaires plus loin ou derrière un menu. Sur un écran tactile, évitez d'entasser les boutons dans la zone où la main du joueur risque de masquer l'animal. Apple suggère de placer les commandes tactiles fréquentes à portée du pouce et les commandes secondaires vers le haut de l'écran ; ses recommandations précisent également de tenir compte d'une portée confortable et des limites de l'appareil. Considérez ces indications comme des points de départ à tester sur l'appareil et l'orientation cibles, et non comme une disposition figée pour chaque jeu.

Veillez à ce que l'icône visible soit compacte sans pour autant réduire la taille réelle de la cible tactile. Apple recommande un minimum de 44 par 44 points pour les commandes fréquemment utilisées et de 28 par 28 points pour les commandes moins importantes sur ses plateformes. Android recommande au moins 48 par 48 pixels indépendants de la densité pour les cibles tactiles interactives. Ces mesures étant propres à chaque plateforme, utilisez les unités et directives appropriées plutôt que de considérer ces chiffres comme interchangeables (Apple game controls, Android accessibility guidance). Laissez un espacement suffisant pour éviter les appuis accidentels, en particulier lorsque deux actions produisent des résultats différents.

Un animal peut techniquement rester à l'écran tout en étant difficile à distinguer lorsque des commandes, des libellés ou des panneaux décoratifs lui font concurrence. Limitez le poids visuel des éléments d'interface secondaires : privilégiez de petites icônes, des libellés courts et des panneaux qui n'occupent que l'espace nécessaire. Gardez le visage de l'animal et les autres détails importants bien visibles lors des actions les plus cruciales. Si la scène de jeu change sous le texte ou les icônes, envisagez un arrière-plan discret ou un contour afin que l'interface reste lisible sans ajouter de grand panneau opaque.

Vérifiez le texte et les icônes sur les zones claires et sombres de la scène. Un contraste efficace sur un arrière-plan donné peut disparaître lorsque l'animal se déplace ou que la scène change. Pour le texte, les recommandations WCAG du W3C préconisent un rapport de contraste de 4,5:1 pour le texte de taille normale et de 3:1 pour le texte de grande taille. Les WCAG s'appliquent au contenu web plutôt qu'aux jeux vidéo, mais leurs seuils de contraste constituent un repère utile pour tester le texte d'interface sur des arrière-plans variables (W3C contrast guidance). Ne vous fiez pas uniquement à la couleur pour signaler qu'une action est indisponible : modifiez également de manière visible son libellé, sa forme ou son état.

Si les commandes permanentes occupent trop de place, faites apparaître les actions secondaires lorsque le joueur ouvre un menu ou sélectionne l'animal. Masquez les actions indisponibles dans l'état actuel et affichez un changement d'état distinct lorsqu'une commande est activée. Apple recommande expressément d'adapter les commandes virtuelles visibles au contexte de jeu, notamment en masquant celles qui ne sont pas pertinentes et en mettant davantage en valeur les commandes actives. Une approche pratique consiste à garder l'action principale disponible, puis à afficher les choix associés dans un menu compact qui se ferme après la sélection.

Faites en sorte que les changements d'état soient prévisibles. Une commande qui disparaît au moment où le joueur s'apprête à l'utiliser peut prêter à confusion ; réservez donc le masquage ou l'affichage aux actions dont la disponibilité découle clairement de l'état actuel. Si un bouton devient inactif, indiquez cet état et, si nécessaire, expliquez brièvement la raison de ce changement. Évitez qu'un menu déroulant ne vienne recouvrir la tête de l'animal ou la zone où le joueur doit appuyer ensuite.

Concevez l'interface en fonction de la zone utilisable, et non du simple rectangle extérieur de l'écran. Les encoches, les découpes d'appareil photo, les barres système et les zones de gestes peuvent empiéter sur les commandes importantes situées près des bords. Les directives de mise en page d'Apple définissent les zones de sécurité comme des régions qui permettent d'éviter que le contenu ne chevauche des éléments d'interface et des fonctionnalités matérielles. De même, Android recommande de respecter les marges intérieures relatives aux barres système, aux gestes et aux découpes d'écran, en maintenant les commandes critiques à l'écart de ces dernières (Apple layout guidance, Android edge-to-edge guidance). Les graphismes d'arrière-plan peuvent s'étendre jusqu'au bord tandis que les éléments interactifs restent en retrait.

Ne partez pas du principe qu'une disposition compacte unique conviendra à tous les formats d'image. Ancrez les commandes à la zone utilisable et laissez l'espacement ou le regroupement s'adapter lorsque la largeur disponible varie. Les recommandations de développement de jeux Android pour Unity préconisent d'utiliser l'API des zones de sécurité et de prendre en charge différentes tailles d'écran et formats d'image. Ne testez les modes portrait ou paysage que si le jeu les prend en charge, et revérifiez l'affichage après une rotation, un redimensionnement de fenêtre ou le pliage de l'appareil si ces configurations sont prévues (Android guidance for Unity games on large screens).

Une maquette statique ne permet pas de voir quelles zones sont masquées par les doigts du joueur en cours d'utilisation. Évaluez l'interface à la taille réelle de l'écran cible, puis effectuez les actions principales tout en vérifiant si des détails du personnage sont cachés, si des erreurs de saisie se produisent et si des commandes chevauchent les éléments du système. Répétez le test sur le plus petit écran pris en charge ainsi que sur un format d'image plus large ou plus haut. Si possible, demandez à une personne qui ne connaît pas l'interface de réaliser la tâche principale et observez où elle appuie, hésite ou perd de vue l'animal.

Utilisez une brève liste de vérification (succès/échec) pour chaque configuration prise en charge :

• L'animal reste visible pendant l'action principale, y compris sa tête ou ses autres détails essentiels.

• L'action principale est facilement accessible, présente un état d'activation clair et ne chevauche aucune autre cible.

• Les libellés et les indicateurs d'état importants restent lisibles sur les différents arrière-plans de la scène.

• Aucune commande essentielle ne se trouve sous une encoche, une barre système ou une zone de gestes.

• L'ouverture d'une commande secondaire ne masque pas la partie du personnage ou de la zone de jeu requise pour l'étape suivante.

En cas d'échec à un point de contrôle, modifiez un seul élément à la fois : supprimez un élément peu prioritaire, déplacez une commande vers le bord de la zone de jeu tout en respectant les marges de sécurité, ou n'affichez les actions secondaires que lorsque c'est nécessaire. Testez à nouveau la même interaction. Cela permet de déterminer plus facilement si la modification a résolu le problème de visibilité ou si elle l'a simplement déplacé ailleurs.

• Apple Developer, Game controls

• Apple Developer, Layout

• Android Developers, Make apps more accessible

• Android Developers, Edge-to-edge design

• Android Developers, Make your Unity game great on all form factors

• W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.3: Contrast (Minimum)