UI Frontend pour Jeux
Aperçu
Utilisez cette compétence chaque fois que le jeu a besoin d'une couche d'interface visible. Le travail n'est pas de produire une UI de tableau de bord générique. Le travail est de produire une interface de jeu en navigateur lisible, thématique, qui soutient l'expérience de jeu.
Hypothèse par défaut : construisez le monde du jeu en canvas ou WebGL, et construisez l'UI textuelle en DOM.
Normes Frontend
- Établissez une direction visuelle avant de coder.
- Genre et fantasy
- Langage matériel
- Typographie
- Palettes
- Ton du mouvement
- Utilisez des variables CSS pour le thème de l'UI.
- Construisez une hiérarchie claire.
- Informations critiques de combat ou de survie en premier
- Outils secondaires ensuite
- Paramètres rarement utilisés derrière des menus ou tiroirs
- Protégez d'abord la zone de jeu, surtout en 3D.
- L'écran initial doit sembler jouable en quelques secondes.
- Par défaut, un cluster HUD persistant principal et au maximum un petit cluster secondaire.
- Gardez le centre de la zone de jeu dégagé pendant le jeu normal.
- Gardez la partie inférieure centrale de la zone de jeu surtout dégagée pendant le jeu normal.
- Placez le lore, les notes de terrain, les détails des quêtes et les longues listes de contrôles derrière des tiroirs, des bascules ou des surfaces de pause.
- Préférez les invites contextuelles et les indices temporaires aux panneaux encadrés permanents.
- Gardez les superpositions lisibles sur le mouvement.
- Utilisez des panneaux de fond, des traitements de bord, du contraste et un flou retenu si nécessaire.
- Concevez pour le bureau et le mobile dès le départ.
- Concevez l'UI 3D autour des limites de la caméra et des entrées de contrôle.
- Mettez en pause ou bloquez les entrées de contrôle de la caméra lorsque des menus, des dialogues ou une UI pilotée par le pointeur sont actifs.
- Gardez les états de verrouillage du pointeur, de glisser pour regarder et d'interaction avec le menu explicites.
Valeurs par Défaut pour le Démarrage 3D
Pour les structures de démarrage d'exploration, de déplacement ou de troisième personne, préférez ce budget UI :
- un objectif compact ou une bande de statut sur le bord
- un indice de contrôle transitoire ou une invite d'interaction
- une surface secondaire optionnelle et repliable comme un journal, une carte ou un journal de quête
N'ouvrez pas chaque surface d'information au premier chargement. La scène doit être lisible avant que l'utilisateur n'ouvre une UI plus profonde.
En tant que contrainte d'implémentation par défaut pour les jeux 3D en navigateur :
- pas de mise en page avec en-tête pleine largeur toujours active, corps multi-cartes et pied de page pleine largeur
- pas de grandes superpositions au centre de l'écran ou dans la partie inférieure centrale pendant le déplacement normal
- pas plus d'environ 20 à 25 % du viewport couvert par un HUD persistant sur le bureau, sauf si l'utilisateur demande explicitement une mise en page plus dense
- sur mobile, réduisez à une pile étroite ou à des puces contextuelles avant de couvrir la zone de jeu avec des panneaux plus grands
Règles de Sollicitation
Lorsque vous demandez au modèle de concevoir ou d'implémenter une UI de jeu, incluez :
- la fantasy du jeu
- la caméra ou le point de vue
- les verbes du joueur
- les couches du HUD
- le mode de contrôle ou de caméra lorsque le jeu est en 3D
- le ton du mouvement
- les attentes pour le bureau et le mobile
- la stratégie de protection de la zone de jeu et de divulgation
- les anti-patrons explicites à éviter
Utilisez ../../references/frontend-prompts.md pour des formes d'invite concrètes.
Règles de Mouvement
- Préférez quelques transitions significatives à une micro-animation constante.
- Réservez les mouvements forts pour les changements d'état, les récompenses, les dangers et l'intégration.
- Respectez les paramètres de mouvement réduit pour les animations non essentielles.
- Évitez que le mouvement du HUD 3D n'entre en compétition avec le mouvement de la caméra.
À Quoi Ressemble un Bon Résultat
- Les éléments du HUD sont lisibles sans aplatir la scène.
- Les menus semblent naturels dans le monde du jeu, pas comme un panneau d'administration SaaS.
- La mise en page s'adapte proprement aux différents points de rupture.
- Les retours du pointeur, du clavier et de l'état du jeu sont évidents.
- Dans les jeux 3D, les états du menu et du HUD ne luttent pas contre le contrôle de la caméra ou le verrouillage du pointeur.
- Dans les jeux 3D, la première vue jouable laisse la majeure partie du viewport disponible pour le mouvement, la visée et la lecture spatiale.
- La densité d'information persistante est suffisamment faible pour que les captures d'écran ressemblent encore à des scènes de jeu, et non à des compositions UI.
Anti-Patrons
- Mises en page de tableau de bord d'application génériques
- Styles de substitution plats sans thème
- Piles de polices par défaut sans intention
- Superpositions denses qui masquent la zone de jeu
- Grandes cartes de titre ou notes multi-paragraphes posées sur une scène de jeu en direct
- Panneaux encadrés de poids égal répartis autour de chaque bord du viewport
- Contrôles, objectifs, notes et lore tous développés en même temps au premier chargement
- Chrome supérieur et inférieur pleine largeur avec de grands panneaux centraux ou de corps toujours actifs dans le jeu 3D
- Mouvement excessif sur chaque élément
- UI uniquement en canvas alors que le DOM serait plus clair et moins coûteux
- Forcer les contrôles HUD dans la scène 3D alors que le DOM standard serait plus clair
- Laisser l'entrée de la caméra active sous les modaux ou les panneaux d'inventaire
Références
- Architecture partagée :
../web-game-foundations/SKILL.md - Recettes d'invite :
../../references/frontend-prompts.md - Modèles de mise en page HUD 3D à faible chrome :
../../references/three-hud-layout-patterns.md - Contexte UI 3D hébergé par React :
../react-three-fiber-game/SKILL.md - Revue de playtest :
../../references/playtest-checklist.md