A gente faz os nossos jogos para dois jogadores, e a gente mesmo testa. Parte disso é gente jogando no sofá. A maior parte, não. Antes de um original ser lançado, ele passa por dezoito verificações automáticas. Elas abrem o jogo em um navegador de verdade, leem o que está na tela, apertam as teclas, tocam nos layouts de celular e tentam resolver as fases. Este post é sobre os bugs que essas verificações encontraram. Todos eles tinham sobrevivido a um playtest humano.
O bug que sobreviveu a todos os playtests
Cada jogo nosso mostra os controles na parte de baixo da tela. Em sete dos doze primeiros originais, essa linha estava errada durante a partida. Ela mostrava as teclas do menu em vez das teclas do jogo. Sumo Smash, o nosso jogo mais jogado, tinha esse bug. Ninguém percebeu. O jogo funcionava perfeitamente, só nunca dizia como jogar. A correção foi uma linha por jogo. A lição foi maior: nossas verificações liam o código, não a tela.
Ler o que a tela diz ao jogador
Então escrevemos uma verificação que joga em vez de ler. Ela começa uma partida solo, espera a contagem regressiva e lê a frase que está de fato na tela. Se essa frase cita as teclas do menu, a verificação falha. Depois colocamos o bug antigo de volta em um jogo, de propósito. A verificação pegou. Um teste que não pode falhar não é um teste, então a gente quebra as próprias verificações antes de confiar nelas.
Menus que se sobrepunham no celular
Nossos menus de título eram desenhados numa porcentagem da altura da tela, mais alguns pixels por linha. Isso funciona num notebook. Num celular deitado, as linhas caíam umas em cima das outras. Uma captura de tela de um jogador mostrou isso em um jogo. Quando testamos todos os jogos em cinco tamanhos de tela, dezoito de vinte e um tinham o mesmo problema em algum lugar. Hoje todo menu de título é uma única pilha que mede o próprio espaço, e a verificação roda todos os jogos em todos os tamanhos antes de cada lançamento.
Toques de verdade, não de mentira
Vários originais deixam duas pessoas dividirem um celular. A tela se divide ao meio e cada polegar ganha o seu próprio analógico. O risco é silencioso. Se a metade direita envia, sem avisar, as teclas do jogador da esquerda, a tela parece perfeita e um jogador simplesmente não consegue se mexer. Nossa verificação de toque usa eventos de toque reais do navegador, não teclas simuladas. Para cada metade, ela lista as teclas que precisam disparar e as que nunca podem disparar. Nós a testamos ligando uma metade à tecla errada, de propósito. Ela falhou, que era o que a gente queria.
Fases que não tinham solução
Jogos de puzzle ganham um solucionador. Tether é um puzzle cooperativo em que duas esferas presas a uma corda precisam ficar, as duas, sobre plataformas ao mesmo tempo. No primeiro rascunho, nenhuma fase tinha solução. As plataformas ficavam em pontas opostas, mais distantes entre si do que o comprimento da corda. A olho nu, parecia tudo certo. Os números diziam outra coisa.
Beam tinha um problema mais sutil. Toda fase podia ser resolvida por algum ângulo da luz. Mas três de seis fases começavam com o andarilho parado no escuro, e o escuro é um cronômetro. Com solução no papel, fatal no primeiro quadro. Agora a verificação testa o ângulo inicial, não só se existe uma resposta.
Color Gates foi o que foi mais longe. Uma verificação calculou o custo de cada fase em segundos. Ela descobriu que três de seis fases podiam ser terminadas sem nunca usar a mecânica principal do jogo, porque os dois jogadores podiam simplesmente se revezar. O design inteiro foi refeito em torno de placas de pressão que os dois jogadores precisam segurar ao mesmo tempo. Uma mecânica que dá para contornar com revezamento não é uma mecânica.
Uma regra, quebrada quatro vezes
Todo original segue o mesmo pequeno contrato. Space numa tela de título nova começa um jogo solo. O número dois começa uma partida para dois jogadores. Escape volta para o título. Escrevemos essa regra e mesmo assim a quebramos quatro vezes. Dois jogos cooperativos começavam em dois jogadores por padrão, então um visitante sozinho que apertava Space ganhava uma esfera e um parceiro morto. Corrigimos esses dois, e depois uma nova verificação achou o mesmo bug ainda vivo em dois jogos mais antigos. Uma regra quebrada quatro vezes não é uma regra. É sorte. Agora uma verificação joga todos os trinta jogos e confere o contrato.
Quebrando nossas próprias verificações de propósito
Cada verificação acima foi testada contra uma falha proposital. Coloque o bug de volta, rode a verificação, confirme que ela falha. Isso importa mais do que parece. Em um jogo de corrida, a verificação da regra de pontuação passou mesmo depois que reescrevemos a regra para algo errado. A verificação só presumia a regra, não a testava. Agora ela confere cada momento de pontuação. Uma verificação que nunca falha não te diz nada.
Por que isso importa para você
Nada disso deixa um jogo divertido. Quem decide isso é gente no sofá, e a gente continua fazendo playtest de todo original. O que as verificações fazem é tirar os bugs que um playtest não consegue ver. Uma dica que mente, um menu que se sobrepõe no seu celular, uma fase sem solução. São esses os bugs que fazem alguém fechar a aba e nunca dizer por quê. Se você quer o lado do design desta história, leia os jogos que a gente matou e como equilibramos nossos jogos. Ou simplesmente abra os originais e veja se funcionou.
