12 outubro 2007

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.

4 comentários:

Raistlin disse...

Como é bom confirmar que até os game designers têm dúvidas! Esses ditos Game Designers que se contentam com o Game Design Doc são assim porque muito possivelmente essas ideias não passaram do papel ou ficheiro de Word.

Aleatoriedade é boa em jogos quando é usada com moderação. É o tipo de coisa que pode salvar um jogo que está a correr mal e deixa o jogador contente.

"Elegante" é a palavra certa.

Vlad disse...

É bom que haja dúvidas, se não houver é porque o desenvolvimento não é ciclico.

Em relação à aleatoriedade. Há tanta aleatoriedade num jogo casual (btw é esse o contexto) que se reduzi-la é uma optima maneira de potenciar o design. Depois falamos sobre isto ou escrevo aqui, não é um tema dificil, é sim, extenso.

Yep, acho que sim, que é a melhor palavra. Por randoms porque não se arranja melhor (assumindo que pelo menos se encara o problema) não é solução.

elf_maniac disse...

É bom mostrares evolução e falando da tua experiencia mostras que ninguém se torna game designer do dia para a noite.
Eu já pensei em ser game designer mas parece dar muito trabalho.
Ainda tenho alguns anos para decidir.
Continua com isso e espero que sejam mostrados resultados em breve.

PRE disse...

Nós no OB deparamo-nos com mudanças às "regras" muitas ezes. Principalmente porque é um jogo com um time line bastante elevado (meses) e há coisas que nos escampam sempre.

Muitas vezes só já com o jogo a decorrer e ao ter centenas de jogadores perante dadas regras é que vemos se estas são adequadas ou não.

E o pior são as batotas... jogadores que pegam nas nossas regras dentro de dados contextos e conseguem tirar mais valias que não era suposto. :)
São coisas que nunca nos passam pela cabeça.