Escolha uma ferramenta de criação de jogos pelo jogo que você consegue jogar, pela mudança que consegue fazer e pelo projeto que consegue manter, não apenas por uma captura de tela. Uma comparação justa começa com um mesmo briefing pequeno e verifica as mesmas regras visíveis ao jogador antes de avaliar a aparência. Também registra trabalho manual, restrições do plano e o conteúdo real de uma exportação. Este teste proposto abrange SEELE AI, Rosebud AI, GDevelop e Buildbox, as quatro ferramentas citadas na comparação existente. Não havia execuções controladas nem inspeções de exportação disponíveis para este rascunho. Portanto, resultados e recomendações continuam pendentes: não há notas, diferenças de capacidade observadas nem vencedor. As seções abaixo definem o que executar e preservar para que uma comparação posterior possa responder honestamente à pergunta de qual escolher.
O briefing comum e os controles
Use um navegador de computador, uma área de visualização fixa e o mesmo dispositivo de entrada em todas as execuções. Declare o plano permitido, o limite de gastos, o limite de intervenções e a condição de parada antes de abrir uma ferramenta. Registre o nível da conta, a data, a versão exibida da ferramenta e os custos reais. Não presuma que quantidades iguais de prompts significam esforço igual quando um fluxo exige edição visual.
Crie Lantern Delivery, um jogo 2D de navegador em uma única tela com visão de cima. Use um entregador original e cenários originais simples. Movimente-se com WASD ou as setas. Colete cinco lanternas enquanto evita um perigo móvel. Mostre a quantidade coletada e um cronômetro de 45 segundos. O contato com o perigo ou o fim do tempo encerra a tentativa. Coletar as cinco dá a vitória. Inclua instruções visíveis e Reiniciar. Mantenha o mesmo entregador e a mesma direção de arte durante todo o jogo. Não use personagens licenciados nem arte protegida por direitos autorais baixada da internet.Trate isso como uma especificação, não como um resultado gerado. Para o teste, inicie o cronômetro no primeiro movimento, bloqueie os comandos após qualquer um dos finais e restaure todo o estado ao reiniciar. Se uma interface não aceitar o briefing diretamente, documente como seu fluxo nativo o implementa. Não conceda silenciosamente preparação extra a um candidato nem substitua o briefing por um modelo mais completo.
Os registros dos quatro candidatos a completar
SEELE AI: verificar a entrega após o prompt
O SEELE descreve a criação em linguagem natural de cenas, recursos e código de jogo. Para esta comparação, a pergunta relevante é se esse fluxo produz o ciclo especificado de Lantern Delivery e permite a alteração controlada no mesmo projeto. Forneça o briefing sem alterações pelo fluxo de criação disponível e preserve a solicitação original, o histórico de respostas, o primeiro build acessível e as condições da conta.
Não deduza acesso ao código-fonte, compatibilidade com motor ou inicialização local bem-sucedida a partir do posicionamento do produto. Inspecione a entrega real e registre seu formato. Se forem necessárias explicações ou correções adicionais, conte-as e preserve-as antes de passar à edição do escudo. Uma recomendação futura útil relacionaria a jogabilidade observada, o esforço de revisão e a reprodutibilidade às necessidades de quem lê. No momento, essas observações não existem, portanto este candidato não recebe nota nem vantagem atribuída.
Rosebud AI: registrar o caminho real de criação e revisão
Execute o briefing comum usando o fluxo disponível na conta Rosebud AI testada. Registre o formato de entrada inicial, a preparação necessária e cada intervenção para obter um build acessível. Consulte a documentação oficial atual sobre as condições do plano, mas mantenha as afirmações documentadas separadas do que a pessoa avaliadora observa. Este rascunho não estabelece quais recursos atuais ou formatos de exportação estão disponíveis.
Quando uma versão de referência puder ser jogada, preserve-a antes de enviar a mesma solicitação do escudo. Registre se a revisão altera o projeto existente e se entregador, regras e mapa permanecem. Para a entrega, inspecione o artefato que o fluxo testado realmente fornece; não chame um link hospedado de “código-fonte”. A falta de acesso em uma conta é uma observação específica do plano, não prova de que o produto nunca oferece uma capacidade. Nenhuma geração, revisão ou exportação do Rosebud foi executada para este artigo.
GDevelop: tornar visível o trabalho no editor
Avalie o fluxo atual do GDevelop como ele se apresenta à pessoa que testa, não como uma suposta cópia de um gerador conversacional. Registre a construção de cenas, edição de eventos, preparação de recursos ou seleção de modelos necessárias para implementar o briefing. Se o fluxo oferecer criação assistida, preserve suas entradas e saídas junto das ações manuais. Este artigo não verificou essas opções atuais nem as condições dos respectivos planos.
Uma estrutura de eventos editável pode ser a entrega relevante para quem usa um editor visual; ela não deve ser descartada apenas por diferir de um diretório de scripts escritos à mão. Por outro lado, um projeto de editor sozinho não prova que um build compartilhado no navegador funciona. Registre separadamente a versão de referência, a alteração controlada de eventos ou projeto, as verificações jogáveis e o conteúdo real da exportação. A comparação futura deve mostrar o esforço e o resultado desse fluxo, sem penalizá-lo ou recompensá-lo pelo rótulo “sem código”. Não há resultado de teste do GDevelop aqui.
Buildbox: distinguir edição de projeto de resultado publicado
Use o fluxo real da conta Buildbox testada para implementar Lantern Delivery, documentando a configuração necessária e qualquer comportamento derivado de modelo. Verifique a documentação atual e as condições da conta antes de descrever opções de publicação ou exportação. Não presuma que a interface de prompt, a organização de arquivos ou as instruções de execução local de outra ferramenta se aplicam aqui. Preserve a primeira revisão do projeto que puder ser avaliada, incluindo qualquer preparação manual.
Para a alteração do escudo, registre a lógica editável ou as diferenças do projeto que implementam a proteção, além de evidências de que as regras de referência continuam intactas. Identifique com precisão a entrega resultante: projeto de editor, build hospedado, artefato compilado ou arquivos-fonte, conforme o que realmente for fornecido. Se um destino ou exportação estiver inacessível, informe o plano testado e a restrição exata observada. Assim, outra pessoa poderá avaliar o fluxo conforme suas necessidades. No momento, nenhum build, revisão ou entrega do Buildbox foi inspecionado e não há fundamento para um veredito sobre capacidades.
Execute as mesmas verificações de jogo, edição e entrega
Primeiro, teste instruções, os dois modos de movimento, coleta única, contato com o perigo, vitória com cinco lanternas, tempo esgotado e reinício após cada final. Repita após um novo carregamento. Marque cada verificação como aprovada, reprovada ou não testada e anexe a revisão do build. Guarde uma gravação ininterrupta que inclua falhas. Uma resposta de página ou uma cena atraente não constitui uma verificação completa do ciclo de jogo.
Depois aplique uma alteração controlada: adicione um escudo coletável que absorva exatamente um contato com o perigo e desapareça quando coletado. Mostre se a proteção está ativa. Preserve a arte do entregador, o mapa, os controles, a contagem de lanternas, o cronômetro e o reinício. Especifique que nenhum segundo escudo aparece antes do reinício. Teste a coleta, o primeiro contato protegido, o contato seguinte sem proteção, o tempo esgotado enquanto protegido e a restauração ao reiniciar. Execute novamente todas as verificações de referência. Salve a diferença entre revisões no formato nativo, seja código, eventos ou outro artefato de projeto inspecionável.
Por fim, diferencie um link jogável, um build compilado, um projeto editável e código-fonte legível por pessoas. Salve e inspecione a exportação fornecida. Abra ou execute-a com as ferramentas documentadas em um diretório limpo, registrando comandos reais, versões, recursos ausentes e correções manuais. O download bem-sucedido, sozinho, não comprova um projeto reproduzível. Mantenha a documentação atual ao lado da observação, sem usá-la para substituir o teste.
Compare elementos equivalentes: primeiro resultado acessível com primeiro resultado acessível, e resultado corrigido com resultado corrigido, informando as intervenções. Uma pessoa iniciante pode priorizar iterações compreensíveis e um ciclo funcional; uma desenvolvedora pode priorizar código-fonte reproduzível; quem usa editor pode preferir eventos inspecionáveis. Relate essas concessões somente quando os artefatos existirem. Números de tempo e créditos precisam de regras registradas de início e parada, não de estimativas feitas depois de ver o resultado. Uma única execução pode sustentar uma comparação limitada de casos, não uma afirmação geral de confiabilidade.
Lista de evidências: nenhuma célula de resultado está completa
- Por candidato: nível da conta, data do teste, versão exibida, navegador, orçamento e histórico real de intervenções.
- Briefing original, projeto ou build de referência e gravação completa das verificações de aceitação.
- Solicitação exata do escudo, revisões antes e depois, alteração inspecionável e observações de regressão.
- Artefato real de exportação ou entrega, registro de configuração em ambiente limpo e resultado observado da inicialização.
- Documentação oficial atual que sustente qualquer afirmação sobre planos ou formatos.
- Constatações por ferramenta e recomendações condicionais redigidas somente após essas verificações.
As quatro execuções dos candidatos continuam não realizadas para este artigo. A lista é um plano de coleta, não uma tabela de resultados. Não há classificação testada, ferramenta mais rápida, jogo concluído mais barato ou vencedor de exportação verificado a informar.
Conclusão: adie a recomendação até haver evidências
A comparação útil não é qual ferramenta parece mais completa, mas qual fluxo testado combina com o projeto que você quer continuar. Preserve o briefing comum, informe a assistência recebida e separe o comportamento jogável da entrega que pode ser inspecionada. Este rascunho não pode escolher um vencedor: faltam as quatro execuções controladas, revisões e exportações. Após a autorização de acesso e de qualquer orçamento necessário, use o briefing comum de Lantern Delivery no SEELE e repita-o sem alterações nos demais candidatos. Mantenha falhas e restrições no registro. Só então reduza as opções com base na jogabilidade observada, no esforço de edição e no acesso ao projeto, em vez de uma classificação presumida.
Ficha de comparação: registre suas próprias evidências
Esta tabela organiza as verificações propostas no artigo. Ela não é um relatório de teste concluído.
| Avaliação | Aplique a mesma verificação a cada candidato | Registre |
|---|---|---|
| Resultado jogável | Execute o briefing comum e verifique as regras visíveis ao jogador. | O que funcionou, o que falhou e as evidências de cada execução. |
| Esforço e custo | Registre plano, gastos reais, prompts e edições manuais. | Nível da conta, data, custo, intervenções e tempo de esforço. |
| Revisão | Solicite a mesma alteração limitada e repita a verificação de referência. | Instruções da alteração e resultados dos testes antes e depois. |
| Entrega | Inspecione o que realmente está disponível após exportação ou entrega. | Arquivos, possibilidade de edição, dependências e termos aplicáveis. |
| Decisão | Compare as evidências registradas com suas prioridades. | Indique verificações pendentes em vez de atribuir um vencedor sem fundamento. |
Perguntas frequentes
Um botão de exportação significa que receberei código-fonte editável?
Não. A exportação pode ser um build compilado ou um projeto destinado a um editor específico. Baixe e inspecione o artefato real, depois abra ou execute-o com as ferramentas documentadas. Registre o plano e o formato testados para que uma observação limitada à conta não seja confundida com uma capacidade universal do produto.
A documentação oficial pode substituir uma comparação prática?
Não. A documentação pode sustentar uma afirmação sobre um recurso ou plano atual, mas não pode mostrar que esse jogo específico funcionou corretamente ou resistiu à alteração do escudo. Guarde documentação e resultados observados em notas separadas. Marque um cenário não executado como não testado, em vez de tirar confiança de um exemplo promocional ou de uma lista de recursos.
Cada candidato deve receber exatamente o mesmo número de prompts?
Use o mesmo briefing inicial e a mesma especificação de alteração, mas informe toda assistência adicional e trabalho manual. Interfaces diferentes podem exigir ações diferentes, portanto a contagem de prompts, sozinha, não mede o esforço de maneira justa. Defina previamente os limites de intervenção e orçamento e preserve o histórico, em vez de ajustar as regras depois de ver os resultados.
