Começa assim:
— Há bons game designers e maus game designers.
— Ser um bom game designer não se aprende nem se adquire. Há quem nasça um bom game designer e quem não. Um bom game designer nasce ensinado, é um génio, e sabe fazer jogos geniais desde sempre.
— Um bom game designer não precisa de saber nada para além de game design. Algumas soft skills ajudam, mas só pouco.
— Um bom game designer, portanto, para além de não saber programar, não sabe também: ilustrar, animar, modelar, criar som, prototipar nem que seja em papel, fazer estimativas, multiplicar, somar, ou falar com outros seres humanos.
— Se um game designer for bom, o jogo “foi criado” por ele (embora na prática tenha sido desenvolvido por uma equipa). Há de sempre referir-se ao produto final como “o meu jogo”.
— Um bom game designer é manipulador. Tem que ser. Isto porque o seu papel é ser “a pessoa que dá ideias”. Se mais gente der ideias, então ele não serve para nada, logo ninguém pode dar input, fora ou dentro da equipa. Mas se ninguém dá input, começam a surgir frustrações, logo alguma manipulação é necessária para que toda a gente fique feliz, com a impressão falsa que a sua opinião interessa.
— Uma crítica para um bom game designer é uma afronta. Sobretudo se for por parte de um utilizador (jogador). Os jogadores não sabem se o jogo é bom ou não, e é preciso explicar-lhes porque é que tudo faz sentido. Sempre que alguém dá feedback, tem que surgir uma justificação.
— Numa equipa, só há um game designer. Isto porque um game designer também é o RP da equipa. E se uma equipa tem mais do que uma cara, então o público fica confuso. O papel do game designer, para além de explicar a toda a gente que o jogo é da sua autoria, como explicado na alínea acima, é apertar a mão a toda a gente, criar contactos, procurar investimento: é “vender o jogo”, de grosso modo.
— Embora um bom game designer não saiba programar, tem que saber dar input aos programadores. Para isso, tem que aprender alguns termos-chave sem, no entanto, entender o significado destes, ou o contexto em que são usados. Apenas para dar alguns exemplos: buffer, pacotes de informação, responsive, algoritmo, procedural, hashset, shader, “cliente-servidor“, input, collider, runtime.
— Embora um bom game designer não saiba fazer nada na prática, sabe um bocado de tudo no papel, seja qual for o tema, desde cinema, a análises de mercado, a História, Química, Filosofia, e até pesca: sabe tudo, porque tem que saber, porque faz jogos.
— Para um bom game designer “não, porque vi num episódio do Extra Credits que…” é a melhor forma de começar um contra-argumento.
— Um bom game designer não faz level design, não faz diagramas, esquema de mecânicas, não se preocupa com UI, nem se deve interessar em garantir que toda a gente na equipa sabe que jogo está a desenvolver. Um bom game designer vai corrigindo o que está mal. Por exemplo, vê o trabalho de outra pessoa, diz-lhe “isto não pode ser assim”, “manda”-o fazer outra coisa, sem no entanto explicar-lhe bem o quê ao concreto. Se decidir fazer trabalho produtivo, como por exemplo level design, terá que ser feito antes da última milestone no calendário de produção, mas sempre depois da penúltima.
— Falando em milestones: um bom game designer sabe que são irrelevantes. São, porque um bom game designer é um deus. Quem decide quando o jogo está pronto é ele, não é o produtor, não é quem investe, não é quem produz conteúdo. Ele é que sabe das datas, por uma razão muito simples que muita gente não compreende: se na última semana entende que um projecto de meses ou anos é para ser todo mudado de uma ponta a outra, é isso mesmo que tem que acontecer.
— Um bom game designer não está sentado, como a ralé que é o resto da equipa. Está de pé, atrás de um programador ou um artista, a olhar para o que está a fazer, de pernas abertas, numa postura militar. Se o game designer for um homem tanto melhor, porque de pernas abertas exibe a sua virilidade e portanto autoridade melhor. Para não parecer um inútil prepotente, o game designer vai ou fazendo perguntas ou dando ordens a quem está à sua frente. As duas frases preferidas de um game designer são “um bocado mais para a esquerda” e “afinal, um bocado mais para a direita”.
— Um bom game designer conhece, usa e abusa da regra do 83%. Que diz, resumidamente que: um número inventado é mais credível quanto mais aleatório for. Por exemplo, diz-se antes sempre 81, 82, 83 ou 84, quando se inventa, nunca 80 ou 85. Concretamente: “fiz um estudo de mercado e 83% do nosso público-alvo…”.
— Para além dessa regra, sabe também que para conquistar é preciso dividir. Para ele, além de o jogo ser “o meu jogo” a equipa é “a minha equipa”. Para a equipa estar nas mãos do game designer, no entanto, este tem que garantir que o diálogo entre membros é mínimo, e passa quase sempre por ele, estilo pombo-correio. Sem esta ferramenta preciosa, o game designer não pode impedir ninguém contribuir criativamente para o jogo.
— E ainda sobre essa regra, há a variante fundamental que é o “diz que disse”. Resumidamente, de novo: o game designer tem uma ideia, fala com o José, pergunta-lhe o que acha, o José diz que sim, e diz à Mariana que o José teve uma ideia incrível, com a qual concorda. Pergunta à Mariana por outra ideia, ela diz “porque não”, e diz ao José que a Mariana teve uma ideia incrível, com a qual concorda. Por sua vez, fala então com o João e o António, que são doutro departamento, e diz-lhes que tanto ele, como o José, como a Mariana, os três, tiveram estas duas ideias, que são na verdade dele.
Estes são apenas alguns pontos-chave, mas penso que são suficientes.
Este texto não foi escrito para bons game designers, que eles já sabem tudo isto, porque já sabem tudo. O que interessa é que quem não seja saiba reconhecê-los para, por sua vez, poder elogiá-los com frequência, e dar-lhes a massagem ao ego regular que tanto precisam.