O que eu gostaria de saber antes de ter feito meu primeiro título como estúdio de jogos

Aviso: Esta é uma leitura complementar a um vídeo que eu postei recentemente no YouTube, falando sobre minha transição da Unity para a Godot. Apesar do vídeo ser brevemente comentado abaixo, ele não é obrigatório para a compreensão do texto.

O primeiro lançamento de um estúdio independente de jogos é uma conquista importante. Na minha humilde opinião, pelo menos, é como o indivíduo ou coletivo coloca oficialmente seu pé no mercado, na indústria. Não apenas sinaliza o início do que se tornará eventualmente uma biblioteca extensa de lançamentos, mas também diz que, mesmo que o currículo do estúdio não seja tão grande ainda, pelo menos existe.

E, pelo pouco que eu conheço sobre o pensamento das publicadoras de jogos, somado ao que eu absorvi sobre as conversas com outros desenvolvedores com mais experiência que eu, ter uma prova de que se consegue entregar um título pode ajudar da aquisição de investimentos para os próximos.

Por mais que eu já tenha lançado alguns joguinhos tanto no Google Play quanto no itch.io como indivíduo, entretanto, publicar em lojas como Steam e a Epic Games Store como um estúdio desenvolvedor, como pessoa jurídica, dá um peso a mais ao trabalho. E embora a minha breve experiência tenha me ajudado em alguns aspectos, há outros detalhes que eu gostaria de ter ciência antes mesmo de ter começado o processo.

O jogo

Antes de falar sobre essas pequenas lições, acredito que é justo eu comentar sobre o desenvolvimento do Alien Paradise, o jogo de ritmo que eu publiquei.

No final de 2023, poucos meses após eu ter aberto o Sendo Estúdio como pessoa jurídica, após quebrar a cabeça com ideias para qual deveria ser o título de estreia, eu resolvi me inspirar em uma franquia da Nintendo que anda adormecida, pelo menos por enquanto, o Rhythm Heaven, também conhecida como Rhythm Tengoku. E conforme eu fui fazendo o protótipo em dezembro daquele ano — que estava mais parecendo um vertical slice, uma versão mínima que serve como base para delimitar o escopo de implementação do jogo antes de expandir o desenvolvimento, do que um protótipo de fato — eu pensei que o alienígena que eu estava usando como algo temporário poderia ser a personagem principal.

Aos poucos, a temática de um alienígena sinestésico que visita o Brasil para tirar férias foi se formando. Foi o primeiro jogo que eu publico com um tempo mais extenso de desenvolvimento, nove meses no total, e a primeira vez que eu utilizo a Godot como motor gráfico, mesmo com os meus dez anos de experiência com a Unity.

No último vídeo que eu postei até a escrita deste texto, eu entro em mais detalhes sobre a minha experiência com essa transição.

Primeira lição: localize o quanto antes

Uma das primeiras vantagens que eu observei ao trabalhar com a Godot foi como ela já incluiu um sistema de localização que eu achei bem simples. Ao colocar algum elemento textual, você pode definir a engine deve usar o que está escrito como uma chave para, caso encontre um valor correspondente no idioma de destino, faça a substituição de forma automática durante a execução do jogo. Para a engine realizar tal procura, basta você criar uma planilha, exportá-la no formato CSV (e eu recomendo o LibreOffice para isso, quem já tentou trabalhar com arquivos csv usando o Excel vai me entender) e, na Godot, informar que esse arquivo será usado para a localização.

Eu acabei descobrindo como fazer isso depois de uma troca de mensagens com uma amiga minha, que me pediu para que o jogo saísse também em português no lançamento e me lembrou o quanto de gente aqui no Brasil não é fluente em inglês. Tal interação aconteceu dias antes de eu mostrar o jogo em um evento presencial aqui no Rio pela primeira vez, então eu acabei passando os dias antecedentes fazendo algumas correções, incluindo adequar os textos do jogo para usar o sistema de localização.

A decisão, embora relâmpago, foi um acerto acidental, já que a inclusão gradual dos textos à tabela de localização se tornou muito menos desgastante do que deixar para achar todos os textos e fazer o processo perto do final do desenvolvimento. E como eu tenho o costume de desenvolver meus jogos em inglês enquanto o idioma principal do meu sistema operacional está em português, eu conseguia “testar” se a tabela estava funcionando, se eu tinha colocado o nome certo na planilha, e ver como textos de tamanho diferente poderiam aparecer na tela.

Segunda lição: cuidado com a estruturação (demasiada) de repositórios

Logo no início do desenvolvimento, eu adotei o uso de um sistema de controle de versão, ou VCS. Para quem não conhece o git ou ferramentas similares, eu recomendo pesquisar sobre o quanto antes, já que seu uso possibilita que problemas de código possam ser resolvidos e, em caso de sistemas de controle de versão distribuído, é possível que mais de um colaborador trabalhem no mesmo código.

Há certos cuidados que devem ser tomados ao usar VCS, como definir com o time qual será o fluxo de trabalho e como as alterações de código serão implementadas, a fim de minimizar as chances de conflito. Até a troca de ramo, por exemplo, pode causar algum problema inesperado no código, mesmo no caso de projetos individuais.

O uso do git foi bom para que eu pudesse, eventualmente, colocar implementações mais específicas para determinadas lojas. A nível de exemplo, a forma como o Steam e a Epic Games Store implementam seus respectivos sistemas de conquista variam muito, então pode parecer intuitivo criar ramos, ou branches, específicos para cada loja, a fim de não misturar SDKs, add-ons ou quaisquer elementos.

Em teoria, a ideia é boa, mas na prática, uma fragmentação muito restrita pode levar a retrabalho. Pelo menos com a Godot, a cada vez que eu preciso usar um dos add-ons necessários para uma das lojas, eu preciso refazer o processo de importação do add-ons por ele não estar presente em todas as branches de código. Para futuros projetos, minha ideia é ver formas de apenas chamar as ferramentas necessárias via código de acordo com a plataforma mas sem que tais branches fiquem diferente demais entre si.

Terceira lição: A documentação só funciona se ela te atende

Acredito que foi ano passado que eu esbarrei em uma postagem no Twitter de uma designer de jogos chamada Rosa Carbo-Mascarell. Ela disponibilizou um modelo de um documento de game design, ou GDD (game design document) gratuito que, na minha opinião, dá uma ótima base, principalmente para aqueles que nunca montaram um.

Para o Alien Paradise, eu decidi que seria importante eu fazer uma documentação legal, já que até então o mais próximo que eu fazia de um GDD era criar algum documento no Word (ou, sendo mais realista, no bloco de notas) com os principais pontos de mecânicas, valores padrões e detalhes relevantes do jogo. Então, parti do modelo da Carbo-Mascarell e fui preenchendo as diferentes páginas de acordo com o jogo.

Com o tempo, entretanto, eu fui percebendo que eu não estava atualizando tanto o GDD quanto eu gostaria. Para eu saber os níveis que eu iria começar a desenvolver, eu usava um arquivo de texto no qual eu listava ideias e via quais tinham sido aprovadas e quais eu ainda estava avaliando se seriam viáveis. E apesar de eu customizar a o sumário de níveis, uma planilha, com as informações relevantes, tinham vezes que eu via abrindo o arquivo da produção da música (eu utilizo o FL Studio para fazer as músicas do jogo) ou até mesmo o arquivo dentro do jogo com as informações de nível para saber alguma informação importante.

Essa experiência me fez perceber que, dependendo do tipo de jogo que estamos fazendo, há formas que serão ideais ou não para apresentar a informação, ainda mais levando em consideração a equipe envolvida. Pode parecer algo óbvio de se pensar num vácuo, mas durante o desenvolvimento, eu acho que é fácil a gente perder noção de quão importante a documentação é, e o quanto podemos facilitar nossa vida ao colocar, às vezes, uma coluna a mais com uma informação que pode parecer muito técnica, mas que vai poupar tempo que o programador levaria vasculhando o código só para ter certeza de algo.

Talvez seja por vermos documentação como algo pouco mutável, algo “fixo” ou rígido, o que faz sentido, mas acho que esse estereótipo pode levar a gente ou a subestimar o poder que uma boa documentação tem durante o desenvolvimento do jogo, até de continuamente responder aos desenvolvedores o que o jogo deve se tornar, ou até mesmo a ver como algo posterior ao projeto. E ter a noção de que uma documentação só é boa se ajuda a todo mundo a “estar na mesma página” pode ajudar a nós, game designers, a encontrar a melhor forma de montá-la sem deixar de entender as necessidades dos nossos colegas (mesmo quando nosso único colega seja nós mesmos).

Quarta lição: mostre o seu jogo, de preferência presencialmente

Algumas pessoas gostam de falar sobre o que estão fazendo, chegando ao ponto até de entrar em detalhes sobre projetos que querem fazer, mesmo sem ter nenhuma comprovação ainda de que conseguirão realizá-lo. Já outras, mais cautelosas, preferem seguir “na calada da noite”, fazendo tudo no escuro até que o momento seja propício para revelarem sua mais nova empreitada. E, com o passar dos anos, eu tenho percebido que eu me encaixo neste último perfil, o dos que fazem calados.

O problema dessa abordagem quando se trata de criação de jogos é que, se não mostramos o que estamos fazendo, não temos como avaliar se aquilo fará sentido fora de nossa própria bolha mental. Obviamente que não queremos também apresentar qualquer coisa aos jogadores, muita das vezes vamos esperar atingir a um mínimo de qualidade para começarmos a mostrar nosso jogo em desenvolvimento para alguém. Só que se esperarmos demais para pegar comentários, fica mais difícil de termos um outro olhar que pode ajudar a construir a base do jogo.

Logo no período em que eu estava fazendo o protótipo, eu resolvi mandar o trabalho feito até então a um amigo meu que gosta bastante de jogos de ritmo. Eu estava receoso por achar que o trabalho ainda estava muito cru, mas achei que precisava de uma segunda opinião para validar se a base que eu estava construindo realmente estava funcionando. E, para minha surpresa, mesmo com correções a serem feitas aqui e ali, boa parte do que eu tinha feito de fato mostrava que algumas decisões de design já estavam funcionando.

Em fevereiro, quando eu já estava mais adiantado no desenvolvimento, foi quando eu decidi anunciar o jogo, e comecei a levá-lo a eventos locais aqui pelo Rio de Janeiro. Com a recepção que eu tive do jogo logo no primeiro evento — recepção inclusive que superou minhas expectativas — eu pude observar os momentos que os jogadores ficavam na dúvida, que entendiam o que estavam fazendo, que precisavam de uma ajuda a mais. Somados às observações, as opiniões e sugestões, tudo isso me ajudou a já consertar problemas a curto, médio ou longo prazo que eu não teria resolvido se não fosse por essa oportunidade de interagir com potenciais jogadores.

Há toda uma discussão válida de até que ponto o jogo precisa atender a todos os jogadores e até que ponto as decisões de criação funcionam como a de outras áreas artísticas, em que a intenção do criador é a que vale. Cada vez mais, eu acho que quando um jogo tenta agradar a todo mundo, mais o jogo tende a se perder, porque cada um de nós temos gostos, preferências e necessidades diferentes, vale mais a pena entender o nicho no qual o jogo se enquadra e, a partir desse nicho, entender o que pode ser feito, até em termos de escopo e orçamento. Com a experiência que eu tive, ainda sim, mostrar o jogo para o máximo de pessoas possível não só ajuda a identificar o nicho, mas também você pode ganhar perspectivas diferenciadas que, mesmo que pareçam fora do universo do seu trabalho, podem ajudar a rever o que a gente vê como lugar comum e, consequentemente, a melhorar tais elementos.

E por mais que a liberação de demonstrações gratuitas ou a inscrição para playtests remotos possam ajudar em colher o tipo de feedback que pode ajudar no desenvolvimento do jogo, eu recomendo fortemente a ida a eventos presenciais se for possível. Será uma ótima forma de criar um primeiro contato com um possível jogador futuro. Mais ainda, é o grande laboratório no qual você pode ver se suas teorias vão se confirmar e tirar lições que irão melhorar seus atuais e futuros projetos.

Conclusão

Quanto vez mais que eu adentro o mundo da criação de jogos, mais eu percebo que há muito a se aprender. Antes, talvez, eu esperava chegar a um patamar que eu me sentiria pronto o suficiente para lidar com todos os desafios de se desenvolver um jogo do início ao fim. Hoje em dia, entretanto, eu sinto que nunca teremos todas as respostas, e sempre olharemos para o passado achando que cometemos erros óbvios demais. No final das contas, são essas decisões das quais gostaríamos de ter em mente antes é que tomaremos decisões melhores nos próximos projetos.