Hiérarchie des informations du HUD mobile : quoi afficher en combat, dans le lobby et dans les modales

Les défaillances de HUD sont rarement « on a oublié une barre de vie » — ce sont trop d’éléments de même priorité sur un seul écran : des onglets de lobby pendant le combat, une boutique cliquable par-dessus une cinématique, ou un HUD sous-jacent qui capte encore les taps quand une modale est ouverte. Les maquettes de design sont souvent à image unique et n’indiquent jamais « masquer la monnaie en combat » — il vous faut une spec état × couche pour que l’ingénierie puisse régler visibilité, blocage des entrées et ordre de dessin.

Ci-dessous, Unity UGUI (Prefab, Canvas.sortingOrder, raycasts des Graphic) sert de terminologie principale. Godot : CanvasLayer layer + Control mouse_filter ; Cocos : ordre de dessin des nœuds + BlockInputEvents / bloqueurs plein écran — mêmes critères et mêmes tableaux. Détails sur la Safe Area, le texte flottant et l’ordre des Canvas : Safe Area, nombres de dégâts flottants. Appareil, toutes les locales et builds Release : checklist avant livraison points 1, 2 et 5.

Critères d’échec (un seul suffit = non validé) : pendant les flux modale / cinématique / paiement, le HUD sous-jacent reste interactif (sauf si la spec dit « demi-écran encore opérable ») ; en combat, une promo hors-combat non fermable bloque la zone de jeu ; la même info affichée deux fois (ex. pièces dans la barre du haut plus grande UI de pièces en combat) sans note produit ; des contrôles de l’état précédent subsistent (visibles ou bloquant encore les raycasts) ; avec les locales de stress multilingues, la mise en page minimale de combat tronque encore les textes longs (DE/ES, etc.).

---

Définir d’abord les états, puis les contrôles

État de jeu (exemples)	Objectif du HUD	À afficher habituellement	À masquer / dégrader habituellement
Lobby / accueil	Navigation + ressources + événements	Monnaie en haut, onglets en bas, entrée d’événement	Compétences de combat, réticule
Combat / en niveau	Actions + infos de survie	Vie, compétences, pause	Onglets de lobby, bannières d’événement plein écran
Cinématique / CG	Aucune entrée ou passer uniquement	Bouton Passer	Presque tout le HUD (ou passer uniquement)
Modale (boutique, réglages)	Focus sur la boîte de dialogue	Contrôles dans la modale	HUD sous-jacent raycasts désactivés ou couche entière masquée
Paiement / conformité	Terminer le flux	Conditions, confirmer	Superpositions promo en jeu

Validez l’énumération des états avec design + ingénierie (ex. GameUIState.Lobby | Combat | Cinematic | Modal). Les racines d’UI s’abonnent à la machine à états (groupes de Prefabs Unity / branches de scène Godot / prefabs Cocos) — évitez les SetActive / visible éparpillés sur chaque script de bouton.

---

Couches et ordre de tri (spec indépendante du moteur)

Documentez du bas vers le haut (nombre plus élevé = devant) :

Couche	Contenu	Entrée
L0	Fond plein écran / débordement d’UI de scène	Aucune
L1	HUD de combat (vie, emplacement de joystick)	Oui
L2	Texte flottant / astuces de combat	Aucun raycast (nombres de dégâts flottants)
L3	Toast système / bandeau défilant	Généralement aucune
L4	Modale / boîte de dialogue plein écran	Oui ; bloque les taps de L1–L3
L5	Perte réseau, mise à jour forcée	Oui ; bloque tout

Unity : sortingOrder / plusieurs Canvas ; Godot : CanvasLayer layer ; Cocos : ordre des frères sous un même Canvas ou Canvas en couches + masque. Quand une modale s’ouvre, élevez L4 et désactivez les raycasts de L1 / mouse_filter / BlockInput — pas seulement « dessiné au-dessus mais les taps passent à travers ».

---

Priorité des informations (exemple de combat)

Si le combat ne peut garder que N blocs lisibles sur petits écrans, plafonds par défaut :

Priorité	Bloc	Stratégie de dégradation
P0	Vie / lié à la condition d’échec	Ne pas masquer
P0	Pause / quitter le combat	Ne pas masquer
P1	Compétences / actions principales	Fusionner en moins de boutons
P2	Court texte d’objectif	Icône + détail en appui long
P3	Monnaie, entrée d’événement	Masqués en combat par défaut ou dans le menu pause
P3	Entrée de chat	Réduire en icône

Les dégradations doivent rester lisibles dans les locales de stress multilingues (DE/ES, etc.) — pas des tests de réduction en anglais uniquement.

---

Validation (5 étapes)

1. Lister les états — À partir du flux principal, énumérez les transitions (entrer en niveau, ouvrir la boutique, CG, reconnexion).
2. Capture par état — Éditeur Play et appareil Release chacun (points 1 et 5 avant livraison) ; vérifiez que les nœuds en SetActive(false) / visible=false bloquent encore les entrées.
3. Contrôle ponctuel des modales — Avec boutique / réglages / paiement ouverts, les taps sur les anciens boutons du HUD ne doivent rien faire (raycast transparent plein écran ou masque BlockInput).

4. Croiser avec la Safe Area — Contrôles P0 de combat dans l’encart sûr (Safe Area).
5. Commiter des assets versionnés — Le tableau d’états pilote la visibilité (Unity ScriptableObject / Godot Resource / config Cocos) — pas des masquages temporaires uniquement dans la scène.

---

Ce que le design doit ajouter

Livrable	Objectif
Wireframes par état (au moins Lobby / Combat / Modale)	L’ingénierie configure la visibilité
Liste « peut masquer » du combat sur la maquette	Éviter de peindre chaque élément sur une seule image
Spec de modale : fond assombri, tap-through autorisé ?	Définit la politique de raycast
Ordre z de la couche promo / événement	Aligner avec L4/L5

Les designers n’ont pas besoin d’écrire la machine à états — tableaux + annotations réduisent les suppositions.

---

Aiguillage des correctifs

Symptôme	Cause probable	Action	Responsable
On peut encore taper le combat après la boîte de dialogue	Raycasts sous-jacents actifs	Désactiver le raycast du Graphic sur la couche modale / masque plein écran	Ingénierie
Événement plein écran en combat	Pas de tableau d’états	Masquer P3 en combat ; validation design	Ingénierie + design
HUD restant après la cinématique	Pas de hook d’état Cinematic	La machine à états masque le HUD uniformément	Ingénierie
Deux affichages de monnaie	Barre de lobby non désactivée en combat	Masquer la barre du haut en Combat ou fusionner la source de données	Ingénierie + design
Locale longue tronquée dans la mise en page minimale de combat	DE/ES non testés	Parcours débordement de locale	Design + ingénierie

---

FAQ

Deux Canvas pour le lobby et le combat ?
Très bien — ou un seul Canvas avec des groupes. Ce qui compte, c’est la visibilité par état + les raycasts, pas le nombre de Canvas.

Boutique en demi-écran — est-ce une modale ?
Oui. Spécifiez si le sous-jacent est cliquable et si la logique de combat se met en pause.

Conflit avec l’UX « less is more » ?
Le tableau de hiérarchie est une règle produit, pas de l’esthétique ; P3 peut se rouvrir pour les événements via des flags de la machine à états.

Barres au-dessus en world-space en 3D ?
Ce sont des infos de combat, gérées avec L1 ; Les règles de tri world-space s’alignent avec nombres de dégâts flottants et Safe Area.