Motivation

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.

4.2.1

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

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 corres- pondente 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

43 4.2. Usando Ações e algoritmos processo de planejamento. O game design, contudo, ainda pôde ser gerado de antemão.

4.2.2

Gerando Visuais com algoritmos

Esta técnica tinha como objetivo usar a lista de instâncias de ações para deter- minar 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 unida- des, 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.

4.2.3

Problemas com o Uso de Ações e algoritmos

As idéias descritas nesta seção foram capazes de reduzir sensivelmente a depen- dência de recursos externos, que era o caso com a abordagem baseada em chunks, que precisavam ser pré-fabricados e armazenados. Contudo, outros problemas fo- ram 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

(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 cami- nhada.

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,

45 4.3. Usando Ações e Tiles