10 personas: para quem o Turian é feito

O maior risco ao construir uma ferramenta é moldá-la apenas ao estilo e às preferências de quem a criou. Mas sempre quis que o Turian fosse útil às pessoas que a usam, não só a mim. Este artigo diz para quem estou construindo o Turian, pelo nome.

Em 256 perfis de gamedev, propus um vocabulário para as pessoas que fazem jogos: quatro camadas, dezesseis estilos e um perfil de quatro letras para cada criador. Desse vocabulário, este artigo seleciona dez pessoas, fictícias, mas específicas de propósito. Cada uma tem uma ocupação, um perfil desse vocabulário e duas frases: o que ama e o que odeia. Aquilo que ama também é condição indispensável, o teste que decide se fica. Aquilo que odeia a faz ir embora sem nem explicar por quê. Listas de recursos podem ser comparadas em tabelas; aquilo que alguém ama é o que verifica primeiro e nunca para de verificar.

Sete das dez fazem jogos com as próprias mãos. As outras três, Gabriel, Isabela e Julio, nunca abrem o editor para criar nada: constroem o pipeline, escolhem a stack e medem a entrega. Estão aqui porque agem em nome de dezenas de criadores, mas o centro de gravidade desta lista é quem cria.

Estou publicando isso de propósito. Itens do roadmap e issues usarão esses nomes, e uma ferramenta que mantém seu público em segredo está avaba pedindo que o público adivinhe.

Este artigo apresenta as pessoas e o que elas pedem. Onde o Turian realmente está para cada uma hoje, incluindo honestamente as lacunas, é assunto da auditoria complementar.

As dez num relance

Persona	Perfil	Ocupação	Ama	Odeia
Ana	P·W·I·J	Ensino médio	Uma primeira sessão, no seu idioma, que termina com algo rodando	Uma etapa que falha sem explicar por quê
Benjamin	C·P·A·J	Indie solo que começa pelo código	Controle de tudo, do carregamento de assets ao build	Um fluxo que exige o editor
Carlos	I·W·I·C	Estúdio remoto nascido numa jam	Ciclos de teste no editor e funções que não bloqueiam umas às outras	Uma função bloqueando as outras três
Daniela	A·P·I·J	Artista de jogos 2D/3D	Fidelidade: o asset que criou chegando como foi criado	Uma importação que o degrada silenciosamente
Eduardo	I·W·C·J	Level designer	Sessões sem travamentos numa enorme biblioteca de assets	Um arquivo corrompido, independentemente do que se conserte depois
Fernando	I·H·I·J	Designer de economia	Balanceamento em planilhas, sem programador no caminho	Pedir a um programador para mudar um número
Gabriel	C·P·A·C	Ferramentas e DevOps	Dois builds sem interface, mesmos bits, rollback a um clique	Uma tarefa que só pode ser feita no editor gráfico
Isabela	C·H·A·D	Presidente de estúdio AA	Benchmarks com provas, preços claros, profissionais que conhecem a ferramenta	Hype que entrega uma demo e a chama de roadmap
Julio	C·H·A·C	Produtor AAA	Entregas que podem ser medidas, divididas e consolidadas	Surpresas e erros que não apontam nada
Mariana	C·S·T·I	Criadora de ferramentas	Uma API versionada e uma loja onde pacotes sobrevivem às versões	Mudanças incompatíveis que ela não causou

Ana

A adolescente que faz jogos por hobby

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

Ana tem dezesseis anos e cursa o ensino médio em São Paulo. Inglês é uma matéria da escola, não seu idioma, mas os tutoriais da internet o pressupõem mesmo assim. Ela quer fazer jogos por diversão sobre o mundo ao redor: sua sala de aula, seus amigos, a fila da cantina. Segue cada tutorial como se fosse seu único trabalho. Pausar, copiar, continuar, repetir, e no fim da noite existe um jogo.

Ela precisa de ajuda com tudo e sabe disso: tutoriais para seguir, assets prontos da loja, um editor que consiga operar arrastando e soltando, e pouca ou nenhuma programação no meio. Nunca começa com uma tela em branco. Pega algo que funciona, troca a arte, adapta as regras até o jogo ser sobre seus amigos e compartilha o resultado. Quando uma etapa falha, presume que o erro é dela.

Ama: uma primeira sessão, no seu idioma, que termina com algo rodando.

Odeia: uma etapa que falha sem explicar por quê.

Benjamin

O indie solo que começa pelo código

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

Benjamin é um desenvolvedor solo com o hábito de lançar jogos: dois publicados, um terceiro em andamento. Seus jogos são feitos quase inteiramente em código, do jeito que aprendeu com MonoGame, e é no terminal que o trabalho acontece. O histórico do controle de versão é o diário do projeto.

No mundo de Benjamin, editores servem para ferramentas internas, e ele constrói as suas. O que precisa ter é controle de tudo: como os assets carregam, para onde vai a memória, o que custa um frame, como o build é feito. O Studio não é inimigo; é uma janela que abre raramente, e qualquer coisa que só possa ser feita clicando é um erro no projeto de outra pessoa.

Ama: controle de tudo, do carregamento de assets e da memória ao desempenho e ao build.

Odeia: um fluxo que exige o editor.

Carlos

O integrante do pequeno estúdio nascido numa jam

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

Carlos e três amigos se conheceram numa game jam. O protótipo não ganhou nada, a amizade ficou, e nasceu um estúdio: quatro pessoas, todas remotas, cada uma com uma função no papel e todas as funções na prática. Numa semana Carlos programa, na seguinte trabalha na fase, e na outra integra o trabalho de alguém.

O estúdio vive de assets de terceiros, especialmente para sistemas, então a programação é principalmente integração e o jogo em si. Para Carlos, ajustar é o trabalho, e cada segundo entre uma edição e um teste é um imposto pago cem vezes por dia. O mesmo instinto vale para a equipe: cada um dos quatro precisa entregar sua parte sem esperar pelos outros.

Ama: ciclos de teste dentro do editor e cada função entregando sem esperar pelas outras.

Odeia: uma função bloqueando as outras três.

Daniela

A artista de jogos

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

O dia de Daniela é uma esteira: Photoshop ou GIMP, exportar; Blender se for 3D, exportar de novo; importar na engine, ajustar materiais; testar; certo, próximo asset. Entre suas ferramentas e a engine, mil idas e voltas por ano, e cada uma é uma chance de algo sair do lugar.

Ela é artista, não engenheira, e o funcionamento interno da engine não é seu trabalho. O que importa é fidelidade: o asset que passou horas criando deve chegar ao jogo do jeito que fez, com as mesmas cores, as mesmas normais, a mesma sensação. Um editor que oferece as mesmas funcionalidades visuais das ferramentas de origem, materiais, curvas, gradação de cor, é uma grande vantagem, porque o que não consegue ver, não consegue corrigir. Seu “certo” na esteira é o de uma profissional; por dentro, nada é tão bom quanto a imagem na sua cabeça.

Ama: fidelidade: horas de Photoshop ou Blender chegando ao jogo exatamente como criou.

Odeia: uma importação que degrada silenciosamente o que passou horas criando.

Eduardo

O level designer

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

Eduardo combina os assets disponíveis em fases, menus de interface e os espaços entre eles. Para ele, tudo é composição. Quando a composição está certa, vai além, em busca de partículas e tweens, porque o objetivo é transmitir arte em forma multimídia, e uma imagem estática é só o começo.

Ele vive dentro do trabalho dos outros: consolidando o novo acervo conforme os artistas entregam, testando animações de combate assim que chegam, mantendo uma cena lotada consistente com kits, prefabs e variantes. Undo é sagrado, e a biblioteca é trabalho de anos.

Ama: sessões sem travamentos numa enorme biblioteca de assets.

Odeia: um arquivo corrompido, independentemente do que se conserte depois.

Fernando

O designer de economia

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

Fernando balanceia a economia de um jogo: curvas de dano, taxas de drop, preços, os números que decidem se um jogador fica. Tem opiniões sobre todos eles e uma planilha para provar cada uma. Suas ferramentas vivem fora do jogo: importação e exportação em formatos próprios, números digitados à mão, sliders, estatísticas, analytics.

Trabalha principalmente fora do editor do jogo e prefere assim, em ferramentas feitas para tabelas inteiras em vez de valores isolados. Um pedido que começa com “peça a um programador” termina uma semana depois com o valor errado, então o jogo precisa aceitar os números como estão.

Ama: balanceamento em planilhas, sem programador no caminho.

Odeia: pedir a um programador para mudar um número.

Gabriel

O DevOps

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

Gabriel cuida da infraestrutura de builds de um estúdio médio e escolheu a stack por conta própria. Seus painéis mostram onde está cada build, para qual dos quatro destinos vai, Android, iOS, PC ou console, e como reverter qualquer um deles. Não abriu o editor neste trimestre, e o jogo foi lançado mesmo assim.

Ama APIs e a vida sem interface gráfica, e sua regra é simples: tudo de que o pipeline precisa deve ser possível pela linha de comando, porque um recurso que só existe no editor gráfico não existe para a CI. Se um build a partir de um checkout limpo na terça difere do de segunda, isso não é um mistério, é um defeito no processo de alguém. Mágica é um risco. Etapas manuais que vivem na cabeça de uma pessoa são um incidente esperando acontecer.

Ama: dois builds sem interface, mesmos bits, com rollback a um clique.

Odeia: uma tarefa que só pode ser feita no editor gráfico.

Isabela

A presidente de estúdio AA

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

Isabela dirige um estúdio novo formado por pessoas que saíram juntas de uma empresa AAA. Decide as ferramentas com base nas habilidades que a equipe já tem, e sem paixão, deliberadamente: paixão é uma ótima razão para fazer um jogo e uma péssima razão para escolher uma stack. Conhece o trabalho do estúdio em sessões periódicas de teste de marcos e sprints, e isso basta.

Ela não tem o luxo de amar uma engine. Uma decisão de stack são quatro planilhas: preço, por licença ou royalty, termos da licença, o ecossistema em que a equipe vai viver e o mercado de contratação, porque o que os próximos três contratados já sabem vai importar mais que qualquer lista de recursos. Viveu os ciclos de hype e sabe quanto custa a uma equipe de quarenta pessoas adotar o entusiasmo dos outros. Roadmaps sem provas são marketing.

Ama: benchmarks com provas, preços claros e um mercado de profissionais que já conhece a ferramenta.

Odeia: hype pelo hype, do tipo que entrega uma demo e a chama de roadmap.

Julio

O produtor AAA

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

Julio coordena várias equipes por issues e tickets e abre o jogo por um motivo: verificar se um recurso funciona, nunca construí-lo. Sabe um pouco de cada ferramenta do pipeline, exatamente o que o trabalho exige. Precisa saber quem entrega o quê, qual o tamanho do próximo patch e quanto demora um build.

Sua semana é versionamento, divisão do trabalho, consolidação e revisão. Se pode ser medido, pode ser gerenciado; se não pode, vai surpreender todo mundo no pior momento. Seu desejo mais silencioso também é o mais alto: avisos e mensagens de erro que apontem o problema, porque uma equipe que não consegue nomear a falha passa a revisão adivinhando.

Ama: entregas por equipe que podem ser medidas, divididas, consolidadas e revisadas.

Odeia: surpresas e mensagens de erro que não apontam nada.

Mariana

A criadora de ferramentas

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

O papel de Mariana na equipe é construir ferramentas e plugins que ajudam os outros a fazer o jogo, e ela conhece as APIs do editor melhor que qualquer pessoa no prédio. Uma de suas criações internas ficou tão robusta que a colocou na loja, mais por acaso que por plano. Encontrou fãs dedicados, trouxe uma renda extra ao estúdio, e agora ela atende clientes internos e externos com o mesmo código.

Ela lança num ritmo regular e conta ao mundo sobre cada versão. Seus dois medos são o mesmo medo duas vezes: uma mudança incompatível na engine é um ticket de suporte que não causou, e uma referência perdida após uma atualização é um pedido de reembolso.

Ama: o editor como API documentada e versionada, e uma loja onde pacotes sobrevivem às versões.

Odeia: mudanças incompatíveis que ela não causou.

O que as dez pedem juntas

Leia as dez lado a lado e três pedidos se repetem:

Tudo que o editor faz, a linha de comando faz. Benjamin, Gabriel, Julio e Isabela nunca vão concordar sobre um editor, mas concordam sobre um pipeline.
Identidade que sobrevive à mudança. Mariana, Julio e Eduardo precisam poder renomear, mover e atualizar sem quebrar o que depende deles.
Números, não adjetivos. Isabela, Julio e Gabriel não vão aceitar “rápido” ou “reproduzível” por confiança. Toda afirmação deve vir com uma medição e uma forma de repeti-la.

Esses três pedidos são a espinha dorsal do roadmap. Sempre que um item do roadmap ou uma issue nomeia um público, nomeia uma dessas dez pessoas.

As pessoas são a metade fácil. A auditoria complementar percorre persona por persona o que cada uma encontra no Turian hoje, o que ama e odeia, e o que ainda devo a elas.