Depuração de jogos gerados por IA

Classifique a falha antes de pedir uma correção

Identifique a primeira etapa que falhou: descoberta do projeto, importação, parsing ou compilação, inicialização da cena, entrada do jogador, estado da jogabilidade, exportação ou lançamento no alvo. Sintomas posteriores podem ser consequências dessa primeira falha. Mantenha juntos a versão do motor, a revisão do projeto, o alvo e a reprodução exata.

Por exemplo, uma cena que nunca inicia não pode dizer se seu botão de reinício funciona. Um navegador que não consegue buscar o pacote do jogo não pode testar o controlador. Encaminhe o erro ao limite correto antes de mudar o código; isso impede que um loop de reparo acumule patches sem relação enquanto o pré-requisito original continua quebrado.

Capture o primeiro erro significativo do motor

No Godot, use o painel do depurador e a saída de runtime relevante. No Unity, inspecione erros de compilação e runtime separadamente e espere o editor ficar pronto antes de interpretar resultados de execução. Preserve a pilha ou localização que identifica o script com falha e a operação que o acionou.

Envie ao agente um trecho focado junto do contexto relevante da cena ou objeto. Evite um log gigante e indiferenciado que esconda o primeiro erro, mas mantenha o registro completo localmente para inspeção posterior. Redija credenciais e dados pessoais. Um relatório útil diz o que o jogador fez, o que deveria acontecer e o que o motor realmente informou.

Reduza a reprodução sem mudar o requisito

Comece de um estado recuperável do projeto e isole a menor cena ou ação que ainda apresenta o defeito. Mantenha o controlador, a regra de colisão ou o limite de salvamento real envolvido no problema. Remover completamente o sistema que falha pode produzir uma execução limpa enquanto elimina o comportamento que você precisava corrigir.

O briefing abaixo é um template diagnóstico original. Preencha-o com detalhes observados em vez de pedir ao modelo que assuma uma causa. Exija uma explicação proposta e uma alteração de escopo estreito. Quando o teste terminar, reconecte a jornada completa do jogador para que o reparo local não esconda uma transição de cena quebrada.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

Investigue uma tela em branco por camadas

Primeiro determine se o motor iniciou e se a cena pretendida foi carregada. Depois inspecione seleção da câmera, dimensões do viewport, visibilidade dos objetos, posições e qualquer sobreposição que cubra a cena. Use o estado do motor e uma captura real juntos: uma imagem sozinha pode não revelar se a cena está pausada, fora da câmera ou vazia.

Aplique uma entrada e observe se o estado muda mesmo quando nada aparece. Se a posição mudar mas a imagem não, concentre-se em renderização ou referências de cena. Se nada mudar, investigue inicialização e entrada antes de ajustar a arte. Mantenha cada hipótese ligada a uma observação para que o agente não reescreva os dois sistemas sem necessidade.

Rastreie a entrada pela transição da jogabilidade

Siga a ação do foco e mapeamento ao handler e depois ao estado que ela deveria mudar. Verifique estado de pausa e interceptação da UI antes de culpar a matemática do movimento. Uma falha de reinício pode ser um handler ausente, uma referência de cena antiga ou um estado que nunca foi redefinido.

Depois do reparo, teste a ação em mais de um estado relevante: primeiro lançamento, depois de uma vitória e depois de uma derrota quando aplicável. Verifique handlers duplicados ou objetos antigos que aparecem somente após rodadas repetidas. Um pequeno minifluxo completo pode localizar esses defeitos de ciclo de vida com mais eficácia do que testar o botão repetidamente de forma isolada.

Separe carregamento do navegador da lógica do jogo

Para uma exportação web do Godot, inspecione os painéis de rede e console do navegador antes de editar o código da jogabilidade. Confirme que HTML, JavaScript, WebAssembly e o pacote do jogo exportados carregam do local pretendido. Compare as configurações de hospedagem com a documentação oficial de exportação web, incluindo os requisitos da configuração de threads escolhida.

Mantenha consistentes os nomes dos arquivos complementares exportados e teste o artefato, não uma mistura de arquivos antigos e novos. Se aparecer o projeto errado, inspecione o cache de service-worker no navegador de teste. Depois exercite a entrada e verifique o conteúdo em movimento. Um canvas que não está vazio é uma verificação inicial de renderização, não uma prova de que o loop do jogo funciona.

Verifique falhas específicas da exportação no alvo

Quando o editor funciona mas a compilação distribuída falha, compare seleção da cena inicial, recursos incluídos, configuração e logs do alvo. Preserve o hash exato do artefato para que uma nova exportação não invalide o registro de reprodução. Teste com um estado inicial limpo antes de depender de salvamentos existentes ou caches do editor.

Não mude a mecânica central para resolver um arquivo empacotado ausente. Corrija o limite de empacotamento e repita o mesmo caminho de aceitação na compilação-alvo. Para artefatos desktop, use o sistema operacional real; para artefatos de navegador, use o navegador e a configuração de hospedagem pretendidos. Exportar para outra plataforma, por si só, não estabelece o comportamento no alvo.

Feche um reparo com um resultado antes e depois

Retenha a reprodução que falhou, o diff de escopo limitado e a ação repetida que agora produz o estado esperado. Adicione uma verificação de regressão no limite que causou o defeito e depois repita o loop de jogo ao redor. Registre correções manuais e as solicitações consumidas por reparos malsucedidos.

Os exemplos aqui são procedimentos de diagnóstico, não um caso publicado de falha e correção. Use-os para criar um relatório concreto do seu projeto. Quando o mesmo sintoma persistir após propostas repetidas, interrompa o loop automático e reúna a observação ausente em vez de escalar para uma reescrita ampla sem novas evidências.

Perguntas frequentes