O que Direção de arte e portões de aprovação faz?
O usuário decide o visual; você torna barato para ele decidir. Cada regra aqui veio de uma rodada de arte que foi rejeitada.
1. Um quadro-alvo
Antes de qualquer asset ser criado, o usuário escolhe um quadro de gameplay (real ou gerado) que é o visual. Ele mostra o jogo real com a câmera real e a UI, não uma foto conceitual bonita. Anote o que ele contém (materiais, luz, layout da UI) e julgue cada portão e asset contra ele.
- Use a câmera real do jogo. Descrições de câmera apenas com texto falharam; anexe uma captura de tela real quando o ângulo precisar corresponder.
- Uma mudança de direção substitui o quadro-alvo e é registrada no mesmo dia.
2. Camadas e portões
A arte é construída em camadas, cada uma terminando em um portão que o usuário testa e aprova. Nunca comece a próxima camada antes que o usuário aprove o portão atual. O usuário pode reordenar as camadas; siga a ordem deles.
- O usuário aprova cada imagem conceitual antes que ela seja modelada, incluindo renders existentes. Mostre conceitos como uma folha de contato rotulada e registre escolhas e anotações de refação.
- A arte apenas muda o visual. Modelos substituem como uma coisa parece, nunca sua colisão ou footprint. Qualquer coisa sem um modelo recai para um placeholder, então o jogo sempre funciona e os testes não se movem.
- Um relatório de portão tem: capturas de tela dos mesmos pontos fixos da câmera a cada vez, incluindo uma correspondência da vista do quadro-alvo; testes verdes; tempo de quadro em uma cena fixa ocupada; uma folha de cada novo asset; os créditos gastos; e verificações finais (a câmera não colide, nada emperrado, log limpo). Faça commit e tag em cada portão aprovado.
- Verifique se uma reconstrução realmente aconteceu (log, timestamps) antes de julgar uma captura. Um script uma vez sobrescreveu silenciosamente o asset de outro.
3. Legibilidade
O jogador deve saber o que uma coisa é a partir da câmera de gameplay em menos de um segundo.
- Uma silhueta distinta mais props de identificação, escritos no prompt. Formas genéricas são rejeitadas como "todas iguais".
- Variantes são lidas como a mesma coisa. Um upgrade ou um level-up é uma mudança visível do mesmo design, não um novo design.
- Materiais dizem quanto custa ou quão avançado é, em uma tabela escrita para o jogo.
- Prompts para um asset único terminam com o asset sozinho em um fundo cinza claro liso, para que o jogo forneça o cenário.
4. Escala do mundo real
Tudo é de tamanho real, e uma verificação comprova isso. Um jogo aprendeu isso tarde, quando um carro ficou tão grande quanto um prédio. Antes do primeiro asset, escreva uma tabela de tamanhos para os tipos de coisas do jogo e adicione uma verificação de escala automatizada na primeira camada de arte. Ela deve reportar 0. Corrija a escala na arte ou nas tabelas de dados, nunca por instância, e nunca estique um modelo para caber.
5. Prompts que funcionam
- Longos e específicos: gameplay real na câmera real, com a UI, os materiais de cada elemento, a hora do dia. Este usuário lê detalhes; prompts vagos dão resultados genéricos.
- Descreva o visual, nunca nomeie um jogo. Nomear jogos trouxe os cenários deles.
- Placeholders em uma referência são copiados. Diga o que cada placeholder deve se tornar.
- Com duas referências, a que parece finalizada assume a câmera. Para manter um layout, anexe apenas sua captura de tela e descreva o visual em palavras. Para um travamento de estilo, anexe o quadro aprovado como a segunda imagem.
- Um prompt com a contagem de imagens definida; nunca escreva "faça 4 variações" (você ganha uma colagem).
- Prompts de UI: uma especificação travada (objetivo, formato, layout como um wireframe em palavras, tipo, cor e material com hex, cópia exata, negativos), direção de arte primeiro, uma variável por variante. Variações vão sobre o estilo aprovado, não novos estilos.
6. Visuais já rejeitados
Mantenha uma tabela por jogo: o que foi rejeitado e as palavras do usuário. Adicione uma linha no dia em que um visual é rejeitado e nunca mais o ofereça. Coisas que este usuário rejeitou em toda a linha: repinturas por IA de nossas próprias capturas de tela, fontes de arte misturadas que colidem (digitalizações ao lado de arte gerada), UI "greybox" desenhada por código, e copiar um jogo de referência muito literalmente.
7. Rubrica de avaliação (1-10, contra o quadro-alvo)
Avalie capturas de portão e novos assets na própria iluminação do jogo.
| Pontuação | Significado |
|---|---|
| 9-10 | Poderia estar dentro do quadro-alvo; lê instantaneamente |
| 7-8 | Visual certo, pequenos defeitos; corrija no lote |
| 5-6 | Ideia certa, execução errada; refaça antes do portão |
| 3-4 | Genérico ou fora do estilo; novo conceito necessário |
| 1-2 | Quebrado: flutuando, enterrado, sem textura, escala errada |
Nada abaixo de 7 vai para o usuário como "pronto". Recorte e amplie antes de chamar algo de bom. Cada defeito abaixo de 7 é um ticket.
Skills relacionadas
studio-operating-model, tripo-studio, ue-scripted-runs, ue-test-gate, character-and-animation.