Do Prompt ao Jogável: Construindo um Jogo de Sobrevivência com Codex e SpriteShip

Há uma grande diferença entre um protótipo de jogo que tecnicamente funciona e um que se sente como um jogo.

Movimento, aparecimento, melhorias e colisão podem ser construídos com retângulos coloridos. Essa é muitas vezes a maneira certa de começar. Mas no momento em que você quer um jogador animado, uma família de inimigos, variedade de armas, colecionáveis e uma identidade visual consistente, o pipeline de arte pode se tornar o projeto.

Para um experimento recente, eu queria ver até onde poderia ir combinando três ferramentas:

• Phaser 3 para o runtime do jogo
• Codex para implementação e iteração
• SpriteShip para ativos visuais prontos para o jogo através de seu fluxo de trabalho MCP/API

O resultado foi Last Light, um jogo de sobrevivência visto de cima que roda em navegadores desktop e móveis. Ele tem um jogador animado, várias famílias de inimigos, um grande humanoide com animações de caminhada e ataque separadas, dezesseis armas, dezesseis colecionáveis, melhorias, um objetivo e um encontro com um chefe.

Jogue Last Light: https://spriteship.github.io/sample_games/last-light/

Navegue pelo repositório fonte: https://github.com/spriteship/sample_games

Mais importante, ele se tornou jogável através de um loop surpreendentemente natural: descrever um ativo, gerá-lo no SpriteShip, inspecioná-lo ou revisá-lo, e deixar o Codex conectar os dados exportados ao Phaser.

Começando com jogabilidade, não apresentação

A primeira versão era intencionalmente simples. Ela estabeleceu os sistemas que importavam:

• Movimento visto de cima
• Alvo e disparo automáticos
• Aparecimento de inimigos e progressão de dificuldade
• Quedas de experiência e melhorias
• Entrada para desktop e toque
• Uma câmera seguindo o jogador por um grande mapa

Isso nos deu algo útil para avaliar. Uma vez que o loop estava jogável, cada decisão artística poderia ser julgada em movimento em vez de isoladamente.

Essa ordem importava. O SpriteShip não precisava inventar o design do jogo; ele poderia fornecer ativos para sistemas que já existiam.

Criando um projeto coerente no SpriteShip

Em vez de fazer imagens não relacionadas uma a uma, criamos um projeto de visão de cima no SpriteShip. Esse contexto de projeto ajudou a manter a direção de sobrevivência em blackout consistente entre personagens, inimigos, armas e colecionáveis.

O jogador passou por um processo normal de seleção criativa. Geramos opções, selecionamos um personagem, refinamos o ângulo da câmera e a direção de face, e então adicionamos estados de animação. O mesmo processo produziu:

• Um ciclo de caminhada do jogador
• Uma animação de inatividade separada
• Quatro inimigos criaturas
• Um inimigo humanoide maior sem arma
• Animações de caminhada e ataque humanoides
• Um conjunto de armas 4×4
• Um conjunto de colecionáveis 4×4

A parte útil não foi apenas obter arquivos PNG. O SpriteShip retornou dados de animação estruturados: quadros de atlas, FPS, comportamento de looping, tamanhos de origem, pré-visualizações e definições de corpo de colisão.

Foi aí que a integração MCP começou a parecer menos como geração de imagem e mais como uma ferramenta de desenvolvimento de jogos.

Conectando animações do SpriteShip ao Phaser

O suporte a atlas do Phaser se mapeia naturalmente para as exportações do SpriteShip. O carregador só precisa da folha e de seus metadados JSON:

this.load.atlas(
  PLAYER_ATLAS,
  "assets/spriteship/player/spritesheet_walk_256.png",
  "assets/spriteship/player/atlas_walk_256.json"
);

A registro de animação pode usar a lista de quadros fornecida pelo atlas em vez de assumir um intervalo numérico frágil:

const definition = atlasData.animations.walk;

scene.anims.create({
  key: "player-walk",
  frames: definition.frames.map((frame) => ({
    key: PLAYER_ATLAS,
    frame,
  })),
  frameRate: 60,
  repeat: -1,
});

O jogador muda para o ciclo de caminhada enquanto se move e para a animação idle_2 do SpriteShip enquanto está parado. Como os dados de animação são nomeados e versionáveis, atualizar uma edição de painel é muito mais seguro do que reconstruir manualmente sequências de quadros.

Os dados de colisão foram mais úteis do que eu esperava

O SpriteShip forneceu corpos de colisão retangulares normalizados para estados de animação individuais. Convertendo esses valores em retângulos rotacionados no espaço do mundo dentro do Phaser.

Para o inimigo humanoide, o corpo muda quando a animação de ataque começa. A pose de ataque é mais ampla e mais baixa do que a pose de caminhada, então usar uma única aproximação circular teria produzido acertos enganosos.

O jogo final usa o mesmo retângulo autorado para:

• Colisão de projéteis
• Contato corpo a corpo com inimigos
• Visualização de depuração

Esse último ponto foi importante. Desenhar o retângulo na tela tornou imediatamente óbvio se a jogabilidade correspondia à arte. Também transformou o ajuste de colisão em algo que um não-programador poderia avaliar visualmente.

O loop de painel e agente funcionou bem

Uma das minhas partes favoritas do fluxo de trabalho foi misturar edições de painel com integração impulsionada pelo Codex.

Em um ponto, a animação de ataque humanoide foi ajustada no painel do SpriteShip. Em vez de exportar tudo manualmente e explicar o que mudou, o ativo atualizado poderia ser buscado novamente e reembalado para o jogo. O mesmo aconteceu com a limpeza de colecionáveis.

A divisão de trabalho parecia sensata:

• O humano selecionou e editou visualmente os ativos.
• O SpriteShip gerenciou o projeto e gerou saídas estruturadas.
• O Codex sincronizou arquivos, gerou variantes de runtime, atualizou o código do Phaser e executou testes.

Foi um loop muito mais suave do que baixar imagens diversas, renomeá-las manualmente e adivinhar como deveriam ser cortadas.

Resolução não é apenas largura e altura

A lição mais útil do projeto foi que dois quadros de 256×256 não são necessariamente os mesmos vi