Vlad on Game Design VI

Acabámos aqui uma coisinha no nosso joguito e eu fiquei satisfeito. Tenho andado a matutar nas soluções quer de design quer de programação que temos arranjado. A verdade é que para primeiro projecto desta equipa, o jogo é demasiadamente complexo e esse é um facto que só nos apercebemos tardiamente. Nada que nos preocupe, está tudo a correr muito bem nesta fase.

Mas o meu propósito com esta blogada não é transmitir uma mensagem subliminar de um eventual projecto ultra-secreto. Serve mais para identificar algumas alterações na minha forma de ver design e development depois de "sobreviver" a 90% de um projecto.

Das conversas informais que tenho e de alguns posts no GD-PT concluo que a maior parte das pessoas tem uma ideia de que design é ter as ideias e documentá-las. Se na generalidade isto é verdade, no detalhe torna-se mais complicado. Isto porque a documentação tem de ser sintética e objectiva. Acredito que, e embora espere estar enganado, a maior parte dos pretendentes a game designer assumem que se escreverem num design document a generalidade de um objectivo de um elemento de design, o seu trabalho está concluído.

E se estou a escrever esta blogada é para demonstrar o oposto. Estávamos a preparar uma versão para playtesting. Existe um elemento do jogo que permite ao jogador safar-se de algumas situações complicadas. Se este elemento existir em demasia, o jogo perde o desafio. Por outro lado é um elemento bom demais para não servir como recompensa momentânea a uma boa performance do jogador. Estava estabelecido que sempre que o jogador atingisse um determinado threshold, ganhava uma unidade desse elemento. Como queríamos reduzir essa recompensa, considerei uma certa aleatoriedade, uma probabilidade de recompensa.

Estas soluções parecem-me sempre coxas. Por um lado o factor aleatoriedade ofende-me em algo tão importante e tão pouco circunstancial como recompensas porque é a recompensa que alimenta o ímpeto. Por outro precisava de uma solução que não fosse algo tão corriqueiro como "recompensa de duas em duas vezes" ou "uma recompensa por nível". Lembrei-me então da sucessão de Fibonacci, excluindo o 2 e não é preciso pensar muito para ver como pode ser eficaz para reduzir de uma forma recursiva e não aleatória. O resultado final foi 1, 3, 4, 7, 11, etc... não é bem a sucessão, mas serve exactamente o propósito.

Não escrevi nada e decidimos e implementámos uma importante alteração ao design em 20 minutos. Do lado do design não foi usada uma solução tipicamente fácil como aleatoriedade e não foi descrita como um desejo do género "o jogador recebe este elemento de vez em quando". Do lado do desenvolvimento foi escrito um gerador da sequência que é inicializado a cada nível. Resolvemos um problema de design mais complexo do que parece, de uma forma totalmente elegante e eficiente.

Há um ano atrás eu teria escrito dois ou três parágrafos sobre como seria melhor recompensar o jogador e optaria de certeza por uma probabilidade comparada com um valor aleatório. Hoje, detectado o problema, definiu-se uma solução aberta e alterável, pronta para teste sem se escrever uma linha porque o design doc não é mais importante do que a implementação do design ou a diversão do jogador.