O texto abaixo foi publicado no PlayStation.Blog brasileiro.
Com o lançamento de Moving Out em apenas um dia (você pode jogar a demo se não conseguir esperar), pensei em falar sobre nossa rodada de testes. Pode parecer como uma parte simples do processo de desenvolvimento, mas começar os testes cedo fazer deles um foco ajudou a melhorar Moving Out de diversas formas.
Por todo o ano de 2019, conduzimos mais de 150 sessões de playtest para Moving Out, chamando amigos, vizinhos e fãs. São mais de 120 horas de testes gravados. E isso não inclui as mais de mil sessões ao vivo em eventos, como a PAX.
Clique para aumentar
O que começou como uma maneira casual de compartilhar testes entre vários estúdios de Melbourne, Sydney, DevM na Suécia e Team17 no Reino Unido, acabou se tornando uma parte importante do processo de controle de qualidade e feedback sobre as fases do jogo. Este processo também levou à decisão de incluir um “Modo de Assistência”, o que é um elemento importante para garantir acessibilidade ao jogo.
Como encontramos pessoas o suficiente para realizar testes?
Esse foi um grande desafio. Encontrar jogadores “novos” e depois encontrar jogadores dispostos a retornar para testar as fases mais difíceis. Organizamos sessões regulares de testes usando Calendly, e tentamos encaixar de 2 a 4 por semana. Toda terça e quinta, disponibilizávamos tempo extra para atualizar o jogo baseado no feedback das sessões anteriores.
Perseguimos as escolas de game locais, além de diversos grupos de Facebook para as várias plataformas. Ao oferecer doces e a chance de jogar um jogo novo, encontramos pessoas dispostas a participar. Acho que gastamos uns 200 sacos de doces. Então, se quiser fazer algo similar, tenha certeza de ter um orçamento para doces 🙂
Aqui vai um exemplo do que dávamos para nossos testers. A equipe consumia o que sobrava.
Aqui está meu filho vendo alguns testes no final de semana. Durante os testes finais, precisávamos de grupos de quatro pessoas que pudessem vir múltiplas vezes. Este grupo que recrutamos via Facebook só podia vir nos finais de semana.
Além disso, também tivemos ajuda do estúdio Team17, que fez sua própria equipe interna de design testar o jogo, além de diversos outros departamentos que serviram como “carne nova”.
Simplificando
O processo consistia em testar, aprender, agir e verificar. Captamos as sessões de gameplay e gravamos os jogadores por meio de uma webcam usando XSplit. Dessa maneira, conseguíamos ouvir o que estavam dizendo e ver como estavam reagindo enquanto jogavam.
Uma grande dica foi ter números visíveis de versões do jogo. Assim, qualquer screenshot ou vídeo que captássemos poderia ser diretamente vinculado a uma versão!
Depois disso, subimos estes vídeos para o YouTube e compartilhamos com a equipe como um todo. Com o desenvolvimento dividido entre o departamento de desenvolvimento em Melbourne, Jan do estúdio DevM na Suécia, a equipe do Team17 no Reino Unido e eu em Sydney, o YouTube era a forma mais rápida e eficaz de compartilhar os arquivos.
Depois, fazíamos várias análises em cada teste. Assim, um mesmo vídeo poderia ser visto diversas vezes por todo o estúdio.
Para efeitos de controle de qualidade, era fácil perceber um problema, marcar o tempo do vídeo em que ele acontecia e abrir um ticket para o suporte. Esse ticket continha o vídeo com o bug em ação. Para nosso primeiro jogo, Death Squared, participávamos das sessões de teste e tentávamos perceber quando um bug acontecia, e depois tomávamos nota rapidamente. Quando captamos os testes em vídeos, não filmamos os jogadores. Olhar apenas para o gameplay atrapalhava, pois não sabíamos exatamente em que momento um jogador estava tendo problemas.
Pessoalmente, eu assistia aos vídeos com velocidade aumentada para 1.5x, o que me economizou diversas horas se comparado a estar presente durante os testes. Isso me fazia sentir como se todos estivessem falando devagar quando eu retornava à velocidade 1x. Fiz isso tanto que não consigo mais assistir ao YouTube na velocidade normal :/
Para os designers de fases, eles podiam ver e ouvir como os jogadores abordavam cada desafio. Eles estavam fazendo exatamente o esperado? Ou talvez usaram alguma abordagem inesperada? Isso nos fez notar tendências nas abordagens dos jogadores de testes diferentes.
Um exemplo simples é o de uma versão inicial, em que o diálogo do “chefe” diz: ” O cliente disse para não quebrar suas coisas”. Isso foi escrito para ser uma frase irônica, afinal, ninguém quer que você quebre suas coisas. O problema é que percebemos que os jogadores estavam levando isso a sério. Então, adicionamos ao texto a frase “Brincadeira! Eles pagaram um seguro. Destrua tudo que quiser”! É sutil, mas ajuda a dar o tom certo ao jogo. Queremos que os jogadores entrem no caos e se divirtam destruindo coisas. Quase negamos esse aspecto do jogo com uma simples frase de diálogo!
Gravar jogadores também nos permitiu ver se as piadas estavam sendo entendidas, e ter o áudio das pessoas rindo e gritando umas com as outras por causa do seu jogo é realmente gratificante, de uma forma esquisita. Então, se tudo mais falhar, isso por si só já valeu o esforço.
Entendendo a parte indefinida do design de jogos
Para qualquer coisa que não seja claramente um bug, descrevíamos em um documento do Google e fazíamos uma revisão semanal como equipe. Depois críavamos um ticket se alguma ação fosse necessária, ou ignorávamos a questão. O processo de design de jogos não possui respostas certas ou erradas. Portanto, discutir aspectos da experiência de usuário foi um processo muito mais fácil com todos tendo material em vídeo para assistir.
Impacto no Design de Fases
Passando agora para Dave e Brodie, que chefiaram o design das fases do jogo:
Ver pessoas jogando na sua frente ajuda muito a validar ideias e fazer ajustes rápidos. Isso vinha desde coisas simples como “os jogadores navegaram as fases da forma que esperávamos?” ou “eles foram por caminhos inesperados/não intencionais?”. Esse processo nos deixou mais confiantes sobre nossas ideias e presunções.
Uma das mecânicas mais marcantes que nasceu nos testes com usuários é o co-arremesso. Em um dos testes, os jogadores tentaram jogar uma máquina de fotocópias por uma varanda. No estágio em que estávamos, apenas permitíamos o arremesso de pequenos objetos, mas este teste nos deu a ideia de um arremesso cooperativo! Ao trabalharem juntos para balançar itens grandes e soltar no momento certo, podíamos dar a jogadores a oportunidade de arremessar objetos grandes por varandas, dentro de piscinas e em caminhões lotados. Essa ideia simples mudou nosso jogo rapidamente!
O Tutorial: queríamos ter o mínimo de interação possível com os testers, para que os testes fossem consistentes em múltiplos escritórios, o que levou ao desenvolvimento do tutorial bastante cedo. Isso significa que cada tester teve a mesma experiência introdutória, e podíamos comparar sessões para tomar decisões com mais informações.
E agora, de volta com John, o produtor do jogo:
Impacto na Produção
Em certos momentos, a quantidade de dados de usuários era esmagadora. Estávamos lidando com mecânicas que não havíamos terminado ainda, ou que entraram no jogo no mesmo dia e não haviam sido completamente finalizadas pelos designers. Foi desafiante manter o foco e as prioridades durante o processo. Como um exemplo, nosso arquivo de documentos de feedback, que lista pontos de discussão ou pequenas notas rápidas, tem mais de 260 páginas!
O resultado dos testes de usuários reiteraram que estávamos no caminho correto e que o jogo era mais divertido quando jogado por dois ou mais jogadores. Ver usuários trabalhando juntos, comunicando e rindo foi bastante motivador. Também ficou claro que o modo single-player precisava ser mais trabalhado, então adicionamos mais funcionalidades, como itens de 2 jogadores mais leves e um novo modo de jogo chamado “Dual Move Mode”, em que um único jogador controla 2 personagens com um único controle. Hora de testar sua ambidextria e seu domínio hemisférico em igual medida!
Como um desenvolvedor, você está constantemente enfrentando bugs e ajustes que precisam de conserto. Os que mais gastam tempo, no geral, são os difíceis de reproduzir. Por sorte, tínhamos montanhas de filmagens de testes. Um exemplo das questões que encontramos foi os jogadores não conseguirem terminar uma fase porque uma ou outra caixa haviam desaparecido. Ela não estava no caminhão, nem na fase. No fim, após assistir ao vídeo novamente, notamos que a caixa não havia sido re-criada pelo jogo após ser jogada na água, pois outro objeto havia sido alocado na posição de recriação da caixa. Isso nos fez criar um sistema de criação de objetos mais detalhado, incluindo uma interface de usuário que aparece quando algo está impedindo que um objeto importante seja criado no mundo do jogo.
Como resultado, os testes de usuário nos permitiram manter o jogo estável, jogável e sem bugs sérios por todo o desenvolvimento, já que apontavam os problemas que haviam dentro do jogo. Sempre havia uma nova versão a ser testada com novos usuários nos próximos dias.
Impacto na Arte?
Jon, o diretor de arte de Moving Out, diz “um dos maiores benefícios de uma testagem ampla é que podíamos ver quando elementos específicos da comunicação visual não estavam otimizados para jogadores lerem rapidamente e a distâncias diferentes. Em um jogo onde a câmera pode ser afastada significativamente para capturar a posição de até 4 personagens — ter certeza que o jogador pode filtrar as informações visuais e entender o espaço de jogo por baixo de tudo é de grande importância.
Uma lição valiosa que aprendemos como resultado direto dos testes de usuário foi que adicionar uma cor uniforme para as paredes e para o chão de uma sala ajudou a identificar o local como um espaço coeso. Além disso, podia ser usada como referência no vocabulário usado pelos jogadores para se coordenar. Os espaços pareciam mais unificados e jogadores podiam dizer que estão limpando a “sala roxa”, por exemplo, o que dava mais ferramentas para a cooperação”.
Impacto geral no jogo
O maior impacto além de um gameplay bastante coeso é na criação do Assist Mode.
Estávamos em dúvida quanto à dificuldade do jogo. Será que deixamos ele mais fácil e removemos alguns dos obstáculos que atrapalhavam constantemente os jogadores? Com os testes, percebíamos que as pessoas ficavam presas, mas ainda estavam se divertindo. Os jogadores geralmente falhavam em certos locais, mas aprendiam e na segunda ou terceira tentativa, tinham sucesso. Mas alguns jogadores ficavam frustrados. Estes eram jogadores completamente capazes que apenas ficavam presos e sua frustração era visível. E quanto a jogadores com menos habilidade ou paciência?
Queríamos que Moving Out fosse DIVERTIDO, não frustrante
A solução foi o Assist Mode. Queríamos adicionar funcionalidades para permitir que os jogadores personalizassem o jogo para suas necessidades. Com o Assist Mode, você pode estender o tempo das fases, remover perigos, fazer itens mais leves, removê-los conforme são adicionados ao caminhão ou apenas pular uma fase se você falhar. Os testes extensos não apenas informaram quais funcionalidades deveríamos melhorar, mas também que essa ideia era válida. Acabou virando mais um foco de acessibilidade depois, conforme percebemos que isso pode ajudar mais pessoas a curtir o jogo.
Agora que o jogo está terminado é bem interessante olhar para trás e ver o quanto progredimos desde a primeira sessão de testes.
Se você é um desenvolvedor de jogos, recomendamos que grave todos os testes que puder. O custo é eficiente, e o tempo que você vai gastar para preparar tudo se paga muitas vezes. E se você for um jogador, entre em contato com seu desenvolvedor independente mais próximo e veja se precisam de ajuda para testar seus jogos e comer seus doces.
Esperamos que as centenas de sessões de teste tenham valido a pena e que todos curtam o jogo. Temos uma demo gratuita para testar, com uma pequena mostra das 50 fases que temos no jogo.
