Como o Roblox avalia a criação de jogos no Build

O Build, nossa nova ferramenta de criação voltada para dispositivos móveis, permite que um usuário do Roblox crie um jogo usando prompts de texto e o publique para jogadores em todo o mundo. A geração de um jogo holístico requer um sistema autônomo de ponta a ponta para a geração de jogos: um sistema que coordene código, recursos visuais, sistemas de jogabilidade, interface do usuário e controles em um único artefato composto. Esse sistema deve lidar de forma robusta com os diversos cenários que surgem com as entradas dos jogadores e as interações multijogador. Desde o lançamento da versão alfa na Nova Zelândia, mais de 100.000 jogadores usaram o Build para tentar criar um jogo, e aproximadamente 9.000 jogos criados com o Build foram publicados.¹ Entre os milhares que usaram o Build para criar um jogo, 71% nunca haviam usado o Roblox Studio antes,¹ o que mostra que estão experimentando algo novo com o Build.

Mas os criadores só usarão essa nova ferramenta se ela for fácil de usar e se a qualidade dos jogos gerados for alta o suficiente para servir de base. Para entender a qualidade dos jogos criados com o Build, avaliamos toda a jornada de criação e usamos essas avaliações, bem como o feedback dos criadores, para aprimorar o produto. Nossa estrutura de avaliação (eval) nos ajudou a priorizar e melhorar a compreensão da intenção, a jogabilidade 3D e o acabamento. Desde o lançamento da versão alfa do Build na Nova Zelândia, a satisfação dos criadores aumentou 10%, os resultados indesejados caíram de 18% para 3% e aproximadamente 14% das sessões solicitadas e 19% dos testes de jogabilidade foram publicados^.² Esses são indicadores descritivos de progresso, não estimativas causais do impacto da avaliação por si só.

Por que a avaliação da criação de jogos é diferente

Os jogos compartilham alguns dos mesmos desafios de avaliação encontrados em outros sistemas que geram artefatos compostos, como aplicativos, vídeos e modelos de mundo. Por exemplo, a qualidade depende de como vários componentes funcionam juntos, e nenhuma pontuação de um único componente descreve totalmente o resultado. 

O que diferencia os jogos é que o artefato é um sistema executável em tempo real, conduzido pelos jogadores. Propriedades como capacidade de resposta, autonomia, progressão e sensação do jogo surgem por meio da interação e não podem ser avaliadas plenamente apenas pela inspeção do código ou dos recursos. Um jogo, portanto, precisa atingir um padrão excepcionalmente alto de correção de baixo nível (livre de defeitos e jogável), bem como de experiência do jogador de alto nível (um jogo que pareça concluído, não um protótipo). 

A questão que buscamos responder por meio da avaliação não é se qualquer elemento isolado está correto, mas se o artefato como um todo corresponde à intenção do criador e se os jogadores conseguem vivenciar a experiência completa. Responder a isso requer mais do que uma única métrica.

Quatro sinais, uma estrutura

Nossa estrutura de avaliação de criação “Build” combina quatro sinais. Cada um responde a uma pergunta diferente, identifica uma classe diferente de falha e gera uma pontuação quantitativa concreta:

1. Qualidade da especificação do jogo (pontuação de 0 a 100): O Build é o agente de criação de ponta a ponta: ele traduz a solicitação do criador em uma especificação e, em seguida, usa essa especificação para gerar o jogo. O avaliador analisa se a especificação toma decisões importantes de forma explícita, preserva a intenção do criador, considera a viabilidade dentro do ambiente de execução do Roblox e evita inventar requisitos que nunca foram expressos.

2. Qualidade estática do jogo (pontuação de 0 a 100): O avaliador estático inspeciona o jogo gerado no modo de edição do Roblox Studio. Isso inclui a estrutura do jogo, scripts, recursos, propriedades, conexões e limites entre cliente e servidor. Buscamos responder a duas perguntas nesta etapa. A primeira é se o jogo foi construído corretamente: implementação dos sistemas necessários, escolhas de API do motor e de rede, presença dos controles e componentes de interface do usuário esperados, robustez e coerência da arquitetura do jogo. 

A segunda é se ele foi projetado para ser divertido: profundidade do ciclo principal, variedade e escalada de conteúdo, progressão, rejogabilidade e inovação além do padrão do gênero. Um jogo pode ter uma arquitetura limpa, mas não ter profundidade de conteúdo, ou estar cheio de ideias, mas mal estruturado. 

Separar essas duas perspectivas e avaliar com base nas melhores práticas nos dá uma ideia mais detalhada de onde o jogo está falhando.

3. Teste de jogabilidade (taxa de aprovação de 0 a 100%): O avaliador do teste de jogabilidade executa o jogo e aplica um plano de teste com entradas reais semelhantes às de um jogador, incluindo toques, cliques, pressionamentos de teclas e navegação, em vez de disparar eventos a partir do código. Um plano de teste caso a caso verifica se o jogo inicia, responde, avança, se recupera de falhas e permanece livre de erros de execução. Cada item é avaliado como aprovado ou reprovado, relatado como uma taxa de aprovação ponderada por nível, juntamente com um veredicto simples de jogável ou não jogável. Repetimos as execuções para medir a consistência.

4. Qualidade visual e experiencial (pontuação de 0 a 100): Alguns dos aspectos mais importantes para a aparência e a sensação de um jogo não podem ser interpretados a partir do código; por isso, o avaliador visual pontua a apresentação de forma independente, utilizando imagens capturadas da jogabilidade em janelas de visualização que representam diferentes dispositivos. Essa rubrica analisa apenas a aparência e o som do jogo com base na qualidade dos recursos, no acabamento da interface do usuário, no movimento, na iluminação e no áudio. A questão central é: o jogo parece um produto pronto para lançamento ou um protótipo? Manter os aspectos visuais separados da mecânica significa que “o código funciona” e “o jogo parece finalizado” não se combinam em uma pontuação única que possa induzir em erro.

Além dos sinais pontuados, cada execução captura métricas meramente informativas, como uso de tokens, chamadas de ferramentas, habilidades acionadas e latência. Essas métricas não alteram a pontuação da avaliação, mas podem explicar como um resultado foi produzido e detectar regressões que as rubricas não identificam, como uma compilação que ficou duas vezes mais cara para o mesmo jogo.

Os sinais correspondem às falhas que detectam:

Percorrendo uma pista de Obby 3D com instruções

Os sinais ficam mais fáceis de identificar em uma sugestão real. Por exemplo: “Um verdadeiro jogo de Obby em 3D, com plataforma de partida, obstáculos móveis, pontos de controle e linha de chegada”. Os Obbys são um tipo popular de jogo de plataforma no Roblox. A intenção do criador é clara, mesmo que não prescreva todos os detalhes de implementação. A construção precisa preencher os detalhes com suposições razoáveis.

Plano e Especificações

A equipe de desenvolvimento produziu um documento de especificações para um novo jogo, chamado Skyforge Ascent, detalhando um percurso de cinco seções com pontos de verificação e três tipos de perigos. Ele definiu o ciclo principal, a curva de dificuldade, a direção de arte, as telas, as sobreposições e os controles. A avaliação das especificações atribuiu uma nota de 91/100, obtendo nota máxima em completude, conformidade com as diretrizes, viabilidade e consistência interna. A dedução decorreu de dois aspectos específicos: detalhes de implementação e cobertura dos critérios de aceitação. 

As especificações nunca definiram suas constantes numéricas, como velocidades de giro, distâncias de deslizamento, tempos de bloco, dimensões das plataformas ou altura do plano de reinício; portanto, um engenheiro ainda precisa defini-las. Além disso, alguns critérios de aceitação (como “cerca de 24 plataformas” ou “paleta celestial-forge”) não são estritamente falsificáveis. Uma pontuação alta na especificação apenas comprova que o documento está pronto para a construção. Se esses compromissos resistem ao contato com o desenvolvimento real do jogo é o que as próximas três etapas medem.

Verificações estáticas: qualidade do código e qualidade do conteúdo

O juiz virtual inspecionou o arquivo de local do Skyforge Ascent sem jogá-lo, e as duas perspectivas de avaliação chegaram a conclusões diferentes.

A lente de engenharia, ao analisar o mesmo arquivo de mapa, atribuiu uma pontuação de 98/100. Ela identificou uma construção exemplar com cinco seções e três obstáculos móveis, atendendo plenamente à intenção do criador por meio de pontos de verificação sequenciais controlados pelo servidor, sistemas de reinicialização após queda e uma interface de usuário construída na estrutura StyleSheet. Tudo o que estava descrito nas especificações foi entregue. O único problema foram duas exportações de funções auxiliares não utilizadas.

A perspectiva de design atribuiu uma nota de 31/100. Tudo funcionava, mas o jogo recebeu nota zero em progressão, rejogabilidade, autonomia do jogador e gancho original. O ciclo principal era simples e linear — alcançar cada ponto de verificação, cruzar a linha de chegada —, com pouca variedade entre as jogadas e nenhum motivo para voltar para uma segunda tentativa. Trata-se de um elemento básico do gênero “obby”, não de um jogo com um gancho próprio.

Essa lacuna é a conclusão. A qualidade do código e a qualidade do conteúdo são dimensões fundamentalmente diferentes, e uma versão pode ser quase perfeita em uma delas, mas falhar na outra. Uma única pontuação de qualidade combinada teria calculado a média dessas duas dimensões, resultando em algo sem sentido.

Teste de jogabilidade

O agente de teste jogou o jogo de corrida usando entradas semelhantes às de um jogador real e passou em todos os nove itens do plano de teste: gerar um personagem na plataforma inicial, navegar pela geometria 3D atravessando aberturas, sofrer impactos de perigos, acionar pontos de verificação e recuperação automática de quedas, completar a corrida e reiniciar, tudo sem nenhum erro de execução. Nesta corrida específica, Skyforge Ascent obteve 100/100 no teste de jogabilidade.

Uma pontuação perfeita no teste de jogabilidade simplesmente prova que a mecânica funciona e que o jogo é tecnicamente jogável do início ao fim. Isso não diz nada sobre se o jogo é realmente envolvente ou divertido de jogar — essa distinção é precisamente o motivo pelo qual a perspectiva de design atribuiu a ele uma pontuação de 31.

Qualidade visual

Por fim, o sistema de avaliação pontuou a sessão gravada em uma janela de visualização do tamanho de um celular para avaliar a apresentação visual. O Skyforge Ascent obteve 86/100: limpo, coeso e confortavelmente alinhado com os visuais de um jogo de obstáculos típico; geometria de plataformas legível; perigos identificáveis; e um HUD moderno e discreto. Pequenas limitações visuais o impedem de atingir a perfeição, mas não há nada que não funcione, nem nada que faça o jogador parar de rolar a tela.

Métricas de rastreamento

A mesma execução também registrou métricas de processo. O jogo levou cerca de oito minutos para ser compilado, não houve erros de ferramentas, e o Build utilizou as habilidades de 3D, interface do usuário, edição de scripts, inserção de recursos e áudio do jogo. Essas métricas não afetam diretamente a pontuação da avaliação, mas nos mostram como o jogo foi feito e alertariam sobre uma compilação futura que ficasse mais lenta ou mais cara sem trazer nenhum ganho.

Ao longo de cinco etapas, o Skyforge Ascent obteve pontuações diferentes em especificações do jogo, qualidade do código, qualidade do conteúdo, teste de jogabilidade e qualidade visual. Quatro dessas dimensões indicam que o Build é capaz de transformar uma única solicitação em uma experiência Roblox completa, correta, jogável e apresentável. Uma dimensão indica que não é um jogo que alguém escolheria jogar duas vezes. Medir essa lacuna, em vez de ignorá-la calculando uma média, é o objetivo principal da avaliação do Build.

Como a avaliação precoce aprimorou o Build 

Os resultados da avaliação fazem mais do que gerar pontuações; eles também fornecem orientações práticas para melhorias no produto. Ao combinar a depuração de componentes individuais com testes holísticos no nível do sistema, as avaliações em lote offline por meio de conjuntos padronizados de prompts moldaram diretamente o desenvolvimento do Build. 

1. Resolução rápida dos pontos críticos dos criadores da versão alfa: em nosso lançamento alfa na Nova Zelândia, os usuários nos deram feedback de que o Build às vezes criava um jogo 2D quando eles queriam um jogo 3D. A estrutura de avaliação ajudou nossa equipe a melhorar rapidamente os recursos 3D do Build. Em duas semanas, aprimoramos a capacidade do Build de compreender a intenção do usuário de criar um jogo 3D — mesmo que ele não a declarasse explicitamente. Também refinamos a jogabilidade e o acabamento 3D, corrigindo problemas comuns relacionados ao posicionamento de objetos, iluminação etc. Desde então, as reclamações do tipo “não é o que eu quero” caíram de 18% para 3% do total de reclamações; a insatisfação geral após os testes de jogabilidade diminuiu 10 pontos percentuais. Também acumulamos aprendizados ao iterar na própria estrutura. 
2. Avaliação comparativa entre modelos e arquiteturas: usamos nossa estrutura de avaliação para comparar rigorosamente as configurações do sistema Build com conjuntos padronizados de prompts. Antes de enviar as alterações para produção, relatórios de avaliação A/B offline comparam as versões candidatas com nossas linhas de base de produção em todas as quatro dimensões: 

Por exemplo, essas comparações offline nos permitem isolar como diversas atualizações de modelo e decisões de roteamento de agentes afetam sinais de qualidade individuais:

• Desempenho do modelo base: a atualização do nosso modelo base proporcionou ganhos consistentes em todos os sinais — o que resultou em menos compilações com falhas na primeira tentativa, acabamento visual superior e conteúdo de jogabilidade mais aprofundado.
• Arquitetura de roteamento de agentes: por outro lado, delegar subtarefas específicas a um modelo leve em uma configuração de agente duplo preservou a profundidade e a diversidade do conteúdo, mas causou regressões acentuadas na jogabilidade e no acabamento visual.

1. Acompanhamento das linhas de base de qualidade em diferentes paradigmas de criação: Também utilizamos a estrutura para compreender a qualidade atual da construção em diferentes momentos, com o conjunto de avaliação mais relevante. Esses conjuntos fornecem instantâneos de tarefas de criação cada vez mais amplas e complexas.
   O conjunto mais antigo consiste inteiramente em jogos 2D com mecanismos relativamente simples. A lógica do jogo era fácil de construir; portanto, a pontuação do teste de jogabilidade tendia a ser mais alta; por outro lado, a pontuação de conteúdo permaneceu baixa exatamente pelo mesmo motivo.
   À medida que mudamos o foco para jogos em 3D, a distribuição das pontuações muda naturalmente: jogar sem bugs se torna mais desafiador, reduzindo as pontuações dos testes de jogabilidade. As pontuações visuais permanecem estáveis devido à falta de refinamento dos recursos, dando aos jogos uma sensação de protótipo. As pontuações de conteúdo são mais altas, pois os jogos em 3D têm o potencial de serem mais profundos — mas as pontuações gerais tendem a permanecer baixas, já que as solicitações de turno único oferecem espaço limitado para expansão de conteúdo.

1. Identificando gargalos específicos de cada gênero: os dados de avaliação também destacam variações significativas de desempenho entre os gêneros. Gêneros com mecânicas de jogo complexas (por exemplo, RPGs, jogos de tiro e de corrida) tendem a apresentar mais problemas de jogabilidade. Gêneros com lógica relativamente simples (por exemplo, jogos de sobrevivência e de simulação de negócios) costumam apresentar melhor desempenho nos testes de jogabilidade, tornando o refinamento visual e o design da interface do usuário o próximo desafio a ser resolvido. Conhecer a diferença entre os gêneros nos incentiva a ampliar nosso conjunto de avaliação com uma amostragem mais equilibrada entre os jogos da Build.
2. Lições aprendidas no projeto do sistema de testes: A iteração na própria estrutura nos ensinou lições essenciais sobre a confiabilidade do sistema de testes:

• Métricas do sistema versus métricas dos componentes: uma estrutura de código limpa ou o uso de APIs não garantem um jogo jogável. Mantemos a correção, o design e a apresentação distintos para evitar que bugs passíveis de correção fiquem ocultos.
• Pontos fracos do harness e calibração humana: verificações estáticas podem deixar passar bloqueadores de tempo de execução que causam falhas no jogo, enquanto testes de jogabilidade automatizados enfrentam dificuldades com física complexa. Juízes virtuais são continuamente calibrados em comparação com desenvolvedores profissionais de jogos e revisores experientes da comunidade.
• Expansão para múltiplas rodadas e tráfego real: Como os criadores reais iteram continuamente (adicionando sistemas, ajustando a dificuldade, corrigindo bugs), estamos expandindo nosso framework de avaliação para avaliar edições em múltiplas rodadas e distribuições de prompts do mundo real.

O que vem a seguir

Atualmente, estamos focados em ampliar nosso sistema de avaliação de criação “Build” em cinco direções:

1. Cobertura mais ampla em todos os gêneros, experiências 2D/2,5D/3D, cenários multijogador e níveis de complexidade
2. Maior suporte para edições em múltiplas rodadas
3. Evidências mais confiáveis de testes de jogo, capturas de tela, vídeos e áudio
4. Calibração com base em avaliações humanas em grande escala e casos de referência liderados por criadores
5. Melhor integração entre avaliação offline, sinais do produto online e testes de regressão

Nosso objetivo de longo prazo é um sistema de avaliação transparente e em constante aprimoramento que avalie o Build no nível que interessa aos criadores: a qualidade das experiências que eles podem criar, testar, compartilhar e continuar desenvolvendo. Atualmente, esses sinais são usados para avaliar jogos gerados pelo Build. Com o tempo, à medida que os refinarmos e calibrarmos ainda mais com base no julgamento humano, eles poderão ser generalizados para outros fluxos de trabalho de criação e ajudar a fornecer uma linguagem comum para compreender a qualidade dos jogos em todo o ecossistema mais amplo do Roblox.

Para uma análise relacionada à avaliação de sistemas agentivos para o Roblox Assistant, consulte “Usando o OpenGameEval para comparar assistentes de IA agentivos para o Roblox Studio”.