Um jogo que abre no navegador não é necessariamente um projeto que você pode continuar desenvolvendo. A próxima pergunta útil é se alguém consegue reproduzi-lo, explicar suas regras e adicionar uma funcionalidade sem quebrar a rodada original. Para verificar isso, preserve uma versão de referência e defina uma extensão limitada, em vez de depender de uma captura de tela ou da garantia de que o código é editável. Este artigo apresenta um teste reproduzível de continuidade para um pequeno jogo de coletar estrelas. Não se trata de um relatório prático concluído: nenhum projeto-fonte, execução de referência ou patch de extensão estava disponível para este rascunho. A exigência de resultados reais continua pendente. Use o protocolo para reunir as evidências que faltam; não interprete seus critérios de aceitação como conclusões sobre o SEELE ou qualquer projeto gerado.
1. Defina o projeto e suas regras originais
Use um cenário de teste delimitado: um jogo de navegador para computador, com movimento pelas setas, cinco estrelas coletáveis, rodada de 30 segundos, vitória ao coletar as cinco, derrota quando o tempo acaba e reinício completo. Esse é o cenário pretendido, não uma versão já existente. Obtenha o projeto realmente editável, seus recursos, declarações de dependências e instruções de inicialização. Registre a versão do gerador ou da ferramenta quando disponível, a revisão do projeto, o ambiente de execução, o navegador e o sistema operacional.
Diferencie os arquivos-fonte de uma prévia hospedada ou de um pacote compilado. Recursos ausentes, dependências não documentadas ou uma entrega de código-fonte indisponível são constatações a registrar, não lacunas a preencher silenciosamente. Se o projeto recebido for diferente do cenário proposto, documente suas regras existentes antes de escolher uma extensão equivalente e limitada. Preserve uma cópia intacta e outra de trabalho para que alterações posteriores não apaguem as evidências originais.
2. Reproduza a versão de referência antes de fazer reparos
Siga as instruções de configuração fornecidas em um diretório limpo. Salve os comandos exatos, a saída da instalação, o log de inicialização e o console do navegador. Não invente um comando só porque o projeto se parece com um framework conhecido. Se a configuração falhar, preserve o erro e registre qualquer intervenção separadamente. Uma versão de referência reparada pela pessoa avaliadora continua sendo uma versão reparada, não um sucesso sem ressalvas do projeto entregue.
Execute quatro cenários: colete uma estrela e permaneça no local; colete as cinco; deixe o tempo acabar; reinicie após cada tipo de término. Verifique se cada estrela é contada uma única vez, se o movimento para após o término e se todos os estados da rodada são restaurados. Para cada cenário, anote a ação, o resultado esperado, o resultado observado e a revisão. Preserve as falhas com o mesmo cuidado dedicado às execuções bem-sucedidas.
3. Rastreie a regra que será alterada
Localize o código real ou a lógica editável que conecta movimento, detecção de contato, estado de coleta, contador exibido e verificação de vitória. Use nomes de arquivos ou identificadores de eventos reais em suas anotações. Explique quem controla o cronômetro e qual ação de reinicialização o restaura. Uma explicação plausível da IA não basta: confira-a no projeto.
Procure contadores duplicados ou lógica de reinicialização espalhada por sistemas sem relação entre si. Esses são pontos a investigar, não provas automáticas de uma arquitetura ruim. O objetivo prático é identificar onde o item bônus deve ficar e quais comportamentos existentes precisam permanecer iguais. Registre as dúvidas antes de solicitar o patch.
4. Adicione uma estrela bônus azul ao mesmo projeto
Salve a revisão de referência e solicite apenas esta alteração. O exemplo separa deliberadamente o novo efeito sobre o tempo do contador de coleta existente:
Adicione uma estrela bônus azul a este jogo existente. No primeiro contato com ela durante uma rodada ativa, remova-a e acrescente três segundos ao tempo restante. Ela não deve aumentar o contador de estrelas normais nem alterar o limite de cinco estrelas para a vitória. O reinício restaura a estrela bônus. Uma rodada encerrada não pode ser reativada. Preserve o movimento, as estrelas normais, o fim do tempo e todas as regras originais de encerramento. Identifique os arquivos ou eventos realmente afetados antes de propor o menor patch possível. Não substitua o jogo nem recursos sem relação com a alteração.Revise a alteração proposta antes de executá-la. Registre os arquivos ou eventos modificados, as dependências adicionadas e qualquer reestruturação. Pergunte por que um subsistema sem relação foi alterado. Um novo jogo independente com um objeto azul não demonstra a continuidade da versão de referência, mesmo que a prévia pareça semelhante. Guarde o patch junto com sua explicação para que outra pessoa possa examinar a mesma revisão.
5. Verifique novamente o comportamento original, os limites e a reversão
Repita todos os cenários de referência. Depois, colete a estrela bônus uma vez e permaneça no local onde ela estava: o tempo deve aumentar apenas uma vez e o contador normal não deve mudar. Reinicie, colete-a novamente e verifique a restauração. Teste o contato perto do fim do tempo e após o encerramento; o novo item não deve retomar uma rodada concluída. Registre as suposições sobre a ordem dos quadros se eventos simultâneos puderem afetar o resultado.
Quando uma verificação falhar, salve a revisão com falha e uma sequência curta para reproduzi-la antes de solicitar outro reparo. Reverta para a versão de referência preservada e execute novamente um dos cenários originais. Só depois dessa verificação é possível informar que a reversão foi reproduzida. Aqui não foi estabelecido nenhum patch bem-sucedido, resultado sem regressões, tempo de reparo ou resultado de reversão.
O que o SEELE pode oferecer e o que precisa ser verificado
O SEELE descreve um fluxo de criação de jogos em linguagem natural que envolve cenas, recursos e código de jogo. Isso faz de um pequeno jogo gerado um ponto de partida pertinente para o teste. Forneça primeiro a breve descrição do jogo e verifique o que o fluxo atual realmente entrega: um resultado jogável, um projeto editável, arquivos-fonte ou outro artefato. Essas entregas não são equivalentes.
Na etapa de continuidade, forneça o contexto do projeto existente e a única exigência da estrela bônus. Examine a alteração resultante em vez de presumir que uma revisão em linguagem natural preserva o estado corretamente. O acesso disponível ao projeto, a compatibilidade com o motor e os detalhes de exportação precisam ser confirmados na conta e no resultado reais. A descrição do produto justifica experimentar o fluxo; ela não comprova a reprodutibilidade, a arquitetura ou a manutenibilidade deste projeto.
As evidências necessárias para uma conclusão real
- Arquivo do código-fonte original ou do projeto editável, recursos necessários e uma revisão de referência estável.
- Instruções reais de configuração, detalhes do ambiente, saída dos comandos e erros ou reparos na inicialização.
- Registro dos cenários de referência e evidências de execução contínua para vitória, derrota e reinício.
- Uma explicação relacionada ao código ou aos eventos reais, a solicitação exata da extensão e seu patch verificável.
- Revisões anteriores e posteriores, observações dos testes de regressão e de limites e uma reversão reproduzida.
- Uma conclusão limitada a este projeto e a esta extensão, incluindo falhas ainda não resolvidas.
Todos esses artefatos que permitiriam apresentar resultados estão ausentes no momento. Uma alteração bem-sucedida da estrela bônus sustentaria uma afirmação limitada sobre continuidade, não uma promessa sobre recursos de rede, migração de dados salvos ou desenvolvimento em escala de produção. Uma entrega incompleta deve permanecer visível no relatório, em vez de ser substituída pela conclusão genérica de que “código de IA é editável”.
Conclusão: reúna primeiro as evidências da próxima alteração
Avalie a continuidade por uma alteração que resista à revisão e aos testes de regressão. Comece com materiais de projeto reproduzíveis, preserve as regras originais e mantenha a extensão pequena o suficiente para que uma edição inesperada seja visível. Este rascunho oferece o método, não o resultado que falta: uma avaliação prática da manutenibilidade continua impedida até que existam o projeto, o patch e as evidências de execução. Como próximo passo, use a breve descrição do jogo de coletar estrelas no SEELE e preserve a entrega real antes de solicitar a estrela bônus. Se faltar o código-fonte ou a configuração falhar, pare, documente o impedimento e não trate uma prévia bem acabada como prova de que o desenvolvimento pode continuar.
Teste de continuidade: evidências a coletar
Esta tabela organiza as verificações propostas no artigo. Ela não é um relatório de teste concluído.
| Verificação | Observação esperada | Evidências a preservar |
|---|---|---|
| Configuração de referência | O projeto fornecido pode ser aberto e executado com suas próprias instruções. | Revisão do projeto, etapas de configuração, dependências e anotações de execução. |
| Rodada original | Movimento, cinco itens coletáveis, cronômetro, vitória, derrota e reinício seguem o cenário especificado. | Registro de teste repetível e revisão de referência. |
| Extensão limitada | A regra solicitada para a estrela bônus funciona sem alterar comportamentos não relacionados. | Solicitação de alteração, patch ou revisão e verificações da nova regra. |
| Regressão e reversão | Os testes originais continuam passando e a alteração pode ser identificada e revertida. | Resultados dos testes antes e depois e referência da reversão. |
Perguntas frequentes
Uma prévia hospedada pode provar que um jogo é sustentável de manter?
Não. Uma prévia hospedada pode demonstrar a jogabilidade observável, mas não comprova a integridade do código-fonte, a configuração reproduzível nem as consequências de uma alteração no código. Use-a como parte do registro. Uma afirmação sobre continuidade também exige os materiais editáveis, a versão de referência preservada, uma alteração verificável e testes de regressão no ambiente de execução pretendido.
Preciso saber programar para realizar este teste?
Você pode registrar cenários visíveis para quem joga sem saber programar, mas uma análise confiável do código-fonte e das dependências exige alguém familiarizado com a linguagem ou o editor do projeto. Separe essas responsabilidades. Peça a uma pessoa qualificada que verifique a alteração real, em vez de tratar uma explicação confiante da IA ou uma tela inicial funcional como revisão de arquitetura.
E se a extensão funcionar, mas a configuração continuar sem documentação?
Relate um sucesso parcial, não uma entrega sem ressalvas. A extensão pode funcionar em um ambiente já configurado enquanto uma nova pessoa desenvolvedora ainda não consegue reproduzi-la. Preserve a revisão que funcionou, anote as etapas de configuração realmente usadas e repita-as a partir dos materiais fornecidos antes de descrever o projeto como reproduzível de forma independente.
