Telas de UI de Jogo
Faça com que cada tela pareça parte do mesmo jogo. Trabalhe a partir da melhor tela do próprio jogo, em vez de estilização web genérica, mantenha a navegação parecida com a de um jogo e verifique cada tela nos tamanhos que os jogadores usam. Adapte-se à tecnologia de UI (DOM sobre canvas, UI de engine ou UI em cena). Use game-foundation para o fluxo de telas em si, se disponível; este skill cobre como as telas se parecem e se comportam.
1. Inventário
Liste cada tela e sobreposição, incluindo as fáceis de esquecer: título, menu principal, menus de cada modo, garagem ou loadout, configurações, telas de lobby ou sala, fluxos de entrada e convite, carregamento, pausa, resultados, erros, estados vazios, HUD e telas apenas para desenvolvedores. Para cada uma, anote o arquivo, como é acessada, como é deixada e se precisa de servidor ou dados salvos para aparecer. Telas que precisam do servidor do jogo devem ser executadas com ele, ou reportadas como não verificadas.
2. Extraia o contrato de estilo
Escolha a âncora: a tela que já parece mais com o jogo (geralmente o título ou menu principal). Anote suas regras antes de tocar em outras telas: tipografia e tratamento do título, tokens de cor, fundo (cena 3D ao vivo, fundo desfocado, arte), formatos dos painéis, estados dos botões (inativo, hover, foco, pressionado, desabilitado), escala de espaçamento, movimento e dicas sonoras. Coloque as partes compartilhadas em tokens ou classes compartilhadas para que as telas não possam divergir. Leia style-contract.md para o modelo e as convenções do jogo.
3. Aplique
- Layouts de tela cheia de jogo, não cards web. Sem scroll de documento no desktop; modais cabem na viewport; listas longas rolam dentro do próprio painel.
- Navegação de jogo. Esc ou o controle de volta sai de cada tela; o foco do teclado e do gamepad se move previsivelmente com um estado de foco visível; a ação principal é óbvia.
- Gates de integração como um fluxo. Se um nome ou perfil for necessário antes de alguns modos, peça em uma única etapa curta de início (campo de nome + Jogar) em vez de mostrar um menu cheio de botões bloqueados. Mantenha a mesma validação nas configurações para que uma edição posterior não a quebre.
- Uma entrada onde uma é suficiente. Não peça aos jogadores para escolher entre opções que levam ao mesmo lugar (por exemplo, três pontos de spawn em um mapa); forneça uma ação principal e ofereça as variantes dentro do jogo.
- Hierarquia do HUD. Leia hud-and-loading.md. Cada número rotulado, nada que pareça saída de depuração, elementos contextuais apenas quando relevantes.
- Telas de carregamento têm movimento que combina com o jogo, progresso real quando disponível e sem flash para carregamentos curtos.
- Espaçamento escala com a altura da viewport (
clamp()ou unidades viewport) para que menus altos nem se amontoem nem se espalhem em telas grandes.
4. Renomeação de nomes voltados ao jogador
Ao renomear o jogo, modos, lugares ou itens: procure cada variante de grafia (maiúsculas/minúsculas, espaçamento, hífens, erros de digitação) em strings de UI, títulos HTML, manifestos, documentação, nomes de pacotes e chaves de armazenamento. Migre dados salvos quando uma chave de armazenamento mudar para que jogadores existentes mantenham seu perfil. Mantenha IDs internos estáveis, a menos que a tarefa exija alterá-los.
5. Verifique
Verifique cada tela tocada em 1440×900, 1280×720, 1024×600 e tamanho de telefone (375×812), além dos alvos do próprio projeto. Use screenshots e use __pt.layout() de playtest (ou uma verificação equivalente de bounding-box) para scroll de página, controles fora da tela e sobreposições. Percorra a entrada e saída de cada tela. Reporte telas que você não conseguiu abrir e por quê.