Este post foi originalmente escrito em italiano por Paolo Gambardella. Foi traduzido por um agente de inteligência artificial e pode conter imprecisões.
Quando o assunto é game design document, documentação de design, a conversa quase sempre cai direto em templates e formatos padrão. Na minha opinião, é aí que se perde a chance de enxergar o quadro geral. O formato, afinal, é só um aspecto de uma das cinco partes de uma boa documentação de design.
Alguns meses atrás escrevi sobre a diferença entre documento e documentação. Este post parte de lá: uma vez que ficou claro que estamos documentando algo concreto, o que esse documento precisa conter?
Cinco pontos de vista
Para deixar tudo mais concreto, vou usar um exemplo simples: o boost num jogo de corrida.
Conhecimentos. Antes de mais nada, um documento de design se organiza em torno de uma série de conhecimentos que o jogo, ou a feature em questão, deveria transmitir aos jogadores. No passado falei sobre a player experience narrative, ou seja, o relato do jogo ou da feature escrito do ponto de vista de um jogador apaixonado. Isso nos ajuda a identificar os componentes do que estamos descrevendo e, consequentemente, os skill atoms — os conhecimentos que vamos transmitir. A diversão nasce sempre de um processo de descoberta, parecido com o processo criativo: jogar é aprender.
No caso do boost, os skill atoms poderiam ser: entender quando a barra está cheia, descobrir que usar o boost numa curva faz o carro perder aderência, aprender a guardá-lo para a reta final. Cada um desses é uma pequena descoberta, e cada um precisa ser descrito.
Objetivos. Em segundo lugar, o documento contém os objetivos que temos do ponto de vista do jogo. Esses se concretizam em comportamentos específicos que esperamos dos jogadores e, às vezes, também em emoções que queremos provocar. Normalmente se parte dos game pillars (quando existem) e se explica assim a meta que precisamos atingir.
Para o boost, o objetivo poderia ser que o jogador o use pelo menos uma vez por volta e que sinta uma descarga de adrenalina na reta. Um pillar só tem valor se nos obriga a abrir mão de alguma coisa: se o pillar é “velocidade”, o documento precisa dizer também o que sacrificamos para mantê-la — por exemplo, nenhum menu durante a corrida. E se esperamos um comportamento específico, escrevemos também como vamos medi-lo. Um objetivo que não conseguimos observar num playtest ou nos dados continua sendo só uma esperança.
Gameplay. Passa-se então a planejar o gameplay, concretizando os objetivos do jogador, os conteúdos, as atividades e as eventuais estratégias que ele pode seguir para superar os obstáculos. Nessa seção aparecem com frequência fluxogramas, listas com marcadores e por aí vai.
É aqui que o formato entra em cena. A forma como apresentamos o gameplay precisa servir a quem vai lê-lo. Para o boost, um diagrama com os estados (vazio, carregando, cheio, ativo) diz mais ao programador do que três páginas de texto, enquanto uma tabela com velocidade e duração é mais útil para quem cuida do balanceamento. O formato se escolhe com base no conteúdo e no leitor, e pode mudar de seção para seção.
Sistemas. Um bom documento de design não tem como ignorar os sistemas. Um sistema é um conjunto de mecânicas que, juntas, ensinam algo ao jogador — por isso eu o vejo como um conjunto de experiências de aprendizado. Existem também dinâmicas não planejadas, que às vezes conseguimos identificar e que acabam se tornando parte do metagame.
Scott Mercer conta em um vídeo curto como projetou o Gruul the Dragonkiller, um boss de World of Warcraft: Burning Crusade. Ele queria recriar a sensação da brincadeira de dança das cadeiras, quando a música para e todo mundo sai correndo para achar um lugar. A primeira mecânica, Shatter, causa dano a quem está perto dos outros, então os jogadores aprendem a se espalhar. Mercer já prevê uma dinâmica não planejada: o raid poderia atribuir a cada um uma posição fixa, e a graça acabaria. Ele adiciona então o Ground Slam, que arremessa cada jogador numa direção aleatória e o força a improvisar. Depois vem a latência: em 2007, muita gente ainda jogava via modem, e cada um via os outros em posições ligeiramente diferentes. Entra então uma desaceleração progressiva, que dá tempo para os clientes sincronizarem e, de quebra, adiciona tensão. Por fim, quanto mais jogadores morrem, mais espaço sobra para se espalhar, então o confronto ficaria fácil demais. Um aumento gradual do dano mantém todo mundo motivado a sobreviver.
Cada mecânica tapa o buraco da anterior, e cada uma muda o que o jogador aprende. É por isso que, se a feature que estamos documentando faz parte de um sistema maior, ou se ela afeta outros sistemas, precisamos demonstrar que entendemos o quadro geral e tentar prever como ele vai funcionar. Voltando ao nosso exemplo: se o boost se recarrega coletando itens na pista, isso também muda a forma como o jogador escolhe as trajetórias — e o level design precisa saber disso.
Produção. Por fim, uma boa documentação de design ajuda a resolver problemas e desafios de design, e orienta programadores e artistas na criação de todos os assets necessários para o sucesso da feature ou do jogo em questão. Para o boost, isso significa listar efeitos visuais, sons e movimentos de câmera, e registrar as perguntas ainda em aberto: o que acontece se o jogador ativar o boost durante um salto?
Templates têm seus limites
Quando nos concentramos demais no formato final, corremos o risco de perder a visão geral e de deixar de fora partes que um formato prevê e outro não.
Peguemos o documento de uma página, o one-pager. É ótimo para alinhar o time ou apresentar uma ideia para um publisher, mas os sistemas e suas interações não cabem ali dentro. Muitos templates clássicos de GDD, por outro lado, têm seções intermináveis sobre gameplay e nenhuma sobre os conhecimentos que o jogador precisa adquirir. Quando escolho um formato, já sei de antemão qual dos cinco pontos estou abrindo mão, e documento esse ponto em outro lugar.
Por isso uso as cinco partes como um checklist, antes mesmo de abrir um template: conhecimentos, objetivos, gameplay, sistemas, produção. Se falta um deles, o documento tem um buraco — independentemente do formato.
