Zone de sécurité de l'interface de jeu et QA appareil : ordre de débogage et corrections de Prefabs
Quand l'éditeur Unity semble correct mais que l'encoche coupe le HUD ou que les taps ratent : classer les échecs, déboguer Canvas Scaler et Screen.safeArea, corriger Prefabs vs ré-export Studio.
- game-ui-design
- game-dev-ai
- ui-to-engine
- safe-area
- unity
- godot
- cocos
- vberai
- qa
- 2026
Le rapport le plus courant : la Game view semble correcte, mais sur un téléphone allongé le HUD se retrouve sous l’encoche, ou les boutons semblent cliquables mais les taps ratent. La Safe Area n’est pas « décaler l’Anchor » — c’est la politique du Canvas racine, le fond full-bleed vs le contenu en retrait, et si le safeArea d’exécution correspond au canal.
classes d’échec, ordre de débogage Unity UGUI, règles de correction des Prefabs, et spécificités canal/mini-jeu. Les repères de zone de sécurité de l’item 7 du handoff design sont résumés sous « ce que le design doit fournir » ; la portée appareil de l’item 1 pré-lancement est développée ici — pas une répétition de la checklist moteur + MCP Raycast / premier Play.
Godot / Cocos : Faire correspondre à DisplayServer.get_display_safe_area() / widgets SafeArea du moteur ; même ordre d’étapes qu’Unity ci-dessous.
Critères d’échec (un seul suffit = non validé) : interface principale lisible ou boutons requis sous occlusion système (encoche, indicateur home, coins arrondis) ; décalage visuel vs hit évident ; Éditeur 16:9 uniquement sans aspect cible sur appareil ; comportement Safe Area Dev vs Release différent sans spec.
Classer d’abord : clip, décalage, ou fond uniquement
| Symptôme | Suspect principal | Étape de debug |
|---|---|---|
| Clip visuel (texte/icônes dans l’encoche) | Contenu non en retrait ; racine traitée comme plein écran | Vérifier safeArea vs rects de contenu |
| Décalage de tap (semble correct, rate) | Mode d’échelle Canvas, Canvas multiples, caméra désalignée | Raycast EventSystem + Canvas renderMode |
| Fond clippé, boutons OK | Fond full-bleed par design, contenu en retrait | Pas un échec si la spec l’autorise |
| Incorrect après rotation | Aucun listener pour changement d’orientation / safeArea | Recalculer le retrait à la rotation |
| Un seul build canal | Le SDK modifie safeArea ou résolution | Smoke test sur ce build ; ne pas se fier au générique Android uniquement |


Unity UGUI : ordre de débogage recommandé (6 étapes)
1. Verrouiller la reproduction
Enregistrer appareil, OS, Dev/Release, orientation, résolution de la Game view. Item 5 pré-lancement : exécuter le HUD principal en Dev et Release.
2. Logger safeArea et résolution de référence
Après le chargement de l’UI principale, logger :
Screen.width/Screen.heightScreen.safeAreaDisplay.cutouts(Android 11+ si utilisé)
Lecture : safeArea plus petit que l’écran → retrait du contenu requis. Dans l’Éditeur, safeArea égale souvent le plein écran → pas un substitut à l’appareil.
3. Racine Canvas et Canvas Scaler
| Vérification | Erreur typique | Direction de correction |
|---|---|---|
Render Mode racine | Screen Space / Camera UI mélangés → décalage ray | Un seul mode pour l’UI |
| Canvas Scaler | Résolution de référence ≠ baseline portrait du projet | Correspondre à checklist moteur item 1 |
| Match width/height | Aspect long met mal à l’échelle ; widgets de bord dérivent | S’accorder sur Match avec design/prod ; corriger le Prefab pas seulement la Scene |
| Tri de Canvas multiples | Les hits vont sur la mauvaise couche | Aligner sortingOrder et cibles raycast |
4. Couche : fond full-bleed vs contenu sécurisé
Hiérarchie Prefab suggérée :
Canvas
├── Background_FullBleed (anchor plein, peut entrer dans l'encoche, sans input)
└── SafeRoot (composant Safe Area ou padding piloté par safeArea)
├── HUD_Content
└── Popups

Utiliser Safe Area d’Unity (ou code projet réglant offsetMin/Max depuis Screen.safeArea). Ne pas étirer les boutons interactifs plein écran sans retrait.
Exports Studio avec une seule couche plate : voir nine-slice / ré-export structuré et canvas → Prefab.
5. Vérification ponctuelle du tap sur appareil
3–5 boutons critiques sur le flux principal ; comparer le centre visuel au doigt. Décalage sur une seule popup → vérifier Canvas imbriqué ou double Scaler.
6. Committer le Prefab dans le repo
Les critères de passage vivent dans le Prefab versionné, pas dans des overrides de Scene de test (item 6 pré-lancement). Après changements d’Anchor, exécuter le smoke débordement locale sur les langues stress.
Canal / mini-jeu
| Scénario | Note |
|---|---|
| App native | Screen.safeArea + appareils réels |
| Certains mini-jeux / quick apps | safeArea / systemInfo du conteneur ≠ sim Éditeur |
| Cutouts Android | cutout vs safeArea peuvent différer |
| PC / deck | safeArea souvent plein écran |
Pattern : ISafeAreaProvider (ou équivalent) ; injecter par plateforme — éviter les #if dans les Prefabs HUD.
Routage des corrections
| Symptôme | Cause probable | Action | Responsable |
|---|---|---|---|
| Clip appareil, Éditeur OK | Pas de SafeRoot / pas de driver safeArea | Prefab en couches + Safe Area ; retester appareil | Ingénierie |
| Fond OK, boutons clippés | Boutons sous la couche bleed | Déplacer vers SafeRoot ; ré-export Studio des couches | Ingénierie + Design |
| Décalage de tap | Canvas multiple / camera UI / Scaler imbriqué | Fusionner Canvas ou unifier la caméra raycast | Ingénierie |
| Dérive au changement de résolution | Anchors fixes uniquement | Corriger les anchors ; item 6 moteur | Ingénierie |
| Design sans cadre de sécurité | Item 7 handoff manquant | Le design ajoute les refs encoche/home ; ré-export | Design |
| Export Studio plat | BG + HUD non séparés | Split in-place puis ré-export | Ingénierie + Design |
Ce que le design fournit
| Livrable | Usage ingénierie |
|---|---|
| Résolution cible + référence safe (encoche / barre home) | Reference Resolution et attentes de retrait |
| Couches nommées full-bleed vs HUD | Prefab Background_* / SafeRoot |
| Onglets de bord dans le safe ou bleed intentionnel | Stratégie d’Anchor |
Les designers n’ont pas besoin d’écrire des scripts — des repères clairs réduisent les px de retrait devinés.
Questions fréquentes
La résolution iPhone de la Game view suffit-elle ?
Smoke Dev uniquement ; le ship exige les appareils cibles (item 1 pré-lancement). Le safeArea de l’Éditeur diffère souvent.
Composant Safe Area vs offset manuel ?
Choix d’équipe ; le manuel doit se rafraîchir aux changements de safeArea/orientation — éviter la logique dupliquée.
Corriger le clip avec le Canvas Scaler seul ?
Le Scaler met à l’échelle ; le retrait est séparé. Le clip est le rect de contenu ; le Scaler est l’échelle globale.
MCP/Cursor peut-il aider ?
Bon pour les renommages de Prefab, attacher Safe Area, smoke Play — les chiffres viennent toujours des logs appareil. Checklist moteur + MCP.
Safe Area plus débordement de locale ?
Corriger d’abord la mise en page SafeRoot, puis locales stress — le retrait réduit la largeur.
VberAI Studio vs Google AI Studio ?
Non. Voir comparaison.
Poursuivre la lecture
D’autres guides qui pourraient vous intéresser
Checklist de passation Figma / PSD : comment les UI de jeu évitent les reprises
Pour les designers d'UI de jeu : calques, nommage, boutons multi-états, 9-slice et vérifications de localisation avant l'export Figma-vers-Unity ou PSD-vers-UGUI.
- game-ui-design
- figma-to-unity
- psd-to-unity
- ui-slicing
Créer un RPG 3D avec Unity MCP : Contrôle à la troisième personne, Combat et Quêtes
Guide pratique Unity MCP pour un prototype RPG 3D jouable : mouvement à la troisième personne, mêlée en temps réel, machines à états ennemies et quêtes dans Cursor ou autres IDE IA MCP. Peaufinez l'UI plus tard.
- Unity MCP
- 3D RPG
- Unity
- combat
VberAI Studio : Assemblage de feuilles de sprites vs Découpage de trames vidéo pour Unity / Godot / Cocos
VberAI Studio génère des vidéos d'action, découpe les trames sur le canevas et livre vers Unity, Godot et Cocos. Comparez les feuilles de sprites GPT Image et les pipelines DIY open source : qui gagne du temps, quand utiliser Studio.
- vberai
- ai-studio
- sprite-frames
- sequence-frames