sprite-generator

Gerador de Sprites

Saídas

Sprites gerados e validados, pré-visualizações e artefatos de integração com Godot.

Não Objetivos

Usar scripts de desenho locais como substituto para a geração real de imagens.

Propósito

Criar sprites 2D orientados à produção a partir de um conceito, uma ou mais imagens de referência ou um briefing detalhado de direção de arte. A skill é intencionalmente agnóstica em relação ao estilo: o usuário pode fornecer uma imagem de referência, um cartão de estilo, uma captura de tela ou uma descrição vívida, e o fluxo de trabalho transforma isso em uma execução reutilizável de geração de sprites com prompts, imagens de base, uma referência base gerada, trabalhos de animação/estado, extração determinística, QA e arquivos iniciais do Godot.

O objetivo não é meramente criar uma imagem bonita. O objetivo é produzir ativos que possam ser colocados em um projeto Godot com nomes de arquivo previsíveis, fundos transparentes, atlas limpos, metadados de quadros, folhas de contato de QA e recursos SpriteFrames iniciais.

Use esta skill para solicitações como:

• "Criar mobília para uma casa com versões limpa e suja."
• "Fazer um personagem neste estilo de arte com animações de idle, andar, apontar e limpar."
• "Criar um mapa de sala de casa de bonecas no mesmo estilo desta referência."
• "Gerar variações alternativas de roupas/cores e manter as mesmas proporções corporais."
• "Transformar este esboço de objeto em um sprite de prop transparente pronto para jogo."

Entradas

Aceitar qualquer combinação destas entradas:

• Imagens de referência: folha de estilo, personagem existente, prop, captura de tela, moodboard, paleta, sprite gerado anteriormente ou captura do jogo.
• Descrição vívida: nome do ativo, função, forma, material, cor, escala, ângulo de câmera, uso pretendido e adjetivos de estilo.
• Tipo de ativo: character, npc, player, furniture, prop, object, map, room, dollhouse ou sprite genérico.
• Animações: ações nomeadas, contagens de quadros, direções, comportamento de loop/único, durações ou FPS e notas especiais de pose.
• Estados e variantes: limpo/sujo, aberto/fechado, saudável/murcho, vazio/cheio, roupa A/B, conjunto de cores, níveis de dano, etc.
• Alvo de integração: versão do Godot, tamanho da célula, colunas do atlas, escala, câmera top-down/isométrica/vista lateral e caminho de importação preferido.

Se o usuário omitir detalhes, inferir padrões sensatos e facilitar a iteração da saída. Não bloquear em cada detalhe ausente. Fazer uma pergunta esclarecedora apenas quando a omissão causar trabalho errado e caro, como estilo desconhecido, identidade de personagem desconhecida ou uma lista de animação necessária.

Delegação de Geração Visual

A arte real deve ser gerada com a capacidade de geração de imagem do ambiente, não com scripts locais. Em um ambiente de skill estilo Codex, delegar para a skill $imagegen instalada, se disponível. No ChatGPT, usar a ferramenta nativa de geração de imagem quando o usuário pedir para criar o ativo visual. Os scripts Python incluídos são apenas para etapas de produção determinísticas.

Etapas determinísticas permitidas:

• criar pastas de execução e arquivos de prompt
• copiar referências estáveis para a execução
• criar imagens de guia de layout
• registrar saídas geradas selecionadas
• remover um fundo de chroma-key plano
• dividir tiras em quadros
• cortar, redimensionar, preencher e centralizar quadros em células consistentes
• compor atlas PNG/WebP
• gerar folhas de contato e pré-visualizações GIF
• escrever manifestos JSON e recursos iniciais do Godot

Limite rígido: não desenhar, pintar, sintetizar, ladrilhar, distorcer ou inventar a arte do sprite com Pillow, SVG, CSS, canvas HTML ou formas programáticas como substituto para a geração de imagem. Os scripts podem processar imagens geradas; eles não podem ser usados como um gerador de arte oculto.

Captura de Estilo e Bloqueio de Estilo

Quando uma referência de estilo for fornecida, tratá-la como a fonte da verdade. Extrair estas qualidades para o plano de prompt:

• ângulo da câmera e perspectiva: frontal, lateral, top-down, isométrica, 3/4, casa de bonecas, ortográfica
• proporções: chibi, realista, agachado, alto, semelhante a brinquedo, pixel, pictórico, vetor plano, renderização low-poly
• tratamento de linha e borda: sem contorno, contorno grosso, borda renderizada suave, borda de pixel, borda cel-shaded
• materiais e iluminação: argila, pelúcia, brinquedo de plástico, 3D pintado, cel plano, brilhante, fosco, aquarela, etc.
• paleta e saturação
• política de sombra: nenhuma para sprites transparentes, a menos que explicitamente mantida como parte do objeto
• política de fundo: fundo transparente ou chroma-key plano para extração
• escala e legibilidade no tamanho da célula alvo

Uma linha ou estado falha se parecer com um ativo relacionado em um estilo diferente, em vez do mesmo ativo no estilo alvo.

Padrões de Tipo de Ativo

Personagens/NPCs/Jogadores

Saídas padrão se o usuário não especificar animações:

Animação	Quadros	Propósito
idle	4	Loop de respiração/piscar; o primeiro quadro funciona como pose estática
walk_down	6	Movimento frontal/para baixo
walk_up	6	Movimento traseiro/para cima
walk_left	6	Movimento de vista lateral voltado para a esquerda
walk_right	6	Movimento de vista lateral voltado para a direita

Ações comuns opcionais: point, talk, pickup, carry, clean, use_item, sit, sleep, cry, celebrate, fail, interact, attack, cast, jump, push, pull.

Móveis/Props/Objetos

Saídas padrão se o usuário não especificar estados:

Estado	Quadros	Propósito
clean	1	Estado normal/organizado
dirty	1	Estado sujo/desorganizado do mesmo objeto

Estados comuns opcionais: empty, half_full, full, overflowing, open, closed, on, off, healthy, wilted, broken, repaired, selected, highlighted, locked, unlocked.

Mapas/Salas/Casas de Bonecas

A saída padrão é um sprite map_base grande ou fundo. Para salas, especificar se você precisa de uma única camada de arte achatada ou camadas separadas como floor, walls, furniture, interactables, path_overlay e collision_reference. Não incluir rótulos de UI, setas, linhas de caminho ou sobreposições de tutorial na arte do mapa de produção, a menos que solicitado como uma sobreposição separada.

Regras de Fundo e Transparência

Preferir fundos de chroma-key planos para geração quando a ferramenta de imagem não produzir alfa verdadeiro de forma confiável. A chave padrão é #00ff00. O atlas final deve ser PNG/WebP transparente após a extração.

Para imagens de origem geradas:

• usar uma cor de fundo plana em toda a tira ou renderização do objeto
• manter o ativo visualmente separado da chave chroma
• evitar destaques/materiais verdes ao usar chave verde; escolher chave magenta ou azul se o ativo precisar de verde
• sem fundo branco, fundo xadrez, painel de UI, rótulos, números de quadro, grade visível, borda ou cenário
• sem sombras projetadas, sombras de chão, brilhos, halos transparentes suaves, nuvens de poeira, linhas de velocidade, rastros de movimento ou efeitos soltos e destacados, a menos que um pequeno efeito opaco anexado seja explicitamente parte do sprite
• cada quadro deve estar completo, separado, sem recorte e dentro de seu slot

Regras de Prompt de Animação

Para cada linha/tira de animação:

• solicitar exatamente o número de quadros declarado
• especificar o layout: geralmente tira horizontal da esquerda para a direita
• usar uma imagem base canônica e imagens de referência como entradas de base
• manter identidade, proporções, paleta, material, estilo de contorno/borda e ângulo de câmera consistentes
• comunicar movimento através de mudanças de pose, não através de desfoque, linhas de velocidade, poeira ou sombras
• o primeiro e o último quadro devem fazer loop limpo quando loop=true
• para animações direcionais, solicitar a direção explicitamente e evitar detalhes espelhados acidentais se o personagem tiver acessórios específicos do lado

Não aceitar uma linha se ela mudar o rosto, forma do corpo, roupa, design do prop, estilo de material ou escala do personagem em relação à base.

Plano de Progresso Visível

Para uma execução normal de ativo, manter uma lista de verificação visível para o usuário:

1. Preparando a solicitação do ativo.
2. Criando a aparência canônica.
3. Criando estados e linhas de animação.
4. Empacotando para Godot.

O que cada etapa significa:

• Preparando a solicitação do ativo: estabelecer nome do ativo, tipo de ativo, fonte de estilo, saídas, tamanho da célula, chave chroma e diretório de execução.
• Criando a aparência canônica: gerar ou escolher a referência base que se torna o bloqueio de identidade/estilo.
• Criando estados e linhas de animação: gerar cada trabalho de saída usando a base e referências; reparar apenas linhas/estados com falha.
• Empacotando para Godot: extrair quadros, compor atlas, criar folha de contato de QA, escrever manifestos, escrever recurso inicial SpriteFrames e relatar caminhos de arquivo.

Marcar uma etapa como concluída apenas quando o arquivo ou decisão real existir.

Fluxo de Trabalho

1. Preparar uma pasta de execução

python3 ./scripts/prepare_sprite_run.py \
  --asset-name "Caixa de Mercado" \
  --asset-type prop \
  --description "caixa de mercado de madeira legível com conteúdo colorido" \
  --style-notes "combinar com a referência de arte do jogo fornecida" \
  --reference /caminho/absoluto/para/style_reference.png \
  --state full:1:"caixa cheia de itens":single:once \
  --state empty:1:"mesma caixa vazia":single:once \
  --cell-size 256x256 \
  --columns 2 \
  --output-dir /caminho/absoluto/para/execucao

Para um personagem:

python3 ./scripts/prepare_sprite_run.py \
  --asset-name "Jogador" \
  --asset-type character \
  --description "personagem jogador amigável com uma silhueta clara" \
  --reference /caminho/absoluto/para/style_reference.png \
  --animation idle:4:"respiração suave e piscada" \
  --animation walk_down:6:"andando em direção à câmera" \
  --animation walk_up:6:"andando para longe da câmera" \
  --animation walk_left:6:"andando vista lateral esquerda" \
  --animation walk_right:6:"andando vista lateral direita" \
  --cell-size 256x320 \
  --columns 6 \
  --output-dir /caminho/absoluto/para/execucao

Execuções avançadas podem ser descritas com um arquivo de configuração JSON e passadas com --config.

2. Inspecionar trabalhos prontos

python3 ./scripts/sprite_job_status.py --run-dir /caminho/absoluto/para/execucao

O trabalho base deve ser gerado primeiro. Registrar a imagem base gerada selecionada antes de gerar trabalhos dependentes. O gravador escreve references/canonical-base.png, que os trabalhos subsequentes devem usar como imagem de entrada.

3. Gerar cada trabalho visual

Para cada trabalho pronto, usar o arquivo de prompt listado em imagegen-jobs.json mais todas as imagens de entrada listadas. Selecionar a melhor imagem original gerada, depois registrá-la:

python3 ./scripts/record_imagegen_result.py \
  --run-dir /caminho/absoluto/para/execucao \
  --job-id job-id-from-status \
  --source /caminho/absoluto/para/saida-gerada.png

Não registrar acessórios editados manualmente, miniaturas ou arquivos das pastas final/quadros da execução como arte de origem. Registrar a saída gerada original selecionada.

4. Finalizar

python3 ./scripts/finalize_sprite_run.py --run-dir /caminho/absoluto/para/execucao

Saída esperada:

execucao/
  asset_request.json
  imagegen-jobs.json
  prompts/
  references/
  decoded/
  frames/frames-manifest.json
  final/spritesheet.png
  final/spritesheet.webp
  final/validation.json
  qa/contact-sheet.png
  qa/previews/*.gif
  qa/run-summary.json
  godot/<ativo>_spriteframes.tres
  godot/<ativo>_animated_sprite_2d.tscn
  godot/godot_import_manifest.json
  godot/README_GODOT.md

5. Copiar para o Godot

python3 ./scripts/package_godot_assets.py \
  --run-dir /caminho/absoluto/para/execucao \
  --project-dir /caminho/absoluto/para/projeto-godot \
  --dest assets/sprites

Revisar godot/README_GODOT.md após o empacotamento. Se copiar arquivos para um local res:// diferente, atualizar o caminho da textura dentro do arquivo .tres gerado.

Fluxo de Reparo

Se o QA falhar, reparar o menor escopo primeiro:

1. Um único estado ruim ou linha de animação.
2. Um único quadro ruim apenas se sua ferramenta de imagem suportar edição no nível do quadro de forma confiável.
3. A base canônica apenas se a identidade/estilo estiver errada em todos os lugares.
4. O atlas completo apenas como último recurso.

Prompts de reparo comuns:

• "Regenerar apenas walk_left; preservar o personagem canônico exato, roupa, proporções e estilo de renderização de brinquedo."
• "Regenerar apenas dirty; deve ser o mesmo sofá que clean, mas com cobertor/travesseiros bagunçados."
• "Regenerar a tira com exatamente 6 quadros e sem números de quadro ou rótulos."
• "Usar chave chroma magenta porque o objeto precisa de material verde."

Após registrar a imagem de reparo, executar novamente a finalização.

Rubrica de QA

Não aceitar um ativo até que estas verificações passem:

• A base gerada corresponde ao estilo solicitado ou às referências de estilo fornecidas.
• Cada estado/Animação é a mesma identidade do ativo, não um redesenho.
• Contagens exatas de quadros estão presentes.
• A extração transparente não remove partes importantes do sprite.
• Os quadros estão completos, centralizados, preenchidos e não recortados.
• Nenhum rótulo, número de quadro, linhas de grade, marcas d'água, painéis de UI ou cenário vazaram para a arte de produção.
• Nenhuma sombra indesejada, brilhos, poeira, linhas de velocidade, desfoque ou efeitos destacados permanecem após a extração.
• A folha de contato parece visualmente correta no tamanho alvo.
• final/validation.json não tem erros; avisos foram revisados visualmente.
• Os nomes do manifesto do Godot correspondem aos nomes de animação que você pretende chamar no código.

Critérios de Aceitação

Uma execução concluída deve incluir:

• uma referência base canônica em references/canonical-base.png
• fontes geradas selecionadas registradas em imagegen-jobs.json
• PNGs de quadros transparentes extraídos
• final/spritesheet.png e, quando suportado, final/spritesheet.webp
• qa/contact-sheet.png
• pré-visualizações GIF para animações de vários quadros
• final/validation.json sem erros
• arquivos iniciais do Godot sob godot/
• um breve relatório voltado ao usuário nomeando quaisquer linhas/estados reparados ou aceitos manualmente apesar dos avisos

Regras

• Usar geração visual para visuais; usar scripts apenas para processamento determinístico.
• Sempre usar uma base canônica para ativos de múltiplas saídas.
• Manter referências anexadas para cada trabalho visual dependente quando a ferramenta de imagem suportar referências.
• Preferir saída transparente ou compatível com chroma-key em vez de ilustrações de cena.
• Não colocar rótulos de UI, setas instrutivas, linhas de caminho ou guias de colisão em sprites de produção, a menos que sejam solicitados como ativos de sobreposição separados.
• Para Godot, manter os nomes de animação estáveis e em minúsculas com ...

[truncado para tradução]