A Criação do Trono Espinhoso: Um Olhar nos Bastidores do Desenvolvimento de Dota 2 pela Valve

A Valve publicou um novo post em seu blog da série “Entre Linhas”, no qual os desenvolvedores compartilharam as dificuldades e particularidades envolvidas na criação do minijogo “Trono Espinhoso” para o evento “Coroa Caída”.

Continuamos nossa série “Entre Linhas”, onde discutimos as dificuldades, erros e felizes acasos que encontramos ao trabalhar em um jogo tão único como Dota 2.

Durante um evento tão grande quanto a “Coroa Caída”, tivemos muitas oportunidades de experimentar: mapas de ato, narrativas ramificadas, fichas de herói, minijogos, quadrinhos, arte pixelada e muitas outras ideias que queríamos explorar há anos.

Ao tomar essas decisões arriscadas, mantivemos a confiança graças à liberdade que a abordagem iterativa nos dá (e à Valve em geral): coletamos dados de jogadores reais, comparamos com nossas expectativas e, ocasionalmente, mudamos de ideia. Costumamos dizer que só entendemos completamente o resultado do nosso trabalho quando o vemos nas mãos dos jogadores, por isso nos esforçamos para chegar a essa fase o mais rápido possível.

Essa abordagem também nos leva a tomar decisões o mais tarde possível durante o desenvolvimento — quando já temos as informações mais úteis (e às vezes as únicas). Em cada etapa, confiamos na experiência real dos jogadores, o que nos ajuda a focar nos aspectos atraentes e evitar os desagradáveis.

O Trono Espinhoso: Uma Luta Final

Hoje, na seção “Entre Linhas”, vamos detalhar o desenvolvimento de algo que apareceu relativamente tarde na “Coroa Caída” — a batalha final no quarto ato entre nossos heróis e a Rainha Impéria, ou seja, o minijogo “Trono Espinhoso”. Usaremos este exemplo para mostrar como os testes e os dados obtidos influenciam nossas decisões.

O primeiro (e único) minijogo no primeiro ato foi uma pescaria simples, onde Leviatã testava sua habilidade na vara de pescar, esperando que alguém pescasse o café da manhã dele. Grande parte do primeiro ato foi assim: espalhamos nossas ideias pelo mapa e esperamos pela reação dos jogadores. Dados encorajadores nos deram confiança e nos levaram a decisões mais ousadas no segundo ato. No terceiro, os jogadores já encontravam “Lutador de Gelo” (um jogo de luta na taverna favorita do Tusk), “Xadrez do Dragão” (um puzzle match-3 da Wyvern de Gelo) e “Covil de Zaug” (um shoot `em up onde Shen se defendia de um dragão maligno nas intrincadas cavernas de Icewrack).

Chegando perto do quarto ato, tínhamos uma boa ideia do que funcionava e do que não funcionava. Que dados tínhamos? Todos! Desde os estritos (números e frequência de execuções de cada minijogo) até os descritivos (feedback de usuários e discussões online). A totalidade dessas informações deixou claro para nós: um confronto final épico, uma batalha explosiva e revolucionária contra a Rainha Impéria — tinha que acontecer!

Naturalmente, não foi fácil decidir qual seria a jogabilidade dessa batalha. Sabíamos que os jogadores esperavam algo grandioso e impactante, e também não podíamos abrir mão da variedade e rejogabilidade que tornariam as tentativas repetidas igualmente cativantes. Além disso, o minijogo deveria ser uma distração rápida e divertida durante a busca por uma partida — uma espécie de lanche agradável, não um jantar completo.

Precisávamos encontrar um gênero que permitisse atingir todos os objetivos estabelecidos, combinando a qualidade do “Lutador de Gelo” e a rejogabilidade do “Xadrez do Dragão”. Afinal, neste confronto épico, Shen, Dragonus e Khez (um novo herói que se juntou ao nosso trio da “Coroa Caída”) atacam a fortaleza de Impéria. Queríamos que, a caminho da rainha, os jogadores sentissem que estavam enfrentando forças claramente superiores.

Explorando Gêneros: De Turnos a Survivors

Uma das ideias que consideramos foi uma batalha por turnos no estilo de RPGs japoneses. No entanto, percebemos rapidamente que não era isso. Precisávamos de algo sem longas esperas. Precisávamos de um entretenimento rápido, intenso e divertido entre as partidas.

Foi assim que chegamos aos jogos estilo Survivors. Um “inferno de balas reverso” com ondas de inimigos incontáveis se encaixou perfeitamente para uma batalha de chefe épica e tensa. O jogador abriria caminho através de hordas de oponentes, usando uma mecânica simples de aprimoramento de habilidades para se preparar para o confronto final com Impéria. Além disso, itens e habilidades de Dota poderiam ser facilmente adaptados a esse gênero, dando aos jogadores algo familiar para se orientar.

Como queríamos que a batalha fosse relativamente curta, a rejogabilidade se tornou outra parte importante do quebra-cabeça. O gênero escolhido já nos ofereceu grande variedade, onde nenhuma tentativa seria igual à anterior: nem itens nem eventos se repetem na ordem que o jogador desejaria. Essa variabilidade incentiva a começar do zero repetidamente, sem causar uma sensação de desesperança ou frustração. Não queríamos que você vencesse logo na primeira tentativa… mas também não queríamos que você abandonasse o jogo após uma derrota.

Prototipagem e Busca pela Diversão

Os protótipos mais antigos do “Trono Espinhoso” começaram com os mesmos elementos-chave da versão final lançada. O jogador escolhia um dos três heróis, superava ondas de inimigos e, eventualmente, chegava até Impéria. Acontece que faltava um elemento crucial: qualquer diversão. Às vezes, o herói vagava por um mapa quase vazio, encontrando um esqueleto ocasionalmente. Em outros casos, as ondas de inimigos eram tão avassaladoras que vencer era simplesmente impossível (pelo menos, era o que pensávamos; mais sobre isso depois). Sabíamos que havia um jogo divertido escondido ali — só tínhamos que encontrá-lo, torturando nossos testadores com builds fracassados no processo.

Cada funcionário da Valve é uma cobaia para quem podemos entregar uma build do jogo e avaliar seu sucesso (ou, com a mesma frequência, seu *insucesso*). Podemos buscar novas ideias o quanto quisermos, mas não saberemos se tomamos as decisões certas até colocarmos alguém para jogar.

No início, os testadores mal conseguiam sobreviver aos primeiros 3-6 minutos. Geralmente, isso significa que o jogo tem problemas de balanceamento ou de comunicação das regras. Pedimos aos testadores que descrevessem detalhadamente suas impressões: momentos em que o jogo os deixava confusos, quando parecia impossivelmente difícil e até quando simplesmente se sentiam entediados. Depois, voltávamos ao trabalho, fazíamos alterações e chamávamos um novo testador. Aos poucos, começamos a notar progresso.

E então, algo aconteceu.

Contando sobre sua primeira tentativa, um testador que acabara de perder perguntou: “Posso tentar de novo?”

Essa reação foi nova — e encorajadora. O “Trono Espinhoso” nem de perto era um bom jogo (geralmente, a estratégia vencedora só era encontrada na terceira tentativa ou mais), mas foi bom ver que desta vez não estávamos forçando um colega a jogar nosso protótipo ruim. O colega *quis* jogar nosso protótipo ruim novamente. Foi uma pequena faísca de interesse: “Não é completamente detestável jogar”. Aceitamos esse feedback com alegria.

Mas a verdadeira epifania estava por vir.

O Momento “Eureka” e o Ritmo do Jogo

Um dos aspectos-chave dos jogos estilo Survivors que estava ausente em nossas primeiras versões era a tensão constante. No início, simplesmente criávamos uma onda de cem esqueletos e deixávamos o herói massacrá-los. Quando não havia mais material para massacrar, criávamos a próxima onda de vilões, mais difícil. Isso rapidamente entediou os testadores: assim que percebiam que o único objetivo era o massacre infinito de inimigos, o jogo virava rotina. A única recompensa por eliminar uma onda eficientemente era o aparecimento mais rápido de oponentes mais difíceis. (Uhul?)

Eventualmente, entendemos: quando criávamos cem esqueletos e o herói começava a massacrar, precisávamos iniciar um cronômetro e reabastecer as fileiras de esqueletos, não importa quantos fossem mortos. Ao fim do tempo, criávamos uma onda de inimigos mais difíceis com um novo cronômetro — agora a tensão nunca diminuía, e os jogadores sempre tinham algo para fazer.

Mas, o que é ainda mais importante, o objetivo deles mudou. Quando nosso herói estava simplesmente lidando com uma multidão de esqueletos diminuindo, o objetivo era reduzir o número de inimigos a zero. No entanto, se matar esqueletos não diminui seu número, os jogadores rapidamente percebem que o objetivo não é matar.

Em vez disso, eles prestam atenção na recompensa por matar hordas de esqueletos — em nosso caso, habilidades e aprimoramentos. De repente, o objetivo mudou de “matar todos os esqueletos” para “quantas dessas criaturas posso matar o mais rápido possível para me tornar o mais forte possível”? De uma rotina, lidar com inimigos se transformou em uma busca por um prêmio, e cada morte aproximava o jogador da build ideal.

Como a transição para a próxima onda não se resumia mais a destruir cada oponente, ganhamos algo novo: um cronômetro compartilhado. Isso significava que os jogadores tinham um ritmo comum — uma linguagem compartilhada que descrevia a progressão da dificuldade do jogo. Então, se alguém falava sobre “as aranhas nojentas no quarto minuto”, todos entendiam do que se tratava (aquelas aranhas são realmente terríveis).

Finalmente encontramos a fonte da diversão. Uma pequena mudança de foco nos ajudou a entender o que e por que os jogadores gostavam, além de gerar uma série de novas ideias: aprimoramentos mais poderosos, habilidades e combinações insanas que nem tínhamos considerado. Isso significava que os testadores podiam criar builds fundamentalmente diferentes — e que eles se envolviam mais, oferecendo feedback e sugestões mais úteis para futuras builds.

Pelo menos, se pedíamos isso várias vezes. Às vezes, descobríamos que, após os testes, nossos colegas não queriam nos contar sobre os prós e contras, mas sim discutir as builds uns com os outros e debater qual era a melhor.

Heróis Únicos e o Equilíbrio

À medida que a variedade de builds crescia, começamos a nos perguntar se havíamos perdido uma parte significativa do quebra-cabeça: e se os próprios heróis fossem tão únicos quanto as habilidades? Nos protótipos iniciais, a jogabilidade era quase idêntica, independentemente do herói escolhido, exceto por sua habilidade inicial. Agora, tornamos a escolha verdadeiramente única — um herói mais forte, outro mais rápido, um terceiro melhor em dano mágico — o que expandiu ainda mais a diversidade de builds. Ao escolher um herói em vez de outro, o jogador também desbloqueava certas árvores de habilidades que de outra forma não poderiam ser desenvolvidas. (E como a lista de aprimoramentos disponíveis dependia da sorte, cada escolha parecia bastante arriscada.)

Enquanto isso, enquanto você está nas nuvens, planejando seu caminho através dos aprimoramentos que o ajudarão a chegar até Impéria, aumentamos gradualmente a dificuldade. Você nem percebeu que, em algum momento, as ondas de inimigos se tornaram mortais e o ritmo — implacável, enquanto você mal se mantinha à tona.

Pelo menos, essa era a ideia. Tendo resolvido a questão dos aprimoramentos, passamos para o ritmo da jogabilidade. Por um lado, o jogo deveria ser tenso, mas não exaustivo (já que sabíamos que a maioria das pessoas o jogaria enquanto esperava por uma partida). Por outro lado, queríamos dar aos jogadores tempo suficiente para que pudessem desfrutar de ver como seus aprimoramentos se combinavam.

Por uma estimativa muito aproximada, tínhamos doze minutos de jogo (sem contar os três minutos finais com Impéria), então começamos a trabalhar no ritmo dos primeiros seis minutos. Com que frequência um jogador deveria escolher um aprimoramento? Quão cedo ele seria capaz de combinar habilidades? Quanto dano cada habilidade deveria causar para ser prazerosa, mas não parecer excessivamente forte?

Como estávamos ajustando a jogabilidade por partes, trabalhar nos primeiros seis minutos significava que, naquele momento, os últimos seis minutos eram praticamente injogáveis. Deixávamos testarem os primeiros seis minutos do jogo e então exigíamos que parassem. *Estritamente falando*, era possível continuar jogando, mas após o sexto minuto, tínhamos apenas placeholders. Não era para jogar mais adiante (o que implorávamos aos nossos colegas).

Um efeito colateral engraçado de tornar as habilidades e aprimoramentos o mais cativantes possível era que, frequentemente, os testadores não se importavam que metade do jogo ainda não estivesse pronta. Sentávamos na mesa de um colega, observávamos a primeira metade do jogo e, assim que o cronômetro chegava aos seis minutos:

“Ótimo, obrigado! — dizíamos nós — Pode começar de novo?”

Pausa.

“Sabe de uma coisa? Acho que ainda consigo vencer.”

Lembramos ao colega que os últimos seis minutos eram um deserto severo e desequilibrado de inimigos empilhados, impossível de passar no momento. O colega respondia que entendia. Fazíamos perguntas sobre os prós e contras, recebíamos muitos comentários excelentes sobre os primeiros seis minutos do jogo. E quando voltávamos para nossas mesas, o colega nos acompanhava com o olhar, tirava o jogo da pausa e tentava passá-lo mesmo assim.

Alguns de nossos colegas levaram para o lado pessoal o fato de não conseguirem passar os últimos seis minutos monstruosamente injustos e literalmente intransponíveis. No fim, enquanto estávamos aperfeiçoando a primeira metade do jogo, eles se uniram e, com esforços coletivos, martelaram a segunda metade, que era para ser intransponível.

E aqui está a questão: eles conseguiram passar.

Eventualmente, eles descobriram a combinação exata de habilidades superpoderosas que ainda não havíamos terminado de balancear e passaram por uma parte do jogo que não foi feita para ser passada. (Isso diz muito sobre design de jogos — mas, talvez, diga ainda mais sobre aqueles que são apaixonados por ele.)

Polimento e Testes Finais

Perto do fim do desenvolvimento, a base do jogo estava criada. Habilidades, encontros com mini-chefes e a batalha final com a Rainha Impéria — tudo estava no lugar. Neste ponto, já não procurávamos erros críticos, mas sim maneiras de ajustar, balancear e polir o que já funcionava. Continuamos os testes, mas abandonamos as análises pós-jogo exaustivas e simplesmente deixamos jogar quem quisesse (e, claro, coletávamos dados adicionais).

Não apenas os dados quantitativos de cada “corrida” eram importantes, mas também os dados qualitativos dos testes. Em um caso memorável, o jogo terminou de forma grandiosa com a Massa Lamentosa (nós a apelidamos internamente de “Almôndega”), que ocupou mais da metade da tela e consumiu o jogador. A essa altura, uma plateia de colegas se reuniu atrás do testador, rindo em uníssono do infeliz. E, claro, ele imediatamente clicou no botão “Jogar novamente”.

Ganhamos confiança de que havíamos preparado um prato digno e começamos a convidar para os testes não apenas voluntários, mas qualquer pessoa que pudéssemos pegar em nossas redes e arrastar para o jogo. Nos estágios iniciais de prototipagem, nos divertíamos com mensagens no Slack à meia-noite como: “O jogo está muito difícil”. Agora, começamos a receber não apenas essas mensagens, mas atualizações para elas às 3 da manhã: “Ah, não, consegui”.

Embora o jogo estivesse quase pronto, continuamos trabalhando no “Trono Espinhoso” até o lançamento do quarto ato da “Coroa Caída”. No início deste post, mencionamos que bons dados nos ajudam a tomar as decisões certas. Bem, finalmente obtivemos esses dados: colegas testadores estavam tão felizes em completar (e rejogar repetidamente) o jogo que coletamos uma enorme quantidade de informações sobre quais elementos do jogo exatamente geravam uma resposta positiva neles. E nada agita mais uma sala cheia de desenvolvedores do que perceber que seu jogo foi considerado divertido. Queríamos adicionar rapidamente o máximo possível do que realmente melhorava o jogo. Novos itens, habilidades, diálogos e até ondas de inimigos — toda vez que pensávamos que o jogo estava completamente pronto, alguém inevitavelmente teria mais uma ideia “definitivamente a última”. E essa ideia geralmente era muito legal, então não conseguíamos resistir à tentação de implementá-la.

A questão não era nem que as ideias estavam aumentando, mas sim que elas estavam ficando cada vez mais legais. No início, quando tínhamos apenas uma ideia vaga do jogo, separar o joio do trigo não era fácil. Mas quando faltava apenas uma semana para o lançamento, tornou-se óbvio exatamente no que deveríamos concentrar atenção e recursos.

O Lançamento e a Reação dos Jogadores

Dando os retoques finais na tela do “Trono Espinhoso”, demos um passo para trás e olhamos para ele com novos olhos. Nossa tarefa era aproveitar os aprendizados dos atos anteriores para criar uma batalha de chefe épica, digna da conclusão do último ato. Ficamos satisfeitos com o resultado; especialmente considerando a restrição de tempo. O jogo ficou divertido.

Acontece que, infelizmente, os jogadores ainda não tinham conseguido chegar até ele. Subestimamos um pouco o fato de que o “Trono Espinhoso” era uma batalha de chefe e, obviamente, essa batalha teria que acontecer… onde o chefe mora, ou seja, bem no fim do jogo. Isso significava que teríamos que esperar agonizantemente um ou dois dias até que os jogadores mais dedicados de Dota passassem correndo pelo quarto ato e tivessem a chance de experimentar o minijogo.

Ao que parece, não tivemos que esperar muito. Pensávamos que os primeiros jogadores chegariam à sala do trono de Impéria em cerca de um ou dois dias. Mas logo ficou claro que subestimamos a velocidade com que nossos jogadores podem consumir conteúdo. Apenas 16 horas depois — sim, horas — encontramos jogadores habilidosos que romperam todo o último ato e conheceram o “Trono Espinhoso”.

No fim, todos os outros também chegaram lá. No momento em que este post foi escrito, o “Trono Espinhoso” foi jogado quase cem milhões de vezes. A propósito, se você ainda não experimentou este minijogo ou quer jogá-lo mais uma vez, o arquivo do evento e todos os minijogos incluídos ainda estão disponíveis no arquivo do evento no menu principal.

Esperamos que este olhar por trás dos bastidores de como a equipe de Dota criou um minijogo do zero permita que você aprenda mais sobre nosso processo de desenvolvimento, em vez de causar pavor pela ideia de que simplesmente inventamos tudo na hora. Na verdade, apenas queremos mostrar que o design de jogos não é alguma magia disponível apenas para gênios trabalhando a noite toda. O desenvolvimento de jogos é um caminho de tentativa e erro, baseado em dados, experiências, testes, falhas, testes, mais falhas e testes novamente.

A abordagem iterativa rende frutos — tudo começa com “algo непонятно” (algo incerto), mas depois você analisa os sucessos anteriores e gradualmente chega a “algo já”. Isso resulta em um protótipo ruim que ninguém quer jogar, mas jogará de qualquer forma (a seu pedido). Então você vê como eles não estão se divertindo, volta ao trabalho, remove tudo o que não é divertido e repete esse processo até que finalmente se divirtam. E então você incansavelmente refina, poli e corrige o jogo, dá uma olhada no calendário com a data de lançamento e começa a chorar. Nós da Valve sempre tentamos abraçar a imprevisibilidade e permitir que os dados guiem o caminho do desenvolvimento. Por causa disso, nossos produtos nem sempre são lançados na data marcada. No entanto, esperamos que vocês gostem deles — quando estiverem prontos.