Philip Michel Duarte. Geração Procedural de Cenários Orientada a Objetivos

Transcrição

1 Philip Michel Duarte Geração Procedural de Cenários Orientada a Objetivos Natal 2012

2 Philip Michel Duarte Geração Procedural de Cenários Orientada a Objetivos Dissertação apresentada ao Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte, para a obtenção de Título de Mestre em Ciências, na área de Sistemas e Informação. Orientador: Santos Selan Rodrigues dos Natal 2012

3 DUARTE, Philip M. Geração Procedural de Cenários Orientada a Objetivos 69 páginas Dissertação (Mestrado) - Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. 1. Geração procedural 2. Cenários 3. Jogos de plataforma/aventura I. Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Comissão Julgadora: Prof. Dr. Jauvane Cavalcanti de Oliveira Prof. Dr. Andre Maurício Cunha Campos Prof. Dr. Selan R. dos Santos (Orientador)

4 Agradecimentos Agradeço ao meu orientador, ao CNPq pela bolsa de estudos concedida e à minha família, essenciais para a realização deste trabalho.

5 "Lasciate ogne speranza, voi ch intrate". (Dante Alighieri)

6 Resumo Recentemente a indústria de jogos vem experimentando um aumento consistente nos custos de produção de jogos. Parte deste aumento é referente à tendência atual de se ter ambientes cada vez maiores, mais interativos e rejogáveis. Esta tendência se reflete num aumento das equipes e do tempo de desenvolvimento, o que torna o desenvolvimento de jogos um investimento de risco e pode reduzir a inovação na área. Como uma possível solução para este problema, a comunidade científica vem apostando na geração procedural de conteúdo e, mais especificamente, na geração procedural de cenários. Dada a grande diversidade e complexidade dos jogos, a maioria dos trabalhos opta por trabalhar em gêneros específicos, sendo os jogos de plataforma um dos gêneros mais estudados. Este trabalho propõe um método de geração de cenários para jogos de plataforma/aventura, um gênero mais complexo que jogos de plataforma clássicos e que até o momento não foi alvo de estudo de outros trabalhos. Dividimos a geração de cenários em etapas de planejamento e geração visual, responsáveis respectivamente por gerar proceduralmente uma representação compacta de cenário e determinar sua visualização. A etapa de planejamento se divide em game design e level design, e se utiliza de um processo orientado a objetivos para produzir como saída um conjunto de salas. A etapa de geração visual recebe um conjunto de salas e preenche seus interiores com partes adequadas de geometria previamente construídas. Palavras-chave: geração procedural de cenários, jogos de plataforma, jogos de plataforma/aventura.

7 Abstract The game industry has been experiencing a consistent increase in production costs of games lately. Part of this increase refers to the current trend of having bigger, more interactive and replayable environments. This trend translates to an increase in both team size and development time, which makes game development a even more risky investment and may reduce innovation in the area. As a possible solution to this problem, the scientific community is focusing on the generation of procedural content and, more specifically, on procedurally generated levels. Given the great diversity and complexity of games, most works choose to deal with a specific genre, platform games being one of the most studied. This work aims at proposing a procedural level generation method for platform/adventure games, a fairly more complex genre than most classic platformers which so far has not been the subject of study from other works. The level generation process was divided in two steps, planning and viusal generation, respectively responsible for generating a compact representation of the level and determining its view. The planning stage was divided in game design and level design, and uses a goaloriented process to output a set of rooms. The visual generation step receives a set of rooms and fills its interior with the appropriate parts of previously authored geometry. Keywords: procedural level generation, platform games, platform/adventure

8 Lista de Figuras 2.1 Gêneros de jogos Exemplos clássicos de RPGs Exemplos de jogos de ação/aventura Exemplos de áreas em Super Metroid, da Nintento. Na Figura 2.4a, uma área com características de floresta. Na Figura 2.4b, uma área de atividade vulcânica Exemplo de gameplay em Limbo Exemplo de gameplay em Insanely Twisted Shadow Planet Exemplo de nível em Rogue Exemplo de Spelunky Exemplo de casamento de âncoras na técnica de Occupancy-Regulated Extension Exemplo de cenário gerado pelo método de Laskov Células gerando estruturas não-lineares Detalhes da conversão de grupos rítmicos em geometria Exemplos de gramáticas de grafos Situação simples que um algoritmo de geração procedural de cenários deve ser capaz de produzir Exemplo da mecânica de obstáculos Segundo exemplo da mecânica de obstáculos Exemplo de sala Etapas do processo de geração procedural de cenários proposto Exemplo de um conjunto de salas geradas pelo algoritmo Sala sendo representada por uma grade de células

9 4.2 Exemplo de cenário real gerado com chunks Exemplo de cenário real gerado com chunks Exemplos de cenários gerados com ações e algoritmos Exemplo da ação de diferentes algoritmos escultores Exemplo de cenário gerado com tiles e ações Exemplo de cenário gerado com tiles para dois objetivos e apenas ações de pular e andar Exemplo de modificação inváluda Exemplo de pincel Exemplo de brecha no algoritmo de grupos intangíveis Brecha no algoritmo de verificação de colisão por tempos Exemplo de sala vista como grade de células Exemplo de pontos de conexão marcando as células de transição de nível Marcando intenções nos pontos de conexão e portas Exemplo de construção dos fluxos de intenção Exemplo de marcação dos intervalos de obstáculos Definição de áreas neutras, exibidas em hachura Exemplo de geração visual usando intenções Mapa de chunks usado na geração dos cenários da Figura Mapa de chunks usado na geração dos cenários das figuras 5.4 e Exemplos de geração de cenário usando intenções e chunks Exemplos de geração de cenário usando intenções e chunks Exemplos de geração de cenário usando intenções e chunks

10 Lista de Algorítmos Gera game design sob a forma de uma lista de objetivos Gera level design para todos os objetivos do game design Gera um caminho de salas para um objetivo

11 Sumário 1 Introdução Geração procedural de conteúdo Jogos de plataforma Jogos de plataforma/aventura Objetivo do trabalho Descrição do documento Referencial Teórico Online versus Offline Necessário versus Opcional Sementes Aleatórias versus Vetores de Parâmetros Construtivo versus Tentativo Gêneros de Jogos Comumente Estudados em PCG RPGs Ação/Aventura Plataforma Plataforma/Aventura Trabalhos Relacionados Planejando Cenários Proceduralmente Visão Geral Definição de Requisitos Planejamento Orientado a Objetivos Gerando Game Design Proceduralmente Gerando Level Design Proceduralmente

12 4 Gerando Visuais Proceduralmente Usando Chunks Mapeando Chunks em Salas Escolhendo Chunks Problemas no Uso de Chunks Usando Ações e algoritmos Planejando Salas com Ações Gerando Visuais com algoritmos Problemas com o Uso de Ações e algoritmos Usando Ações e Tiles Esculpindo Geometria Problemas com o Uso de Ações e Tiles Usando Intenções Planejando Salas com Intenções Resultados 57 6 Conclusão e Trabalhos Futuros 65 Referências Bibliográficas 67

13 Capítulo 1 Introdução A indústria de jogos percorreu um longo caminho nas últimas três décadas, evoluindo de pequenos experimentos liderados por programadores em seu tempo livre para um negócio multibilionário. Apesar do sucesso comercial desfrutado pela indústria, desenvolver jogos ainda é um investimento de risco, pois os investimentos na produção de jogos de última geração giram em torno de U$15 a U$30 milhões [8]. Além disso, para Guillemot, CEO da Ubisoft, os custos de produção podem crescer até U$60 milhões já na próxima geração de consoles [11]. Com custos desta magnitude, as empresas naturalmente tendem a priorizar ideias consagradas, o que aos poucos limita a capacidade de inovação da indústria. O crescimento dos custos de produção está diretamente relacionado à complexidade dos jogos da atual geração. Os custos na área tecnológica ainda podem ser mitigados por meio do licensiamento de tecnologia de terceiros, como por exemplo middlewares específicos para gráficos, física, animação e inteligência artificial [9]. Contudo, não há equivalente disto para as equipes de design/arte; todo o game content aspectos de um jogo que afetam jogabilidade e que não estão relacionados ao comportamento de personágens não-jogáveis (em inglês, Non-Player Character, NPC), como terrenos, mapas, estórias, diálogos, missões e itens [23] deve ser produzido para cada projeto individualmente, o que torna sua produção manual bastante custosa [1].

14 Capítulo 1. Introdução Geração procedural de conteúdo Uma possível solução para o poblema do custo proibitivo de criação manual de game content pode ser a geração procedural de conteúdo. Segundo Togelius et al[23], geração procedural de conteúdo (em inglês, Procedural Content Generation, PCG) refere-se à criação de game content por meios algorítmicos. Além da redução de custos, o uso de técnicas de PCG apresenta uma série de outros benefícios, como por exemplo: redução no consumo de memória, devido à forma comprimida de armazenamento; aumento do valor de replay, devido à variabilidade introduzia pelo uso de PCG cada vez que um mesmo nível é jogado; adaptação automática de cenários para regular dificuldade em tempo real [12][18]; e servir como fonte de inspiração e ferramenta de auxílio ao design, para aumentar a produtividade de designers humanos. Uma das formas de PCG mais estudadas é a geração automática de cenários, como veremos na Seção 2.6. Design de cenários é uma atividade dependente do gênero de jogo, uma vez que os cenários devem propor desafios que explorem as regras do jogo de modo interativo. Por este motivo, o estudo de técnicas de geração procedural de cenários também está relacionado ao gênero de jogo [20]. 1.2 Jogos de plataforma Dentre os gêneros de jogos existentes, o de plataforma é um dos que mais recebeu atenção da comunidade científica nos últimos anos. Segundo Gregory, um jogo de plataforma clássico pode ser definido como um jogo de ação em terceira-pessoa, centrado no personagem, e que tem como principal mecânica de gameplay o trânsito entre plataformas por meio da ação de pulo [9]. Como exemplos de jogos clássicos de plataforma, o autor cita Space Panic, Donkey Kong, Pitfall! e Super Mario Brothers. Uma característica marcante dos jogos de plataforma é o conceito de linearidade. Linearidade de um jogo diz respeito ao estilo de navegação empregado. Um jogo é dito linear se, a todo instante, o jogador tem no máximo um caminho disponível para seguir. É o caso dos jogos de plataforma clássicos, em que tipicamente a movimentação ocorre apenas no eixo horizontal, da esquerda para a

15 Jogos de plataforma/aventura direita. Apesar do relativo sucesso obtido pela comunidade científica em gerar cenários para jogos de plataforma clássicos, a simplicidade inerente ao gênero de plataforma clássico impede a aplicação direta destas pesquisas na indústria. A grande maioria dos jogos de plataforma recentes incorpora em seu gameplay uma série de novos elementos, como por exemplo: passágens secretas dentro dos cenários; ações como empurrar, atirar ou mergulhar; botões, gatilhos, alavancas e elementos encadeadores de eventos; dinâmica de corpos rígidos, e novas estratégias de gameplay associadas à física. Esse quadro alterou a expectativa dos jogadores quanto ao gameplay de jogos de plataforma ao longo dos anos, e para que geração procedural de conteúdo possa ser efetivamnete usado na indústria, é preciso não se limitar à definição clássica dos gêneros e se desenvolver métodos que levem em conta essa complexidade adicional. 1.3 Jogos de plataforma/aventura Existe uma classe de jogos derivada dos jogos de plataforma que apresenta grande potencial com relação ao uso de PCG e que poderia se beneficiar largamente de um melhor valor de replay. Os maiores expoentes deste gênero são Metroid [16] e Castlevania [13], o que motivou sua denominação informal de Metroidvania [17]. Por falta de consenso da comunidade científica em se determinar uma taxonomia precisa para os gêneros de jogos, usaremos o termo plataforma/aventura para descrever este gênero. Jogos de plataforma/aventura estão na interseção entre jogos de tiro, plataforma e aventura. Adiciona-se ao gameplay padrão de jogos de plataforma a resolução de puzzles e a exploração do ambiente, típicas do gênero aventura, além da mecânica básica de combate dos jogos de tiro. O resultado é um tipo de jogo ambientado em vastos cenários, e cuja navegação, feita em ambos os eixos horizontal e vertical, assume características não-lineares decidir o destino de navegação é parte integrante do gameplay. O jogador começa com um conjunto limitado de habilidades, explora o cenário gradativamente, enfrenta inimigos, resolve puzzles e adquire novas habilidades. Cada nova habilidade permite ao jogador explorar áreas anteriormente inacessíveis do cenário, e o jogador fre-

16 Capítulo 1. Introdução 4 quentemente precisa retornar a áreas previamente visitadas para aprofundar a exploração. A interação das habilidades do jogador com o cenário, como meio de possibilitar a exploração e a resolução de puzzles, é a ferramenta do gameplay dos jogos de plataforma/aventura. Uma descrição mais detalhada deste gênero pode ser encontrada na Seção Objetivo do trabalho Este trabalho propõe um método de geração de cenários para jogos de platforma/aventura. A contribuição deste trabalho reside no fato de que, apesar dos nossos esforços, não foi possível encontrar um outro método de geração procedural de cenários que tratasse deste gênero. O método proposto recebe como entrada um conjunto de objetivos e habilidades que o jogador pode obter durante o jogo e a partir disso, gera automaticamente conteúdo na forma de gameplay e geometria para o cenário, garantindo a corretude destes conteúdos. 1.5 Descrição do documento O Capítulo 2 contém o referencial teórico desta pesquisa. Na Seção??, fazemos uma breve revisão de conceitos essenciais da área de PCG. O leitor que já estiver familiarizado com esta nomeclatura pode seguir adiante para a Seção 2.6, em que revisamos algumas das principais pesquisas desenvolvidas na área, especialmente aquelas que mais se assemelham a este trabalho. O Capítulo 3 descreve a etapa de planejamento de cenários, definindo em alto nível um conjunto de tarefas para a obtenção do objetivo proposto. Com base no planejamento delineado no Capítulo 3, uma série de abordagens de implementação distintas foram exploradas para gerar visuais que se adequem ao planejamento, e estas experiências são relatadas no Capítulo 4. Por fim, os resultados da pesquisa são apresentados e analisados no Capítulo 5.

17 Capítulo 2 Referencial Teórico Nesta seção, faz-se uma revisão de alguns conceitos básicos da área de jogos, fundamentais para o entendimento do restante deste trabalho. Togelius et al define em [23] um conjunto de distinções a se levar em conta ao analizar técnicas de PCG, discutidas do Item 2.1 ao 2.4. No Item 2.5, discutimos as características de alguns gêneros de jogos comumente estudados em PCG. 2.1 Online versus Offline A primeira distinção a ser feita diz respeito ao momento em que a geração de conteúdo ocorre: se online, em tempo de execução do jogo; ou se offline, durante o desenvolvimento do jogo. Um exemplo de geração online seria quando um jogador entra numa porta em um prédio e o interior da sala adentrada é instantaneamente gerado. Para o caso offline, uma ferramenta de suporte ao design de ambientes sugere layouts de interiores, que são posteriormente editados e aperfeiçoados por um designer humano. Estratégias mistas também são possíveis, com conteúdo gerado tanto online quanto offline. Diablo [2] faz uso desta abordagem de forma eficiente, com ambientes gerados offline em regiões reservadas para eventos-chave do jogo e ambientes gerados online para o restante do mundo.

18 Capítulo 2. Referencial Teórico Necessário versus Opcional Outra distinção importante relacionada ao conteúdo gerado diz respeito à obrigatoriedade de se interagir com o conteúdo gerado. Conteúdo necessário requer interação obrigatória do jogador e.g. calabouços que devem ser trafegados, inimigos que devem ser destruídos, regras específicas que devem ser cumpridas, dentre outros ao passo que conteúdo opcional pode ser ignorado pelo jogador sem problemas para o progresso no jogo. A principal diferença que motiva a classificação é o fato de que conteúdo necessário sempre deve estar correto; não é aceitável para um jogo gerar puzzles sem solução se sua travessia for obrigatória. Por outro lado, é perfeitamente aceitável que um algoritmo gere obstáculos eventualmente intransponíves se sua transposição não for essencial para o progresso no jogo. 2.3 Sementes Aleatórias versus Vetores de Parâmetros Algoritmos de geração de conteúdo podem ser classificados com relação ao seu nível de parametrização. Todas as técnicas de PCG geram conteúdo expandido, no sentido de que partem de uma representação simples e geram/combinam/criam versões mais elaboradas; elas diferem, contudo, quanto à forma de representação inicial do conteúdo. Em um extremo, um algoritmo pode requerir apenas uma semente para o seu gerador de números aleatórios como entrada. No outro extremo, pode-se ter como entrada um vetor multidimensional de parâmetros que especifiquem propriedades do conteúdo gerado. 2.4 Construtivo versus Tentativo Uma distinção final pode ser feita entre os algoritmos ditos construtivos e os tentativos. Um algoritmo construtivo gera conteúdo apenas uma vez, e por isso deve garantir a corretude do conteúdo gerado. Um algoritmo tentativo, por outro lado, incorpora mecanismos de geração e de

19 Gêneros de Jogos Comumente Estudados em PCG teste. A saída do processo de geração de conteúdo é submetida a um mecanismo de teste, que deve tipicamente satisfazer um critério referente ao jogo (isto é, há uma saída no labirinto, ou há ao menos um caminho que conecta todos os pontos de interesse?). Se o teste falha, o conteúdo é descartado e gerado novamente. O processo continua até que se atinja uma métrica pré-estabelecida. 2.5 Gêneros de Jogos Comumente Estudados em PCG O estudo de técnicas de geração procedural de conteúdo para jogos dificilmente poderia ser conduzido de maneira genérica, objetivando-se encontrar um único procedimento que gerasse qualquer tipo de conteúdo, para qualquer tipo de jogo. Isto se deve às diversas particularidades e restrições pertinentes a cada jogo em particular; não se tem notícias de um modelo capaz de expressar o comportamento de elementos tão diversos e unificar sua representação. Faz-se necessário, ao menos por enquanto, buscar características em comum a diversos jogos e agrupálos em gêneros, mais fáceis de analisar, modelar e representar. A Figura 2.1 apresenta três gêneros básicos e algumas de suas possíves combinações, que foram alvo ou estão relacionados a trabalhos de PCG. Figura 2.1: Gêneros e subgêneros de jogos. A proximidade dos subgêneros aos círculos indica seu grau de pertinência a um determinado gênero.

20 Capítulo 2. Referencial Teórico RPGs Um dos primeiros gêneros de jogos a surgir foi o jogo de interpretação de personagens (em inglês, Role-Playing Game, RPG). RPGs são jogos originalmente derivados de Dungeons & Dragons, e têm como principal característica a evolução das habilidades do personagem, tipicamente por meio de aquisição de experiência ou equipamentos. Apesar de pequenas diferenças entre si, o gameplay dos RPGs é basicamente composto pelos mesmos elementos: exploração e combate. O jogador geralmente controla um grupo de personagens, mas também são comuns RPGs em que o jogador controla apenas um personagem. Em ambos os casos, o combate pode ser baseado em turnos ou de tempo real. RPGs focados no controle de grupos de personagens frequentemente possuem um forte viés narrativo, em que o jogador experiencia um enredo pré-determinado de eventos; como exemplo desta classe, muito popular nas culturas orientais, podemos citar as séries Final Fantasy [6] e Dragon Quest [5]. RPGs focados em apenas um persoangem, mais comuns no ocidente, proporcionam um enredo não-linear e priorizam o combate, geralmente em tempo real; exemplos desta classe são Diablo [2], Torchlight [7] e Dragon Age dage. A Figura 2.2 contém exemplos de ambos os tipos de RPGs. A exploração em RPGs se dá de forma simples, sendo necessário ao jogador navegar pelos cenários, interagir com NPCs e, no máximo, seguir direções. Os cenários, neste caso, têm a função de conferir a ambientação do jogo em momentos chave do enredo, mas possuem pouca ou nenhuma interação com o jogador. Esta simplicidade é o motivo pelo qual os RPGs foram os primeiros jogos a aplicar com sucesso técnicnas de PCG na geração de cenários Ação/Aventura Outro gênero que pode ser objeto de estudo de PCG é o de ação/aventura. Jogos de ação/aventura combinam desafios de destreza e combate, características de jogos de ação, às atividades de exploração e resolução de puzzles dos jogos de aventura. Jogos de ação/aventura tipicamente são estruturados ao redor de seu enredo. O jogador é apresentado a uma sucessão de enredos menores (arcos), por meio dos quais o jogador é introduzido a novos recursos, na forma de habilidades ou itens; é treinado a fazer uso destes recursos de diversas maneiras, tanto para

21 Gêneros de Jogos Comumente Estudados em PCG (a) Diablo II (b) Final Fantasy VII Figura 2.2: Exemplos clássicos de RPGs. Na Figura 2.2a, um exemplo de RPG ocidental. O sistema de câmera, os controles de interface e o próprio cenário indicam um gameplay voltado para o combate. Na Figura 2.2b, um exemplo de RPG oriental. O uso de cenários pré-renderizados, completamente estáticos e observados por pontos de vista fixos, indica um gameplay mais focado em narrativa. combate quanto para a resolução de puzzles; e é testado quanto à sua proficiência em tais recursos, tipicamente pelo inimigo final de um arco. A sucessão de arcos prepara o jogador para um confronto final, coincidente com o clímax do enredo, em que o jogador deve fazer uso de todas as habilidades, itens e técnicas adquiridos durante o jogo. Diferentemente dos RPGs, em jogos de ação/aventura os cenários participam ativamente do gameplay, pois são responsáveis pela grande maioria dos puzzles do jogo. Puzzles, os principais elementos de gameplay, são compostos pelas seguintes atividades: desafios temporais, em que é preciso completar uma tarefa antes do tempo limite, como atravessar um portão antes que este se feche; desafios cognitivos, em que é preciso se resolver problemas de raciocínio, como por exemplo organizar um conjunto de caixas para criar uma ponte ou misturar reagentes químicos corretamente para produzir uma vacina; desafios de destreza, como acertar uma flecha num objeto distante ou esquivar-se de bolas de fogo; desafios de busca, como por exemplo encontrar a chave de um baú ou encontrar um determinado NPC escondido na cidade; e desafios de combate, em que é preciso vencer um conjunto de inimigos. Além disso, é comum encontrar combinações

22 Capítulo 2. Referencial Teórico 10 de desafios, como por exemplo ter de derrotar um inimigo para obter a chave do baú ou ter de montar a ponte e atravessá-la antes do portão se fechar. A Figua 2.3 mostra alguns exemplos consagrados de jogos de ação/aventura. (a) The Legend Of Zelda - The Wind Waker (b) Resident Evil I Figura 2.3: Exemplos de jogos de ação/aventura. Na Figura 2.3a, um exemplo de jogo que foca em desafios de destreza, tempo e busca. Na Figura 2.3b, um Survival Horror, subgênero de ação/aventura, exemplo de jogo que foca em desafios cognitivos e de busca Plataforma Jogos de plataforma, uma categoria dos jogos de ação, também vem recebendo atenção da comunidade PCG nos últimos anos. Jogos desde gênero se tornam especialmente atraentes para a comunidade científica devido à simplicidade de suas regras e ao seu elevado nível de interação com o cenário. Smith, Cha e Whitehead [20] resumem os principais elementos de gameplay dos jogos de plataforma: Plataformas são quaiquer objetos que o jogador possa andar sobre ou pular para atravessar o cenário. Obstáculos são objetos capazes de imprimir dano ao jogador.lacunas entre plataformas também são consideradas obstáculos, apesar de não serem objetos explícitos do cenário.

23 Gêneros de Jogos Comumente Estudados em PCG Auxílios de Movimento são todos os objetos que ajudam o jogador a atravessar o cenário, tais como molas, trampolins, escadas ou cordas. Itens Colecionáveis são os objetos que conferem uma recompensa ao jogador caso sejam capturados, como moedas, corações ou expansões. Gatilhos são objedos do cenário que, de alguma maneira, alteram o estado do cenário. Exemplos de gatilhos incluem interruptores que transformam blocos em moedas, botões que ativam plataformas móveis ou objetos que alterem o comportamento do avatar Plataforma/Aventura O gênero abordado neste trabalho pode ser descrito como uma combinação entre jogos de plataforma e ação/aventura. Usaremos no decorrer deste trabalho o termo plataforma/aventura para descrever este gênero. Mais especificamente, os jogos de plataforma/aventura mapeiam conceitos de ação/aventura para um gameplay de plataforma. A seguir, uma breve descrição de suas principais características. Jogos de plataforma/aventura tipicamente estão estruturados ao redor de um modelo sequencial de objetivos, assim como os jogos de ação/aventura. Os objetivos, que frequentemente envolvem derrotar um inimigo-chefe e adquirir uma nova habilidade ou item, são alocados a áreas. Áreas podem ser descritas como sub-regições do cenário que possuem propriedades semelhantes, tais como: visuais, sons e efeitos sonoros, habitantes (inimigos ou NPCs) e idiomas (conjunto de movimentos, habilidades e ações com maior probabilidade de serem requisitados em uma área). O dever de um designer, humano ou computadorizado, é combinar de forma harmoniosa estes elementos de modo a criar uma atmosfera facilmente reconhecível e distinta. Além disso, é comum ocorrer que áreas introduzam idiomas específicos com o intuito de preparar o jogador para um desafio posterior. A Figura 2.4 possui exemplos de áreas. Objetivos devem ser completados numa ordem específica, condição tipicamente garantida pelo encadeiamento adequado de objetivos e construção adequada de cenários. Um exemplo disto é dado na Figura 2.4: o jogador pode

24 Capítulo 2. Referencial Teórico 12 (a) Brinstar (b) Norfair Figura 2.4: Exemplos de áreas em Super Metroid, da Nintento. Na Figura 2.4a, uma área com características de floresta. Na Figura 2.4b, uma área de atividade vulcânica. explorar a área da Figura 2.4b somente após adquirir a habilidade de resistir a temperaturas extremas, localizada na área da Figura 2.4a (caso tente fazê-lo antes, o jogador morre em questão de segundos). Jogos de plataforma/aventura via de regra possuem muitos objetivos, o que inviabiliza o método tradicional de navegação de jogos de plataforma em apenas uma direção: como pode ser visto na Figura 2.4, o jogador tem liberdade para se deslocar em ambos os eixos horizontal e vertical. Esta condição faz com que a escolha do destino de navegação também faça parte do gameplay, dada a nãolinearidade dos cenários: sempre que o jogador adquire uma nova habilidade, deve revisitar (backtracking) os locais cuja ausência de tal habilidade impediu o progresso da exploração. Puzzles em jogos de plataforma/aventura seguem a mesma estrutura dos jogos de ação/aventura, isto é, são conjuntos de desafios fortemente dependentes dos elementos de gameplay do jogo em questão. Apesar disso, a necessidade de se fazer backtracking impõe algumas restrições à criação de puzzles. A primeira das restrições diz respeito às direções de trânsito de um puzzle. Um mesmo local pode ter de ser visitado várias vezes, e por direções diferentes. Caso o designer deseje instalar um puzzle em um local assim, deve garantir que

25 Trabalhos Relacionados tal puzzle seja solucionável por quaisquer das direções que o jogador possa vir. A segunda restrição diz respeito ao ciclo de vida de puzzles. Existem puzzles que se reiniciam toda vez que precisam ser atravessados (permanentes); um exemplo seria uma porta trancada, que apenas abre quando todos os inimigos da sala são derrotados (provido que os inimigos ressuscitem sempre que o jogador entre na sala). Outra classe de puzzles mantém seu estado após sua resolução (transientes); um exemplo seria um elevador que funciona ininterruptamente, uma vez restaurada a fonte de energia. Este tipo de puzzle pode representar problemas caso seja, em seu estado final, intransponível. Um exemplo seria um elevador que, após ter a energia restaurada, pode funcionar apenas uma vez; o jogador ficará impedido de prosseguir no futuro se, após tomar o elevador e seguir caminho, acabe por retornar a esta mesma posição, pois o elevador estará imobilizado num andar superior. Devido aos problemas que podem causar, puzzles transientes não são comuns em jogos de plataforma/aventura. Jogos mais antigos, como Super Metroid e Castlevania - Symphony Of The Night, mais centrados em exploração e combate, têm em sua maioria puzzles relacionados à exploração, o que pode levar o cenário a se tornar estático; na maior parte do tempo, o jogador está procurando usar habilidades que liberem algum caminho escondido. Contudo, jogos modernos já foram capazes de integrar o gameplay de exploração a puzzles altamente dinâmicos, que combinam elementos do cenário com o uso de habilidades especiais do jogador, como mostram as figuras 2.5 e Trabalhos Relacionados Como visto na Seção 2, a mecânica dos RPGs frequentemente requer pouca interação entre o cenário e o jogador, que geralmente precisa apenas navegar pelo cenário. Como consequência, RPGs impõem poucas restrições aos cenários, o que pode ter sido o motivo pelo qual RPGs foram os primeiros jogos a apresentar técnicas de PCG, ainda em meados dos anos 80. Rogue [24], precussor de sucessos como Diablo [2] e Torchlight [7], foi um dos primeiros a apresentar este recurso; um antigo jogo de caracteres baseado em Dungeons & Dragons [10] cujos cenários são gerados proceduralmente toda vez que se adentra em um novo nível. Em

26 Capítulo 2. Referencial Teórico 14 Figura 2.5: Exemplo de gameplay em Limbo. Rogue, o objetivo é atravessar todos os níveis de cenário e obter um item específico no fim do jogo. Os cenários possuem um formato fixa, como salas organizadas em uma grade 3x3, de modo que o algoritmo de geração não requer uma etapa de planejamento; o algoritmo apenas conecta as salas aleatoriamente por meio de corredores, criando a geometria do cenário de forma algorítmica, como mostrado na Figura 2.7. Para se tratar de gêneros mais complexos e que envolvam uma maior interação do jogador com o cenário, no entanto, outras estratégias são necessárias. Um gênero comumente estudado é o dos jogos de plataforma. Uma possível abordagem para se gerar cenários é fazer uso de algoritmos especialistas na construção de determinados tipos de geometria. Infinite Mario é um exemplo de jogo de plataforma que faz uso desta abordagem [19]. O método usado constroi iterativamente seções de tamanho variável. Cada seção é construída a partir de um algoritmo simples, que modela um único padrão de terreno. Os possíveis padrões são: straight, hill, jumps, tubes e cannons. Esta técnica pode apresentar problemas de variedade, pois o número limitado de padrões faz com que um jogador experiente possa identificar e antecipar obstáculos do jogo. Além disso, cada padrão atua em uma região específica, o que limita seriamente o surgimento de construções emergentes, uma característica desejável em jogos do gênero. Entende-se por construção emergente uma geometria do cenário

27 Trabalhos Relacionados Figura 2.6: Exemplo de gameplay em Insanely Twisted Shadow Planet. Os pistões móves são um exemplo altamente dinâmico de puzzle permanente. não explicitamente programada, surgindo como consequência da combinação de múltiplos passos do processo de geração. Outro trabalho a fazer uso de geração algorítmica de geometria é o de Sorenson e Pasquier [22]. Os autores definem uma função de challange para jogos de plataforma, segundo a qual a dificuldade de um pulo está relacionada com a distância entre as plataformas e o tamanho da plataforma de destino. A função de challange é usada para definir uma função de diversão, segundo a qual a diversão que um jogador experimenta aumenta com a proximidade entre a challange de uma situação e a habilidade do jogador. A função de diversão é então usada em um algortimo genético, que gera geometria ao maximizar o seu valor. Apesar da capacidade de se gerar geometria com base em um conceito intuitivo como diversão ser promissora, a escolha da função de challange pode não ser trivial ao se considerar outros tipos de jogos. Além disso, como jogos de plataforma em geral possuem cenários simples e lineares, é difícil se estimar se algoritmos genéticos seriam adequados para geração de geometrias mais complexas. Outra abordagem de geração de geometria comumente utilizada explora o uso de chunks blocos de geometria previamente construídos, tipicamente agrupados em uma biblioteca. Spelunky é um jogo de plataforma que faz uso de chunks na geração de geometria [25]. Em Spelunky, o cenário possui uma estrutura fixa,

28 Capítulo 2. Referencial Teórico 16 Figura 2.7: Exemplo de nível em Rogue. O cenário é dividido em uma grade 3x3 de salas, que são conectadas aleatoriamente. com 16 salas dispostas em uma grade regular. Os chunks, nesse caso, funcionam como fôrmas para as próprias salas. Após a geração de geometria, o jogo aplica uma etapa de pós-processamento baseada em regras do tipo se-então e adiciona armadilhas ao cenário. Apesar de os cenários resultantes apresentarem pouca variedade em termos de geometria, devido ao uso de um único chunk para cada sala, o foco do jogo é nas armadilhas, como mostrado na Figura 2.8. Figura 2.8: Exemplo de Spelunky. Visando atacar o problema da falta de variedade, Mawhorter e Mateas introduzem em [15] a noção de Occupancy-Regulated Extension para geração procedural de cenários. A técnica também constroi cenários combinando chunks

29 Trabalhos Relacionados de uma biblioteca, mas difere de Spelunky por não associar chunks a elementos específicos do cenário, podendo ser associados livremente. Para isso, os chunks contém metainformações (âncoras) que determinam sua conectividade com outros chunks. A técnica foi aplicada a um jogo de plataforma semelhante ao Infinite Mario [19]. Por fazer uso de uma biblioteca pré-configurada, esta abordagem possui a vantagem de aproveitar a criatividade de designers humanos. Os autores ainda detectaram o aparecimento de construções emergentes nos cenários gerados. Entre os problemas, destaca-se a não-garantia de jogabilidade, isto é, não há garantia de que os cenários gerados serão solucionáveis. Além disso, o mecanismo de âncoras oferece pouco ou nenhum suporte para geração de cenários mais complexos e não-lineares. A Figura 2.9 mostra como ocorre o casamento de âncoras nos chunks para se criar os cenários. Figura 2.9: Exemplo de casamento de âncoras na técnica de Occupancy-Regulated Extension. Outro exemplo de método a fazer uso de chunks é o trabalho de Laskov [14], que trata a geração de cenários como uma sequência de ações tomadas por um agente e usa aprendizado reforçado para criar uma política de construção de cenários. O trabalho usa 9 chunks de tamanho fixo como ações, e os posiciona

30 Capítulo 2. Referencial Teórico 18 da esquerda para a direita em diferentes alturas. A corretude dos cenários é assegurada por meio de um teste de alcançabilidade, caracterizando um método tentativo. Como o domínio de geração deste traabalho inclui apenas um tipo de obstáculo, um tipo de inimigo e um tipo de tesouro, é difícil avaliar a generalidade da abordagem baseada em aprendizado, ou mesmo sua aplicabilidade em outros domínios/gêneros, mas a idéia de encarar a construção de cenários como uma sequência de decisões é interessante. Um exemplo de cenário gerado por este método é dado na Figura Figura 2.10: Exemplo de cenário gerado pelo método de Laskov. Uma outra forma de se abordar o problema da geração de cenários é criar modelos para representar os elementos que fazem parte do gameplay. O trabalho de Compton e Mateas [3] segue essa linha, propondo um modelo composto dos seguintes elementos: componentes, padrões e células. Componentes são as unidades básicas que compõem cenários, tais como plataformas, vinhas, espinhos, tesouros e outros; padrões são um mecanismo para agrupar componentes individuais em sequências mais longas, mantendo uma movimentação rítmica; e células são compostas de conjuntos lineares de padrões, e determinam formas não-lineares de estruturação de gameplay, como é visto na Figura O modelo funciona parcialmente como uma gramática livre de contexto, e a tarefa de geração de geometria é vista como a geração de uma palavra em uma gramática, com o cenário como símbolo de início, padrões e células como não terminais e componentes como terminais. O cenário começa com uma célula, que pode ser dividida em várias outras células. Cada célula gera um conjunto de padrões ou ritmos, que são posteriormente transformados em componentes do cenário. Apesar de garantir a corretude do resultado e ser um processo intuitivo, dada sua natureza recursiva, o método apresenta problemas de variedade; como há um número finito de padrões de células, essas estruturas podem se tornar repetitivas.

31 Trabalhos Relacionados Além disso, o mecanismo de células peca pela falta de controle que oferece: o uso de uma célula como a hub, por exemplo, pode levar à criação de geometria sem propósito dentro do design do cenário. Figura 2.11: Células gerando estruturas não-lineares. Um trabalho semelhante é apresentado por Smith et al, com a diferença de não contemplar células (e consequentemente, cenários não-lineares) e de separar a etapa de geração de ritmos da geração de geometria [21]. Ritmos seriam um conjunto de ações do jogador, executadas durante um determinado tempo e com uma dada frequência. De certa maneira, são equivalentes aos padrões definidos por Compton e Mateas, pois um conjunto de ações do jogador pode ser mapeado para um conjunto de componentes do cenário; contudo, como pode haver mais de um mapeamento de ações para componentes de cenário, o uso de ações confere mais variedade ao método. Grupos rítmicos são criados a partir dos verbos andar e pular, variando-se as durações e frequências, e ligados entre si por plataformas de descanso. Uma vez completa a etapa de geração de ritmos, a etapa de geração de geometria é responsável por criar possíves interpretações para os conjuntos de ritmos anteriormente gerados; uma gramática como a exibida na Figura 2.12a é usada na conversão entre grupos rítmicos e componentes de cenário. A Figura 2.12b mostra um exemplo de conversão de ritmo em geometria. Esta técnica posteriormente foi usada com sucesso para regular dinâmicamente o nível de dificuldade de um jogo, ajustando a geração de cenário a dados capturados em tempo de execução [12]. Este trabalho introduz ideias interessantes, como a separação entre planejamento e geração de geometria, além do uso de ações para representar o planejamento. Contudo, o uso de uma gramática para a geração de

32 Capítulo 2. Referencial Teórico 20 geometria dificulta a aplicação desta técnica em ambientes não-lineares, devido ao poder de expressão insuficiente de gramáticas livres de contexto. (a) Gramática de geração de geome-(btria. Conversão de ritmo em geometria. Figura 2.12: Detalhes da conversão de grupos rítmicos em geometria. Na Figura 2.12a, estados do jogador derivados das ações dos ritmos gerados são nãoterminais nesta gramática. A Figura 2.12b mostra quatro possíveis interpretações do ritmo exibido, demonstrando a maior variedade advinda da separação entre planejamento de ritmos e geração de geometria. Ciente das limitações das gramáticas livres de contexto, Dormans propõe o uso de gramáticas de grafos e de formas para a geração procedural de cenários em jogos de ação/aventura [4]. Dormans divide a geração de cenário em duas etapas, uma de planejamento de missões e uma de geração de espaços (análogos a geometria). Missões são responsáveis pelo componente de aventura dos cenários, adicionando elementos como chaves, portas trancadas, itens ou desafios; missões são geradas por gramáticas de grafo, um tipo de gramática que produz nós e arestas e os mapeia respectivamente a fragmentos de missões e conexões físicas, como pode ser visto na Figura 2.13a. Missões são mapeadas em espaços, que definem o layout da geometria; espaços são produzidos por gramáticas de forma, cujas regras indicam que tipos de símbolos podem ser trocados por que tipos de geometria, como visto nas figura 2.13b e 2.13c. O trabalho de dormans é inovador no sentido de tratar da geração de cenários para jogos de ação/aventura, tipicamente mais complexos que jogos de platafomra; apesar disso, gramáticas de forma apenas definem layouts de geometria,

33 Trabalhos Relacionados e o autor não menciona uma forma de convertê-los em geometria real. Além disso, o método lida apenas com puzzles simples, como portas trancadas e chaves escondidas, e não está claro se gramáticas de grafos podem ser adaptadas para gerar puzzles mais complexos, essenciais em jogos de ação/aventura. (a) Missão gerada por gramática de grafos. (b) Regras da gramática de forma. (c) Exemplo de produção de geometria. Figura 2.13: Exemplos de gramáticas de grafo (Figura 2.13a) e forma (figuras 2.13b e 2.13c). Com base na revisão dos trabalhos mencionados, as principais conclusões que pudemos tirar foram as seguintes: Gêneros de jogos mais complexos que jogos de RGP e plataformas possivelmente necessitam de uma etapa de planejamento, de modo a assegurar suas restrições.

34 Capítulo 2. Referencial Teórico 22 Métodos de planejamento ou geração baseados em gramáticas podem produzir elementos desnecessários, devido ao baixo poder de expressão de alguns tipos de gramáticas. Geração de geometria baseada em algoritmos especialistas pode apresentar problemas de variedade, caso tais algoritmos trabalhem separadamente em seu espaço de atuação. Representar o cenário em função de ações do jogador confere mais variedade que e função de elementos do cenário, apesar do trabalho extra na conversão. Abordagens de geração de cenários podem oferecer bastante variedade, mas pode não ser possível garantir a corretude dos cenários gerados.

35 Capítulo 3 Planejando Cenários Proceduralmente 3.1 Visão Geral Como visto no Capítulo 2, existem diversas formas de se estruturar um método de geração procedural de cenários. Neste trabalho, dividiremos a geração procedural de cenários em duas etapas: 1. Planejamento. 2. Geração visual. Deste modo, o processo de geração procedural de cenários é dividido em duas etapas: gerar proceduralmente um plano para o cenário, e realizar este plano. A etapa de planejamento prévio recebe como entrada um conjunto de informações sobre o jogo, que chamaremos "modelo de jogo", e produz como saída a descrição completa de um cenário proceduralmente gerado. Esta descrição é posteriormente expandida para a versão final do cenário pela etapa de geração visual. O planejamento prévio oferece a oportunidade de se definir completamente o cenário sem ter de se lidar com detalhes visuais ou geométricos, facilitando a etapa de geração visual. Tratamos neste capítulo da etapa de planejamento, abordando a geração procedural de uma perspectiva em alto nível. O Capítulo 4 abordará a etapa de

36 Capítulo 3. Planejando Cenários Proceduralmente 24 geração procedural de visuais. 3.2 Definição de Requisitos Como vimos no Capítulo 1, o objetivo deste trabalho é desenvolver um algoritmo de geração de cenários para jogos de plataforma/aventura. Para isso, é importante conhecer as construções de cenário mais recorrentes no gênero e definir os requisitos do algoritmo, de modo a compreender os tipos de situações que deverão ser produzidas pelo algoritmo. Considere a Figura 3.1, que exibe uma cena simples e pode ser encontrada em diversos jogos de plataforma/aventura. O jogador deve partir do ponto de início e chegar ao objetivo, situado no ponto a. Apesar de o cenário ser visualizado de modo bidimensional, do ponto de vista do game design esta é uma cena linear; o jogador segue um caminho único, sem obstáculos ou outras opções. Figura 3.1: Situação simples que um algoritmo de geração procedural de cenários deve ser capaz de produzir. Considere agora a Figura 3.2. Ao tomar o caminho óbvio, como na situação anterior, o jogador se depara com o obstáculo em a. A partir deste momento, o jogador deve começar a investigar o cenário, com o propósito de superar o

37 Definição de Requisitos obstáculo e prosseguir. Neste caso, a solução envolve atravessar a parede falsa em b, caminhar até o ponto c e obter a senha da tranca eletrônica em a, liberando o caminho até o objetivo em d. A introdução do obstáculo para a obtenção do objetivo é um dos mecanismos fundamentais dos jogos de plataforma/aventura. Figura 3.2: Situação que um algoritmo de geração procedural de cenários deve ser capaz de produzir. Note que o caminho percorrido agora não é mais linear, o que força o jogador a usar suas habilidades, tomar decisões e explorar o cenário. A Figura 3.3 também exibe uma situação comum em jogos de plataforma/aventura, apenas ligeiramente mais complexa. Tomando o caminho percorrido anteriormente como base, o jogador irá encontrar um novo obstáculo em g. Para resolvê-lo, deve ativar a chave elétrica situada em e, que está bloqueada por uma parede de rocha ( d ) e uma caixa movível ( c ). A parede de rocha, por sua vez, pode ser explodida com a dinamite encontrada em b, e as caixas em a e c podem ser movidas sem maiores problemas. Esta figura mostra que uma maneira eficiente de aumentar a complexidade do cenário é por meio do empilhamento de obstáculos: quanto maior for a pilha de obstáculos para um objetivo, mais difícil ou complexo ele será. As figuras exibidas anteirormente serviram para ilustrar o tipo de mecânica que um eventual algoritmo de geração procedural de cenários deve ser capaz de produzir, isto é: o empilhamento de obstáculos para a aquisição de um objetivo.

38 Capítulo 3. Planejando Cenários Proceduralmente 26 Figura 3.3: Situação que um algoritmo de geração procedural de cenários deve ser capaz de produzir. O caminho é ainda mais complexo que na Figura 3.2, oferencendo diversas possibilidades de exploração. Devemos agora definir a etapa de planejamento a ser usada na representação de cenários deste tipo. 3.3 Planejamento Orientado a Objetivos O propósito da fase de planejamento é definir um conjunto de algoritmos capaz de receber uma descrição das regras do jogo como entrada e retornar como saída um plano para o cenário. Um detalhe importante é que o plano deve garantir que o futuro cenário seja resolvível. Portanto, o primeiro passo é definir um formato de representação do cenário (plano) adequado. Uma vez definido, devemos propor um algoritmo capaz de gerar cenários nesta representação proceduralmente. A noção de solução em cenários de jogos de plataforma/aventura está diretamente condicionada à capacidade do jogador atingir todos os objetivos propostos. Na Figura 3.2, o cenário seria irresolvível caso o ponto c não existisse, pois o ponto d não poderia ser alcançado. Desse modo, é conveniente representar os cenários em termos de objetivos.

39 Planejamento Orientado a Objetivos Isto pode ser feito de maneira simples observando-se que a maioria dos jogos, em especial os de plataforma/aventura, pode ser encarada do ponto de vista do game design como um conjunto de objetivos associados a uma lista de obstáculos e suas respectivas soluções. Objetivos tipicamente são locais que devem obrigatoriamente ser visitados pelo jogador, e podem representar um ponto crítico no enredo do jogo, um novo item, uma nova habilidade ou uma luta com um boss. Obstáculos são elementos que impedem o progresso do jogador até uma certa condição ser satisfeita, quebrando a linearidade do jogo e introduzindo a mecânica de exploração característica do gênero. Como exemplo de obstáculo, podemos citar a parede de rochas da Figura 3.3. Soluções são elementos, ferramentas ou habilidades usadas na solução de obstáculos. No exemplo da Figura 3.3, a solução do obstáculo da parede de rocha é a dinamite. É importante notar que a noção de game design usada neste trabalho difere ligeiramente da usada na indústria de jogos. Um algoritmo de geração de game design, neste contexto, conhece os diferentes elementos que fazem parte do gameplay e como eles se relacionam, e faz uso desse conhecimento para produzir uma sequência lógica de objetivos. Já na indústria de jogos, o game designer é responsável por conceber os elementos de gameplay que fazem parte do jogo. Neste sentido, um algoritmo de geração de game design recebe diretamente como entrada o produto do trabalho do game designer. Um exemplo de informação a que um algoritmo de geração de game design teria acesso é a capacidade da dinamite de destruir paredes de rocha, como ilustrado na Figura 3.3. Usando os conceitos de objetivo, obstáculo e solução, podemos representar por exemplo o game design da Figura 3.2 como apenas um objetivo ( d ) possuindo uma lista de 2 obstáculos ( a e b ) e uma solução ( c ). Obstáculos e soluções, por sua vez, representam essencialmente o mesmo conceito que um objetivo: um determinado local no cenário que deve ser visitado ou resolvido. Assim, podemos tratá-los da mesma maneira, de modo que uma lista de objetivos é suficiente

40 Capítulo 3. Planejando Cenários Proceduralmente 28 para representar o game design de um cenário. O game design da Figura 3.3, por exemplo, pode ser representado pela seguinte lista: 1. Atravessar a passagem secreta em a. 2. Adquirir a dinamite em b. 3. Atravessar a passagem secreta em c. 4. Explodir a parede em d com a dinamite. 5. Ativar a chave elétrica em e. 6. Atravessar a passagem secreta em f. 7. Atravessar a grade em g. 8. Obter a senha da tranca em h. 9. Atravessar a porta trancada com a senha em i. 10. Adquirir o objetivo principal em j. Apesar da lista de objetivos ser suficiente para representar o game design gerado proceduralmente, a ausência de informação espacial induz à ocorrência de colisões com geometria previamente construída, dificultando o seu uso direto como formato de plano na geração procedural de visuais. Evidência disto é dada na Seção 4.3 do Capítulo 4, que ilustra problemas encontrados na implementação que faz uso direto da lista de objetivos. Deste modo, faz-se necessária uma etapa de processamento adicional, capaz de adicionar informação espacial ao game design previamente produzido. Este processo adicional, que chamaremos de level design, é responsável por criar um conjunto de caminhos e alocar os objetivos do game design a espaços apropriados. Assim como os elementos fundamentais do game design são os objetivos, os elementos fundamentais do level design são as salas e as portas. Salas são regiões no espaço de tamanho conhecido, formato retangular e conectadas dois-a-dois por portas.

41 Planejamento Orientado a Objetivos Usaremos salas para definir a geometria básica do cenário, pois seu formato retangular facilita a resolução de colisões de forma antecipada. Apesar de retangular, o formato das salas não restringe o tipo de visual que um possível algoritmo de PCG possa vir a criar, visto que a sala age apenas como um volume de fronteira (bounding volume) para o seu conteúdo. Uma vantagem adicional é que o uso de salas leva naturalmente a cenários semelhantes aos dos jogos de plataforma/aventura, como pode ser visto na Figura 3.4. (a) Shadow Complex (b) Representação de salas Figura 3.4: Exemplo de sala. Na Figura 3.4a, uma cena do jogo de plataforma/aventura Shadow Complex. Na Figura 3.4b, a representação visual de um caminho formado por salas. Uma vez definido o conceito de sala, podemos representar o level design de um cenário seu plano por meio de uma lista de salas associadas por cone. Para tanto, devemos mapear os objetivos, obstáculos e soluções do game design em salas e portas, construindo o level design. Este mapeamento pode variar dependendo da complexidade do modelo de jogo, mas em geral mapearemos objetivos e soluções para salas inteiras, ao passo que obstáculos serão associados à portas. Como exemplo, considere a Figura 3.3. Tanto o objetivo do ponto j quanto a solução do ponto b foram mapeados para salas exclusivas. Já obstáculo do ponto c bloqueia o caminho para uma porta (do ponto de vista do level design), mesmo que ela não apareça. Além disso, a etapa de level design é ideal para introduzir informações úteis à geração visual ou tomar decisões que não estão relacionadas a objetivos. Um

42 Capítulo 3. Planejando Cenários Proceduralmente 30 exemplo seria decidir se uma porta que conecta duas salas, como no ponto c da Figura 3.3, deve ou não ser visualmente representada. Como outro exemplo, um determinado jogo pode possuir 3 tipos de salas de trânsito, de combate e secretas e o level designer pode decidir o tipo de uma dada sala, caso não esteja reservada para um objetivo. Uma vez definida a lista de salas como o formato de representação do cenário na saída da etapa de planejamento, a geração visual tem seu trabalho facilitado, e precisa apenas gerar uma representação visual para cada sala individualmente, sem a necessidade de considerar interesses de game design ou colisão com outras salas. Neste trabalho, game design e level design gerados proceduralmente compõem a etapa de planejamento. A Seção 3.4 detalha o procedimento de geração de game design. O processo de geração de level design é detalhado na Seção 3.5. A Figura 3.5 ilustra o fluxo de informação das etapas definidas até o momento. Figura 3.5: Etapas do processo de geração procedural de cenários proposto. 3.4 Gerando Game Design Proceduralmente Vimos na revisão de trabalhos similares, no Capítulo 2, que para comportar tipos de cenários complexos, é comum fazer uso de uma etapa de geração conceitual antes da geração de visuais propriamente dita. Sabendo-se que uma lista de objetivos é suficiente para representar o game design de um cenário, o primeiro passo para se construir um algoritmo de geração procedural de cenários é construir um algoritmo de geração de game design. O Algoritmo mostra uma possível ideia parar se gerar proceduralmente o game design de um jogo. O algoritmo obtém do modelo de jogo a sequência de

43 Gerando Game Design Proceduralmente objetivos pretendida pelo game designer e prossegue para adicionar obstáculos e soluções a esta lista. O algoritmo funciona percorrendo a lista de objetivos. A cada passo, existe a chance de um obstáculo ser inserido na sequência (linha 10). Caso se determine Require: model : game_model 1: result 2: goals model.goals() 3: prev_goals 4: for all g goals do 5: stack {g} 6: put_goal (g = goals.begin()) 7: repeat 8: top stack.top() 9: prob model.odds(put_obstacle) 10: if rand()%101 prob then 11: prob2 model.odds(put_main_obstacle) 12: if put_goal and rand()%101 prob2 then 13: result.push( g-1 ) 14: put_goal true 15: else 16: set model.obstacles() model.solutions() prev_goals 17: pick set[rand() % set.size()] 18: result.push(pick) 19: end if 20: if model.is_solution(pick) then 21: stack.push(model.dual_obstacle(pick) ) 22: end if 23: else if put_goal then 24: result.push(top) 25: stack.pop() 26: if model.is_goal(top) and top-2 goals.begin() then 27: prev_goals.push(top-2) 28: end if 29: end if 30: until stack.empty() 31: end for 32: return result Algorítmo 3.4.1: Gera game design sob a forma de uma lista de objetivos.

44 Capítulo 3. Planejando Cenários Proceduralmente 32 que um obstáculo deve ser inserido, existe a chance dele ser um obstáculo "principal", que requer como solução o uso de alguma habilidade ou item adquirido no último objetivo resolvido (linha 12). Isto cria um ambiente progressivamente explorável, e garante que o jogador não tenha acesso irrestrito ao cenário desde o princípio do jogo. Quando um obstáculo principal é inserido na solução, torna-se possível também inserir o objetivo atual (linha 23). Caso o obstáculo a ser inserido não seja principal (linha 16), o algoritmo escolhe aleatoriamente uma solução, um obstáculo simples ou um objetivo de ao menos duas iterações anteriores para ser inserido. Obstáculos simples são elementos como os pontos f ou c da Figura 3.3, que podem ser atravessados diretamente. Introduzir uma solução, por outro lado, implica em introduzir posteriormente um obstáculo que faça uso de tal solução para ser atravessado; soluções causam o empilhamento de seus respectivos obstáculos. Introduzir um objetivo previamente adquirido também pode ser interessante, pois permite reusar elementos adquiridos anteriormente; especialmente se os objetivos representarem habilidades previamente adquiridas. O algoritmo também pode ser modificado para dar suporte a diferentes tipos de game design. Como exemplo, considere a diretiva: quanto mais próximo do objetivo, mais difícil deve ser o cenário. Podemos modificar o algoritmo para levar em conta essa diretiva de maneira simples, aumentando a probabilidade da inserção de soluções quanto maior for o número de passos até o momento para um dado objetivo. Outra ideia seria alterar os tipos de obstáculos e soluções à disposição com base no objetivo atual, no número de passos ou em alguma outra medida. O resultado deste algoritmo é uma lista de objetivos, contendo também uma série de obstáculos e suas respectivas soluções. Esta lista será usada como entrada no processo de level design para concluir a etapa de planejamento do cenário. 3.5 Gerando Level Design Proceduralmente Utilizando o game design produzido pelo algoritmo 3.4.1, devemos propor um método para gerar proceduralmente o level design adequado. Os algoritmos e mostram um exemplo de como fazer isto.

45 Gerando Level Design Proceduralmente O algoritmo começa construindo uma sala inicial. A partir daí, para cada objetivo do game design, o algoritmo escolhe uma sala de partida tenta gerar um caminho até o objetivo atual. O caminho é gerado pela função make_path(), detalhada no algoritmo A escolha da sala de partida é feita segundo o tipo de objetivo: caso o objetivo seja um obstáculo, ele deve bloquear o caminho adiante, e a sala de partida deve ser a última sala adicionada; caso contrário, a sala de partida é escolhida aleatoriamente do conjunto de salas atual (linhas 6 a 10). Caso ocorram colisões na criação do caminho (linha 15), outras portas da fronteira da sala são escolhidas aleatoriamente (linha 13) como ponto de partida até que se consiga adicionar o caminho ou até que não haja mais portas, caso em que outra tentativa é feita (linha 20). Caso o número máximo de tentativas para um objetivo seja atingido (linha 21), o algoritmo falha e não é capaz de gerar um plano para o cenário, devendo ser executado outra vez. O algoritmo detalha o funcionamento da função make_path(), usada no algoritmo O propósito desta função é construir por meio de salas um caminho livre de colisões até o objetivo. Isto é feito de maneira recursiva: à cada chamada, o algoritmo tentará adicionar uma nova sala ao caminho atual. No início, o algoritmo decide se é hora de consumir o objetivo. Após isso, decide-se o tipo da sala (linhas 4 a 14). Os tipos de salas podem variar, dependendo do jogo em questão. Neste exemplo, consideramos que uma sala pode ter um dos quatro tipos: GOAL_ROOM, salas que guardam objetivos; TRAN- SIT_ROOM, salas que servem apenas como corredores; COMBAT_ROOM, salas em que ocorrem situações de combate; e PUZZLE_ROOM, salas que abrigam um desafio que envolve o uso de habilidades. Caso se deva consumir o objetivo, o tipo escolhido é GOAL_ROOM (linhas 3 e 4). Além disso, caso objetivo seja um obstáculo, ele é devidamente mapeado para a respectiva porta (linhas 7 e 31). É tarefa do level designer balancear a ocorrência dos diferentes tipos de salas, e estratégias mais específicas podem ser usadas no lugar da escolha aleatória. O próximo passo é definir o tamanho da sala (linhas 15 a 17). Uma vez feito isso, a nova sala é conectada à sala anterior. Este processo envolve a escolha de uma porta livre da sala nova para se ligar à sala anterior, e determina a posição absoluta da nova sala (linha 18).

46 Capítulo 3. Planejando Cenários Proceduralmente 34 Neste momento, o algoritmo verifica a existência de colisões entre a sala nova e o restante das salas. Caso uma colisão seja detectada, o processo falha (linhas 23 a 26). O último passo é usar a nova sala como ponto de partida para uma nova chamada recursiva (linhas 30 a 38). Para isso, todas as portas livres da nova sala são recuperadas e aleatoriamente ordenadas. A partir daí, para cada porta da nova sala, verifica-se o resultado da chamada recursiva. Um resultado falso indica que um determinado caminho parcial falhou em algum momento futuro, e aguarda-se as outras tentativas. Por outro lado, um resultado verdadeiro é Require: goals : List 1: all_rooms { make_first_room()} 2: for all g goals do 3: num_trials MAX_TRIALS 4: next false 5: repeat 6: if g.is_obstacle() then 7: start_room all_rooms.last() 8: else 9: start_room rand_pick(all_rooms) 10: end if 11: doors start_room.doors() 12: random_shuffle(doors.begin(),doors.end()) 13: for all d doors do 14: ok make_path(g,start_room,d,all_rooms) 15: if ok then 16: next true 17: break 18: end if 19: end for 20: until num_trials = 0 or next 21: if num_trials = 0 then 22: return 23: end if 24: end for 25: return all_rooms Algorítmo 3.5.1: Gera level design para todos os objetivos do game design.

47 Gerando Level Design Proceduralmente propagado. Caso todas as possíveis portas sejam testadas e não se possa construir um caminho válido a partir delas, o processo falha (linha 40). A Figura 3.6 mostra um exemplo típico de como se distribuem as salas geradas por este algoritmo. Figura 3.6: Exemplo de um conjunto de salas geradas pelo algoritmo

48 Capítulo 3. Planejando Cenários Proceduralmente 36 Require: current_goal : Goal Require: last_room : Room Require: last_door : Door Require: all_rooms : List 1: new_room new Room() 2: theme current_goal.theme 3: put_goal (rand()%101 theme[put_goal]) 4: if put_goal then 5: new_room.type GOAL_ROOM 6: if current_goal.is_obstacle() then 7: door_obs current_goal 8: else 9: new_room.goal current_goal 10: end if 11: else 12: types {TRANSIT_ROOM, COMBAT_ROOM, ACTION_ROOM} 13: new_room.type = rand_pick(types) 14: end if 15: min theme.min_size 16: max theme.max_size 17: new_room.size {rand_int(min[0],max[0]), rand_int(min[1],max[1])} 18: last_door.link_to(new_room) 19: collision false 20: for all r all_rooms do 21: collision collision or r.collides_with(new_room) 22: end for 23: if collision then 24: last_door.cut_link(new_room) 25: return false 26: end if 27: all_rooms.add(new_room) 28: doors new_room.doors() 29: random_shuffle(doors.begin(),doors.end()) 30: for i = 0 to doors.size() do 31: doors[i].obstacle door_obs? door_obs : NULL 32: res self(current_goal,end_goal,new_room,doors[i], all_rooms) 33: if res then 34: return true 35: else 36: doors[i].obstacle NULL 37: end if 38: end for 39: all_rooms.remove(new_room) 40: return false Algorítmo 3.5.2: Gera um caminho de salas para um objetivo.

49 Capítulo 4 Gerando Visuais Proceduralmente Vimos no Capítulo 3 como gerar proceduralmente planos e descrições para cenários de jogos do gênero plataforma/aventura. Este capítulo trata da etapa posterior, isto é, da geração procedural de visuais. Neste trabalho, diferentes técnicas de geração de visuais foram experimentadas, e as seções de 4.1 à 4.4 detalham as decisões, os erros, os problemas e as lições aprendidas com quatro das mais significativas. Nas Seções 4.1, 4.2 e 4.4, a técnica descrita recebe como entrada um plano em forma de lista de salas, referente ao level design do Capítulo 3. A técnica da Seção 4.3, por outro lado, faz uso direto do resultado da etapa de game design, a lista de objetivos. Por fim, a técnica da Seção 4.4, que sintetiza grande parte das lições aprendidas nas outras tentativas, foi usada na implementação do protótipo deste trabalho. O protótipo é detalhado no Capítulo Usando Chunks A primeira técnica de geração visual experimentada neste trabalho envolvia o uso de chunks. Este processo recebia como entrada um conjunto de salas e usava uma biblioteca de chunks para construir o interior de cada sala. Chunks são partes de cenário previamente construídas, e seu uso é especialmente interessante por permitir combinar o aspecto visual de conteúdo manual-

50 Capítulo 4. Gerando Visuais Proceduralmente 38 mente criado com técnicas de geração automática procedural Mapeando Chunks em Salas O primeiro passo para gerar visuais usando chunks é definir um processo para mapeá-los no espaço da sala. Para tanto, faremos uma restrição: as dimensões da sala devem ser múltiplas das de uma célula, de modo que a sala possa ser representada por uma grade de células como a da Figura 4.1a. (a) Grade de células (b) Escolha de chunks Figura 4.1: Sala sendo representada por uma grade de células na Figura 4.1a. As arestas em vermelho representam as portas. Na Figura 4.1b, um chunk já foi alocado à primeira célula e restringe as possibilidades para seus vizinhos. Uma vez que representamos a sala por uma grade de células, mapeamos um chunk para cada célula. Logo, gerar visuais usando chunks se resume a escolher com base em alguma heurística um conjunto de chunks para completar a grade da sala Escolhendo Chunks Os chunks são alocados aleatoriamente a cada célula. Usamos uma forma de escolha de chunks semelhante à usada no trabalho de Mawhorter e Mateas [15], adicionando aos chunks meta-informações que permitissem determinar os seus possíveis vizinhos. Deste modo, o conjunto de possíveis chunks para uma determinada célula depende das paredes ao seu redor, dos chunks em sua vizinhança e de sua configuração de portas. A Figura 4.1b mostra um exemplo do processo

51 Usando Chunks de escolha de chunks, e as figuras 4.2 e 4.3 mostram exemplos de cenários reais gerados com chunks. Figura 4.2: Exemplo de cenário real gerado com chunks Problemas no Uso de Chunks O uso de chunks da maneira como foi experimentado neste trabalho se mostrou bastante limitado. Em primeiro lugar, por não haver algum tipo de planejamento interno, a associação livre de chunks, restrita apenas pela informação de vizinhança, pode não ser capaz de gerar o interior das salas. Além disso, o processo de alocação aleatória não oferece mecanismos para tratar obstáculos, que tipicamente requerem um encadeamento particular de construções geométricas e são um recurso essencial em jogos de plataforma/aventura. Outro prolema é a grande quantidade de chunks requerida. Um cenário via de regra possui diferentes look-and-feel s, o que implica um conjunto diferente de chunks para cada tema (look-and-feel). Além disso, salas frequentemente são de diferentes tipos (sala de objetivo, sala de combate, dentre outras), o que implica

52 Capítulo 4. Gerando Visuais Proceduralmente 40 Figura 4.3: Exemplo de cenário real gerado com chunks. um conjunto diferente de chunks para cada tipo de sala dentro de cada tema. Uma sala frequentemente também terá portas com obstáculos, e para cada tema e para cada tipo de sala, diveros chunks precisam ser construídos para contemplar todos os possíveis obstáculos. Além de obstáculos, jogos de plataforma/aventura tipicamente desafiam o jogador de diversas maneiras, requerindo o uso das habilidades adquiridas no decorrer do jogo para atravessar as salas; desse modo, para cada situação de uma dada célula, é preciso que haja chunks para cada possível habilidade do jogador. Ainda, se existir apenas um chunk para cada tipo de situação, os cenários se tornam repetitivos, devendo haver mais de um chunk para cada situação. Por fim, todos os chunks adequados a uma dada situação devem "combinar"com todos os chunks adequados à todas as situações vizinhas. Por combinar, queremos dizer que a justaposição dos chunks não deve evidenciar que se tratam de elementos distintos, mantendo uma aparência consistente. Desse modo, a geração de cenários por meio de chunks requer uma grande quantidade de chunks. Além disso, a manutenção de uma biblioteca de chunks

53 Usando Ações e algoritmos deste tipo requer um esforço contínuo, uma vez que a adição de um novo tipo de chunk implica a verificação de compatibilidade com todos os chunks vizinhos atualmente na biblioteca (o que dificilmente pode ser automatizado). Por estes motivos, abandonamos o uso de chunks em prol de uma solução capaz de expressar mais tipos de gameplays e menos custosa do ponto de vista dos recursos (memória e processamento) necessários para produzi-la. 4.2 Usando Ações e algoritmos Durante o desenvolvimento da técnica de chunks, ficou claro que se pudéssemos separar, replicar e agrupar os elementos que compunham os chunks de acordo com alguma lógica, o trabalho requerido seria sensivelmente menor. Esta idéia motivou a geração algorítmica de visuais. Contudo, para funcionar, esta nova abordagem necessitaria de uma etapa de planejamento de gameplay para definir o interior das salas. Como vimos no Capítulo 2, abordagens baseadas em geração algorítmica de visuais tipicamente apresentam problemas de variedade; frequentemente os algoritmos trabalham individualmente em espaços do cenário, e a versatilidade de um algoritmo fica limitada à sua região de atuação. O problema subjacente é que se está abordando a geração de geometria por um nível de detalhamento insuficiente. Observando a situação pelo ponto de vista do jogador, um cenário nada mais é do que uma sucessão de oportunidades para se executar uma ação (habilidade). Portanto, ações são o elemento atômico da experiência de um cenário, e oferecem o maior grau de detalhamento possível para a geração de geometria. Neste sentido, os "verbos"do trabalho de Smith et al podem ser vistos como ações, sendo este um dos primeiros a usar ações para planejar cenários Planejando Salas com Ações O processo de planejamento do interior das salas começa organizando-se as portas da sala numa lista. A partir daí, o primeiro elemento da lista atua como o ponto de partida: para todas as portas subsequentes, constroi-se um caminho do ponto

54 Capítulo 4. Gerando Visuais Proceduralmente 42 de partida até a porta de destino. A construção de um caminho, por sua vez, é feita produzindo-se uma lista de instâncias de ações do jogador. O conjunto de ações que o jogador pode executar depdende da situação ou estado em que o jogador se encontra; se o jogador estiver nadando, por exemplo, não poderá executar ações que requeiram estar-se em terra firme. Mais genericamente, cada ação possui como pré-condição algum estado do jogador. Para modelar este requisito, usamos uma matriz de probabilidade; cada linha da matriz indica a última ação executada, cada coluna indica uma habilidade possível para o próximo passo e cada célula indica a probabilidades de escolha de uma habilidade. Além de escolher uma habilidade, é preciso ainda instanciá-la. Uma ação de pulo, por exemplo, pode possuir diferentes instanciações: amplitude, direção e distâncica podem variar. O resultado do processo de produção de caminho é uma lista de instanciações de ação. Cada elemento desta lista possui, entre outros atributos, uma posição e uma região de ocupação, usadas nos testes de colisão. Ao fim do processo de construção do caminho, as regiões de ocupação de todos os caminhos anteriores são testados com o novo caminho, em busca de colisões. Caso não haja colisões, o novo caminho é aceito e escolhe-se aleatoriamente um outro ponto de partida. A escolha do novo ponto de partida é feita da seguinte maneira: escolhe-se aleatoriamente um elemento da lista de instâncias de ações. Caso essa particular instância não comporte uma ramificação de caminho, ela é descartada e tenta-se novamente. Uma vantagem deste tipo de planejamento de sala é que garantir a presença dos obstáculos das portas se torna trivial; basta instanciar a habilidade correspondente em algum momento na geração do caminho até determinada porta. Outra vantagem é que, como estamos usando movimentos que o jogador, por definição, é capaz de utilizar, os cenários gerados serão sempre executáveis. Outra consequência desse tipo de planejamento é que as salas (level design) não podem ser planejadas de antemão. Isto se deu por que, ao implementar a instanciação de ações, não encontramos uma forma simples de garantir que o plano tenha um tamanho ou destino pré-determinado, isto é, não encontramos uma forma boa o suficiente de guiar a geração de caminho a uma posição específica no espaço, de modo que a posição final das portas deve ser determinada pelo

55 Usando Ações e algoritmos processo de planejamento. O game design, contudo, ainda pôde ser gerado de antemão Gerando Visuais com algoritmos Esta técnica tinha como objetivo usar a lista de instâncias de ações para determinar os visuais de uma sala. Para tanto, ao invés de usar partes completas de cenário previamente construídas (chunks), fizemos uso de algoritmos específicos para gerar diferentes tipos de geometria. Deste modo, era preciso definir uma forma de mapear as diversas instâncias de ações a algoritmos diferentes. Uma vez definido, o algoritmo seria responsável por criar uma geometria que obedecesse os parâmetros desejados. Por exemplo, ao observar uma ação de andar instanciada com um comprimento de 30 unidades, um algoritmo poderia consturir uma passarela de comprimento 30 unidades. As Figuras 4.4a e 4.4b mostram resultados preliminares que obtemos com esta abordagem Problemas com o Uso de Ações e algoritmos As idéias descritas nesta seção foram capazes de reduzir sensivelmente a dependência de recursos externos, que era o caso com a abordagem baseada em chunks, que precisavam ser pré-fabricados e armazenados. Contudo, outros problemas foram introduzidos. Em primeiro lugar, o fato de não se poder fazer uso do level design gerado anteriormente comprometia severamente o seu uso, uma vez que implicaria a modificação do processo de geração de level design para contemplar salas de tamanho variável. Além disso, a definição de estruturas para representar uma região de ocupação se mostrou um esforço repetitivo; era preciso oferecer tanto uma representação volumétrica, para os testes de colisão, quanto uma visual. Seria interessante que a representação visual também servisse para colisão, ou que a representação volumétrica pudesse ser extendida para representar os visuais. Outro problema sério dessa abordagem, e que motivou o seu abandono, era a dificuldade de se encontrar um mapeamento entre a lista de instâncias de ações

56 Capítulo 4. Gerando Visuais Proceduralmente 44 (a) Exemplo 1 (b) Exemplo 2 Figura 4.4: Exemplos de cenários gerados com ações e algorítmos. Em ambos os casos, o plano consiste de executar dois pulos, seguidos de um trecho de caminhada. e os algoritmos de geração de geometria. Em casos simples, como os das Figuras 4.4a e 4.4b, era fácil encontrar os algoritmos correspondentes ao planejamento. Em casos mais complexos, contudo, que envolviam ações além de pular ou andar,

57 Usando Ações e Tiles este processo se tornava mais difícil, ainda mais ao levarmos em conta que pode haver mútliplos cenários que se adequem a uma mesma lista de instâncias de ações. Estes e outros fatores levaram à busca de uma técnica mais adequada à geração de visuais para listas de instâncias de ações. 4.3 Usando Ações e Tiles Diante da impossibilidade de se obter progressos com a implementação da Seção 4.2, uma nova abordagem se fazia necessária. Apesar disso, o planejamento orientado a ações parecia promissor, sendo necessário apenas econtrar uma forma mais versátil de gerar geometria a partir do dito planejamento. Além disso, era interessante que a nova forma de geração de geometria fosse capaz de resolver colisões, de modo a se evitar trabalho repetitivo. Esta situação motivou o uso de mapas de tiles como forma de geração de geometria. Tiles têm um propósito análogo ao de pixels em uma imagem, mas tipicamente armazenam coordenadas de textura ao invés de uma única cor. O uso de tiles oferece grande flexibilidade na definição de geometria, além de permitir a verificação imediata de colisões, se mostrando uma escolha natural para a dada situação. A mudança para tiles acarretou um conjunto de modificações no método de geração definido até então. Em primeiro lugar, assim como na técnica da Seção 4.2, não se poderia fazer uso da etapa de level design definida no Capítulo 3, uma vez que o planejamento ainda seria orientado a ações. Assim, o algoritmo não recebe como entrada um conjunto de salas, mas a lista de objetivos como definida na etapa de game design no Capítulo 3. Como o novo algoritmo não operaria em termos de salas, mas de objetivos, o processo de planejamento não poderia mais se restringir apeans ao interior de uma sala, devendo abranger o cenário em sua totalidade. Isto requer apenas uma pequena modificação no processo de planejamento de ações da Seção 4.2: o ponto de partida é escolhido aleatoriamente entre todos os tiles anteriormente adicionados, e não mais entre os caminhos de uma mesma sala. Um caminho continuou sendo definido como uma lista de instâncias de ações.

58 Capítulo 4. Gerando Visuais Proceduralmente 46 O uso de tiles também alterou a forma de representação do cenário. Com efeito, não mais seria necessário haver uma representação intermediária do caminho para se fazer testes de colisão, de modo que o próprio mapa de tiles, acrescido de informações de contexto (como a última ação instanciada), foi escolhido como forma de representação de cenário Esculpindo Geometria À cada passo do algoritmo, uma ação é convertida numa configuração de tiles que esculpe o mapa de tiles atual. As ações são esculpidas no cenário por meio de algoritmos especializados. A Figura 4.5 mostra um exemplo de como diferentes algoritmos agiriam numa mesma situação. (a) Pulo (b) Ponte Figura 4.5: Exemplo de como diferentes algorítmos agiriam numa mesma situação. Na Figura 4.5a a ação escolhida é um pulo. Na Figura 4.5b, o algoritmo esculpe o espaço para se adicionar uma ponte (a ponte pode ser uma textura). Assim como na técnica descrita na Seção 4.2, uma determinada ação ainda poderia ser instanciada de diversas formas diferentes. Para conseguir expressar essa diversidade, desenvolvemos uma biblioteca de rotinas auxiliares inspiradas em programas de pintura digital, dada a correspondência entre tiles e pixels. A primeira camada da biblioteca de pintura de tiles consistia de funções para criar formas básicas, como círculos, retângulos, triângulos e afins. A segunda camada consistia de um conjunto de pincéis, que combinavam as funções da camada an-

59 Usando Ações e Tiles terior para criar um formato de pincel e sabiam aplicá-lo em uma determinada posição do mapa. A última camada da biblioteca consistia de funções para facilitar a aplicação de pincéis no percurso de uma linha poligonal. Desse modo, um algoritmo escultor necessitava apenas definir uma ou mais linhas poligonais e associar um pincel a elas para definir seu funcionamento. Os algoritmos escultores aplicam modificações no mapa de tiles imediatamente, e caso encontrem colisões, pode-se fazer backtrack para um momento anterior e tomar outras decisões (como instanciar outras ações, ou escolher outra direção). A mecânica de backtracking pode ser implementada salvando-se o contexto do algoritmo por meio de uma cópia do mapa de tiles na pilha de recursão; este processo de salvamento de contexto pode ter um custo proibitivo de memória caso seja executado à cada passo do algoritmo. Assim, escolhemos salvar o contexto apenas em momentos chave, o que torna a técnica passível de falhar, isto é, não haver etapas de recursão suficientes para criar caminhos livres de colisão. As Figuras 4.6 e 4.7 mostram exemplos de cenários reais gerados usando a técnica descrita nesta seção. Figura 4.6: Exemplo de cenário gerado com tiles e ações Problemas com o Uso de Ações e Tiles Um detalhe importante introduzido após o uso da biblioteca de pintura diz respeito à verificação de colisões. A verificação de colisões tem por objetivo detectar

60 Capítulo 4. Gerando Visuais Proceduralmente 48 Figura 4.7: Exemplo de cenário gerado com tiles para dois objetivos e apenas ações de pular e andar. se o ramo do cenário atualmente sendo gerado está passando por cima de outra parte do cenário anteriormente criada, como ilustrado na Figura 4.8. Em um primeiro momento, pode-se imaginar que isto é simples, bastando verificar se os tiles a serem alterados (pintados) eram de fato vazios, isto é, não haviam sido preenchidos anteriormente. (a) Antes (b) Depois Figura 4.8: Nesta situação o cenário se tornará inválido caso a modificação proposta na Figura 4.8b seja aplicada, pois se criará uma conexão não pretendida entre duas partes do cenário. Contudo, essa verificação simples não pode ser usada com a biblioteca de pintura. Isto por que, dependendo do formato do pincel, o ato de aplicar uma pincelada numa região do mapa pode sobrescrever tanto tiles vazios quanto preenchidos e mesmo assim ser válida, como ilustrado na Figura 4.9. Para resolver este problema, duas abordagens distintas foram desenvolvidas.

61 Usando Ações e Tiles Figura 4.9: O pincel em formato de elipse, a ser aplicado nas posições 1, 2 e 3, fatalmente sobrescreverá tiles marcados anteriormente, o que pode ser visto pelas regiões marcadas em vermelho. Apesar disso, estas modificações não alterariam o gameplay pretendido e são, intuitivamente, válidas. A primeira abordagem considera como colisão apenas as modificações que sobrescreverem dois ou mais grupos inatingíveis de tiles preenchidos. Esta abordagem detectaria corretamente que as modificações da Figura 4.9 são válidas, uma vez que, separadamente, cada passo sobrescreveria apenas um grupo de tiles (regiões em vermelho). Da mesma forma, casos como o da Figura 4.8b seriam classificados como inválidos, pois ao aplicar o pincel na posição pretendida, dois grupos distintos e inatingíveis (dentro da grade que limita a atuação do pincel) de tiles seriam formados. Apesar de funcionar em diversas situações, a abordagem de grupos inatingíveis não funcionava em todas os casos. A Figura 4.10 ilustra uma situação assim. Diante destes fatos, uma nova abordagem para detecção de colisões se fez necessária. A segunda abordagem para detectar colisões envolvia a adição de uma propriedade extra aos tiles com o intuito de representar o "tempo"de sua última atualização. Assim, ao aplicar pinceladas no mapa de tiles, a segunda abordagem considera como colisão todas as modificações que sobrescrevam tiles preenchidos em um tempo t menor que o tempo atual em duas ou mais unidades. Usando esta abordagem, o caso da Figura 4.10 seria corretamente classificado como livre de colisões, visto que ambos os grupos de tiles sobrescritos na Figura 4.11b teriam um mesmo tempo t = t 1. No entanto, adicionar uma propriedade extra aos tiles pode se mostrar inviável em termos de memória, uma vez que o

62 Capítulo 4. Gerando Visuais Proceduralmente 50 (a) Aplicação de um pincel (b) Regiões sobrescritas Figura 4.10: Uma situação desse tipo seria considerada como inválida pelo algorítmo de grupos inatingíveis, sendo no entanto claramente válida. cenário inteiro é representado por um mapa de tiles e o processo de geração faz diversas cópias deste mapa para usar nas recursões. Além disso, ainda existem casos que esta segunda abordagem não resolve, como é ilustrado na Figura Por fim, esta técnica por definição impede a ramificação de caminhos, uma vez que diferentes caminhos são construídos em tempos diferentes. Desse modo, é necessário adicionar diversos casos especiais para que a ramificação de caminhos seja possível. (a) Antes (b) Depois Figura 4.11: Ao ser aplicado, o pincel em formato de retângulo tem um alcance tal que o permite preencher todos os tiles vazios do caminho sem sobrescrever nenhum tile do outro lado. Mesmo assim, ainda abriria um caminho entre as duas partes do cenário e seria aceito. Além de problemas com detecção de colisão e uso de memória, também vale

63 Usando Intenções ressaltar que o uso de grandes mapas de tiles para representar o cenário em sua totalidade pode rapidamente degradar a performace do processo, impedindo o seu uso em cenários mais complexos. Por fim, a qualidade visual dos cenários gerados por esta técnica é bastante inferior à dos outros métodos estudados; dada a dificuldade de se controlar a direção em que o cenário é expandido, dificilmente a qualidade visual poderia ser melhorada. Por estes e outros motivos, outra solução se fez necessária. 4.4 Usando Intenções Analisando as dificuldades enfrentadas nas outras técnicas de geração visual estudadas, ficou claro que abandonar o level design foi um erro e trouxe mais dificuldades, uma vez que a organização em salas não apenas resolve grande parte dos problemas de colisão, mas também confere um visual semelhante à grande parte dos jogos de plataforma/aventura. Apesar disso, era óbvio que deveria haver algum tipo de planejamento interno para as salas, visto que escolher o seu interior de maneira completamente aleatória se mostrou inviável na abordagem direta com chunks Neste sentido, o uso de abordagens baseadas em ações, apesar de promissor, se mostrou de difícil implementação. Além disso, o planejamento com ações não funciona bem com salas de tamanho fixo, introduzindo dificuldades em seu uso. Estas considerações levaram ao desenolvimento de um processo de geração visual orientado a intenções, uma forma mais simples de planejar o interior de salas que ações. Intenções representam as possíveis movimentações de um jogador entre as células de uma sala Planejando Salas com Intenções Para planejar o interior de uma sala usando intenções, as salas devem ser vistas como uma grade de células, assim como ilustrado na Figura O planejamento consiste em definir um caminho conectando todas as portas da sala. Essa definição deve conter informação suficiente para possibilitar sua futura geração visual.

64 Capítulo 4. Gerando Visuais Proceduralmente 52 Figura 4.12: Exemplo de sala vista como grade de células. É interessante que o processo de definição deste caminho nunca gere ciclos, o que descarta uma implementação trivial em que uma nova direção é escolhida aleatoriamente à cada passo. Por este motivo, usaremos um outro processo. Assumiremos que, na ausência de obstáculos, o layout das salas deve ser simples e permitir movimentação rápida, o que é até desejável neste gênero, uma vez o jogador deve via de regra atravessar uma mesma sala diversas vezes. Assim, o primeiro passo deve ser estabelecer um conjunto de pontos de conexão entre as linhas da sala. Os pontos de conexão estabelecem regiões em que o jogador deve ser capaz de transitar entre diferentes linhas da grade correspondente à sala. A Figura 4.13 mostra um exemplo de pontos de conexão. Num segundo momento, é preciso criar um mapa de intenções com base nos pontos de conexão. O mapa de intenções possui um formato semelhante à grade de células da sala, e as intenções são representadas por direções. Cada célula no mapa de intenções pode ter até quatro direções ao mesmo tempo: norte, sul, leste e oeste. Para criar o mapa de intenções, cada ponto de conexão deve adicionar uma intenção sul em sua célula e norte na célula imediatamente abaixo (Figura 4.14a). Isto representa que naquela região deverá haver uma conexão vertical. Além disso, todas as células que possuem portas adicionam intenções na mesma direção das portas, como ilustrado na Figura 4.14b.

65 Usando Intenções Figura 4.13: Exemplo de pontos de conexão marcando as células de transição de nível. (a) (b) Figura 4.14: Exemplo ilustrando a marcação de intenções nos pontos de conexão (Figura 4.14a) e nas portas (Figura 4.14b). A partir daí, para cada linha da grade, cada porta da linha deve emitir um fluxo de intenções lateral até que tal fluxo encontre um ponto de conexão. Caso não haja portas numa dada linha, usa-se os próprios pontos de conexão como partida. A direção das intenções é determinada da seguinte maneira: caso seja

66 Capítulo 4. Gerando Visuais Proceduralmente 54 a primeira intenção do fluxo, a direção é lateral, no sentido do fluxo; caso seja intermediária, a intenção tem direção dupla; caso seja a última, a direção é contrária ao sentido do fluxo. Um exemplo deste processo é dado na Figura Figura 4.15: Exemplo de construção dos fluxos de intenção. Uma vez construído o mapa de intenções, é preciso marcar nos fluxos de intenção os intervalos de obstáculos. Intervalos de obstáculos determinam as regiões em que um obstáculo pode ser inserido. Eles são úteis para prevenir que o obstáculo de uma porta interfira no caminho de outras portas. Os intervalos de obstáculos podem ser calculados por meio de um processo de três fases. Na primeira fase, escolhemos uma célua que faça parte do mapa de intenções para atuar como centro. Num segundo momento, partimos da célula de cada porta que possui obstáculo e seguimos o caminho inverso do fluxo de intenções até atingir o centro ; as células visitadas são adicionadas ao intervalo de obstáculo correspondente, e caso seja visitada uma célula que já contém informação de obstáculo, o processo para. Por fim, partimos da célula de cada porta que não possui obstáculos e percorremos o caminho até o centro, removendo as informações de obstáculos do caminho. No exemplo da Figura 4.16, as estrelas azuis representam o obstáculo de corda, enquanto a estrela verde representa o obstáculo de parede de pedra. Apos a definição do mapa de intenções e dos intervalos de obstáculos, as regiões que não foram marcadas por intenções são consideradas neutras e podem

67 Usando Intenções Figura 4.16: Exemplo de marcação dos intervalos de obstáculos. ter qualquer representação visual. Na Figura 4.17 estas áreas são representadas por hachuras. Figura 4.17: Definição de áreas neutras, exibidas em hachura. Nesse ponto, os elementos que fazem parte do jogo, como portas, paredes, pisos, rampas, grades e caixas, são usados para cumprir as intenções em cada célula, como visto nas Figuras de 4.18a a 4.18c. Como, nesta abordagem, os elementos atômicos de cenário são as células de uma sala, o uso de intenções pode ser usado como uma forma de planejamento

68 Capítulo 4. Gerando Visuais Proceduralmente 56 (a) (b) (c) Figura 4.18: Exemplo completo de geração visual de sala usando intenções. As barras em vermelho representam portas, e ambas as portas possuem obstáculos. A porta da primeira linha requer o uso de cordas, e a da última é selada com pedras. para a abordagem de chunks descrita na Seção 4.1, pois garante a geração dos interiores e a colocação de obstáculos. Neste caso, tanto as possíveis ações do jogador quanto os possíveis obstáculos devem ser traduzidos em chunks. Os resultados obtidos com a implementação desta técnica são discutidos no Capítulo 5.

69 Capítulo 5 Resultados Vimos no Capítulo 4 diversas formas de geração visual de cenários, em diferentes graus de complexidade. Neste capítulo, analisamos os cenários produzidos pelo protótipo implementado com as etapas de planejamento do Capítulo 3 e a técnica da Seção 4.4 do Capítulo 4. Abaixo seguem as principais informações sobre esta implementação: Implementado como um aplicativo para ios 5.0. Implementado nas linguagens C++ e Objective-C. Compilado com o Apple LLVM 3.0. Aproximadamente 2800 linhas de código. Renderização em OpenGL ES 2.0. Neste protótipo, os objetivos poderiam ter um dos seguintes tipos: skill, skill_usage, key, locked_door, boss, secret_passage e end. Objetivos do tipo skill introduzem soluções, e objetivos do tipo skill_usage introduzem obstáculos que requerem o uso de uma determinada habilidade. Da mesma forma, objetivos do tipo key são recíprocos aos do tipo locked_door. Objetivos do tipo boss indicam um evento de confronto com algum inimigo chefe. Objetivos do tipo secret_passage indicam a necessidade de se haver, em algum momento, uma porta camuflada e/ou escondida, e objetivos do tipo end marcam o fim do cenário.

70 Capítulo 5. Resultados 58 Além do seu tipo, os objetivos nesta implementação também apresentavam um tema, um buffer de dados e um campo de bits. O tema dos objetivos determina o seu mapeamento de chunks e um conjunto de probabilidades usadas na etapa de geração visual. Já o buffer de dados genérico foi usado para armazenar informações como o tipo da habilidade em objetivos do tipo skill_usage ou a identificação do inimigo em objetivos do tipo boss. Além disso, a fim de obter maior representatividade, introduzimos um campo de bits nos objetivos para indicar se um determinado objetivo era de secreto, o que se deveria refletir numa mudança visual; ou se deveria continuar no caminho anterior, de modo a usar como ponto de partida a última sala adicionada e não uma sala aleatória. Consideramos a existência de quatro tipos de salas: TRANSIT_ROOM, COMBAT_ROOM, ACTION_ROOM e GOAL_ROOM. O propósito era introduzir variedade no cenário utilizando parâmetros distintos para gerar cada um destes tipos de salas. Salas de trânsito servem apenas para o jogador se locomover dentro do cenário; salas de combate oferecem desafios baseados em conjuntos de inimigos para o jogador; salas de ação requerem o uso de habilidades adquiridas anteiormente para sua transposição, e salas de objetivo demarcam o local para se adicionar um objetivo. Além do tipo, as salas possuem posição, tamanho (representados por valores inteiros) e um conjunto de portas. Uma sala pode possuir tantas portas quanto o tamanho do seu perímetro. Cada porta, por sua vez, pode ter um dos seguintes tipos: REGULAR_DOOR, LOCKED_DOOR, OBSTACLE_DOOR, CONTINOUS_DOOR e SECRET_DOOR. Portas regulares são normalmente representadas; portas trancadas podem ser abertas apenas por meio de chaves, obtidas em objetivos anteriores; portas com obstáculos são consequências de objetivos do tipo skill_usage ; portas contínuas são um mecanismo para aumentar a variedade dos cenários gerados fazendo com que determinadas portas não sejam representadas, criando a ilusão de salas com design não exclusivamente retangular; o fato de uma porta ser secreta indica que ela deve estar escondida e camuflada junto aos elementos do cenário. Para este protótipo, fixamos o game design e variamos apenas o level design e o visual design. O game design determinado consiste da seguinte lista de objetivos:

71 59 1. Passagem secreta. 2. Chave. Objetivo secreto e que continua no mesmo caminho do anterior. 3. Porta trancada. 4. Chefe. Continuando no mesmo caminho do anterior. 5. Habilidade de míssil. Continuando no mesmo camiho do anterior. 6. Uso de habilidade de míssil, para destruir uma parede. 7. Chefe 2. Continuando no mesmo caminho do anterior. 8. Fim. Continuando no mesmo caminho do anterior. Para a geração de visual design, utilizamos a abordagem de chunks com planejamento baseado em intenções. Implementar a geração de cenário com base em chunks significava introduzir nos temas um mapeamento de intenções para coordenadas de textura. Para tanto, usamos uma mecânica de referência à coordenadas de textura por índice, de modo que apenas um índice inteiro era sufuciente para representar as coordenas de textura de um determinado chunk. Para representar chunks em mais de uma textura, os índices de chunks foram deslocados para a esquerda em 4 bits e este espaço extra foi usado para indicar a textura de cada chunk, de modo a possibiliar que chunks em texturas distintas fizessem parte do mesmo tema. Desse modo, para cada possível configuração de intenções em uma célula, há ao menos um índice no mapa de chunks do tema em vigor. As Figuras 5.1 e 5.2 mostram exemplos de bibliotecas de chunks usadas no protótipo. Graças ao uso de chunks, foi possível obter variedade na geração de visuais e ainda garantir sua corretude, como pode ser visto nas figuras de 5.1 a 5.4, que mostram exemplos de cenários gerados pelo protótipo. As figuras de 5.4a a 5.3f ilustram diferentes situações construídas pelo algorítmo, de modo a demonstrar sua versatilidade visual. Já as figuras 5.3g, 5.4 e 5.5 apresentam exemplos de cenários completos gerado com base na lista de objeivos anteiormente descrita.

72 Capítulo 5. Resultados 60 Figura 5.1: Mapa de chunks usado na geração dos cenários da Figura 5.3. Com base nas figuras, é possível notar que a organização estrutural dos cenários gerados se assemelha à dos jogos de plataforma/aventura, graças às etapas de game design e level design. Apesar de permitir a combinação do planejamento procedural com visuais feitos por artistas e garantir a corretude dos cenários gerados, a técnica proposta partilha de alguns dos problemas das abordagens baseadas em chunks. Em especial, da necessidade de se ter uma grande quantidade de chunks para representar todas as possíveis situações. Isto é especialmente crítico em jogos de plataforma/aventura, cujo gameplay é fortemente orientado à habilidades, uma vez que para cada habilidade distinta deve haver uma série de chunk para representar seu uso em diversas situações.

73 61 Figura 5.2: Mapa de chunks usado na geração dos cenários das figuras 5.4 e 5.5. Como consequência, e em virtude do tempo restante, não foi possível implementar no protótipo a renderização de portas ou obstáculos, visto que seria necessário uma quantidade sensivelmente maior de chunks para tanto. Isto se reflete na ausência de elementos para representar portas ou obstáculos nas figuras de 5.3g a 5.5. Apenas a geração da geometria básica das salas foi pssível de ser gerada. Ainda assim, sua localização estava prevista no planejamento do interior de salas. Além disso, os caminhos simples estabelecidos pelo uso de intenções conferem um visual semelhante a corredores para as salas, como visto na Figura 5.3, o que em muitos casos não é desejável. Este problema também poderia ser reduzido com uma maior biblioteca de chunks.

74 Capítulo 5. Resultados 62 (a) (b) (c) (d) (e) (f) (g) Figura 5.3: Exemplos de geração de cenário usando intenções e chunks.

75 63 (a) (b) Figura 5.4: Exemplos de geração de cenário usando intenções e chunks.

76 Capítulo 5. Resultados 64 (a) (b) Figura 5.5: Exemplos de geração de cenário usando intenções e chunks.