A mais de um ano atrás eu vi uma palestra do GDC no Youtube sobre Evil Data e achei o conceito interessantíssimo. Resolvi guardar o assunto no meu documento de ideias para ser um tópico tratado aqui no blog. E nunca mais retomei essa ideia. Bom, tendo em vista a escassez de Lições, resolvi buscar as antigas anotações e cá estamos nós.
Antes de começar, deixo aqui o vídeo para quem quiser ver. Entretanto, não é necessário assisti-lo para compreender a Lição.
Primeiramente, do que se trata Evil Data? Basicamente são dados coletados (Feedbacks) de Playtests realizados no qual as informações não condizem com a realidade. Isto é, são dados potencialmente perigosos para o Game Designer, pois ele vai usar toda essa informação para guiar suas decisões. Você, desenvolvendo seu jogo com dados do capeta, a tendência é você chegar no inferno. O que não parece ser uma coisa boa…
Inclusive, já vou iniciar corrigindo algo que falei aqui um bom tempo atrás. Eu comentei que você deveria montar uma versão demo para eventos, caso seu jogo fosse relativamente longo. Afinal, dessa maneira você conseguiria mais partidas. Logo, coletar mais Feedbacks e aproveitar melhor o evento. Errado, ao menos a parte sobre aproveitar melhor o evento. Na verdade, eu sempre fui contra essa política, só falei por ser uma indicação de quase todos os presentes no tal evento. Cortar o jogo nunca serviu para testá-lo, a não ser que você queira realmente testar apenas um pedaço dele. Você usar o Feedback de uma partida cortada como um Feedback do jogo como um todo pode ser um problema grande. Então, tenha consciência disso. Quer fazer uma versão reduzida? Pode fazer, mas cuidado com as consequências.
Vamos para um exemplo que deve deixar as consequências bem claras. Pense no jogo Ticket to Ride. Não conhece? Shame on you. Bom, a maneira mais simples de criar um demo é reduzir o número de rodadas. Como em Ticket to Ride não existe uma quantidade fixa de rodadas, você pode simular isso terminando o jogo antes antes ou adiantando o começo do jogo. Como fazer isso? Para terminar antes bastaria colocar menos trens para cada jogador. Já para adiantar o começo você precisaria colocar alguns trens já no tabuleiro, como se fosse um pré-Setup. Nenhuma das opções prestam. Como Ticket to Ride tem primariamente duas maneiras de pontuar (fazendo rotas e cumprindo objetivos) terminando antes fará com que os objetivos fiquem desbalanceados. Ou fracos demais ou fortes demais, pois o jogo foi pensado para X trens e não X-Y trens. Isso pode acarretar em Feedbacks do tipo: “não valeu a pena investir nos objetivos, eu terminei perdendo muitos pontos” ou “nunca usei a ação de comprar objetivos, pareceu difícil demais” ou “eu ignorei os objetivos e ganhei, soou estranho”. Então, as impressões dos jogadores sobre o jogo foram distorcidas pela modificação. No segundo caso, adiantar o começo, forçaria os jogadores a seguirem determinada estratégia. Isso engessaria o jogo e poderia render comentários como: “achei meu Setup fraco demais” ou “as rotas longas são muito fortes” ou “Fulano só venceu, pois já começou com objetivo quase pronto”. A primeira opção é mais fácil de implementar, mas não avalia bem seu jogo. A segunda opção é pior ainda, pois além de mais complexa de implementar, você literalmente transformou seu jogo em outro… Um jogo com assimetria.
Outro caso seria seu demo funcionar perfeitamente e você acreditar que seu jogo original também está bom. Na realidade, esse seria a melhor situação, pois se seu jogo realmente estava ruim e o demo funcionou bem, você conseguiu reduzir com sucesso a duração do seu jogo. Win win. Entretanto, sinto informar, acho difícil acontecer.
Sendo que essa não é a única maneira de você esbarrar com Evil Data. Esse capeta pode surgir onde você menos espera. Suponha que você foi para um evento e não fez uma versão demo. Afinal, a duração do seu jogo é apenas 20 minutos. Você testou várias partidas completas no evento e ficou satisfeito com todos os Feedbacks. Com base neles, seu jogo estava pronto para publicação. Só tem um porem: o evento foi em uma escola e era um evento de apresentação de jogos de tabuleiro. Isto é, o público carecia de conhecimento sobre jogos e até das ferramentas necessárias para dar algum Feedback útil. Você publicando esse jogo estará trazendo um jogo com potenciais falhas, pois achou que testar com 50 adolescentes que nunca jogaram jogos de tabuleiro modernos fosse uma boa ideia. Então, é importante você testar com todo tipo de pessoa. Inclusive, isso pode acontecer testando apenas com jogadores experientes. Afinal, seu jogo pode ser dificílimo de aprender mas para esse pessoal é tranquilo. Deste modo, eles nunca reportaram nenhum problema com as regras ou aprendizado. Então, você lança o jogo e a maioria das pessoas simplesmente não conseguem compreender o fluxo básico do seu jogo. Jogam tudo errado e dizem que o jogo não presta. Ou jogam até certo, mas demoraram uma Era inteira para entender como funcionava.
Outro local com problemas são os formulários. Talvez as pessoas não respondam honestamente ou inventem elogios/defeitos apenas para escrever algo. Eu, raramente consigo uma boa extração de dados por formulários e penso seriamente em abolir. Por sinal, Feedback Online é um dos piores que existe. Ao menos se for preenchido muito tempo depois da partida em questão. O jogador vai ter tempo para ficar matutando sobre o jogo, criar memórias falsas e dar sugestões aleatórias.
Tudo bem, no meio dessas sugestões pode ter algo bacana, mas assim fica difícil saber onde o jogo está bom ou onde o jogo está ruim. O jogador não é o Game Designer do jogo. Então, as sugestões dele podem não estar de acordo com o que o jogo deve ser. Geralmente, sugestões adicionam algo ao jogo e muitas vezes o Game Designer quer diminuir o jogo e não aumentá-lo. Ou a sugestão altera a natureza do jogo, deixando-o mais tático do que estratégico. Então, sugestões podem ser Evil Data.
E, para fechar, faça Blind Playtest. Parece ser uma das poucas maneiras de evitar Evil Data, pois o jogo estará sendo testado em sua experiência completa. Isto é, necessitando de leitura do manual, alguém precisando explicar, as pessoas jogando o jogo inteiro (ou parando no meio por ser terrível). O problema é se você não estiver assistindo. Aí os jogadores podem ter jogado a partida inteira errada e você receber um Feedback mais do capeta do que nunca.
Resumindo: tudo pode ter Evil Data. Cuidado. Resta você evitar situações que aumentem as chances de acontecer e, quando acontecer, saber filtrar.
Interessante tópico.
Uma ideia: ao criar um formulário tipo Likert ("com escalas"), para ter uma melhor precisão nos resultados e conclusões, de repente seria necessário ter mais afirmativas, até mesmo contraditórias, pois pode ajudar a entender algum viés proporcionado pela própria afirmação. Isso pode ajudar a eliminar bastante evil data.
É trabalhoso motivar as pessoas a responder on-line, mas os resultados via Likert tem sido bem proveitosos pra mim (pelo menos no ajuste de regras e estudo das estratégias).
De vez em quando dou uma olhada no teu Blog, pra motivar e refletir sobre o processo de design de jogos. Parabéns!
Alderic::Interessante tópico.
Uma ideia: ao criar um formulário tipo Likert ("com escalas"), para ter uma melhor precisão nos resultados e conclusões, de repente seria necessário ter mais afirmativas, até mesmo contraditórias, pois pode ajudar a entender algum viés proporcionado pela própria afirmação. Isso pode ajudar a eliminar bastante evil data.
É trabalhoso motivar as pessoas a responder on-line, mas os resultados via Likert tem sido bem proveitosos pra mim (pelo menos no ajuste de regras e estudo das estratégias).
De vez em quando dou uma olhada no teu Blog, pra motivar e refletir sobre o processo de design de jogos. Parabéns!
Opa, valeu pela informação Alderic. Daria para aplicar esse mesmo formulário na mão mesmo, pós-partida. O ruim é depois transcrever as coisas para poder gerar alguma estatística mais visível.
E obrigado pela olhada.
