Eu estou lendo o livro Swords & Circuitry: A Designer’s Guide to Computer Role-Playing Games (aguardem uma análise desse livro, farei assim que tiver tempo), e uma parte que chamou a minha atenção é uma que trata da definição de jogador. Ele não é apenas uma pessoa contra quem você está jogando; quando você está jogando um RPG, o outro jogador é a inteligência que toma as decisões do oponente.

Essa visão é importante para percebermos que o jogo não é algo estático, passivo. Um jogo precisa de comunicação, e a relação entro o jogador humano e o jogador digital é semelhante a uma amizade: quanto mais forte, melhor, ocorrem menos enganos, gasta-se menos energia e tempo para se transmitir intenções e pensamentos.

A relação ideal poderia ser representada por essa (belíssima) imagem:

É aquela relação rara: numa amizade “usual”, é aquela na qual você não precisa falar tudo que o outro entende o que você precisa, um olhar pode expressar muito. Também é rara essa relação em jogos – sabem aqueles jogos nos quais você se sente completamente imerso, você simplesmente entra e para de contar os polígonos, os desvios da física e simplesmente faz parte do mundo daquele jogo? Pois é.

São aqueles jogos que não precisam de centenas de linhas de diálogo para transmitir uma mensagem, uma simples imagem, objeto, expressão de um personagem pode ser suficiente para que você entenda aquele universo.

Mas isso não é fácil. Essa comunicação dificilmente é tão direta. O controle / mouse / teclado que você usa estão no seu caminho. Quem nunca morreu em um jogo de tiro por não conseguir mexer no controle tão rápido quanto precisava? Ou aquele maldito jogo que precisa de precisão cirurgica que você tentou jogar com o mouse de bolinha meio capenga? É apenas o início de um problema de comunicação. Você diz “Eu quero correr!” e o jogo entende “Eu quero morrer!”. A relação começa a não ir tão bem…

Mas se fosse o teclado o único inimigo! O esquema ainda seria belo e simples. Mas as vezes os gráficos são suficientes para serem frustrantes, o jogo fala como se fosse seu miguxo enquanto você está na Idade Média…

Pode não parecer, mas essa relação de comunicação, esse sistema, é responsável por muito do sucesso ou fracasso de um jogo. A mente de um jogador funciona, em termos gerais, como uma malha de controle, onde ele planeja seu próximo movimento de acordo com a diferença entre o que ele deseja e o que o jogo está lhe informando. Ao desenhar um esquema, seria algo assim:

Essa é a visão do jogador, e é a visão que todos os aspectos de um jogo deveriam respeitar! Ainda que os detalhes desse esquema ainda possuam muitas variáveis – por exemplo, a variação entre desejo e resposta e o que fazer a seguir depende de cada jogador, e o jogador também leva em conta o esforço para conseguir aquela resposta do jogo. Imaginemos um jogo “hardcore”, cujo objetivo em uma das missões é passar despercebido por uma fábrica e roubar um objeto importante. Podemos analisar dois cenários, para jogadores diferentes:

O jogador A é um jogador experiente, daqueles que aprendem rápido e gostam de desafios. Ele passa pela fase na primeira vez, e é descoberto por um guarda na terceira sala, a missão falha. Ele tenta de novo, e dessa vez chega à décima sala. Ele percebe que está “pegando a manha” e continua, percebendo que está cada vez mais perto do seu objetivo. Na terceira vez, ele consegue pegar o objeto, mas falha na hora de escapar. A fase é realmente difícil, mas ele percebe que, a cada iteração da sua relação com o jogo ele se aproxima do seu objetivo, diminuindo a a diferença entre seu objetivo e o que ele está conseguindo. Graficamente, teríamos algo assim para a resposta do jogador ao jogo:

Na realidade, dificilmente teríamos uma resposta assim em um caso real. A progressão não é tão suave e sem sobressaltos – quem nunca recomeçou uma fase e morreu logo no início, ou falhou em uma parte que já havia passado com facilidade anteriormente? A resposta de um jogador experiente provavelmente está mais próxima deste gráfico:

Com um tempo de resposta rápido, algumas oscilações, mas indo para o equilíbrio – ou seja, para o objetivo alcançado. É uma boa relação, você não acha? Ainda que, novamente, os detalhes por trás de tais gráficos sejam por deveras intrincados, não é difícil de enxergar que o jogador evolui de maneira rápida, tem alguns sobressaltos mas consegue chegar ao seu objetivo.
Agora, ao jogador B. É alguém que gosta de jogos, mas não tem muito tempo – joga de vez em quando, sem muita pretensão, já zerou alguns jogos, mas não costuma ficar horas jogando para melhorar suas habilidades.  Jogava mais quando era mais novo, hoje em dia quase pode ser definido como um “jogador casual”, seja lá o que isso signifique. Ele começa a jogar. Falha na primeira sala. Tudo bem, ele reinicia a fase, entra na primeira sala, dá alguns passos, e é novamente descoberto. E isso por mais três vezes. Quando está quase desistindo, ele passa da primeira sala, parece ter pegado o jeito, chega até a quinta sala e… volta a ser descoberto. Tudo bem, ele melhorou, aproximou-se do seu objetivo… mas ele não sente vontade de reiniciar e passa novamente pela primeira sala. Ele faz uma última tentativa, e dessa vez falha na segunda sala. Frustrado, ele resolve desligar o videogame.

Dessa vez, teríamos um gráfico semelhante a este:

A partir do início, a comunicação começa a oscilar, com altos e baixos cada vez maiores, até que a resposta do jogador cai de vez – e ele desliga o videogame.

Não preciso nem dizer que isso não é desejado, não é mesmo?

Como evitar esse tipo de resposta? Se estivessemos falando de um sistema industrial, como um tanque de água, uma caldeira industrial, nós faríamos testes, traçariamos gráficos de resposta semelhantes a estes acima e, a partir disso, elaborariamos uma projeção matemática do sistema. Com isso em mãos, aplicaríamos técnicas de controle para inserir um controlador e modificar essa resposta – deixá-lo mais rápido, ou menos oscilatório, ou estabilizar um sistema instável.

No caso do desenvolvimento de jogos nós não temos modelos matemáticos tão elaborados, mas a estratégia é semelhante: observar a resposta dos jogadores e, a partir dessa resposta, estabelecer maneiras de corrigir respostas indesejadas. Membros do público alvo estão abandonando o jogo ao terem de reiniciar muitas vezes o nível? Que tal estabelecer checkpoints automáticos para que o jogador não tenha de refazer todo o caminho? Isso funciona muito bem em jogos voltados a puzzles, nos quais o interessante é descobrir o “pulo do gato”, entender aquela lógica para seguir adiante e, uma vez compreendida essa lógica, refazer essa parte do jogo se torna algo mecânico, repetitivo e não-divertido – ainda que você vá voltar a jogar e zerar o jogo mais de uma vez, você dificilmente terá vontade de refazer a mesma parte cinco vezes porque falhou em puzzles muito adiante.

Mas isso é apenas um exemplo. Ainda que exista pouca documentação formal sobre esse assunto, desenvolvedores descobrem técnicas de acordo com sua experiência, seja como jogador ou como desenvolvedor, para corrigir respostas indesejadas.

Assim como em sistemas industriais, existem muitos passos até chegar ao ponto no qual são definidas soluções para as respostas indesejadas:

1. Levantar os requisitos – qual o público alvo do jogo? Qual a duração esperada? Que emoções ele irá provocar, que habilidades ele irá exercitar? Quanto ele deve vender para se tornar rentável?
2. Estabelecer o processo – no caso, o jogo. Idealmente, ao final desse processo nós teríamos um jogo completo e pronto para ser vendido. Mas ele dificilmente atende a todos os requisitos, a tudo que é esperado, especialmente pelo fato dessa ser uma área essencialmente empírica: muitas vezes, o único jeito de  descobrir se uma mecânica de jogo funciona é… testando essa mecânica!
3. Analisar o processo – deixar com que jogadores testem o jogo, estabelecer sua resposta ao jogo, tal qual os gráficos acima. É o esperado? É desejado?
4. Definir soluções para melhorar a resposta do jogador ao processo – identificar as causas dos problemas e encontrar soluções. Muitas vezes isso não consiste em remover a causa em si, como no caso de um jogo bastante difícil como o analisado acima, mas elaborar pequenos “amaciantes” para que o jogador não desanime e perca a empolgação em jogar. Esses “amaciantes”, se bem aplicados, também permitem que o jogador mais experiente não passe a achar o jogo muito “fácil”.
5. Aplicar as soluções.

E temos um processo iterativo nos passos 3 a 5, já que essas soluções novamente devem ser testadas. Daí a importância dos testes em um jogo, e do desenvolvimento contínuo. Se mesmo em processos industriais, amplamente definidos e estudados, são necessários controladores em certos casos, o que dizer de uma área como a de desenvolvimento de jogos?

O que vocês acham? Será que alguém chegou ao final desse artigo ou eu assustei todo mundo com um texto grande e gráficos esquisitos?