As dez sob auditoria: o Turian em outubro de 2026

Em 10 personas: para quem o Turian é feito, apresentei as dez pessoas para quem o Turian é feita e aquilo que cada uma ama e odeia. Este é o texto complementar: a auditoria honesta.

Para cada persona abaixo, você encontra o que o Turian oferece hoje, o que ainda deve e o indicador de sucesso que me diria que ela está sendo conquistada, tendo como referência as mesmas coisas que ama e odeia no primeiro artigo. O que existe e o que está planejado ficam separados, e quando algo que ela ama está atendido só pela metade, o texto diz isso. Uma lista de recursos que finge estar tudo pronto não ajuda ninguém.

Esta é a análise de outubro de 2026. Quando a realidade discordar desta página, a realidade vence, e a próxima análise substitui esta.

Ana

A adolescente que faz jogos por hobby

P·S·I·J: Prototipadora, Compradora, Integradora, Profissional de ofício.

No Turian hoje

O Turian Studio cria um projeto com uma cena inicial, e Play (F5) a executa dentro do Studio. Parar descarta a cópia em execução, então um erro não pode quebrar a cena em edição.
Um manual escrito para iniciantes no site, em quatro idiomas, e o próprio Studio localizado com o mesmo sistema.
A loja de assets, com alguns bricks nas prateleiras: os controladores de câmera (Free Fly, FPS, Orbit, Follow) e a interface dentro do jogo são instalados, não reconstruídos.
actions de input: um controle é uma ação com nome em vez de uma tecla bruta.
Modding por variação. Uma variante de prefab ou de data asset é o original mais os valores sobrescritos, e continua acompanhando o original quando ele muda.

O que ainda devo

Tutoriais passo a passo. Não existem. O manual é uma referência, e um iniciante precisa de um caminho do zero ao primeiro jogo.
Assets de terceiros na loja, prontos para comprar e baixar.
Criação em 2D. Iniciantes procuram 2D primeiro, e o Turian hoje é um editor 3D.
Projetos de demonstração bem acabados, cada um focado numa área e pronto para abrir, editar e executar, com README e a versão da engine necessária.
Templates de projetos e kits completos pela loja de assets.

Indicador de sucesso: proporção de primeiras sessões que terminam com algo rodando e exportável.

Benjamin

O indie solo que começa pelo código

C·P·A·J: Finalizador, Purista, Arquiteto, Profissional de ofício.

No Turian hoje

turian-cli executa o mesmo compilador, importador, exportador e renderer que o Studio: new, compile, export, play, scene, screenshot, playmode, pick. Códigos de saída são diferentes de zero em caso de falha, então scripts podem confiar neles.
Um projeto é uma pasta de arquivos comuns. Scripts são C# normal sob definições de assembly armazenadas como dados, e pacotes são declarados em Bricks/manifest.json, então nada exige o editor aberto.
Renderização sem interface para avif, mesmo numa máquina sem GPU, e turian-cli ui renderiza um documento de interface sem precisar de cena.
A engine usa MPL 2.0, e o código-fonte pode ser lido, então qualquer implementação pode ser investigada em vez de aceita por confiança.
Bibliotecas reutilizáveis que vivem fora da engine e podem ser usadas sem ela, como Graph e Guinevere, com nomes e versões próprios.
Simulação configurável de ticks fixos com pausa e avanço de um passo, além de replay de comandos, para que um teste sem interface conduza o jogo tick a tick.

O que ainda devo

A engine e seus atributos como pacotes NuGet, para que um projeto C# comum possa referenciar o Turian sem instalar o Studio.
Um projeto de demonstração só em código que compile e execute sem nunca abrir o editor.
Data assets só em código: criar, ler e usar um data asset em C# comum, sem envolver o editor.
Um profiler. Ainda não existe.

Indicador de sucesso: proporção de projetos em que o editor nunca é aberto.

Carlos

O integrante do pequeno estúdio nascido numa jam

I·W·I·C: Iterador, Construtor de mundos, Integrador, Maestro.

No Turian hoje

Play, Pause e Step Frame (F5, F6, F10) dentro do Studio, executando uma cópia da cena aberta. Quando um script falha ao compilar, o último build funcional permanece carregado, então um erro de digitação não encerra a sessão.
Bricks também são o sistema de plugins, e a loja de assets os distribui: o que uma jam precisa é instalado, não escrito.
Edição de múltiplos objetos no Studio: selecionar vários objetos, editar um campo compartilhado uma vez e desfazer o lote inteiro num passo.
Cache que compensa no meio da jam: reabrir um projeto reutiliza arquivos importados e código compilado quando nada mudou, e File → New Scene abre uma cena descartável para experimentos.

O que ainda devo

Designers alterando valores e listeners enquanto o jogo roda, sobre os data assets que Fernando usa. As peças existem (veja Fernando); o ciclo de edição ao vivo ainda não.
Manter os valores alterados durante o Play Mode. Hoje, parar sempre descarta a cópia em execução e tudo que foi ajustado nela.

Indicador de sucesso: tempo mediano do ciclo entre edição e teste nos projetos ativos.

Daniela

A artista de jogos

A·P·I·J: Alquimista, Purista, Integradora, Profissional de ofício.

No Turian hoje

Plugins de importação FBX e OBJ para seus modelos.
Layouts com painéis acopláveis no Studio: o espaço de trabalho que organiza é o que mantém.
Um único renderer desenha as visualizações Scene e Game do Studio, as capturas sem interface e o jogo exportado, com materiais PBR metallic-roughness. O que Daniela vê é o que chega ao lançamento.
Cada modelo instanciado tem uma cor de tingimento e quatro valores personalizados sem quebrar o batch.
Prefabs e variantes de prefab mantêm kits consistentes, com navegador de assets, undo e redo.

O que ainda devo

Um sistema de animação com edição de curvas e timeline.
Sprites 2D. A Turian renderiza 3D, e um fluxo 2D ainda não existe.
Partículas.
Ainda não há sistema de áudio.
Sombras, iluminação baseada em imagem, skybox, pós-processamento e passes de renderização personalizados a partir do código do projeto; depois, um editor de shaders baseado em nós.

Indicador de sucesso: proporção de importações de assets que dispensam retrabalho após a ida e volta.

Eduardo

O level designer

I·W·C·J: Iterador, Construtor de mundos, Curador, Profissional de ofício.

No Turian hoje

Física com Bepu, pronta para usar.
Falhas nunca tocam a cena em edição: o Play Mode executa uma cópia, e parar a descarta. Prefabs, variantes, navegador de assets, undo e redo mantêm uma cena lotada consistente.
Instanciamento na GPU reúne cada sequência de malha e material idênticos numa chamada de desenho. Numa cena de teste, 10.000 objetos idênticos passaram de 8.791 draw calls para uma, com pixels idênticos. Frustum culling ignora o que a câmera não consegue ver.
Tags e espaços independentes de camadas, travas de visibilidade e seleção, seleção retangular, gizmos de rotação e um controle de orientação: as pequenas ferramentas que tornam uma cena lotada utilizável.

O que ainda devo

Partículas. Ainda não há sistema de partículas.
Tweens e uma timeline de animação. Ainda não há sistema de animação no Turian.
Pós-processamento.
Arrastar e soltar: um arquivo de modelo levado à cena diretamente do gerenciador de arquivos.
Snapping, inclusive em outros modelos, não apenas na grade do mundo.
Ferramentas de construção de mundos, como distribuição de objetos e terreno, depois da animação e das lacunas de renderização.

Indicador de sucesso: taxa de sessões sem travamentos entre usuários que nunca abrem um arquivo de código.

Fernando

O designer de economia

I·H·I·J: Iterador, Eremita, Integrador, Profissional de ofício.

No Turian hoje

Dados de jogo vivem em data assets, arquivos JSON comuns editados com formulários no Inspector. Um programador expõe um novo tipo uma vez com [CreateAssetMenu], e depois designers o criam e editam por conta própria. Variantes de data assets sobrescrevem apenas o que mudou.
Um monitor de arquivos no Studio reimporta mudanças externas: edite um arquivo de dados fora do editor e ele é detectado sem precisar avisar.
Tags e camadas também são assets, então renomeá-las ou reordená-las não quebra referências de cenas ou prefabs.
A primeira versão do design orientado a data assets: eventos, variáveis, conjuntos de runtime e máquinas de estado são assets que designers conectam, distribuídos como bricks junto com a engine.
O canal de troca de dados: uma tabela .strings por localidade com chave estável, texto-fonte, tradução, nota e estado; fallbacks que nunca lançam exceções; substituição; blocos de plural e seleção; --locale para forçar um idioma numa sessão ou captura; e uma biblioteca de editor que lê e escreve XLIFF 1.2 e CSV preservando chave, fonte, destino, nota e estado.

O que ainda devo

A visão geral no Studio mostrando quem escuta o quê, além de valores ao vivo e um botão de disparo manual enquanto o jogo roda.
Importação e exportação de tabelas para data assets, com validação e undo. Tabelas de strings já fazem ida e volta por CSV; tabelas de balanceamento, não.
O fluxo XLIFF ao redor da biblioteca: exportação e importação pelo Studio e pela linha de comando, um ciclo completo testado, relatório do que mudou entre exportações, XLIFF 2.x, validação de chaves e placeholders e escritas da direita para a esquerda.
Analytics, para avaliar mudanças de balanceamento contra o que os jogadores realmente fizeram.
Serviços em nuvem. Nada no Turian pressupõe um backend hoje, e nada ajuda a operar um.

Indicador de sucesso: proporção de mudanças de conteúdo que entram no jogo sem um programador.

Gabriel

O DevOps

C·P·A·C: Finalizador, Purista, Arquiteto, Maestro.

No Turian hoje

Uma imagem oficial de contêiner com o SDK e um driver Vulkan por software. turian-cli export roda em qualquer serviço de CI, e o manual inclui workflows prontos para dois deles.
Entradas fixadas. A restauração de bricks usa --locked automaticamente quando CI=true; o lock registra versão, hash, registro e chave de assinatura, e as assinaturas são chaves OpenSSH ed25519 comuns. Uma pasta de cache de bricks pode ser compartilhada entre execuções.
turian-cli oap validate verifica o cabeçalho de um pacote e o CRC-32 de cada asset e termina com código diferente de zero em caso de falha.
Checkpoints de simulação com hash de estado a cada tick, comparados entre renderização a 30, 60 e 144 Hz e entre salvamento e retomada. Gameplay reproduzível é comprovado no cenário de teste sem interface, não apenas prometido.

O que ainda devo

Relatórios de tamanho e tempo de build por brick e por pacote, para saber o peso de um patch antes de lançá-lo.
Uma verificação de CI que compile duas vezes e compare os bytes. Hoje o Turian pode prometer entradas idênticas; ainda não pode prometer saídas idênticas.
Análise de assets de grafo durante o build.
Empacotamento de assets para distribuição; hoje uma exportação distribui a árvore importada como está.
Um profiler.
Destinos iOS, Android e consoles; hoje a exportação é para desktop (Windows/Linux).
Servidores NativeAOT sem interface; os primeiros exemplos já exportam sem avisos de trimming. O determinismo da física entre plataformas continua sendo trabalho futuro.

Indicador de sucesso: organizações distintas executando a CLI em CI.

Isabela

A presidente de estúdio AA

C·H·A·D: Finalizadora, Eremita, Arquiteta, Diretora.

No Turian hoje

Os termos em linguagem clara: MPL 2.0, sem royalties, a licença do jogo é escolha do estúdio. Versões são pequenas e frequentes, uma versão major significa que uma mudança pode quebrar um projeto, e cada major traz um guia de migração no manual.
Notas de versão que citam números medidos e dizem o que não comprovam, como 10.000 objetos instanciados numa draw call e cerca de 0,6 ms de CPU para 10.000 cubos coloridos, ou “o determinismo da física entre plataformas continua sendo trabalho futuro”.
Uma exibição de estatísticas no Studio e no runtime informa draw calls, instâncias e contagens de objetos descartados por culling. Capturas sem interface informam os mesmos contadores, então qualquer pessoa pode reproduzir um número.

O que ainda devo

Um jogo lançado. Qualquer um, feito por qualquer pessoa, em qualquer loja. A contagem hoje é zero, e não vou fingir o contrário.
Demos fortes: do tipo que um estúdio pode entregar a um novo contratado no primeiro dia, não notas de versão com números.
Suporte oficial, gratuito ou pago. Hoje o suporte sou eu.
Uma suíte pública e reproduzível de benchmarks: cenas, assets, câmera e configurações de qualidade fixos, publicados com hardware, driver, versões exatas e data, informando tempo médio e de pior caso por frame, pico de memória, latência até o primeiro frame e tamanho da exportação.
Projetos de demonstração construídos sobre versões lançadas e exportação mobile com uma lista pública de critérios de aceitação.

Indicador de sucesso: jogos comerciais que creditam a ferramenta.

Julio

O produtor AAA

C·H·A·C: Finalizador, Eremita, Arquiteto, Maestro.

No Turian hoje

O conteúdo de cada equipe é um brick com id, versão, dependências declaradas e uma faixa de compatibilidade com a engine. Lançamentos fora dos nomes com aprovação automática de uma loja aguardam aprovação, versões nunca são excluídas nem substituídas, e retirar uma versão da seleção automática ou descontinuá-la é explícito e exige um motivo.
Definições de assembly: os scripts de uma equipe compilam como unidades com referências explícitas, então o trabalho pode ser dividido sem que todos compilem tudo.
Bricks pré-compilados: brick pack --precast distribui assemblies compilados, então restaurar um brick não significa recompilá-lo.
Pacotes de assets (OAP) podem exigir um pacote base e sobrescrever assets por id sem reescrever referências, a base para distribuir apenas o que mudou.
Reabrir um projeto e executar Build & Run reutiliza arquivos importados e código compilado, copiando apenas o que mudou, o que torna o tempo de build algo que pode ser acompanhado de semana a semana.

O que ainda devo

Relatórios de tamanho e tempo de build por brick e por pacote, para saber o peso de um patch antes de lançá-lo.
Uma revisão sistemática de avisos e mensagens de erro que apontem o problema, por build, importação e script. Alguns já fazem isso; ainda não é uma promessa.
Suporte com um prazo de resposta que ele possa colocar num cronograma.
Um brick multiplayer opcional com builds de servidor dedicado.

Indicador de sucesso: consultas recebidas que citam empacotamento e patches.

Mariana

A criadora de ferramentas

C·S·T·I: Finalizadora, Compradora, Ferramenteira, Influenciadora.

No Turian hoje

O próprio Studio é um plugin de uma plataforma de plugins. Painéis, comandos, menus, atalhos, páginas de configurações e temas passam pelos mesmos registros que um plugin de terceiros usa.
Extensões vêm de código C# do projeto usando atributos, sem referência a nenhum assembly do editor: [MenuItem], [Panel], [CreateAssetMenu], [ComponentContextMenu], etc., além de atributos de Inspector como [Button], [Range] e [ReadOnly].
O manifesto do brick contém id, versão, faixa compatível da engine, dependências, requisitos NuGet e uma licença SPDX. Cada script e asset vem com um arquivo .meta cujo id outros projetos referenciam, então renomear e mover arquivos não quebra nada para ninguém.
Guinevere.Autoformer, uma biblioteca para criar formulários e ferramentas de interface automaticamente.
brick verify --against verifica se um stub ainda corresponde ao brick real, e brick stub permite que outros construam sobre trabalho inacabado. Bricks instalados são somente leitura; clientes os alteram por variantes e overrides de importação.
Toda mudança incompatível entra numa nota de migração.
Versões nunca são excluídas nem substituídas. Uma versão retirada da seleção automática continua disponível para projetos cujo lock a fixa e nunca volta a ser escolhida. brick diff e brick rebase cuidam dos forks, e a publicação usa um token com escopo num registro assinado: releases, yank, deprecate.

O que ainda devo

A superfície de extensão documentada como API versionada, com uma promessa de compatibilidade declarada para cada versão da engine, e a engine, os atributos e o SDK como pacotes que um plugin possa referenciar.
Um site de referência da API, gerado e versionado, para que quem cria plugins não precise procurar assinaturas no código-fonte.
A vitrine pública sobre o registro: escopos de publicadores, fluxo de aprovação, avisos de versões e proveniência, além de variantes do mesmo pacote por plataforma de destino.

Indicador de sucesso: extensões e plugins publicados por pessoas de fora da equipe principal.

Por trás da auditoria: oito aspectos e a matriz

Toda decisão que tomo sobre a engine acaba num de oito aspectos:

Aspecto	O que entra nele
Arte	Renderização, shaders, 2D, 3D, áudio, ferramentas de criação
Automação	CI/CD, testes, empacotamento, builds sem interface e reproduzíveis
Negócios	Preço, planos, termos, direitos, serviços, suporte
Código	Fluxos centrados em código, APIs, controle profundo, pacotes, desempenho
Ecossistema	Extensões, ferramentas auxiliares, loja de assets, integrações, importação/exportação de dados
Editor	Facilidade de uso, arrastar e soltar, ferramentas de “programação” visual, composição de cenas
Aprendizado	Tutoriais, documentação, comunidade, vídeos, salas de conversa, traduções
Plataformas	Mobile, VR, consoles, servidor, multiplayer

A matriz abaixo é minha leitura do que cada uma das dez personas precisa de cada aspecto. Cada persona tem quatro estilos, e o mais forte dos quatro define o padrão da célula. É uma opinião viva e pode mudar.

Aspecto/Persona	A	B	C	D	E	F	G	I	J	M
Arte	◐	○	◐	●	●	○	○	◐	○	○
Automação	○	●	◐	○	○	○	●	◐	●	◐
Negócios	◐	●	◐	○	○	○	◐	●	●	●
Código	○	●	●	○	○	○	●	○	○	●
Ecossistema	●	○	●	◐	●	◐	◐	◐	◐	●
Editor	●	○	●	●	●	◐	○	○	○	●
Aprendizado	●	◐	◐	◐	◐	◐	◐	◐	◐	●
Plataformas	◐	●	●	○	○	○	●	●	●	◐

Um círculo cheio é condição indispensável: se o aspecto falta ou está quebrado, aquela persona vai embora, independentemente do que mais estiver bom. Um meio círculo importa, mas não é decisivo. Um círculo vazio é atendido quando vem como consequência de outro trabalho.

O que a matriz diz

O Editor é indispensável para quem vive dentro da ferramenta: Ana, Carlos, Daniela, Eduardo e Mariana. Os demais colocam suas condições em outros lugares.
Arte é indispensável para exatamente duas pessoas. Elas fazem a aparência do jogo; as demais a consomem ou nunca a tocam.
Ecossistema é indispensável para os criadores que compram. A célula de Benjamin está vazia de propósito, porque um usuário que começa pelo código obtém suas bibliotecas como código, não numa loja. Para os quatro que dependem dele, a loja não é um recurso. É metade do produto.
As pessoas do pipeline se agrupam. Benjamin, Gabriel e Julio têm condições indispensáveis em Automação, Código ou Plataformas, e Isabela se junta a eles em Plataformas. Nunca vão concordar sobre um editor, mas concordam sobre um pipeline.
Aprendizado é indispensável para a iniciante e a criadora de ferramentas. Os demais conseguem ler um manual ou o código-fonte.
Negócios é indispensável para quem paga, assina, vende ou fornece. Os demais simplesmente trabalham.

Como a MASS4 usa essas personas

A matriz é a ponte entre as pessoas e o trabalho:

Rotular issues. Algumas issues têm uma label persona:*. Quando ela aparece, indica que aquela persona se importa com o assunto.
Manutenção diz seu nome. Um recurso que não serve a nenhum público é manutenção ou um erro. Ambos são aceitáveis, mas ambos devem se identificar.
Afirmações precisam mover um indicador. Cada persona acima termina com um indicador, a medida observável que diz se o Turian está realmente a conquistando. Se um item diz servir a uma persona, pode nomear o indicador que afeta. Se não pode, é decoração.
A regra do veto acompanha o trabalho. Entregar algo que quebra uma condição indispensável de uma persona atendida significa falhar inteiramente com ela, e a matriz diz exatamente com quem.

É o ecossistema, não só a engine, que atende às dez.

A loja de assets é o lugar mais claro: Ana compra templates e kits, Carlos busca bricks que salvam uma jam, Eduardo busca objetos de cenário, e Mariana publica ali, então tanto o cliente quanto o fornecedor da loja têm lugar à mesa.
As bibliotecas são outro: Graph, Guinevere, OAP, KTX2 e outras vivem fora da engine, atendem Benjamin e Mariana primeiro e manteriam seus nomes e versões se a engine mudasse sob elas.
Serviços e espaços de comunidade são o terceiro: o mercado de contratação de Isabela, o canal de suporte de Julio e a primeira pergunta de Ana respondida no próprio idioma.
Os aspectos Negócios e Ecossistema da matriz não são preenchidos pela engine; são preenchidos por tudo ao redor dela, e esse conjunto é a razão de ser da MASS4.

Uma última coisa. Essas dez pessoas não existem. São minha leitura do que uma ferramenta como o Turian precisa atender, e cada círculo da matriz é uma opinião, o que significa que pode estar errada. Você existe. Se faz jogos ou constrói ferramentas para quem faz jogos, você é o cliente de quem este texto inteiro trata, e o que ama, o que odeia e suas discordâncias contam mais que os meus. As personas são o mapa; você é o território. Onde o mapa estiver errado, diga, num comentário, numa issue ou num post onde quer que tenha encontrado isto. A próxima auditoria será melhor por isso.