ForgeAX é umEstúdio de jogos pessoais nativo de IA. Acreditamos que a barreira para a criação de jogos está sendo redefinida pela IA.
Nossa visão é direta:deixe equipes menores, com IA, criarem jogos que antes exigiam jogos muito maiores.Não para substituir os criadores, mas para entregar a engenharia pesada e a produção entre a “ideia” e o “jogo jogável” à IA.
Onde estamos
O estágio atual étransformando ideias em jogos jogáveis com IA: já podemos fazer demos jogáveis de FPS, ARPG, sobrevivência e tiro no estúdio, com um motor que cobre renderização PBR, física e animação esquelética. Continuaremos aprimorando esse estágio em direção à qualidade de entrega.
Código aberto
A camada de ferramentas ForgeAX está licenciada sobLicença Apache 2.0- qualquer pessoa pode bifurcar, usar, construir comercialmente e redistribuir livremente. Queremos que seja um projeto aberto que a comunidade possa construir junta. Veja opágina de licença.
Deixe equipes menores fazerem jogos maiores.
No estúdio, você descreve o jogo que deseja para um líder de IA chamado Forge – por meio de chat, trabalhando diretamente em um editor visual e (mais tarde) com entradas como imagens e vídeo. Planeja, traz subagentes especializados quando necessário (jogabilidade, design, arte...), entãoescreve o próprio código do motor, recarregando o resultado em uma visualização ao vivo do navegador.
Abaixo estão duas fundações internas: umamotor redesenhado para o ponto de vista da IA(para que a IA possa ler, escrever e entender seus erros) e umciclo de desenvolvimento que mantém a IA em um resultado correto e verificável(requisitos de entrada, saída reproduzível, cada etapa observável e rastreável).
Um loop de sete passos
Dentro do mecanismo, cada recurso passa pelo mesmo pipeline - entrada de requisitos, saída de trabalho, com um registro legível em cada etapa:
- Requisitos — indique o que construir, com critérios de aceitação.
- Pesquisa — histórico, restrições e opções da pesquisa.
- Planejar — defina uma estratégia e divida-a em tarefas.
- Implementar — escrever código e testes.
- Verificar — verificações independentes; qualquer vermelho bloqueia a mesclagem.
- Julgamento — um humano toma a decisão final.
- Finalizar — mesclar assim que passar.
Um orquestrador e subagentes
Um “orquestrador” dirige a máquina de estado, decidindo qual subagente enviar em cada etapa e verificando sua saída; os subagentes são especializados em funções com seu próprio contexto. Os humanos julgam apenas dois pontos: declarar requisitos e revisar resultados.
Nenhum "parece bem" escapando
A verificação tem duas portas de IA: uma verifica estaticamente documentos e APIs da perspectiva de um usuário de IA, capturando “prometidos, mas não implementados”; o outro realmente executa a demonstração em uma sandbox isolada, captura capturas de tela e as verifica novamente – protegendo-se contra “testes verdes, tela preta”.
Fica mais estável com o tempo
Após cada recurso, o atrito encontrado ao longo do caminho é capturado como feedback que atualiza o próprio pipeline. O próximo recurso usa automaticamente a versão melhorada – o pipeline alimenta sua própria saída e fica mais inteligente.
O resultado: a IA não produz código de “nível de demonstração”, mas recursos verificados e reproduzíveis que um ser humano pode assumir.
A maioria das APIs de mecanismos de jogos são escritas para humanos. Quando a IA se tornar quem escreve o código, o mecanismo deverá parecer diferente.
A ideia central do ForgeAX é simples: o usuário descreve um jogo e a IA escreve o código do motor. Isso soa como “apenas um autor diferente”, mas na prática os mecanismos existentes não são amigáveis à IA – eles assumem um leitor que lê documentos, adivinha e preenche o contexto como um ser humano faz.
Nossa postura é direta: A IA é o primeiro usuário do mecanismo. Quando “amigável à IA” entra em conflito com “amigável aos humanos”, a IA vence. Aqui estão algumas consequências concretas.
1 · Uma fonte de verdade, deriva o resto
Um fato é definido exatamente num lugar; tudo o mais deriva dele. Os campos de componentes, por exemplo, ficam embutidos em um esquema – inspetores, depuradores e ferramentas leem o esquema em vez de buscar a fonte e adivinhar. A IA não precisa “lembrar” convenções espalhadas por toda parte, porque só há um lugar para procurar.
2 · Erros que a IA pode compreender e recuperar
Um erro não é apenas uma frase humana que você “lança”. Usamos um conjunto fechado de códigos de erro, cada um contendo informações estruturadas do tipo "o que/por que/como recuperar". Quando a IA encontra um erro, ela sabe o que mudar em seguida – em vez de tratar o texto da exceção como misticismo.
3 · Dados estruturados em vez de “olhar para a tela”
A parte mais difícil de um bug de renderização é que “parece errado na tela”. Um humano pode olhar para o monitor; A IA não pode. Assim, o mecanismo pode capturar um quadro de chamadas de renderização – chamadas de desenho, ligações, destinos de renderização, estado do pipeline – para ler offline, reproduzir e inspecionar o estado completo no enésimo sorteio. Um problema visual é que os dados que a IA pode ler.
4 · Duas implementações que se verificam
A camada de renderização possui duas implementações de back-end (WebGPU e uma wasm) atrás de uma única interface. Eles são renderizados lado a lado: no momento em que a IA faz uso indevido de uma API de mecanismo, o outro back-end diverge imediatamente, revelando o problema – muito mais rápido do que esperar por uma revisão humana.
Esses designs compartilham um critério: quanto menos conceitos um leitor (humano ou IA) tiver em mente, melhor. Quanto mais autoconsistente e indexável localmente a API, mais frequentemente a IA acerta — e mais fácil será para um humano assumir o controle.
“IA-nativo” não é um slogan – é uma longa série de decisões de “refazer para o ponto de vista da IA”. Descompactaremos mais deles na documentação e em postagens futuras.