Nesta página
Eu queria que um lojista da Shopify acompanhasse um pedido pelo depósito, visse o que acontece quando ele muda e saísse com algo útil para sua loja. Isso se tornou Warehouse Rush, nosso jogo gratuito de navegador, disponível apenas em inglês.
Você separa produtos, monta kits, embala pacotes, carrega vans e investe o dinheiro que coleta. Maple Depot cresce e dá lugar a Riverside Warehouse e Aurora Fulfillment. O jogo inclui The Nine-Figure Upsell Playbook, um guia prático para escolher e testar uma oferta.
Se você quer criar um jogo 3D de navegador com agentes de programação de IA, este é nosso registro de desenvolvimento. Ele aborda Three.js, Codex, Claude, Higgsfield e ElevenLabs, incluindo as partes que mudaram durante o desenvolvimento.
A imagem acima é uma arte principal promocional. As capturas de tela do depósito abaixo mostram o mundo jogável.
Por que um app da Shopify criou um jogo de depósito
Eu queria um material de captação de leads cuja atividade explicasse o fluxo do pedido e cuja recompensa ajudasse o lojista a agir a partir dele.
A Revize permite que os clientes editem pedidos elegíveis da Shopify antes do processamento. A questão operacional interessante é o que acontece entre um cliente alterar um pedido e um depósito enviá-lo. Nosso guia sobre um pedido que já está sendo separado por um 3PL aborda a coordenação no mundo real.
O jogo torna visível uma versão menor disso. Os produtos pertencem a pedidos específicos. Pedidos alterados precisam de correção e de uma etiqueta atual antes do despacho. Embalagem, estoque e entrega são ações conectadas.
O guia oferece o trabalho do lojista após essa ilustração. Sua capa diz “Escolher / Criar / Comprovar / Decidir” e “Lições práticas do nosso trabalho com marcas de faturamento de nove dígitos”. Em 16 páginas, suas seis missões abrangem escolher uma combinação útil, criar e posicionar a oferta, fazer a oferta pretendida vencer, comprovar o pagamento, diagnosticar o resultado e decidir com base na sua própria ficha de resultados.
Entre no jogo com seu e-mail e a URL da loja. O primeiro pacote enviado rende o guia de upsell. Esta é uma introdução jogável ao tema; não temos um resultado medido de treinamento no trabalho para relatar.
A stack e a separação que importa
Three.js desenha o depósito, TypeScript guarda suas regras e Vite empacota o projeto independente de navegador.
O jogo tem seu próprio código-fonte, arquivo de dependências travadas, testes e recursos, separados do projeto Astro do site. Vite produz o pacote para o navegador com caminhos relativos de recursos, de acordo com seu fluxo de build estático de produção.
A divisão principal é entre a simulação e sua apresentação:
tycoon-model.tscuida de pedidos, quantidades, a qual pedido cada pacote pertence, revisões, funcionários, dinheiro e validação de dados salvos.tycoon-world.tsdesenha esse estado e gerencia os recursos visuais da cena.tycoon-entry.tsconecta entrada de comandos, menus, salvamento, áudio e o ciclo de quadros.
Uma função de retorno de animação nunca concede estoque nem dinheiro. Um caderno voando é uma resposta visual a uma alteração no modelo. Manter essa distinção faz um efeito visual ausente ser diferente de um item perdido.
A câmera de jogo é uma THREE.PerspectiveCamera, a câmera de perspectiva do Three.js; a câmera ortográfica do renderizador é usada apenas para as sombras do sol.
Rapier aparece no histórico de licenças do projeto de origem. O tycoon ativo não o importa; colisão, navegação e movimento limitado de objetos de cenário são implementados diretamente.
O que criamos em código e o que geramos
O depósito e os personagens animados são criados em código, enquanto imagens selecionadas, um modelo de esteira, o vídeo do portal e os efeitos sonoros vieram de ferramentas de geração.
A distinção importa quando alguém pergunta como o jogo foi feito. Um retrato, uma estrutura de animação de personagem e um vídeo são entregáveis diferentes, com trabalhos de integração diferentes.
| Parte | Origem documentada | Trabalho que continua no jogo |
|---|---|---|
| Depósito, produtos e personagens ativos | Geometria original de Three.js, com texturas Canvas desenhadas localmente | Layout, movimento, transporte de objetos, maquinário e animação orientada pelo estado |
| Pôster original e conjunto portrait-v2 | image_gen integrado / geração de imagens da OpenAI, registrada em ASSETS.md |
Preparação dos recursos e posicionamento na interface |
| Esteira de despacho | Cena de 3D Jutsu do Higgsfield do proprietário, exportada como GLB | Integração de objeto estático; pacotes e interações continuam sob controle do jogo |
| Piso de concreto anterior | Conjunto de texturas PBR do Higgsfield do proprietário | Recurso histórico; os tratamentos de piso posteriores são criados em código |
| Portal | Recursos do Higgsfield da conta do proprietário e clipes do Kling 3.0 | Substituição da capa, edição de loops, codificação e temporização da entrada |
| Banco de amostras sonoras do jogo | eleven_text_to_sound_v2 da ElevenLabs |
Carregamento, mixagem, conexão aos eventos e alternativas sintetizadas |
O histórico de recursos inclui um conjunto intermediário de personagens ilustrados. Claude Opus criou um atlas Canvas2D e uma animação de recortes; Codex fez a integração. A documentação atual de passagem do projeto informa que essas camadas planas foram removidas desde então e que os personagens ativos usam geometria de Three.js. O atlas faz parte do histórico de desenvolvimento, não do renderizador atual de personagens.
A arte principal atual, nos formatos paisagem e retrato, foi gerada em 24 de outubro de 2026 pelo Codex gpt-6-astra usando sua ferramenta integrada de geração de imagens da OpenAI, com a renderização “Cozy Soft” do jogo, de nossa propriedade e aprovada, como referência de estilo e os retratos v2 dos personagens, também de nossa propriedade, para a identidade. Os arquivos distribuídos são codificados em WebP, e os prompts ficam em art-src/menu-v3/jobs.tsv. O retrato abaixo pertence ao conjunto v2 gerado e documentado.
Como usei Codex e Claude sem perder o histórico de desenvolvimento
O fluxo útil com agentes atribuía trabalho concreto e permitia identificar os responsáveis pela direção, implementação e verificação.
Os registros sustentam créditos específicos. ASSETS.md credita a Astra e Claude Opus a direção editorial dos guias práticos. Sol implementou o conteúdo, o renderizador compartilhado e a apresentação no menu do jogo. O histórico dos personagens ilustrados nomeia Claude Opus como autor e Codex como integrador. O registro também documenta Claude Opus refinando esses personagens com base na minha arte principal do depósito.
A verificação da expansão registra um encerramento posterior por Opus após correções aprovadas. Essas entradas descrevem contribuições reais; não comprovam que um agente tenha criado ou revisado todas as partes do jogo.
Meu processo reutilizável a partir desses registros é:
- Defina o comportamento e quem controla seu estado antes de pedir trabalho visual.
- Dê à tarefa de implementação um módulo ou recurso nomeado e uma condição de aceitação visível.
- Revise a integração, incluindo dados salvos antigos, liberação de recursos e caminhos de falha.
- Guarde evidências da versão resultante. Marque um experimento anterior como histórico quando ele for substituído.
Essa última etapa detectou uma divergência real na documentação aqui: uma técnica antiga de personagens pode continuar descrita após a mudança do renderizador. Um relato de desenvolvimento precisa do mesmo cuidado que uma passagem de projeto.
A mídia gerada ainda precisava de edição e decisões de execução
A geração forneceu o material de origem; o pós-processamento e a conexão aos eventos o tornaram utilizável no navegador.
A exportação da esteira do Higgsfield remove pacotes de exemplo, câmeras e luzes da cena ativa. Caso contrário, um modelo de apresentação poderia duplicar os pacotes do jogo ou trazer sua própria iluminação. A esteira continua sendo um recurso estático, enquanto a simulação controla os produtos em movimento.
O portal exigiu outro tipo de ajuste. Seu fluxo registrado usa vídeo de Higgsfield/Kling, projeta a capa real do guia nas imagens e cria loops de movimento para a frente. Também mantém a arquitetura pintada estável fora da abertura em movimento para eliminar a oscilação das texturas. Os quadros de pôster e os arquivos codificados finais recebem verificações separadas.
A entrada também tem um contrato funcional. A aceitação do lead e a prontidão do jogo precisam ter sucesso. O portal só desaparece depois que o jogo ativo confirma um quadro renderizado. O fim de uma cena cinematográfica não comprova que o depósito está pronto para receber comandos.
Para o som, a documentação ativa de passagem do projeto registra 23 efeitos distribuídos da ElevenLabs, gerados com eleven_text_to_sound_v2. A ElevenLabs documenta efeitos gerados por texto para jogos e mídias interativas. Nossas amostras cobrem ações como separação, fechamento de caixas, saída de vans e conclusão de melhorias.
Uma entrada anterior do registro informa 24 efeitos gerados. A documentação de passagem explica a contagem distribuída: ui-tap foi gerado, mas omitido porque não havia um ponto central de conexão para cliques em botões.
O navegador carrega e decodifica o banco de amostras após um gesto que libera o áudio. Os eventos acionam as amostras; amostras indisponíveis usam alternativas sintetizadas. Nenhuma chamada à API nem chave da ElevenLabs é necessária durante a execução. A música e os pequenos sons de materiais são sintetizados em código, com controles de música e efeitos salvos separadamente.
O trabalho de desempenho começou pelo layout e pelo carregamento
A remoção do trabalho repetido de layout do navegador e a redução dos bytes dos recursos necessários foram importantes, junto com o orçamento da cena 3D.
O arquivo registrado docs/perf-report.md identifica uma medição repetida do canvas dentro do posicionamento dos botões das estações. Leituras de getBoundingClientRect() vinham após alterações de estilo durante o quadro. Armazenar em cache o retângulo do canvas e invalidá-lo no redimensionamento removeu esse trabalho repetido de layout.
Esse relatório também registra qualidade adaptativa, buscas paralelas de recursos e objetos estáticos agrupados. As etapas de qualidade reduzem a proporção de pixels e, depois, sombras e partículas quando o tempo dos quadros continua acima do orçamento.
Para dar uma ideia de escala, a versão de teste do relatório lista um pacote JavaScript de 1.072 KB, ou 308 KB com gzip. A célula de teste do início de Maple com área de visualização de celular registra 59 chamadas de desenho, incluindo a passagem de sombras. São medições históricas do Chrome sem interface gráfica em Apple Silicon, usando amostras de 20 segundos. Não são uma nova auditoria da versão de lançamento nem medições em um celular físico.
A esteira mudou após esse relatório. ASSETS.md registra compressão meshopt de 641.960 para 51.044 bytes, sem simplificação da geometria nem texturas. O carregador registra o MeshoptDecoder do Three.js para o GLB comprimido. O tamanho da esteira sem compressão no relatório antigo não deve ser apresentado como atual.
Eu manteria as duas verificações em uma versão futura: o que a cena envia a cada quadro e o que o navegador precisa buscar antes do primeiro quadro jogável.
Os testes acompanharam o pacote por toda a jornada
Os testes do modelo verificaram a qual pedido cada item pertencia e a contabilização, enquanto as verificações no navegador cobriram a jornada renderizada e os controles.
A suíte de testes Node cobre a simulação, a lição guiada, as recompensas, o estado salvo e o comportamento do controlador. O verificador de jornada mais longa percorre caminhos reais do modelo, conquista melhorias e conclui o trabalho aceito antes de mudar de depósito. Ele confere estoque, dinheiro e salvamento/recarregamento em pontos de controle.
A verificação da expansão registra uma campanha conquistada de 48 envios e execuções de continuação que chegam a 300 entregas totais nas rotas de Riverside e Aurora. São execuções para verificar a correção do funcionamento, não contagens de jogadores nem evidências de que um iniciante conclui o capítulo com facilidade.
A verificação no navegador acrescenta o que uma jornada do modelo não consegue mostrar: se a ficha do pedido cabe, se uma janela permite rolagem, se um controle continua acessível e se o portal revela um quadro real. As verificações registradas no Chrome usam áreas de visualização de desktop e de tamanho de celular, incluindo casos de movimento reduzido e falha.
Em um caso de teste ilustrativo, imagine uma loja de presentes enviando duas canecas e um caderno. Altere o requisito do caderno após a separação. A verificação útil é que o pacote final corresponda ao pedido e à etiqueta atuais, enquanto os produtos não afetados continuam contabilizados. Uma animação bem-sucedida, sozinha, não comprova isso.
A montagem também torna essa distinção visível. A captura de tela mostra o minijogo do kit de presente com urso de pelúcia; sua apresentação ainda precisa corresponder ao conteúdo subjacente do pacote.
Decisões humanas e o que eu faria diferente
Eu conciliaria a documentação mais cedo e colocaria testes em dispositivos físicos antes de mais decoração.
Os registros de desenvolvimento contêm escolhas humanas que um resultado gerado não consegue resolver. Forneci arte de referência de nossa propriedade. A revisão do portal rejeitou uma ampliação de resolução com artefatos nas letras e nas bordas. O processo de mídia verifica a legibilidade do conteúdo da capa e o movimento, além das medições dos arquivos. São decisões de aceitação, não consequências de uma exportação bem-sucedida.
A documentação atual de passagem também mantém limites concretos em aberto. O deslocamento manual pode atravessar um caminhão estacionado na borda expandida do despacho, embora as entregas por rotas continuem funcionando. Um relato de lentidão e falhas visuais no celular não tem os detalhes do dispositivo necessários para reprodução. Verificações em áreas de visualização de desktop não resolvem o desempenho em dispositivos nem esse relato.
O progresso fica localmente no navegador. Não há sincronização de dados salvos na nuvem nem modo multijogador. As ofertas de parceiros continuam pendentes. Esses limites fazem parte do relato de desenvolvimento junto das telas concluídas.
Para lojistas, o jogo é uma ilustração. Use o guia de posicionamento de upsells pós-compra para o fluxo comercial; os recursos de upsell da Revize exigem Pro. Verifique sua própria jornada de oferta em um pedido de teste.
O que você deve fazer esta semana?
Crie e verifique um ciclo completo de pedido antes de expandir o depósito ou encomendar mais recursos.
- Escreva quem controla os estados do pedido, estoque, pacote e recompensa.
- Faça a separação, a embalagem e o despacho funcionarem em uma jornada visível.
- Registre a origem, o processamento e o uso atual de cada recurso gerado.
- Verifique um recarregamento, uma falha de carregamento e movimento reduzido e, depois, teste em um celular físico.
Jogue Warehouse Rush para inspecionar nosso resultado. Entre com seu e-mail e a URL da loja, envie seu primeiro pacote e obtenha The Nine-Figure Upsell Playbook. Suas seis missões transformam a tarefa do lojista em uma oferta nomeada, uma jornada de pagamento testada e uma decisão baseada nas suas próprias adições mantidas e custos.
Perguntas frequentes
Estas respostas distinguem o jogo distribuído dos experimentos anteriores e das condições registradas de teste.
Posso criar um jogo 3D de navegador com agentes de programação de IA?
Sim, mas a implementação ainda precisa de regras explícitas, trabalho de integração e verificação. Warehouse Rush separa a simulação de seu renderizador, usa agentes em tarefas documentadas e verifica jornadas completas. Arte gerada não comprova que o estoque, a vinculação dos pacotes aos pedidos ou o progresso salvo funcionam corretamente.
Toda a arte de Warehouse Rush foi gerada por IA?
Não, o depósito ativo e os personagens animados são trabalho em Three.js criado em código. O registro documenta separadamente os recursos gerados de pôster e retratos, uma esteira do Higgsfield e a mídia do portal. Um atlas anterior de personagens em Canvas também foi criado em código. Distinga esse histórico do renderizador ativo.
Warehouse Rush usa física do Rapier?
O tycoon ativo não importa Rapier. Ele aparece no histórico do projeto de origem e nos registros de licenças. A colisão, a navegação e o movimento visual limitado atuais são implementados diretamente, então manter um aviso de licença não comprova uma dependência ativa de física.
Como vocês usaram os efeitos sonoros da ElevenLabs no jogo?
Geramos efeitos fora do build para navegador e conectamos as amostras distribuídas aos eventos do jogo. A documentação de passagem registra 23 efeitos usando eleven_text_to_sound_v2. A reprodução segue as preferências de efeitos e usa alternativas sintetizadas quando as amostras estão indisponíveis. O navegador não chama a API de geração.
Seus testes de desempenho comprovam que o jogo roda bem no meu celular?
Não, o Chrome de desktop com uma área de visualização do tamanho de celular não é evidência de desempenho em um celular físico. O relatório de desempenho informa a máquina, as condições de amostragem e os limites restantes. Experimente o jogo no seu dispositivo real; o relato de celular ainda não resolvido precisa de um caso reproduzível com dispositivo e navegador identificados.
Como obter The Nine-Figure Upsell Playbook?
Entre em Warehouse Rush com seu e-mail e a URL da loja e, depois, envie o primeiro pacote para ganhar o guia. O guia tem 16 páginas e seis missões. Ele leva uma oferta pela compatibilidade do produto, pelo posicionamento, pela prioridade, pelas verificações de pagamento, pelo diagnóstico e por uma decisão com base na ficha de resultados.