Cursos / Jogos Digitais / Criação de Personagens e Narrativas de Jogos / Aula

arrow_back Aula 08 - Quests: associando personagens, mecânica e narrativa

Criando Quests: casos práticos

O processo de criação de quests capazes de concentrar as qualidades desejadas em uma jornada épica nos jogos está entre os grandes desafios do design de games. Obter êxito em tais projetos é resultado de uma parceria entre criatividade, pesquisa, playtests, playtests e mais playtests, e, como vimos, o uso de mecânicas que valorizem a produção, gerenciando recursos de maneira fluída no jogo, e de tabelas de inventário ao encadeamento de quests que se tornem plenas e memoráveis para os jogadores.

Podemos observar alguns exemplos de produções de jogos que mostram como desenvolvedores e criadores conseguiram contornar, de forma brilhante, problemas e gargalos tecnológicos e mecânicas nem sempre alinhadas às intenções originais dos projetos para realizar trabalhos que se tornaram marcos no design de games. Abaixo, apresentamos breves relatos de profissionais do ramo e escritores da história dos games para exemplificar tais criações.

Fallout 3: O design de RPG´s, role-playing games, por exemplo, está entre os mais complexos, envolvendo um entrelaçamento intrincado de narrativa, design de quests, puzzles e level design. Como meios importantes para transmitir a história dos jogos, as missões ditam as configurações e conteúdos dos níveis (levels) e os níveis fornecem desafios a serem superados pelo jogador na busca pela conclusão das missões de uma quest. Smith et al. (2011), pesquisadores da Universidade da Califórnia em Santa Cruz, explicam em um trabalho acadêmico a importância de um level design integrado ao projeto do jogo, por meio do processo de quests sequenciais e sua continuidade em etapas menores, que dão sentido e coesão à jornada, com a apresentação de um trecho retirado do game Fallout 3 (2008), da Bethesda: O jogador é solicitado inicialmente por alguém em Megaton (a cidade de origem) para entregar uma carta à sua família, em uma localização diferente. Ao chegar, o jogador descobre que a pessoa que deveria receber a carta desapareceu, e as pessoas da cidade culpam [certos] atacantes pelo sequestro. O jogador está agora encarregado de um objetivo menos geral, mas mais significativo, de caçar os tais atacantes. Ao encontrá-los, ele tem a opção de matá-los todos, varrendo-os do mundo do jogo, ou conversar e convencê-los a não atacar mais a cidade. Esta tarefa final tem um impacto muito maior sobre o mundo do jogo em relação a qualquer outra na cadeia dos quests. (SMITH et al, 2011, p.328)

The Secret of the Monkey Island: Em outro artigo abordando as dificuldades encontradas em criar densas ambientações narrativas para RPGs de computador, uma equipe paralela de Sullivan, Mateas e Wardrip-Fruin. (2009) comentam a frustração vivida em quests pretensamente baseadas em objetivos, mas que, em razão da falta de reais escolhas pelo jogador, permanecem no campo das quests baseadas estritamente na realização de tarefas ou, como afirmam, checklist. O exemplo apresentado no trabalho resgata uma fase de The Secret of the Monkey Island na qual o protagonista do game, Guybrush Threepwood, deverá cruzar a área guardada pelos temíveis Poodles Piranhas:

Neste ponto no jogo, o jogador já se tornou um espadachim, mas não lhe é permitido combater os poodles [...] O jogador tem um pedaço de carne, mas isso por si só não é exatamente o necessário. Usar a carne com grog (um álcool potente) não funciona e, em vez disso, o jogador deve eventualmente perceber que precisa usar a carne com uma pequena flor que (espera-se) tenha encontrado durante a caminhada pela floresta para drogar a carne. Até deparar-se com esta solução, o jogador não pode progredir no game. (SULLIVAN; MATEAS; WARDRIP-FRUIN, 2009).

Muitas são as situações que exigem atenção dos desenvolvedores na criação de recursos que possam converter-se em elementos de boa jogabilidade ou, ao contrário, transformar-se em problemas a serem administrados e que nem sempre apresentam soluções fáceis aos seus criadores. Um caso emblemático, relatado em uma análise de mercado feita pelo pesquisador e criador de jogos Costikyan (2000) explica como a produção de jogos de mesmo gênero pode beber na fonte de seus antecessores com sabedoria, como aconteceu com a produção de EverQuest (1999), lançado após Ultima Online, e que apresentavam significativas mudanças, capazes de oferecer segurança aos seus jogadores. Costikyan (2000) chama a atenção para o fato de, ao contrário do game de Richard Garriot, EverQuest não permitir que um personagem matasse outro, impedindo, dessa forma, a subida de níveis de jogadores serial killers, como atesta, ao apontar as diferenças entre os games, a começar da análise das chacinas frequentes, promovidas em Ultima Online:

O resultado é o que Amy Jo Kim, na Wired, chamou de ‘um sentimento palpável de terror nas ruas.’ Você nunca pode confiar em ninguém, e a sua resposta normal, ao avistar um outro personagem do jogador, é fugir ou atacar. Apesar das melhores intenções de desenvolvedores de UO (Ultima Online), UO é uma guerra Hobbesiana de todos contra todos, um lembrete dos horrores da anarquia e ilegalidade, em forma de punição. Ela faz você apreciar policiais, ou, pelo menos, faz você perceber o valor de viver em uma sociedade que é policiada.

Em Everquest, pelo contrário, outros jogadores são fontes potenciais de informação e assistência, não alguém a ser temido. E você pode juntar-se com eles para compartilhar experiências, para matar coisas e, em conjunto, ir atrás de monstros muito mais poderosos do que você poderia sozinho. Você pode fazer o mesmo no Ultima Online, é claro, mas a natureza da visão de mundo de UO torna muito mais difícil de encontrar um grupo de confiança dos companheiros. (COSTIKYAN, 2000, p. 64).

As formas narrativas dependem, não raro, das condições técnicas e das mecânicas possíveis para a produção do game. Assim, a ideia de um mundo open world sandbox (mundo aberto do tipo caixa de areia, aquele que o jogador pode fazer experiências) parece muito mais crível na atualidade, em que sistemas de processamento e armazenamento de informação estão em seu patamar mais elevado desde o início do desenvolvimento de jogos digitais, do que no tempo de consoles anteriores, embora projetos como King’s Bounty e Shemnue tenham sido clássicos em suas épocas de lançamento, entre outros fatores, por apresentar mundos aparentemente abertos ou aleatórios.

King’s Bounty: esse jogo de 1990, desenvolvido inicialmente para PCs, contava com várias mecânicas que seriam reaproveitadas posteriormente na série Heroes os Might and Magic, como o sistema de combate por turnos, guerreiros, anões, dragões e criaturas – que podiam ser recrutadas para o combate, sair à jornada em busca de tesouros, estratégias de ação e inúmeras opções de táticas, entre outras singularidades incomuns nos jogos daquele período, como informa a análise online do blog especializado Retro Games Brasil que:

King´s Bounty foi pioneiro por uma série de inovações presentes no jogo. Era possível, por exemplo, escolher aleatoriamente as missões (alguém aí falou em Shemnue ou GTA?), e também era possível terminar o jogo sem precisar passar por todas as fases se, a qualquer momento, você conseguisse localizar o Cetro da Ordem, objeto central da trama da game. (RETRO GAMES BRASIL, 2008).

Alone in the Dark: Trabalhando com as mecânicas em favor da narrativa de suspense, o diretor criativo Raynal (2002) precisou contornar problemas técnicos de outra grandeza, no lançamento de Alone in the Dark, para a Infogrames (1992). Em seu relato, o produtor de games afirma que “estava fascinado pelo 3D em tempo real, que se tinha finalmente tornado viável graças aos novos demoníacos PCs de 33Mhz”. Apaixonado por filmes de terror, Raynal (2002) decidiu ambientar o novo projeto em uma morada sombria, onde o protagonista deveria viver momentos de pesadelo e tentar sair com vida.

O número total de polígonos que podiam ser utilizados para criar a personagem (cerca de 1.000 por imagem a 60 imagens por segundo) não permitia, no entanto, reproduzir um conjunto de personagens e ambientes suficientemente realistas para criar a atmosfera de ‘casa assombrada’, dos filmes de terror. Para ultrapassar esse problema, decidi que todo o poder de processamento de polígonos do computador seria dedicado a recriar os heróis e monstros em 3D. Para os fundos, existia apenas uma solução: utilizar bitmaps para modelar os fundos (o ambiente). Mas esses deveriam ser vistos em perspectiva, para encaixarem com os personagens 3D. (RAYNAL, 2002, p. 22).

Bejeweled: Um caso emblemático, ainda que não envolva questões narrativas, mas demonstra como o uso sagaz das mecânicas pode mudar o futuro de um projeto é o do jogo casual Bejeweled, criado pelos jovens designers do site PopCap, em 2000. Em linhas gerais, o jogo é um bubble breaker que propunha fusão de pedras preciosas em um painel, com destreza, para o acúmulo de pontos. Uma espécie de avô do Candy Crush. Os criadores haviam implementado um modo de jogo com cronômetro para testar o projeto, mas nada parecia empolgar colegas do meio e profissionais do mercado, a ponto de terem recebido um e-mail de um executivo do site Pogo, que dizia: “Essa coisa estúpida nem mesmo é um jogo!”. Ao escrito Goldberg (2011), os designers narraram a mudança que fez com que os entendessem o potencial do projeto:

A equipe precisava determinar se deviam incluir um modo cronometrado para acelerar o ritmo e apimentar a ação [...] Ele (Kapula) deu a Roma, sua mãe, um laptop para jogar e percebeu que ela gostava do jogo quando ele não era cronometrado [...] Rapidamente, Kapula reportou a seus parceiros: 'Quando ela joga no modo cronometrado, não gosta muito do jogo. Quando não está cronometrado, ela joga muito, dizendo que a relaxa. O modo cronometrado a deixa estressada.' (GOLDBERG, 2011, p. 251-252).

Não faltam histórias e exemplos que denotam a intrínseca relação entre as mecânicas dos games e os aspectos narratológicos possíveis de serem incorporados ao projeto, estabelecendo oportunidades e condições para diversão, vivência imersiva e experiências únicas para os jogadores ou, como proposto nas primeiras aulas, interator.

Versão 5.3 - Todos os Direitos reservados