¿Qué hace Pantallas de UI de Juego?
Haz que cada pantalla se sienta parte del mismo juego. Trabaja a partir de la mejor pantalla del propio juego en lugar de un estilo web genérico, mantén la navegación propia de un juego y verifica cada pantalla en los tamaños que usan los jugadores. Adáptate a la tecnología de UI (DOM sobre un canvas, UI del motor o UI dentro de la escena). Usa game-foundation para el flujo de pantallas si está disponible; este skill cubre cómo se ven y se comportan las pantallas.
1. Inventario
Enumera cada pantalla y superposición, incluidas las que son fáciles de olvidar: título, menú principal, cada menú de modo, garaje o equipamiento, ajustes, salas o pantallas de sala, flujos de unión e invitación, carga, pausa, resultados, errores, estados vacíos, el HUD y pantallas solo para desarrolladores. Para cada una, anota el archivo, cómo se accede, cómo se sale y si necesita un servidor o datos guardados para aparecer. Las pantallas que necesitan el servidor del juego deben ejecutarse con él, o reportarse como no verificadas.
2. Extraer el contrato de estilos
Elige el ancla: la pantalla que ya se ve más como el juego (normalmente el título o el menú principal). Escribe sus reglas antes de tocar otras pantallas: tipografías y tratamiento del título, tokens de color, fondo (escena 3D en vivo, fondo desenfocado, arte), formas de paneles, estados de botón (inactivo, hover, foco, presionado, deshabilitado), escala de espaciado, animación y señales de sonido. Pon las partes compartidas en tokens o clases compartidas para que las pantallas no se desvíen. Lee style-contract.md para la plantilla y las convenciones del juego.
3. Aplicar
- Diseños de pantalla completa de juego, no tarjetas web. Sin scroll de documento en escritorio; los modales se ajustan al viewport; las listas largas se desplazan dentro de su propio panel.
- Navegación de juego. Esc o el control de retroceso sale de cada pantalla; el foco del teclado y el gamepad se mueve de forma predecible con un estado de foco visible; la acción principal es obvia.
- Pasos de incorporación como un flujo. Si se requiere un nombre o perfil antes de algunos modos, pídelo en un solo paso corto (campo de nombre + Jugar) en lugar de mostrar un menú lleno de botones bloqueados. Mantén la misma validación en los ajustes para que una edición posterior no lo rompa.
- Una entrada cuando una basta. No pidas a los jugadores que elijan entre opciones que llevan al mismo lugar (por ejemplo, tres puntos de aparición en un mismo mapa); da una acción principal y ofrece las variantes dentro del juego.
- Jerarquía del HUD. Lee hud-and-loading.md. Cada número etiquetado, nada que parezca salida de depuración, elementos contextuales solo cuando sean relevantes.
- Pantallas de carga con movimiento que coincida con el juego, progreso real cuando esté disponible y sin destellos para cargas cortas.
- El espaciado escala con la altura del viewport (
clamp()o unidades de viewport) para que los menús altos ni se aprieten ni se extiendan en pantallas grandes.
4. Renombrar nombres visibles para el jugador
Al renombrar el juego, modos, lugares o elementos: busca cada variante ortográfica (mayúsculas, espacios, guiones, errores tipográficos) en cadenas de UI, títulos HTML, manifiestos, documentación, nombres de paquetes y claves de almacenamiento. Migra los datos guardados cuando cambie una clave de almacenamiento para que los jugadores existentes conserven su perfil. Mantén estables los IDs internos a menos que la tarea requiera cambiarlos.
5. Verificar
Revisa cada pantalla tocada en 1440×900, 1280×720, 1024×600 y tamaño de teléfono (375×812), además de los objetivos propios del proyecto. Usa capturas de pantalla y usa __pt.layout() de playtest (o una verificación equivalente de cuadro delimitador) para detectar scroll de página, controles fuera de pantalla y superposiciones. Recorre la entrada y salida de cada pantalla. Reporta las pantallas que no pudiste abrir y por qué.