Quem quer trabalhar com jogos esbarra cedo numa confusão de nomes, e Murilo Moura Alencar, Tech, People & Game Strategist e cofundador de um estúdio de games, observa que ela começa já nos anúncios de vaga. Algumas pedem game designer, outras pedem game developer, e muitas descrevem as duas funções como se fossem uma só.
Escolher mal custa meses de estudo numa direção que não combina com o próprio perfil. A diferença fica mais clara quando se olha para uma pergunta simples: quem decide como o jogo funciona e quem faz esse funcionamento acontecer. Ao longo deste artigo, os dois papéis aparecem lado a lado, a partir de um mesmo exemplo prático.
O que faz um game designer?
Em muitos jogos de plataforma, o personagem ainda consegue pular por uma fração de segundo depois de sair da borda. Quase ninguém percebe, mas quem joga sente que o controle é justo. O recurso tem nome no meio, “coyote time”, e sua existência é uma decisão de game design.
O game designer define as regras e a sensação que elas devem provocar: quanto dura essa tolerância, qual a altura do pulo, quanto dano um inimigo causa, em que ordem as habilidades aparecem. O trabalho envolve documentar, prototipar, testar com jogadores e ajustar números até que a experiência pretendida surja na tela. A pergunta que guia essa função é se o jogo é bom de jogar. Em produções maiores, ela se divide em especialidades, como design de níveis, de sistemas e de narrativa.
E o game developer, onde entra?
Voltando ao pulo: alguém precisa escrever o código que conta o tempo desde que o personagem deixou a plataforma, compara esse tempo com o limite definido e libera ou bloqueia o salto. Esse é o trabalho do game developer, termo que, no mercado, costuma designar quem programa o jogo.
A função exige domínio de linguagens de programação, de motores gráficos e de otimização. Um jogo precisa redesenhar a tela dezenas de vezes por segundo, e cada regra criada pelo design consome parte desse orçamento. A pergunta que guia o game developer é se o jogo funciona em diferentes aparelhos, sem travar.
É comum, como nota Murilo Alencar, que parte de quem chega a essa função venha pelo caminho inverso: começa querendo criar mundos e se encanta ao ver uma regra ganhar vida no código. Para esse perfil, o problema técnico faz parte da diversão.
Em estúdio pequeno, uma pessoa faz os dois papéis?
Com frequência, sim. Em equipes enxutas, comuns entre estúdios independentes, quem programa também propõe mecânicas e ajusta números. Ao mesmo tempo, o mercado mostra espaço para especialização: segundo a pesquisa nacional da Abragames, a procura de parceiros para construção e design de níveis, que envolve montar cenários, obstáculos e o ritmo de cada fase, subiu de 25% para 32% entre duas edições do levantamento.
Na leitura de Murilo Moura Alencar, essa sobreposição é uma vantagem para quem está começando. Entender o lado de quem programa torna o designer mais realista nas propostas, e entender o design torna o programador mais útil em qualquer discussão sobre o jogo.
A fronteira que mais importa é a conversa
A qualidade de um jogo raramente nasce de um lado só. O designer pede um pulo mais responsivo, o programador mostra o custo, e da negociação sai uma solução que nenhum dos dois teria desenhado sozinho. Murilo Alencar salienta que, nos estúdios que funcionam bem, essa conversa acontece cedo, ainda no protótipo, e não quando cada mudança já custa caro.
Para quem ainda vai escolher, o critério mais honesto não é salário nem prestígio do cargo. É descobrir qual pergunta dá mais vontade de responder todos os dias: se o jogo é divertido ou se ele funciona. As duas carreiras existem porque todo bom jogo precisa das duas respostas.
