modelos e algoritmos para o problema de planejamento para ......oliveira, caio freitas de. modelos e...
TRANSCRIPT
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e
Computação
Modelos e Algoritmos para o Problema dePlanejamento para Produção de Recursos em
Jogos de Estratégia de Tempo Real
Caio Freitas de Oliveira
Natal-RN
Agosto de 2016
Caio Freitas de Oliveira
Modelos e Algoritmos para o Problema de
Planejamento para Produção de Recursos em Jogos de
Estratégia de Tempo Real
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.
Orientadora
Dra. Elizabeth Ferreira Gouvêa Goldbarg
Universidade Federal do Rio Grande do Norte � UFRN
Centro de Ciências Exatas e da Terra � CCET
Departamento de Informática e Matemática Aplicada � DIMAp
Programa de Pós-Graduação em Sistemas e Computação � PPgSC
Natal-RN
Agosto de 2016
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial
Especializada do Centro de Ciências Exatas e da Terra – CCET.
Oliveira, Caio Freitas de. Modelos e algoritmos para o problema de planejamento para produção de recursos em jogos de estratégia de tempo real / Caio Freitas de Oliveira. – Natal, RN, 2016. 91 f. : il.
Orientadora: Profa. Dra. Elizabeth Ferreira Gouvêa Goldbarg.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação.
1. Inteligência artificial – Dissertação. 2. Modelos de otimização – Dissertação.
3. Otimização multiobjetivo – Dissertação. 4. Jogos de estratégia em tempo real – Dissertação. 5. Planejamento de projeto – Dissertação. I. Goldbarg, Elizabeth Ferreira Gouvêa. II. Universidade Federal do Rio Grande do Norte. III. Título. RN/UF/BSE-CCET CDU 004.8
I can't believe they put me in one of these things!
I told 'em I was claustrophobic, I gotta get outta here!
SCV, StarCraft
Modelos e Algoritmos para o Problema dePlanejamento para Produção de Recursos em Jogos de
Estratégia de Tempo Real
Autor: Caio Freitas de Oliveira
Orientadora: Dra. Elizabeth Ferreira Gouvêa Goldbarg
Resumo
Jogos de estratégia em tempo real (RTS) apresentam muitos desa�os para a criação de
inteligências arti�ciais. Um destes desa�os é criar um plano de ações efetivo dentro de um
dado contexto. Um dos jogos utilizados como plataforma para criação de inteligências ar-
ti�ciais competitivas é o StarCraft. Tais inteligências arti�ciais para jogos têm di�culdade
em se adaptar e criar bons planos para combater a estratégia inimiga. Neste trabalho, um
novo modelo de escalonamento de tarefas é proposto para os problemas de planejamento
em jogos RTS. Este modelo considera eventos cíclicos e consiste em resolver um problema
multiobjetivo que satisfaz restrições impostas pelo jogo. São considerados recursos, tare-
fas e eventos cíclicos que traduzem as características do jogo em um caso do problema.
O estado inicial do jogo contém as informações sobre os recursos, tarefas incompletas e
eventos ativos. A estratégia de�ne quais recursos maximizar ou minimizar e quais res-
trições são aplicadas aos recursos, bem como o horizonte de projeto. São investigados
quatro otimizadores multiobjetivo: NSGA-II e sua variante focada em joelhos, GRASP e
Colônia de Formigas. Experimentos com casos baseados em problemas reais de Starcraft
são reportados. Nestes experimentos, o NSGA-II mostrou um desempenho superior aos
outros otimizadores.
Palavras-chave: Modelos de Otimização, Otimização Multiobjetivo, Jogos de Estratégia
em Tempo Real, Planejamento de Projeto.
Models and Algorithms for the Resource ProductionScheduling Problem on Real-time Strategy Games
Author: Caio Freitas de Oliveira
Advisor: Dra. Elizabeth Ferreira Gouvêa Goldbarg
Abstract
Real-time strategy (RTS) games hold many challenges in the creation of a game arti�cial
intelligence (AI). One of those challenges is creating an e�ective plan for a given context.
A game used as platform for experiments and competition of game AIs is StarCraft. Its
game AIs have struggled to adapt and create good plans to counter the opponent strategy.
In this paper, a new scheduling model is proposed to planning problems on RTS games.
This model considers cyclic events and consists in solving a multi-objective problem that
satis�es constraints imposed by the game. Resources, tasks and cyclic events that trans-
late the game into an instance of the problem are considered. The initial state contains
information about resources, uncompleted tasks and on-going events. The strategy de�nes
which resources to maximize or minimize and which constraints are applied to the resour-
ces, as well as to the project horizon. Four multi-objective optimizers are investigated:
NSGA-II and its knee variant, GRASP and Ant Colony. Experiments with cases based
on real Starcraft problems are reported. In these experiments, NSGA-II showed better
performance than the other optimizers.
Keywords : Optimization Model, Multi-objective Optimization, Real-time Strategy Ga-
mes, Project Scheduling.
Lista de �guras
1 Captura de tela de Dune II. . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2 Recursos de StarCraft. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3 Soluções para a estratégia exemplo. . . . . . . . . . . . . . . . . . . . . p. 43
4 Soluções para a estratégia exemplo. . . . . . . . . . . . . . . . . . . . . p. 48
5 Representação de um sistema de um jogo simples de coleta de recursos e
produção de unidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50
6 Grafo para um algoritmo de criação de soluções baseado em formigas. . p. 60
7 Hipervolumes para as meta-heurísticas utilizadas. . . . . . . . . . . . . p. 67
8 Tempo em segundos para os otimizadores testados. . . . . . . . . . . . p. 68
9 Soluções encontradas pelas meta-heurísticas para o caso de teste (l). . . p. 70
10 Base inicial em StarCraft após poucos minutos de jogo. . . . . . . . . . p. 76
11 Recursos na interface grá�ca de StarCraft. . . . . . . . . . . . . . . . . p. 77
12 Matriz psiônica dos Protoss. . . . . . . . . . . . . . . . . . . . . . . . . p. 78
13 Árvore tecnológica dos Protoss. . . . . . . . . . . . . . . . . . . . . . . p. 79
14 Árvore tecnológica dos Terran. . . . . . . . . . . . . . . . . . . . . . . . p. 83
15 Gosma dos Zerg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
16 Árvore tecnológica dos Zerg. . . . . . . . . . . . . . . . . . . . . . . . . p. 87
17 Hipervolume de um conjunto de pontos num espaço bidimensional. . . p. 91
Lista de tabelas
3 Recursos do exemplo de produção de recursos. . . . . . . . . . . . . . . p. 41
4 Tarefas do exemplo de produção de recursos. . . . . . . . . . . . . . . . p. 41
5 Estado inicial I0 do exemplo de produção de recursos. . . . . . . . . . . p. 42
6 Eventos do exemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
7 Tarefas do exemplo com eventos cíclicos. . . . . . . . . . . . . . . . . . p. 46
8 Estado inicial I0 do exemplo com eventos cíclicos. . . . . . . . . . . . . p. 47
9 Intervalos de valores dos parâmetros comuns utilizados pelo irace. . . . p. 63
10 Parâmetros comuns encontrados para os otimizadores pelo irace. . . . . p. 63
11 Intervalos de valores dos parâmetros especí�cos utilizados pelo irace. . . p. 64
12 Parâmetros especí�cos encontrados para os otimizadores pelo irace. . . p. 64
13 Funções objetivo e restrições adicionais para os casos de teste dos expe-
rimentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
14 Ranking dos algoritmos baseado nas medianas de cada indicador. . . . p. 66
15 Resultado dos p-valores para o teste U de Mann-Whitney. . . . . . . . p. 69
Lista de abreviaturas e siglas
AIIDE Arti�cial Intelligence and Interactive Digital Entertainment
CIG Computational Intelligence and Games
GRASP Greedy Randomized Adaptve Search Procedure
IA Inteligência Arti�cial
IEEE Institute of Electrical and Electronics Engineers
MOACO Multi-Objective Ant Colony Optimization
MOGRASP Multi-Objective GRASP
NSGA-II Non-Dominated Sorting Genetic Algorithm II
PDDL Planning Domain De�nition Language
PPOPR Problema de Planejamento Online para Produção de Recursos em RTS
PPPMRR Problema de Planejamento de Projetos Multimodo com Restrição de Re-
cursos
PPPR Problema de Planejamento para Produção de Recursos
PPPREC Problema de Planejamento para Produção de Recursos com Eventos Cí-
clicos
RTS Real-Time Strategy
SLA* Search and Learn A*
Lista de símbolos
α In�uência dos feromônios no algoritmo MOACO
β In�uência da heurística no algoritmo MOACO
δc Contribuição de custos e consumos de tarefas úteis, para o algoritmo de criação
de soluções
δm Contribuição do aumento do máximo utilizável de um recurso produzido por
tarefas úteis, para o algoritmo de criação de soluções
δo Contribuição de objetivos, para o algoritmo de criação de soluções
δp Contribuição de pré-requisitos e usos de tarefas úteis, para o algoritmo de cri-
ação de soluções
δr Contribuição de restrições, para o algoritmo de criação de soluções
δFo Contribuição de objetivos, para o algoritmo de reconstrução de soluções
δFr Contribuição de restrições, para o algoritmo de reconstrução de soluções
∆o Fator de aumento do contribuição δo, no algoritmo de criação de soluções
∆r Fator de aumento do contribuição δr, no algoritmo de criação de soluções
∆Fo Fator de aumento do contribuição δFo , no algoritmo de reconstrução de soluções
∆Fr Fator de aumento do contribuição δFr , no algoritmo de reconstrução de soluções
ρ Taxa de evaporação dos feromônios no algoritmo MOACO
τi Tempo real de início do evento i, para o PPPREC
Brt Quantidade do recurso r imobilizada no tempo t, para o PPPR
Boir Quantidade do recurso r necessária como uso para realização da tarefa i, para
o PPPR
c Quantidade de soluções criadas pelos algoritmos heurísticos
Cmax Tempo de conclusão da última tarefa (makespan)
Crt Total coletado do recurso r a partir do estado inicial até o tempo t,
para o PPPR
Cmir Quantidade do recurso r necessária como consumo para realização da tarefa i,
para o PPPR
Ctir Quantidade do recurso r necessária como custo para realização da tarefa i, para
o PPPR
di Duração da tarefa i, para o PPPR
dim Duração da tarefa i no modo m, para o PPPMRR
ei Tempo de término da tarefa i, para o PPOPR
E Conjunto de arestas que representam precedências, para o PPPMRR
Esr Valor binário que indica a equivalência entre os recursos s e r, para o PPPR
ESi Tempo mais cedo de início da tarefa i, para o PPPMRR
G Grafo dirigido representativo da rede de dependências do projeto, para o
PPPMRR
K Conjunto de limites superiores para as funções do conjunto U , para o PPPR
I0 Estado inicial, para o PPPR
L Conjunto de limites inferiores para as funções do conjunto V , para o PPPR
LB Menor tempo de início de uma tarefa ou evento presente no estado inicial I0,
para o PPPREC
LSi Tempo mais tardio de início da tarefa i, para o PPPMRR
mr Valor mínimo para o recurso r, para o PPOPR
M Conjunto de funções-objetivo para maximizar, para o PPPR
Mi Quantidade de modos da tarefa i, para o PPPMRR
MCr Máximo coletável do recurso r a partir do estado inicial até o tempo t, para o
PPPR
MUrs Máximo utilizável do recurso r por unidade de outro recurso s, no PPPR
nilm Quantidade consumida do recurso não-renovável l pela tarefa i no modo m,
para o PPPMRR
N Conjunto de funções-objetivo para minimizar, para o PPPR
N(?,?) Relação de vizinhança de conjuntos em que soluções de vizinhanças de várias so-
luções de um conjunto são adicionadas à fronteira de aproximação, para buscas
locais multiobjetivo baseadas em conjuntos
N Conjunto de recursos não-renováveis, para o PPPMRR
Nl Quantidade inicial do recurso não-renovável l, para o PPPMRR
O Estratégia a ser otimizada pelo PPPR
O Conjunto de restrições, para o PPOPR
Prir Quantidade do recurso r necessária como pré-requisito para realização da tarefa
i, para o PPPR
qr Quantidade de recurso r, para o PPOPR
rikm Quantidade requerida do recurso renovável k pela tarefa i no modo m, para o
PPPMRR
R Conjunto de recursos, para o PPPR
R Conjunto de recursos renováveis, para o PPPMRR
R Conjunto de recursos, para o PPOPR
Rk Quantidade disponível do recurso renovável k, para o PPPMRR
si Tempo de início da tarefa i, para o PPOPR
S Sistema que representa o jogo, para o PPPR
Smax Tempo de início da última tarefa, para o PPPR
T Conjunto de tarefas, para o PPPR
T Conjunto de tarefas não-concluídas, para o PPOPR
Tf Tarefa postiça �nal, para o PPPMRR
Tim Modo m da tarefa não-postiça i, para o PPPMRR
urt Total consumido do recurso r a partir do estado inicial até o tempo t, para o
PPPR
U Conjunto de funções de restrição com limite superior, para o PPPR
Urt Quantidade utilizável do recurso r a partir do estado inicial até o tempo t, para
o PPPR
UB Tempo máximo para execução da ordem de tarefas, ou horizonte do projeto
V Conjunto de funções de restrição com limite inferior, para o PPPR
V Conjunto de vértices que representam tarefas, para o PPPMRR
x Variável de decisão do PPPR
xe Variável de decisão adicional do PPPREC
ximt Variável de decisão do PPPMRR
yf Valor da função f no tempo de conclusão da última tarefa ou no tempo máximo,
caso a última tarefa termine após este tempo, para o PPPR
Lista de algoritmos
1 Função que atribui o peso a uma tarefa task baseada numa contribuição δ p. 51
2 Algoritmo para valoração inicial de tarefas em um estado I0 segundo uma
estratégia O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
3 Algoritmo de valoração de tarefas em um estado I0 segundo uma estra-
tégia O. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4 Algoritmo de geração de soluções para um estado I0 e uma estratégia O. p. 55
5 NSGA-II Simpli�cado . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
6 Algoritmo de ordenação baseada em ângulos . . . . . . . . . . . . . . . p. 58
7 GRASP multiobjetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
8 Criação de soluções através de formigas . . . . . . . . . . . . . . . . . . p. 60
9 Colônia de formigas multiobjetivo . . . . . . . . . . . . . . . . . . . . . p. 61
Sumário
1 Introdução p. 17
1.1 Jogos de Estratégia em Tempo Real . . . . . . . . . . . . . . . . . . . . p. 17
1.2 StarCraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.3 RTS em Inteligência Arti�cial . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.4 Planejamento de Produção em StarCraft . . . . . . . . . . . . . . . . . p. 21
1.5 Problemas de Otimização . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
1.6 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
1.7 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
1.8 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
1.9 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
1.10 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2 Revisão Bibliográ�ca p. 27
2.1 Problema de Planejamento Online para Produção de Recursos em RTS p. 27
2.1.1 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.1.2 Aplicação em jogos RTS . . . . . . . . . . . . . . . . . . . . . . p. 28
2.2 Problema de Planejamento de Projetos . . . . . . . . . . . . . . . . . . p. 30
2.2.1 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
2.2.2 Aplicação em jogos RTS . . . . . . . . . . . . . . . . . . . . . . p. 32
3 Problemas Propostos p. 34
3.1 Problema de Planejamento para Produção de Recursos . . . . . . . . . p. 34
3.1.1 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.1.2 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3.1.3 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.1.4 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 40
3.2 Problema de Planejamento para Produção de Recursos com Eventos Cí-
clicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
3.2.1 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
3.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
3.2.3 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4 Algoritmo de Geração de Soluções p. 49
4.1 Valoração de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.2 Criação de Soluções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
5 Meta-heurísticas p. 56
5.1 NSGA-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
5.1.1 �Knee� . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57
5.2 MOGRASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
5.3 MOACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
6 Experimentos Computacionais p. 63
7 Conclusão p. 71
Referências p. 73
Apêndice A -- Descrição do jogo StarCraft p. 76
A.1 Protoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.1.1 Estruturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
A.1.2 Unidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
A.2 Terran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.2.1 Estruturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
A.2.2 Unidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 85
A.3 Zerg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 86
A.3.1 Estruturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 88
A.3.2 Unidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 89
Apêndice B -- Hipervolume p. 91
17
1 Introdução
Este trabalho apresenta um novo problema de planejamento que tem como inspiração
o ambiente dos jogos de estratégia em tempo real. Neste capítulo, iremos introduzir os
conceitos de jogos de estratégia em tempo real, as peculiaridades de um jogo deste gênero,
StarCraft, e mostrar como sua di�culdade e dinamismo inspirou pesquisadores a criar
novos métodos de Inteligência Arti�cial voltados a este ambiente. O pesquisador do Google
Je�rey Dean indicou a possibilidade do Google DeepMind voltar seus esforços a este
jogo (WEINBERGER, 2016), após a derrota do campeão mundial de Go Lee Sedol para a
inteligência arti�cial AlphaGo.
1.1 Jogos de Estratégia em Tempo Real
Jogos de estratégia em tempo real, ou RTS (Real-Time Strategy), tiveram seu início
com o lançamento de Dune II 1 em 1992. Desde então, vários títulos do mesmo gênero
foram lançados, como as séries WarCraft, Age of Empires e Command & Conquer. Deste
gênero, a série de maior sucesso tanto como produto quanto como esporte eletrônico é a
StarCraft2.
Os jogos de estratégia em tempo real possuem um conjunto de características que os
diferenciam de outros jogos:
• Coleta de recursos;
• Construção de estruturas;
• Produção de unidades;
• Diferentes facções;
1Publicado pela Virgin Interactive, desenvolvido pela Westwood Studios.2Publicado e desenvolvido pela Blizzard Entertainment.
18
Figura 1: Captura de tela de Dune II.
• Mapa conceitual do campo de batalha (ver Figura 1);
• Controle feito pelo cursor do mouse.
Partidas deste gênero começam com um estado inicial similar: o jogador possui no
início do jogo uma pequena quantidade de recursos, uma estrutura que serve de base e
trabalhadores para coletar recursos. Alguns jogos dão ao jogador unidades militares no
início do jogo também, como os jogos da série Age of Empires. Com estes coletores de
recursos, o jogador poderá investir seus recursos em aprimorar sua economia, ao criar
novos trabalhadores e novas bases, e criar um exército forte o bastante para derrotar o
seu adversário.
Como este gênero de jogos se joga em tempo real, as decisões que o jogador deve
tomar devem ser ponderadas enquanto se controla todo o grupo de unidades criado por
ele. Esse controle envolve: (a) patrulhar o terreno de jogo em busca de novos recursos e
unidades inimigas, para aquisição de informações sobre suas posições e as decisões tecno-
lógicas tomadas pelos oponentes; (b) expandir sua economia para lugares determinados
como seguros, criando novas estruturas de produção de unidades ou de coleta de recursos;
(c) confrontar as unidades inimigas de maneira vantajosa, controlando cada unidade do
confronto e�cientemente; (d) criar unidades militares e�cientes contra o exército inimigo.
19
1.2 StarCraft
StarCraft é um RTS em que o jogador deve coletar dois tipos de recursos, minérios e
gás vespeno, para poder enfrentar um grupo de inimigos. Esses recursos são normalmente
distribuídos pelo mapa de forma tal que se possa criar uma base de extração, também
chamada de expansão, próxima a todas as fontes de recursos3, jazidas de minérios e
gêiseres de gás vespeno (Figura 2). O conjunto de jazidas de minérios próximo a uma base
é chamado de linha de minério.
(a) Jazidas de minérios (b) Gêiser de gás vespeno
Figura 2: Recursos de StarCraft.
Este jogo possui três facções, chamadas de raças, que o jogador pode escolher antes
das partidas: Protoss, Terran e Zerg. Todas as raças possuem mecânicas únicas, porém
a raça Zerg possui características que se diferem de forma mais nítida das outras. Ao
invés de produzir unidades por construções especializadas que trabalham com uma �la
de produção, os Zerg possuem uma estrutura que produz continuamente uma unidade
chamada larva. Larvas podem se transformar em qualquer unidade que o jogador possa
construir. Além disso, estruturas podem �evoluir�, isto é, elas podem se transformar em
outras estruturas, habilitando novas possibilidades tecnológicas. Uma descrição completa
do jogo se encontra no Apêndice A.
1.3 RTS em Inteligência Arti�cial
A partir do trabalho de Buro (2003), cujo foco é estimular pesquisas de inteligência
arti�cial voltada a jogos RTS, muitos trabalhos foram feitos usando StarCraft como objeto
de estudo, (NAVES; LOPES, 2012), (SAJJAD; ISLAM, 2011), (HAGELBÄCK, 2012). Pelo que
foi mostrado por Ontañón et al. (2013), jogos deste gênero são ambientes complexos,
onde as técnicas de IA ainda têm di�culdades, pois possuem um espaço de estados muito
3Estruturas neutras que são o alvo da coleta de recursos.
20
grande.
Jogos clássicos, como Xadrez e Go, possuem uma grande complexidade com regras
inteligentes e objetivos simples. Por este motivo, eles foram alvo de diversos trabalhos,
como mostra o trabalho de Bouzy e Cazenave (2001). Conforme ONTAÑÓN et al. expli-
cam, jogos de estratégia em tempo real possuem uma complexidade muito superior às
complexidades destes dois jogos, que continuam a ser explorados por diversas técnicas de
inteligência arti�cial.
Outra maneira de medir a complexidade do jogo é olhando o fator derami�cação, b, e a profundidade do jogo, d, [...] , com uma complexidadetotal de bd. Em Xadrez, b ≈ 35 e d ≈ 80. Em jogos mais complexos, comoGo, b ≈ 30 a 300, e d ≈ 150 a 200. A �m de determinar o fator de rami-�cação em StarCraft quando uma IA o joga, nós devemos ter em menteque a IA pode dar ações simultaneamente a quantas unidades no jogofor desejado. Então, considerando que, em um jogo típico, um jogadorcontrola entre 50 e 200 unidades, o fator de rami�cação �caria entre u50
e u200, onde u é o número médio de ações que cada unidade pode exe-cutar. Estimar o valor de u não é fácil, pois o número de ações que umaunidade pode tomar é altamente dependente do contexto. [...] Agora, setivermos em mente que ações possuem tempos de cool-down4, e assimnem todas as unidades podem executar todas as ações a todo quadro,podemos tomar uma estimativa conservadora de cerca de 10 possíveisações por unidade por quadro do jogo. Isto resulta em uma estimativaconservadora para o fator de rami�cação entre b ∈ [1050, 10200], somenteconsiderando unidades (ignorando as ações que construções podem exe-cutar). Agora, para computar d, nós simplesmente consideramos o fatode que os jogos típicos duram em torno de 25 minutos, o que resultaem d ≈ 36000 (25 minutos × 60 segundos × 24 quadros por segundo)(ONTAÑÓN et al., 2013, p. 294).
Esta comparação de complexidade mostra uma diferença grande entre a quantidade
de estados dos jogos. Devido a esse fator, pesquisadores como BURO e ONTAÑÓN et al.
acreditam que o investimento de pesquisas com foco em jogos de estratégia em tempo real
possibilita um amplo melhoramento ou criação de técnicas de inteligência arti�cial.
Após 10 anos de publicação do trabalho de Buro e vários artigos sobre StarCraft e seu
gênero, Ontañón et al. (2013) expuseram os seis atuais desa�os na criação de inteligências
arti�ciais para jogos RTS: (a) planejamento, (b) aprendizado, (c) incerteza, (d) raciocínio
temporal e espacial, (e) exploração do conhecimento de domínio, (f) decomposição de
tarefas. Destes desa�os, este trabalho foca no planejamento a longo prazo. Ao contrário
do planejamento a curto prazo que está voltado ao microgerenciamento das unidades,
4Tempo de cool-down é o tempo em que uma habilidade ou ataque �ca indisponível entre um uso eoutro. Esse conceito não se restringe aos RTS e pode ser observado em jogos como World of WarCraft.
21
o planejamento a longo prazo buscar encontrar uma série de ações que consiga cumprir
algumas restrições dadas pelo jogador arti�cial, normalmente voltadas a desenvolver uma
economia forte.
1.4 Planejamento de Produção em StarCraft
StarCraft possui uma natureza determinística, no sentido de que toda ação demora o
tempo exato que foi programado, além de não haver chance de erro nos movimentos das
unidades, construção de estruturas ou produção de unidades. Por manter essa dinâmica
previsível, é possível imaginar a produção de unidades e estruturas como um problema de
planejamento. Para isso, é necessário gravar o estado atual dos recursos. Esta �fotogra�a�
do sistema permite simular o ambiente do jogo a partir de um determinado ponto, chamado
de estado inicial do planejador.
Para encontrar a melhor ordem de tarefas ou ordem de construção, a otimização foi
escolhida pela simplicidade das ações no jogo. Porém, os problemas clássicos de otimiza-
ção de planejamento não se encaixam na natureza de produção dinâmica de recursos de
um RTS. Isto não impediu que modelos fossem criados para otimizar ordens de constru-
ção. Estes modelos se aproximaram da área de planejamento de inteligências arti�ciais,
seja usando uma linguagem especí�ca da área, PDDL ou Planning Domain De�nition
Language, para descrever o problema de otimização de ordens de construção (KOVARSKY;
BURO, 2006), seja usando planejadores em conjunto com algoritmos de busca local (NA-
VES, 2012). Duas abordagens utilizando algoritmos genéticos foram implementadas apenas
para a segunda versão do jogo, StarCraft 2 (KUCHEM; PREUSS; RUDOLPH, 2013) (KÖS-
TLER; GMEINER, 2013). A abordagem mais utilizada para representação do problema de
produção é o modelo de planejamento online para produção de recursos em RTS (CHAN
et al., 2007b). Esta abordagem ainda se faz dependente de planejadores e não possui uma
formulação matemática próxima dos problemas de planejamento clássicos.
O modelo de otimização proposto neste trabalho procura aproximar-se do problema
clássico de planejamento de projeto, adotando uma abordagem de otimização combinató-
ria em comparação aos outros métodos mais próximos dos métodos de planejamento para
inteligência arti�cial. Ao invés de se especializar nas informações particulares do jogo, um
modelo generalista é proposto, onde aspectos do jogo, como limite máximo de capaci-
dade de suprimentos, podem ser aplicados. Estas restrições não foram estabelecidas em
nenhum outro modelo de otimização até então. Além disso, recursos podem estar tanto
22
nas restrições como nas função objetivo. Dos métodos multiobjetivo para otimização de
ordens de construção, apenas um deles utiliza recursos como função objetivo (KUCHEM;
PREUSS; RUDOLPH, 2013) e, entre esses métodos, todos usaram algoritmos genéticos para
otimização. O trabalho de Köstler e Gmeiner (2013) e o trabalho de Blackford (2014) uti-
lizaram o algoritmo NSGA-II como otimizador em conjunto com outros algoritmos como
planejadores. O trabalho de Kuchem, Preuss e Rudolph (2013), entretanto, faz uma aná-
lise multiobjetiva utilizando um otimizador mono-objetivo variando restrições ao longo
de um intervalo de valores.
1.5 Problemas de Otimização
Este trabalho propõe um novo problema de otimização. Problemas de otimização
podem ser divididos entre os problemas mono-objetivo e os problemas multiobjetivo. O
problema proposto é um problema de otimização multiobjetivo. Para explicar problemas
multiobjetivo, é preciso familiaridade com os problemas de otimização mono-objetivo.
Estes problemas de otimização possuem uma função objetivo que deve ser minimizada,
f(x). Isto é, o otimizador deve procurar um x tal que f(x) seja o menor possível. Estes
problemas possuem a seguinte forma (BOYD; VANDENBERGHE, 2009):
minimizar f(x) (1.1)
sujeito a gi(x) ≤ bi, i = 1, . . . ,m (1.2)
Onde x = (x1, . . . , xn) é a variável de decisão do problema, a função f : Rn → R é
a função objetivo, as funções gi : Rn → R, i = 1, . . . ,m são as funções de restrição e as
constantes b1, . . . , bm são os limites. Um vetor x∗ é chamado de ótimo quando ele possui
o menor valor objetivo entre todos os vetores que satisfazem as restrições, isto é, para
qualquer z tal que g1(z) ≤ b1, . . . , gm(z) ≤ bm, nós temos f(z) ≥ f(x∗).
O problema proposto neste trabalho é um problema de otimização multiobjetivo. Tais
problemas possuem pelo menos duas função objetivos, e por isso precisam de um método
de comparação de soluções mais elaborado. Estes problemas possuem a forma:
minimizar f(x) = (f1(x), . . . , fk(x)) (1.3)
sujeito a gi(x) ≤ bi, i = 1, . . . ,m (1.4)
Ao invés de apenas uma única função objetivo, problemas multiobjetivos possuem
23
um conjunto de função objetivo f1(x), . . . , fk(x) que são igualmente importantes (ZITLER;
LAUMANNS; BLEULER, 2004). Então, uma solução para o problema não está relacionada
a um único valor, mas a um vetor chamado vetor objetivo. Como a representação da
qualidade da solução mudou, é necesário usar um outro sistema de comparação, ao invés
da simples comparação: x é melhor que y se e somente se f(x) < f(y).
No caso de múltiplas funções objetivo, precisamos usar o conceito de dominância de
Pareto. Um vetor objetivo f(x) domina outro vetor objetivo f(y), ou f(x) � f(y), se
não há um componente de f(x) maior que o componente correspondente em f(y) e pelo
menos um componente de f(x) é menor que o componente correspondente em f(y). Uma
solução é chamada de ótima caso não haja nenhuma outra solução que a domine. Desta
forma, podem haver muitas soluções ótimas que representam diferentes trade-o�s entre
os objetivos.
O conjunto de soluções ótimas em um problema multiobjetivo é chamado de conjunto
de Pareto e está relacionado a vetores objetivo. O conjunto destes vetores objetivo é
chamado de fronteira de Pareto. Então, otimização multiobjetivo busca obter todas as
soluções no conjunto de Pareto para ajudar o tomador de decisão a escolher a melhor
solução.
1.6 Motivação
Os desa�os de criar um plano de ações em tempo-real são grandes, ainda mais em um
ambiente dinâmico como um jogo RTS. O modelo estado-da-arte utilizado para o problema
de produção de recursos (CHAN et al., 2007b) consegue agregar muitas características de um
RTS, porém ele não possui nenhuma formulação matemática bem de�nida, nem consegue
tratar como os suprimentos são utilizados em um ambiente real. Este modelo teve uma
versão multiobjetivo apresentada por Blackford (2014), mas não utilizou recursos como
função objetivo, mas parâmetros de comparação com um estado-objetivo.
Além disso, não é possível modelar de maneira natural as características da raça Zerg,
o que o torna impraticável para uma raça de StarCraft. Esta raça foi escolhida também
por ser presumidamente mais difícil de se criar inteligências arti�ciais para ela (ONTAÑÓN
et al., 2013). Os torneios da IEEE Conference on Computational Intelligence and Games
(IEEE CIG) não apresentaram inscrições de inteligências arti�ciais para a raça Zerg até
a conferência de 2015, quando as três novas inteligências Zerg ganharam os três primeiros
lugares.
24
Como as estratégias dentro de um jogo podem mudar drasticamente, devido ao ta-
manho da árvore de possibilidades, o número de restrições e objetivos também deve ser
variável. Esta variabilidade não é vista em nenhum modelo de planejamento que tenha
sido utilizado em ambientes RTS.
1.7 Objetivo
O trabalho tem como objetivo princiapl propor um novo modelo de otimização que
consiga uni�car os modelos de planejamento de projeto com o modelo de planejamento
online para produção de recursos em RTS sob um foco multiobjetivo, procurando atender
às características da raça Zerg.
O modelo proposto é um problema de planejamento para produção multiobjetivo ge-
neralista. Embora tenha inspiração na raça Zerg, não é exclusivo à esta raça. O problema
possui uma função objetivo em comum entre todos os casos, minimizar o tempo de con-
clusão das tarefas. Ao contrário do problema proposto por CHAN et al., mais do que chegar
a um determinado estado escolhido, deseja-se otimizar a utilização dos recursos do jogo.
Então, as funções objetivo adicionais são apenas recursos do sistema dado.
Como problema multiobjetivo, não se procura apenas um estado ótimo, mas vários
estados em que cada um apresente um trade-o� diferente entre o tempo e os recursos
selecionados como funções objetivo.
1.8 Contribuições
• Apresentação de um modelo para planejamento da produção e utilização de recursos
de um jogo RTS;
• Modelagem multiobjetivo generalista voltada para otimização do tempo de término,
com quantidade variável de restrições e funções objetivo adicionais, para melhor
atender as necessidades de uma determinada estratégia e capaz de ser utilizado em
outros contexto além da raça Zerg em StarCraft ;
• Introdução de algoritmos baseados nas meta-heurísticas Algoritmo Genético, GRASP
e Colônia de Formigas, bem como análise experimental dos resultados.
Como fruto deste trabalho, um artigo foi aceito na IEEE Conference on Evolutionary
25
Computation 2016 (IEEE CEC 2016), expondo o modelo apresentado nesta dissertação
(OLIVEIRA; GOLDBARG; GOLDBARG, 2016).
1.9 Metodologia
Para con�rmar a consistência do modelo proposto, quatro otimizadores foram im-
plementados. Dois otimizadores são baseados em algoritmos genéticos, NSGA-II (Non-
Dominated Sorting Genetic Algorithm) e sua versão voltada a joelhos. Os outros oti-
mizadores são o GRASP (Greedy Randomized Adaptve Search Procedure) e o MOACO
(Multi-Objective Ant Colony Optimization). Dois tipos de algoritmos de criação de solu-
ções foram projetados para os otimizadores, visando atender às quantidades variáveis de
restrições e funções objetivo.
Um conjunto de experimentos foi feito em 14 casos de teste, criados para este problema
baseados na raça Zerg. Os casos de teste incluem estratégias consolidadas em ambientes
de competição pro�ssional, e estratégias para veri�car o desempenho de acordo com a
profundidade dos recursos de interesse. Para cada caso de teste, 30 execuções foram feitas.
Indicadores de tempo e hipervolume (BEUME et al., 2009) foram usados para medir o
desempenho dos algoritmos. Os otimizadores têm como objetivo �nal funcionarem em um
cenário real e trabalhar em conjunto com uma inteligência arti�cial para o jogo StarCraft,
então o seu desempenho é crucial para um bom funcionamento da inteligência arti�cial.
Para determinar os valores dos parâmetros de cada otimizador, uma corrida iterativa
foi usada, através da ferramenta irace (LÓPEZ-IBÁÑEZ et al., 2011), em sete casos de teste
baseados em estratégias usadas no início do jogo ao longo de 840 experimentos. Destes
casos de teste, quatro foram usados nos experimentos �nais.
1.10 Organização do trabalho
O restante deste trabalho está dividido em:
• Capítulo 2: explicação e discussão sobre o problema de planejamento online para
produção de recursos em RTS;
• Capítulo 3: explicação e discussão sobre o problema de planejamento de projetos;
• Capítulo 4: introdução ao problema de planejamento de produção de recursos;
26
• Capítulo 5: expansão do problema de produção de recursos com a adição de eventos
cíclicos;
• Capítulo 6: introdução ao algoritmo de geração de soluções;
• Capítulo 7: descrição das meta-heurísticas usadas nos experimentos;
• Capítulo 8: resultados dos experimentos;
• Capítulo 9: conclusões e trabalhos futuros.
27
2 Revisão Bibliográ�ca
Neste capítulo, os problemas que deram inspiração para o modelo apresentado neste
trabalho serão apresentados. Inicialmente o problema de planejamento online para pro-
dução de recursos em RTS será exposto. Em seguida, o problema de planejamento de
projetos será apresentado. Estes problemas são expostos com seus modelos, e suas apli-
cações em jogos RTS serão discutidas. Utilizamos estes modelos como referência para a
criação de um novo problema mais completo, que consiga preencher as lacunas existentes
em cada problema descrito aqui.
2.1 Problema de Planejamento Online para Produção
de Recursos em RTS
O problema de planejamento online para produção de recursos em RTS (PPOPR)
possui grande parte das características que são necessárias para a descrição deste tipo
de jogo, apesar de incompleto. Este modelo de planejamento de produção foi criado por
Chan et al. (2007b). Ele foi o modelo mais utilizado para o jogo StarCraft, e foi utilizado
como base para os trabalhos de Chan et al. (2007a), Branquinho e Lopes (2010), Churchill
e Buro (2011), Naves (2012) e Blackford (2014).
2.1.1 Modelo
O problema de planejamento online para produção de recursos em jogos RTS foi mo-
delado para ser utilizado por uma inteligência arti�cial que controla um jogador de RTS.
Desta forma, assume-se que o agente jogador está executando as tarefas e manipulando
os recursos.
Este problema possui um conjunto de recursos R e um conjunto de restrições O. O
estado do jogo em um instante t possui: (a) para cada recurso r ∈ R, uma quantidade
qr que o agente possui e (b) a lista de ações não-concluídas T , de forma que os tempos
28
de início e �m si e ei obedeçam à restrição si < t < ei, para toda ação i ∈ T . O
objetivo consiste em achar uma sequência de ações que cumpra um conjunto de restrições
O = {q1 ≥ m1, . . . , qn ≥ mn}, a partir do estado atual. Isto é, para cada recurso r ∈ R,existe um valor mínimo mr que deve ser atingido no estado �nal. Dentro deste contexto,
os componentes principais são os recursos e as ações. Recursos são manipulados pelas
ações através de quatro categorias:
• Require: Um recurso necessário para uma ação ser executada, porém não há aumento
ou redução em tal recurso;
• Burrow : Recurso que é �trancado� pela duração da ação, mas é devolvido ao seu
término;
• Consume: Recursos que são removidos ao início da ação;
• Produce: Recursos que são adicionados ao �nal da ação.
2.1.2 Aplicação em jogos RTS
O modelo foi estendido no trabalho de Chan et al. (2007a) para acomodar análise de
meios e �ns no planejamento sequencial de ações. O método de análise de meios e �ns
é um método inicialmente proposto para um solver de propósito geral (NEWELL; SHAW;
SIMON, 1959), e posteriormente utilizado no planejador STRIPS (FIKES; NILSSON, 1971).
A ideia por trás da análise de meios e �ns consiste em construir uma sequência de ações
cujas produções correspondam a partes da descrição do estado-alvo (MCDERMOTT, 1996).
No trabalho de Branquinho e Lopes (2010), o modelo foi usado para a criação de
um otimizador baseado no algorimo SLA*, que já foi utilizado para resolver problemas de
escalonamento de projetos (ZAMANI; SHUE, 1998). Este trabalho comparou um planejador
que usa SLA* em conjunto com o MeaPop, método criado por Branquinho e Lopes (2010)
para a criação de planejamento parcial, e outros dois planejadores que usaram o método
de escalonamento descrito no trabalho de Chan et al. (2007b), um deles usando o MEA e
o outro usando o MeaPop.
Um algoritmo branch and bound foi criado por Churchill e Buro (2011), e então apli-
cado em uma inteligência arti�cial para jogos que participou da competição 2010 AIIDE
StarCraft AI Competition.
O trabalho apresentado por Blackford (2014) possui uma abordagem multiobjetivo
para o modelo inicial, procurando otimizar três objetivos na busca por satisfazer um
29
determinado estado-alvo. O otimizador pode não encontrar o estado-alvo, e retornar um
estado intermediário, chamado de estado �nal. As funções objetivo desta abordagem são:
(a) minimizar o tempo total de sair do estado inicial para o estado �nal encontrado
pelo algoritmo, (b) minimizar a diferença de recursos entre o estado �nal e os recursos
necessários para se chegar ao estado-alvo, (c) minimizar o tempo necessário para se chegar
do estado �nal ao estado-alvo.
Este modelo apresentado por Chan et al. (2007b), entretanto, não descreve relações
entre os recursos, nem possibilita a existência de eventos cíclicos no sistema, tornando
particularmente ruim a modelagem da raça Zerg de StarCraft. Para representar a relação
entre a estrutura Hatchery1 e a unidade Larva de StarCraft, é necessário um modelo que
aceite eventos cíclicos, bem como uma dependência inter-recursos, uma vez que não é
possível possuir mais que três larvas por hatchery e elas são geradas automaticamente a
cada sete segundos. A importância das larvas se dá pela maneira como as unidades são
produzidas por esta raça: ao invés de necessitar de uma estrutura especializada, os Zerg
utilizam larvas para a produção de unidades transformando-as nas unidades desejadas.
Além desta de�ciência, o problema de planejamento online para produção de recursos
em jogos RTS não aceita limites �xos de recursos. Nas séries StarCraft, WarCraft e Age of
Empires, o recurso �suprimento� é limitado por um valor �xo. No caso de StarCraft, este
limite é 200, o que signi�ca que por mais que as ações do jogador possam fazê-lo superar
este limite, isto não acontece devido às regras do jogo. Portanto, utilizar o modelo descrito
anteriormente em situações de meio-jogo ou �nal de jogo pode se tornar inadequado.
Um outro aspecto em que o modelo de Chan et al. (2007b) possui di�culdade em
expressar é quando recursos podem ser tratados como iguais para �ns de requisitos. Isto
acontece em StarCraft quando a estrutura hatchery evolui2 para uma lair ou esta para
uma hive. Estruturas que precisam de uma hatchery podem ser criadas com uma lair ou
uma hive. De forma similar, as estruturas que precisam de uma lair podem ser criadas
com uma hive. Isto pode ser contornado ao criar tarefas idênticas para cada uma des-
sas equivalências, porém haveria um grande número de tarefas idênticas dependendo da
quantidade de equivalências e das dependências relacionadas.
Esta evolução também não consegue ser expressa nos termos anteriores, pois durante
todo o processo de evolução de uma hatchery, ela ainda existe e é válida para preencher
pré-condições de quaisquer ações. Somente quando a evolução é concluída, a hatchery
1Estrutura base da raça Zerg.2A evolução se dá por um processo que transforma uma unidade ou estrutura em outro tipo mais
avançado, efetivamente destruindo a unidade antiga e criando uma nova no seu lugar.
30
deixa de existir e a lair é criada. Assim, um novo tipo de consumo deve existir, que
reduza recursos ao �nal da ação.
Desta forma, este trabalho apresenta um novo modelo para solução de problemas de
planejamento em jogos RTS, para modelar aspectos que não foram explorados nos modelos
já utilizados.
2.2 Problema de Planejamento de Projetos
Neste trabalho será usada a versão de planejamento de projetos multimodo com restri-
ção de recursos (PPPMRR). Esta versão oferece suporte a uma mesma tarefa que possua
diferentes precedências de acordo com o modo em questão. Esta variação de modos é
importante em contextos onde uma unidade ou estrutura pode se transformar em outra,
como a evolução dos Zerg.
2.2.1 Modelo
O modelo do problema de planejamento de projetos multimodo com múltiplos re-
cursos renováveis e não-renováveis (COELHO; VANHOUCKE, 2015) pode ser expresso da
seguinte forma. Um conjunto de tarefas V , numeradas a partir de uma tarefa postiça
inicial 0 até uma tarefa postiça �nal Tf , deve ser escalonado sem preempção em um
conjunto de recursos renováveis R e um conjunto de recursos não-renováveis N . Cada
recurso renovável k ∈ R tem uma disponibilidade constante de Rk unidades, enquanto
cada recurso não-renovável l ∈ N é restrito em Nl unidades por todo o horizonte de pla-
nejamento. Cada tarefa não-postiça i ∈ V pode ser realizada em um de seus Mi modos,
Tim = 〈dim, rikm, nilm〉, onde m ∈ {1, . . . , Mi}, dim é a duração da tarefa, rikm é a quan-
tidade requerida de recursos k ∈ R e nilm é a quantidade de recursos l ∈ N consumidos.
A rede de dependências do projeto é representada por um grafo dirigido G = (V , E), em
que os vértices, i ∈ V , representam as tarefas e as arestas, (i, j) ∈ E, representam as
relações de precedência em que a tarefa j deve começar, no mínimo, no tempo em que a
tarefa i terminar. Isto signi�ca que deve haver um tempo de atraso maior ou igual a zero
entre o início de uma tarefa e o �m de todas as tarefas que a precedem. Assume-se que
esta rede seja acíclica. As tarefas postiças 0 e Tf representam o início e o �m do projeto,
e possuem duração e requisitos de todos os recursos iguais a zero. Um agendamento S é
de�nido por um vetor de tempos iniciais de tarefas, e é dito viável se todas as restrições
de precedência e restrições de recursos renováveis e não-renováveis forem satisfeitas. O
31
objetivo deste tipo de problema é encontrar um agendamento viável com o menor tempo
de conclusão possível (Cmax ou makespan).
Assim, o problema é representado como (m, 1T |cpm, disc,mu|Cmax) usando a classi�-cação de Herroelen, Demeulemeester e Reyck (1999), ondem indica que o problema possui
uma quantidade m de recursos; 1T indica que estes recursos podem ser tanto renováveis
quanto não-renováveis; cpm indica que as tarefas estão sujeitas a restrições rigorosas de
precedência sem nenhum atraso, como usado no método de caminho crítico; disc indica
que os requisitos das tarefas são uma função discreta da duração da tarefa; mu indica que
as tarefas possuem múltiplos modos de execução; e Cmax indica que a função objetivo é
minimizar o makespan.
O PPPMRR também pode ser representado como (MPS|prec|Cmax) usando a clas-
si�cação de Brucker et al. (1999), onde MPS indica que o problema de planejamento de
projeto é multimodo; prec indica a existência de precedência entre tarefas; e Cmax indica
que a função objetivo é minimizar o makespan.
A formulação do PPPMRR é descrita nas equações 2.1�2.6.
minimizar Cmax (2.1)
sujeito a
Mi∑m=1
LSi∑t=ESi
(t+ dim)ximt ≤Mj∑m=1
LSj∑t=ESj
txjmt,∀(i, j) ∈ E (2.2)
Mi∑m=1
LSi∑t=ESi
ximt = 1, ∀i ∈ V (2.3)
∑i∈V
Mi∑m=1
LSi∑t=ESi
nikmxims ≤ Nk,∀k ∈ N (2.4)
∑i∈V
Mi∑m=1
t+dim−1∑s=t
rikmxims ≤ Rk,∀k ∈ R, ∀t ∈ {1, . . . , UB} (2.5)
ximt ∈ {0, 1},∀i ∈ V,m ∈ {1, . . . ,M}, t ∈ {1, . . . , UB} (2.6)
Na formulação apresentada, ximt é igual a 1 se a atividade i for realizada no modo m e
inicializada no tempo t, ou igual a zero nos outros casos. A primeira equação (2.1) mostra
a função objetivo, que é minimizar o tempo de conclusão da última tarefa. A restrição 2.2
garante que as tarefas cumpram as relações de precedência com nenhum tempo de atraso.
32
A restrição 2.3 garante que cada tarefa seja executada exatamente uma vez em apenas um
modo. A restrição 2.5 restringe os recursos não-renováveis por todo horizonte de tempo.
As restrições sobre recursos renováveis são satisfeitas pela restrição 2.4, onde UB é o
horizonte de projeto ou o limite superior para o seu tempo de conclusão. As variáveis de
decisão tem seus limitem em 2.6. Os valores ESi e LSi denotam o tempo mais cedo e mais
tardio de início da tarefa i, usando os cálculos de caminho crítico tradicionais.
2.2.2 Aplicação em jogos RTS
O modelo do PPPMRR pode ser utilizado para aproximar o tempo de conclusão de
um conjunto de tarefas num cenário de jogos RTS. Neste contexto, os recursos de um
jogo podem ser as construções, unidades militares e trabalhadores, além de tecnologias.
Por exemplo, para produzir um marine3, é necessário usar, e portanto possuir, uma es-
trutura especializada (barracks), que por sua vez precisa de recursos brutos (minérios) e
trabalhadores para ser construída.
Como o problema de planjeamento de projetos possui diferentes variações, a versão
escolhida, multimodo com restrição de recursos, é a que mais se adequa ao contexto deste
gênero de jogos. Para RTS, o problema deve ser não-preemptivo com restrição de recursos,
além de ter recursos renováveis e não-renováveis. Isto quer dizer que as tarefas (e.g. ações
de produção de unidades) não podem ser pausadas e concluídas futuramente, por ser não-
preemptivo. A restrição de recursos se dá pela natureza limitada dos recursos do jogo.
Trabalhadores são recursos renováveis que possuem uma quantidade limitada. Já minérios
são recursos não-renováveis, que também possuem uma quantidade limitada e que se reduz
a cada ação de produção.
Entretanto, a natureza rígida das restrições de recursos, bem como a necessidade
de concluir todas as tarefas do projeto tornam o trabalho de modelar um jogo pouco
recompensador. As restrições de recursos não permitem que a aquisição de recursos ao
longo do jogo seja levada em conta durante os cálculos, como a produção de novas unidades
ou coleta de recursos por trabalhadores. Já as restrições de precedência dão trabalho
adicional ao modelador das instâncias. Embora os tipos de recursos do jogo não mudem
nem suas dependências, é necessário ter um novo grafo de precedência para cada conjunto
de tarefas que se queira fazer em um determinado momento do jogo.
O problema de planejamento de projetos contribuiu para os trabalhos envolvendo jo-
3Unidade militar básica da raça Terran.
33
gos de estratégia em tempo real com o método SLA*, que foi utilizado para problemas de
escalonamento de projetos por Zamani e Shue (1998). Branquinho e Lopes (2010) utiliza-
ram este método para solucionar uma extensão do problema de planejamento online para
produção de recursos em RTS. No próximo capítulo, o novo problema de produção será
abordado. Este modelo procura resolver as restrições que o problema de planejamento de
projeto impõe aos recursos e à precedência de tarefas, incorporando conceitos do problema
de planejamento online para produção de recursos em RTS.
34
3 Problemas Propostos
Neste capítulo, os dois novos problemas propostos para produção de recursos são
discutidos. O primeiro problema, problema de planejamento para produção de recursos
(PPPR), busca apenas uni�car os dois problemas discutidos no capítulo anterior com al-
gumas das mudanças discutidas. Em seguida, uma extensão deste problema é apresentada
� o problema de planejamento para produção de recursos com eventos cíclicos (PPPREC).
Esta extensão é a base do restante do trabalho, servindo como foco para os algoritmos de
otimização utilizados nos experimentos.
3.1 Problema de Planejamento para Produção de Re-
cursos
O problema de planejamento para produção de recursos (PPPR) é de�nido por três
variáveis: o sistema S, o estado inicial I0 e a estratégia O. De uma forma mais detalhada,
o sistema S = 〈R, T 〉 é uma dupla que possui: (a) o conjunto de recursos R e (b) o
conjunto de tarefas T . Recursos representam os objetos (como unidades e estruturas) e
valores (como dinheiro e capacidade de suprimento) que são manipulados pelas tarefas
durante o jogo. As tarefas são as ações que o jogador pode realizar para criar e consumir
recursos.
O estado inicial I0 deve conter as informações sobre o total coletado e consumido de
cada recurso r ∈ R, além do tempo restante para conclusão das tarefas em progresso. Por
ser um problema de otimização, é necessária uma fotogra�a do estado do sistema (I0)
para servir como base para aplicar certos operadores determinísticos (tarefas).
As próximas seções irão descrever os recursos, tarefas, bem como estratégia O, além
de apresentar um exemplo de caso do problema.
35
3.1.1 Recursos
Ao contrário do problema de planejamento de projetos, todos os recursos podem ser
tanto não-renováveis como renováveis. A diferenciação ocorre apenas para tarefas que
utilizam recursos como renováveis ou não.
Os recursos possuem atributos que determinam algumas restrições sobre o quanto
pode-se produzir. Seus atributos são:
• Máximo coletável : determina quanto de um determinado recurso pode ser produzido
a qualquer momento do jogo. Para saber quanto de um recurso é utilizável em um
determinado estado jogo é necessário saber quanto do recurso já foi coletado até o
momento e quanto foi gasto.
• Máximo utilizável por recurso: determina a quantidade máxima de recursos em es-
toque de um determinado recurso, regulada pela quantidade em estoque de outros
recursos.
• Equivalência: determina a equivalência entre recursos como pré-requisitos de uma
tarefa.
Para facilitar a manipulação de recursos, três atributos são usados para de�nir cada
recurso em um tempo t.
• Crt indica o total coletado do recurso r a partir do estado I0 até o tempo t.
• urt indica o total consumido do recurso r a partir do estado I0 até o tempo t.
• Urt indica a quantidade utilizável do recurso r no tempo t.
Uma vez que o total coletado não pode ser maior que o máximo coletável deste recurso,
temos que utilizar o valor correto em nossos cálculos. Tarefas podem possuir valores de
produção que não permitam que o Crt seja igual ao máximo coletável em algum tempo t.
A forma mais simples de eliminar este problema é adotar o máximo coletável como limite
superior para o valor de Crt. Assim, para qualquer recurso r ∈ R, em qualquer tempo t,
temos que:
Crt = min{Crt,MCr} (3.1)
Urt = Crt − urt (3.2)
36
Onde Crt é o total coletado real do recurso r, MCr é o máximo coletável de r. Além
disso, a restrição 4.3 deve ser atendida em qualquer tempo t.
Urt ≤s 6=r∑s∈R
MUrsUst (3.3)
MUrs indica o máximo utilizável do recurso r por unidade de outro recurso s.
3.1.2 Tarefas
As tarefas, ou ações, possuem relações com os recursos, ao invés de relações entre
si como os próprios recursos possuem. Além destas relações, tarefas possuem o atributo
�duração�. Os atributos das tarefas são listados a seguir.
• Duração: tempo entre o início da tarefa e sua conclusão. Representado pelo símbolo
di.
• Pré-requisito: quantidade de recursos necessária para o início desta tarefa. Estes
recursos não são usados. As equivalências de recursos são veri�cadas apenas neste
contexto. Representado pelo símbolo Prir.
• Custo: quantidade de recursos a serem consumidos no início da tarefa. Representado
pelo símbolo Ctir.
• Consumo: quantidade de recursos a serem consumidos no término da tarefa. Estes
recursos são imobilizados pela duração da tarefa e não poderão ser utilizados ou
consumidos neste período. Representado pelo símbolo Cmir.
• Uso: quantidade de recursos que estarão imobilizados até o �m da tarefa porém
sem serem consumidos. Estes recursos não poderão ser utilizados ou consumidos
por outras tarefas. Representado pelo símbolo Boir.
• Produção: quantidade de recursos que serão gerados após o término da tarefa. Re-
presentado pelo símbolo Prir.
Os atributos �custo�, �consumo� e �produção� indicam alterações nos recursos consu-
midos (urt) e nos recursos coletados (Crt). Isto signi�ca que é possível modelar sistemas em
que tarefas tenham valores negativos para certos atributos, que podem gerar sequências
de ações não-triviais, ao se considerar os máximos de cada recurso (MCr,MUrs).
37
Para que uma tarefa possa ser executada em um determinado estado, ele deve pos-
suir, pelo menos, a quantidade de recursos indicada em cada uma de suas relações de
dependência: pré-requisitos, custos, consumos e usos. Importante notar que o consumo
de pré-requisitos após o início de uma tarefa não a invalida neste problema, isto é, os
pré-requisitos precisam ser válidos apenas no instante inicial da tarefa. Junto com as de-
pendências de recursos também existe a dependência temporal, em que uma ação deve
demorar exatamente o tempo prescrito em sua de�nição. Estas a�rmações podem ser ex-
pressas nas restrições 4.4 e 4.5, onde Prir, Ctir, Cmir, Boir são os pré-requisitos, custos,
consumos e usos da tarefa i ∈ T em relação ao recurso r ∈ R, respectivamente. Esr
representa a equivalência entre os recursos r e s. Brt indica a quantidade do recurso r
imobilizada no tempo t. Além disso, temos que di indica a duração da tarefa i.
max{Urt, EsrUst|s ∈ R} ≥ Prir (3.4)
Urt −Brt ≥ Ctir + Cmir +Boir (3.5)
3.1.3 Modelo
Este problema recebe como entrada o sistema S = 〈R, T 〉, o estado inicial I0 e a des-
crição da estratégia O = 〈M,N,U, V,K, L, UB〉. A descrição da estratégia, O, possui seis
conjuntos e um valor inteiro. Os conjuntos M e N possuem as funções de maximização e
minimização, respectivamente. Estes conjuntos não podem se intersectar, N ∩M = ∅. Osconjuntos U e V possuem as funções de restrição referentes a mínimos e máximos, res-
pectivamente. Os conjuntos K e L possuem os valores das restrições referentes a mínimos
e máximos, respectivamente. Por tratarem da mesma quantidade de restrições, |U | = |K|e |V | = |L|. UB é o horizonte de tempo.
Antes de descrever o modelo, é necessário explicar quais valores serão otimizados. Uti-
lizaremos a notação yf para denotar o valor da função f(x, I0, UB). Este valor é capturado
ou no tempo �nal da execução das tarefas prescritas na variável de decisão x partindo do
estado inicial I0, ou no tempo UB caso a última tarefa termine após o tempo máximo.
Desta forma, é possível veri�car quais ações podem ser iniciadas durante o tempo. A
função f pode ser um dos seguintes atributos de algum recurso r ∈ R: (a) total coletado,(b) total consumido, e (c) quantidade utilizável. Portanto, podem existir até três funções
para cada recurso. Por exemplo, em StarCraft pode-se minimizar o total coletado de gás
vespeno para forçar pouco tempo de coleta de gás e mais tempo de mineração, além de
exigir uma quantidade utilizável mínima de unidades militares.
38
O modelo simpli�cado para otimização deste problema está descrito de 4.6 a 4.11.
minimizar min {Cmax, UB} (3.6)
maximizar ym,∀m ∈M (3.7)
minimizar yn,∀n ∈ N (3.8)
sujeito a
Smax ≤ UB (3.9)
yu > ku,∀u ∈ U (3.10)
yv < lv, ∀v ∈ V (3.11)
A variável Cmax guarda o tempo de conclusão da última tarefa de x. Porém, o plane-
jamento ainda pode ser útil caso a última tarefa não termine em tempo hábil, uma vez
que uma ordem de tarefas que não conclua a última tarefa ainda modi�ca o estado do
jogo no tempo UB. Neste caso, o tempo máximo UB é utilizado e o estado do jogo no
tempo UB pode ser considerado na otimização. Isto só é possível caso o tempo de começo
da última tarefa, Smax, esteja dentro do limite determinado (equação 4.9). Uma função
de avaliação poderia aplicar cortes em uma ordem de tarefas x de forma que a função
retorne uma ordem xf que possua todas as tarefas em x que podem ser começadas até
UB.
Em cenários multiobjetivo, o tempo máximo UB pode se tornar mais importante.
Devido ao grande número de possibilidades que o espaço de soluções tem, reduzir a oti-
mização à uma janela de tempo especí�ca pode se tornar mais útil tanto pelo tempo de
processamento como pela quantidade de soluções ótimas. Soluções que demorem muito
podem ser tão inúteis quanto soluções que não satisfaçam às outras restrições.
Estes cenários também expõem os trade-o�s entre os recursos e o tempo. Utilizando
StarCraft como exemplo, podemos elaborar um modelo que vise minimizar o makespan
e maximizar a quantidade utilizável de minérios. Neste exemplo, não há uma ligação
simples entre o tempo que a ordem de tarefas leva para ser feita e a quantidade utilizável
de minérios, pois o estoque de minérios depende de: (a) quantidade de trabalhadores
minerando, (b) o tempo que cada trabalhador passa minerando e (c) quanto de minério
foi gasto.
Além dos objetivos personalizados, o problema também apresenta restrições persona-
lizadas. Estas restrições são semelhantes ao que se busca em uma programação de metas,
39
como feito em Blackford (2014), no sentido que elas dão um estado-objetivo mínimo para
as soluções ótimas de um caso. Por exemplo, se uma restrição for �quantidade utilizável
de trabalhadores maior que 5�, temos que todas as soluções ótimas devem obedecer esta
restrição.
A personalização é necessária pois, caso contrário, não haveria direção para o otimi-
zador: fazer nada (uma solução com nenhuma tarefa) seria a solução ótima. Ao colocar ao
menos uma restrição ou função objetivo, o otimizador pode encontrar soluções coerentes.
Este modelo simpli�cado apresenta apenas as restrições personalizadas, além das fun-
ções objetivo do problema. Porém, existem outras restrições referentes ao funcionamento
das tarefas e gerenciamento de recurso inerentes ao problema. Estas restrições são apre-
sentadas em 4.12 a 4.17.
Crt = Cr0 +∑i∈x
t∑τ=1
xi(τ−di)Pir,∀t ∈ {1, . . . , UB},∀r ∈ R (3.12)
urt = ur0 +∑i∈x
t∑τ=1
(xi(τ−di)Cmir + xiτCtir
),∀t ∈ {1, . . . , UB},∀r ∈ R (3.13)
Brt =∑i∈x
t∑τ=1
(xiτ − xi(τ−di)
)(Boir + Cmir) ,∀t ∈ {1, . . . , UB},∀r ∈ R (3.14)
Urt ≤s 6=r∑s∈R
MUrsUst,∀t ∈ {1, . . . , UB}, ∀r ∈ R (3.15)
max{Urt, EsrUst|s ∈ R} ≥∑i∈x
xitPrir,∀t ∈ {1, . . . , UB}, ∀r ∈ R (3.16)
Urt −Brt ≥∑i∈x
xit(Ctir + Cmir +Boir),∀t ∈ {1, . . . , UB},∀r ∈ R (3.17)
Para estas restrições, temos que xit é uma variável binária que recebe valor 1 caso a
tarefa i inicie no tempo t. Sem perda de generalidade, podemos assumir que tarefas não-
concluídas apresentadas no estado inicial I0 estão representadas na solução x e começam
em um tempo t < 0. Cr0, ur0, Br0 representam o total coletado, o total consumido e o uso
de um recurso r no estado inicial I0. Pelas equações 4.1 e 4.2, temos que:
Urt = min{Crt,MCr} − urt (3.18)
A forma simpli�cada foi adotada para melhorar a legibilidade.
40
As restrições 4.12, 4.13 e 4.14 tratam da coleta e utilização de recursos ao longo do
tempo, servindo para garantir que as quantidades dos atributos de cada recurso em um
tempo t estejam corretas de acordo com as tarefas que foram alocadas. A restrição 4.12
informa que a quantidade de recursos coletados brutos é igual à quantidade de recursos
iniciais mais a produção de cada tarefa, que só acontece após um tempo di do início.
A restrição 4.13 mostra que o consumo de recursos é feito no início das tarefas para o
custo (Ctir), e no �m delas para o consumo (Cmir). A quantidade de recursos travados
da restrição 4.14 mostra que apenas são consideradas tarefas que não foram concluídas
ainda e que possuem atributos de �uso� ou �consumo�.
A restrição 4.15 impõe os limites sobre o total utilizável de qualquer recurso r em
relação ao seu máximo por recurso, MUrs. Esta é a generalização da restrição mostrada
na restrição 4.3. A restrição 4.16 serve para garantir que os pré-requisitos de uma tarefa
sejam cumpridos, e a restrição 4.17 mostra que deve haver recursos disponíveis para o
custo, consumo e uso de uma tarefa no início de sua execução.
3.1.4 Exemplo
Para exempli�car um caso deste problema, será exposta uma versão simpli�cada da
raça Zerg de StarCraft como sistema para a estratégia que visa maximizar o estoque de
minérios e garantir um spawning pool1, a partir do estado inicial do jogo. Também serão
mostrados exemplos de soluções com seus valores para cada função objetivo.
A Tabela 3 mostra os recursos do exemplo e seus atributos, onde minérios são utiliza-
dos como custo pela maioria das tarefas, gás vespeno é usado para evoluir uma hatchery
para uma lair e os suprimentos são utilizados como custo para a criação de unidades.
Suprimentos possuem um limite superior, ou seja, não se pode produzir mais que 200 uni-
dades de suprimentos. O restante dos recursos possuem restrições que estão atreladas a
outros recursos, e.g não pode haver mais larvas do que o triplo da quantidade de hatcheries
e lairs juntas, ou mais drones que 18 vezes a quantidade de hatcheries e lairs. Extratores
também não podem exceder a quantidade de hatcheries e lairs, nem pode haver mais do
que três drones coletores de gás em cada extractor.
Evoluir uma lair a partir de uma hatchery requer que se trave a unidade até que a
evolução seja concluída. Neste momento, a hatchery deixa de existir e a lair é produzido.
Além desta tarefa, algumas tarefas possuem atributos negativos (tabela 4). A construção
1Estrutura Zerg que possibilita a criação de Zerglings, a primeira unidade militar.
41
Tabela 3: Recursos do exemplo de produção de recursos.MU denota o máximo utilizável,MC o máximo coletável e ≡ denota equivalência.
Recurso Símbolo AtributosMinérios mGás Vespeno vSuprimentos s MCs = 200Larva l MUlh = 3,MUla = 3Drone d MUdh = 18,MUda = 18Drone coletor de gás g MUge = 3Zergling zOverlord oSpawning Pool pHatchery hExtractor e MUeh = 1,MUea = 1Lair a a ≡ h
Tabela 4: Tarefas do exemplo de produção de recursos.Tarefa Tempo Custo Pré-R. Cons. Uso Prod.Morph Drone 20 50 m, 1 l, 1 s 1 dMorph Drone (gás) 2 1 d 1 gMorph Zergling 28 50 m, 1 l, 1 s 2 zMorph Overlord 40 100 m, 1 l 1 o, 8 sMorph Hatchery 120 300 m, 1 d, -1 s 1 h, 1 l, 1 sMorph Sp. Pool 80 200 m, 1 d, -1 s 1 h 1 pMorph Extractor 40 50 m, 1 d, -1 s 1 eMorph Lair 100 150 m, 100 v 1 h 1 a, 1 lCreate Larva 14 1 h 1 lGather Minerals 7 1 d 8 mGather Gas 5 1 g 8 v
de estruturas requer o consumo de um drone. Estas tarefas são Morph Hatchery, Morph
Sp. Pool e Morph Extractor. Quando este drone é consumido, uma unidade de suprimento
é liberada. Como há uma diferença entre quantidade máxima de suprimentos atual e a
quantidade utilizada (produzido e consumido, respectivamente), deve haver uma redução
na quantidade consumida, enquanto o produzido ainda permanece o mesmo.
Dado este sistema, a estratégia que maximiza o estoque de minérios e garante um
spawning pool num tempo máximo de 300 segundos segue abaixo.
minimizar min {Cmax, 300} (3.19)
maximizar Um (3.20)
42
Tabela 5: Estado inicial I0 do exemplo de produção de recursos.
m v s l d g z o p h e aColetado 50 0 9 1 4 0 0 1 0 1 0 0Consumido 0 0 4 0 0 0 0 0 0 0 0 0
sujeito a
Smax ≤ 300 (3.21)
Up > 1 (3.22)
O objetivo 4.19 é a minimização do tempo de conclusão das tarefas, tendo em vista
o horizonte de 300 segundos. Objetivo 4.20 é a maximização da quantidade de minérios
utilizáveis. A restrição 4.21 limita o tempo de inicialização da última tarefa pelo horizonte
estabelecido, e a restrição 4.22 determina a quantidade mínima utilizável de spawning
pools.
Duas soluções para o problema estão apresentadas na Figura 3. As linhas azuis mos-
tram o estoque de minérios ao longo do tempo, enquanto a linha magenta mostra o estoque
de drones ao longo do tempo. Retângulos azuis com listras diagonais esquerdas são as ta-
refas que consomem minérios, e possuem legendas apropriadas. Retângulos magenta com
diagonais direitas são tarefas de coleta de recurso. As tarefas de coleta de recurso estão
limitadas pelo estoque de drones, por isso a altura de cada retângulo é igual à altura de
uma unidade de drone no estoque. Como estas tarefas apenas usam os drones, não há
redução no seu estoque em razão destas tarefas. Tarefas que consomem minérios possuem
uma altura equivalente ao seu custo.
A sequência de ações da solução 4 pool está representada em 4.23, enquanto a solução
6 pool é apresentada em 4.24.
{ 20x Gather Minerals; Morph Sp. Pool; 36x Gather Minerals } (3.23)
{ Morph Drone; 8x Gather Minerals; Morph Drone; 26x Gather Minerals; (3.24)
Morph Sp. Pool; 60x Gather Minerals }
Estas soluções mostram o impacto que drones possuem na geração de recursos. Em-
bora haja uma diferença de 15 segundos entre o tempo �nal das soluções, a solução que
demora mais, 6 pool, possui quase o dobro de minérios que a outra solução: 462 minérios
em contraste com 274 minérios da primeira solução.
43
(a) 4 pool : 116 segundos, 274 minérios (b) 6 pool : 131 segundos, 462 minérios
Figura 3: Soluções para a estratégia exemplo. Os retângulos representam tarefas. Retân-gulos sem nome representam a tarefa Gather Minerals.
Tarefas de criação de larvas são repetidas a cada 14 segundos, por isto são omitidas
na �gura 3. A solução 4 pool possui 56 tarefas de coleta de recursos, e a solução 6 pool
possui 94 destas tarefas. Elas estão representadas na �gura pelos blocos vermelhos sem
nome, limitados pela quantidade de drones.
A progressão das tarefas de coleta de minérios se dá em função de um recurso, drones, e
do tempo. Isto não só apresenta um problema computacional para alocá-las, mas também
um problema para interpretar o resultado �nal do otimizador. Tarefas repetidas acabam
não perdendo real signi�cado entre todas as tarefas de uma solução, pois no contexto de
um jogo de estratégia em tempo real a coleta de recursos é tida como a atividade padrão
de toda unidade que puder fazê-la, sendo a retirada de drones da coleta uma ação mais
signi�cativa neste contexto. Além disso, elas são constantemente alocadas em todas as
soluções ótimas da maior parte das estratégias em um RTS real, pois qualquer tarefa
que possua um custo, consumo ou pré-requisito precisa de coleta de recursos que permita
sua produção. Assim, dentre 57 tarefas totais na solução 4 pool, apenas uma possui real
signi�cado para a análise da solução, Morph Spawning Pool. Na solução 6 pool, são três
tarefas signi�cativas em meio a 97.
Um outro aspecto da complexidade adicional destas tarefas repetidas aparece em
cenários multiobjetivo. É possível, a partir de uma solução com a menor quantidade de
tarefas repetidas, criar várias outras soluções apenas adicionando mais tarefas repetidas à
solução original. Estas novas soluções não apresentam nenhuma informação signi�cativa,
servindo apenas para mostrar a projeção de produção de recursos num tempo futuro.
Embora ainda esteja limitado ao tempo máximo, a adição de tarefas repetidas aumenta
o espaço de busca consideravelmente para o otimizador.
44
3.2 Problema de Planejamento para Produção de Re-
cursos com Eventos Cíclicos
Este problema é uma extensão do problema de planejamento para produção de recur-
sos, e será o foco do restante do trabalho. Assim, ele é de�nido pelas mesmas três variáveis:
o sistema S, o estado inicial I0 e a estratégia O. Porém, o sistema possui um elemento
adicional: o conjunto de eventos. O sistema S = 〈R, T,E〉 é uma 3-upla: (a) o conjunto
de recursos R, (b) o conjunto de tarefas T e (c) o conjunto de eventos E. Recursos e
tarefas possuem as mesmas conotações que no problema anterior, já os eventos são ações
periódicas que iniciam automaticamente ao criar um tipo de recurso, como por exemplo
a coleta de recursos periódica iniciada ao produzir um trabalhador.
O estado inicial I0 deve incluir, além das informações dos recursos e das tarefas in-
completas, informações sobre quais eventos estão ativos e seus tempos de início.
As próximas seções irão expor o funcionamento dos eventos e seu impacto no modelo
�nal do problema.
3.2.1 Eventos
Ao criar alguns recursos, pode-se ativar eventos cíclicos que produzem mais recursos,
do mesmo tipo ou não. Eventos possuem os três atributos listados a seguir.
• Tempo de espera: o período de cada ciclo do evento.
• Produção: a quantidade de recursos produzidos a cada ciclo. Esta produção altera
o Crt de cada recurso r gerado após um tempo τ igual ao tempo de espera desde a
criação do evento ou desde a última produção.
• Gatilho: o recurso que, quando criado, gera um novo evento deste tipo.
Ao consumir uma unidade de um tipo de recurso que produza eventos, o evento que
demorará mais para ser terminado também é destruído no processo, de forma que para
qualquer evento e ∈ E, em qualquer tempo t, a seguinte restrição deve ser satisfeita:
|Vet| = Urt (3.25)
onde Vet é o conjunto de todos os eventos do tipo e ativos no tempo t. Urt é a quanti-
dade utilizável do recurso r, tal que r seja o gatilho do evento e. Isto se dá pela dependência
45
que eventos cíclicos têm com seu gatilho. A coleta de recursos depende dos trabalhadores,
e sem eles é impossível coletar recursos em jogos RTS. Da mesma forma, uma hatchery
de StarCraft precisa estar viva para que haja produção de larva.
3.2.2 Modelo
O modelo do PPPREC permanece com as mesmas características do modelo anterior,
PPPR. Porém, a adição de eventos altera a equação do total consumido. A equação
corrigida é apresentada a seguir (equação 5.4), além das restrições referentes aos eventos.
Utilizamos eventos como uma segunda variável de decisão (xe), que é o conjunto de todos
os eventos ativados pela solução x. O símbolo eit indica se o evento i foi iniciado no tempo
t, enquanto eit denota o término do evento i no tempo t.
A equação 5.2 mostra o tempo real de início de um evento i (τi), onde LB é o menor
tempo de início presente no estado inicial, seja de uma tarefa não-concluída ou de um
evento. O tempo real é igual ao máximo entre dois valores, onde um é a busca pelo início
do evento no intervalo LB ≤ τ ≤ 0, e o outro valor é uma busca pelo início no intervalo
1 ≤ τ ≤ UB. Caso o início se dê antes do tempo τ > 0, é preciso saber o primeiro tempo
de ativação com τ > 0. Como os valores são dependentes de eiτ , o valor de qualquer
somatório será 0 ou um valor positivo que corresponde ao primeiro tempo de ativação.
A produção de um recurso r até o tempo t a partir de eventos é dada pela equação
5.3. Nesta equação, a produção é o somatório das projeções de todas as produções de um
recurso r para cada evento i, desde o início do evento até tempo t, ou até o tempo de seu
término, caso o evento acabe antes do tempo t.
τi = max
{0∑
τ=LB
dei
⌈−eiττdei
⌉+ eiττ,
UB∑τ=1
eiττ
},∀i ∈ xe (3.26)
P ert =
∑i∈xe
P eir
[(t−min {t, τi})−
t∑τ=1
eiτ (t− τ)
]\dei ,∀t ∈ {1, . . . , UB},∀r ∈ R
(3.27)
46
Tabela 6: Eventos do exemplo. A cada intervalo de tempo descrito é realizada a produçãodos recursos.
Evento Tempo Produção GatilhoColetar minério 7 8 minérios dColetar gás vespeno 5 8 gás vespeno gProduzir larva (Hatchery) 14 1 larva hProduzir larva (Lair) 14 1 larva a
Tabela 7: Tarefas do exemplo com eventos cíclicos.
Tarefa Tempo Custo Pré-Req. Consumo ProduçãoMorph Drone 20 50 m, 1 l, 1 s 1 dMorph Drone (gás) 2 1 d 1 gMorph Zergling 28 50 m, 1 l, 1 s 2 zMorph Overlord 40 100 m, 1 l 1 o, 8 sMorph Hatchery 120 300 m, 1 d, -1 s 1 h, 1 l, 1 sMorph Spawning Pool 80 200 m, 1 d, -1 s 1 h 1 pMorph Extractor 40 50 m, 1 d, -1 s 1 eMorph Lair 100 150 m, 100 v 1 h 1 a, 1 l
Crt = Cr0 +∑i∈x
t∑τ=1
xi(τ−di)Pir + P ert,∀t ∈ {1, . . . , UB},∀r ∈ R (3.28)
t∑τ=1
eiτ = min{Cgei t,MCgei },∀t ∈ {1, . . . , UB},∀i ∈ xe (3.29)
t∑τ=1
eiτ = ugei t +Bgei t,∀t ∈ {1, . . . , UB},∀i ∈ xe (3.30)
A equação 5.4 adiciona a projeção da produção de todos os eventos, dada na equação
5.3, ao total coletado do recurso r até o instante t. As equações 5.5 e 5.6 asseguram
que a quantidade de eventos em cada instante t é igual à quantidade utilizável do seu
recurso-gatilho. Isto é feito de forma que o total de eventos criados seja igual ao total de
recursos-gatilho coletados, e o total de eventos destruídos seja igual à soma do total de
recursos consumidos com o total de recursos presos.
3.2.3 Exemplo
Como forma de comparação entre os dois modelos apresentados, abaixo segue o exem-
plo do seção anterior modi�cado para incluir eventos cíclicos.
47
Tabela 8: Estado inicial I0 do exemplo com eventos cíclicos.
m v s l d g z o p h e aColetado 50 9 1 4 1 1Consumido 4
Evento InícioColetar minério (1) 0Coletar minério (2) 0Coletar minério (3) 0Coletar minério (4) 0Produzir larva (Hatchery) 0
Os recursos permanecem inalterados (ver Tabela 3), mantendo as mesmas restrições
de máximo coletável, máximos utilizáveis e equivalência que o exemplo original. Porém
com a adição de eventos (Tabela 6) a quantidade de tarefas (Tabela 7) diminuiu. A antiga
tarefa de criação de larva usava uma hatchery, de forma que era impossível criar um lair e
produzir larva ao mesmo tempo. Caso o sistema fosse completo, também não seria possível
pesquisar tecnologias na mesma hatchery que estivesse produzindo larvas. Ao transformar
em evento, ambas situações se tornam possíveis.
Em compensação, o estado inicial (Tabela 8) agora possui mais informações que apenas
o estado dos recursos e tarefas. Enquanto o tamanho de informações sobre recursos varia
de acordo com a quantidade de recursos do sistema, o tamanho de informações sobre
eventos varia de acordo com a quantidade utilizável de cada gatilho no estado inicial.
A estratégia de otimização permanece idêntica, maximizando a quantidade utilizável
de minérios e garantindo um spawning pool num tempo máximo de 300 segundos (ver
objetivos e restrições 4.19 a 4.22).
As soluções para a mesma estratégia produzem os mesmos resultados (ver Figura 4).
Isto mostra que esta extensão do modelo básico não altera o comportamento do problema,
uma vez que não houve redução de termos mas adição de termos. Para decidir quais
eventos são excluídos no consumo de recursos-gatilhos, a técnica utilizada foi excluir o
evento que levará o maior tempo para voltar a se ativar.
Uma vez que são utilizados eventos ao invés de tarefas repetitivas, a quantidade de
informações que o otimizador tem que trabalhar cai drasticamente. Não é mais possível
estender uma solução mínima para vários períodos de tempo distintos, produzindo apenas
diferentes projeções de produção.
48
(a) 4 pool : 116 segundos, 274 minérios (b) 6 pool : 131 segundos, 462 minérios
Figura 4: Soluções para a estratégia exemplo. Retângulos cinza representam tarefas queproduzem unidades ou estruturas, e o recurso produzido está descrito dentro de cadaretângulo.
49
4 Algoritmo de Geração de Soluções
Para criar soluções para o PPPREC, foi pensada uma maneira de transformar estas
relações em um dígrafo, onde cada vértice é um recurso, evento ou tarefa, e as arestas
representam as relações entre os vértices, como máximo por recurso ou pré-requisito. A
Figura 5.a mostra um exemplo de um dígrafo que é utilizado para representar um sistema.
Nesta �gura, as tarefas possuem custos em preto, produções em vermelho e usos em azul,
recursos possuem gatilhos em verde e os eventos possuem produções em vermelho. Este
grafo é reduzido em um multidígrafo de tarefas (ver Figura 5.b). Inicialmente, reduzindo
os eventos e recursos em um único tipo de aresta, e então reduzindo todas as arestas
em tarefas. As arestas correspondem a todas as relações entre recursos produzidos e as
tarefas. Elas recebem um peso associado aos objetivos e restrições do modeloM . Com este
multidígrafo base, pode-se calcular o valor associado a cada tarefa em um determinado
estado.
Para reduzir o grafo, inicialmente unem-se os eventos aos seus gatilhos, eliminando
assim um tipo de vértice. No exemplo da �gura 5.a, Minerar é unido com Trabalhador.
Então cada recurso é fundido com os recursos que os produzem. No exemplo, o Ouro é
fundido com Trabalhador. Finalmente, os recursos são unidos às tarefas que os produzem.
Trabalhador é unido com Fazer Trabalhador, Quartel une-se com Fazer Quartel e Soldado
é fundido com Fazer Soldado. As arestas sempre saem das tarefas para os recursos, dos
recursos para os eventos (gatilhos) e dos eventos para recursos (produção). Este grafo
reduzido pode ser calculado em tempo de pré-processamento e utilizado como base para
cálculos futuros.
Como cada recurso pode possuir uma necessidade distinta (seja como objetivo ou res-
trição), as tarefas recebem um peso inicial para cada objetivo ou restrição cuja produção,
custo e consumo que ajudem ou atrapalhem. No exemplo da Figura 5, uma estratégia que
necessitasse de Ouro como objetivo aumentaria o peso de Fazer Trabalhador enquanto
reduziria o peso das outras tarefas. Este peso é calculado com base nas relações que os
recursos consumidos ou produzidos possuem com os recursos-alvo (restritivos ou objetivo)
50
Ouro Trabalhador Quartel Soldado
Minerar
Fazer Trab. Fazer Quartel Fazer Sold.
(a)
θ0 θ1 θ2
wcost
wborrow
wcost
wborrow
(b)
Figura 5: Representação de um sistema de um jogo simples de coleta de recursos e produ-ção de unidades. (a) Grafo no estado inicial, mostrando todo o sistema do problema. (b)o multidígrafo correspondente, com os pesos para cada tarefa e tipo de relação. O círculorepresenta o evento do sistema e a aresta verde sua relação com o gatilho, as arestasvermelhas representam as produções, as arestas pretas representam os custos, as azuisrepresentam os usos.
e o quanto cada efeito (i.e. produção ou consumo) vai mudar os valores dos recursos. En-
tão, cada tarefa repassa o seu peso (caso seja favorável) para as outras tarefas da qual
dependa, por cada uma de suas arestas. Os pesos não são passados mais de uma vez para
um mesmo vértice através do mesmo tipo de aresta. Como existem vários tipos de arestas,
é recomendado haver pesos distintos para cada tipo, a �m de criar o viés desejado para a
solução.
Uma vez que os recursos do estado atual podem cumprir alguns pré-requisitos, é inte-
ressante podar o grafo de forma que as tarefas que já tenham seu pré-requisito cumprido
não passem informações erradas. Este procedimento também pode ser feito em arestas li-
gadas a seu uso, já que as arestas estão relacionadas com a existência de números mínimos
de alguns recursos.
Como o cálculo é feito a partir de um estado arbitrário, é possível gerar uma solução
ao utilizar este método iterativamente. Ao utilizar o estado inicial do problema e uma
solução vazia (i.e. sem tarefas en�leiradas), pode-se adicionar tarefas a esta solução inviá-
vel progressivamente utilizando o estado �nal da solução inviável anterior como entrada,
51
Algoritmo 1 Função que atribui o peso a uma tarefa task baseada numa contribuição δ1: função pesoTarefa(δ, I0, task, r)2: peso← 03: se tarefa.producao(r) então4: peso← peso+ δ5: �m se
6: se task.custo(r) então7: peso← peso− δ
2
8: �m se
9: se task.consumo(r) então10: peso← peso− δ
2
11: �m se
12: retorne peso13: �m função
e escolhendo uma das tarefas de alto valor até que se possua uma solução que atenda a
todas as restrições. Para acelerar a intensidade da busca pela satisfação de restrições, é
recomendado um aumento progressivo, a cada iteração, dos pesos iniciais relacionados a
elas.
4.1 Valoração de Tarefas
O algoritmo 3 tem como função atribuir valores entre zero e um para cada uma das ta-
refas que podem contruibuir para a satisfação das restrições e melhoramento dos objetivos.
Para isto, ele precisa do estado I0 e da estratégia O como base, além de pesos relacionados
aos benefícios trazidos pela execução de cada tarefa. Os pesos e seus signi�cados são:
• δo: contribuição para o objetivo;
• δr: contribuição para restrições;
• δp: contribuição para pré-requisitos e usos de tarefas úteis;
• δc: contribuição para custos e consumos de tarefas úteis;
• δm: contribuição para o aumento do máximo possível de um recurso produzido por
tarefas úteis.
O funcionamento do algoritmo 3 começa com a aquisição de valores iniciais para cada
tarefa através da função initialWeights. Estes valores iniciais são dados por uma função
que atribui às tarefas um valor (δo) para cada recurso produzido que ajude nos objetivos e
52
Algoritmo 2 Algoritmo para valoração inicial de tarefas em um estado I0 segundo umaestratégia O.1: função pesosIniciais(δo, δr, I0, O)2: inicial← {}3: para todo i ∈ T faça
4: inicial[i]← 05: para todo o ∈M faça
6: inicial[i]← inicial[i]+ pesoTarefa(δo,I0,i,o)7: �m para
8: para todo o ∈ N faça
9: inicial[i]← inicial[i]+ pesoTarefa(−δo,I0,i,o)10: �m para
11: para todo o ∈ U faça
12: se I0[o] ≤ ko então13: se o ∈ {Cr0|r ∈ R} ou o ∈ {Ur0|r ∈ R} então14: inicial[i]← inicial[i]+ pesoTarefa(δr,I0,i,o)15: senão
16: inicial[i]← inicial[i]+ pesoTarefa(−δr,I0,i,o)17: �m se
18: �m se
19: �m para
20: para todo o ∈ V faça
21: se I0[o] ≥ lo então22: se o ∈ {Cr0|r ∈ R} ou o ∈ {Ur0|r ∈ R} então23: inicial[i]← inicial[i]+ pesoTarefa(−δr,I0,i,o)24: senão
25: inicial[i]← inicial[i]+ pesoTarefa(δr,I0,i,o)26: �m se
27: �m se
28: �m para
29: �m para
30: �m função
uma penalidade (δo/2) para cada recurso-objetivo consumido. Estes bônus e penalidades
também são calculados para os recursos gerados por eventos engatilhados pela tarefa em
questão. O mesmo é feito para as restrições, utilizando os valores atuais dos recursos em
I0 para comparação e um outro valor de peso, δr.
Então, cria-se um novo grafo sem as arestas de relações já cumpridas. As arestas
restantes recebem um valor correspondente ao tipo de relação. Considerando a aresta
saindo de uma tarefa t e indo para uma tarefa-alvo a, estes vértices estão ligados devido
a dois recursos, r e s, produzidos respectivamente por t e a. O valor associado à aresta
depende de um peso δ, do bônus associado à tarefa-alvo B e da necessidade da tarefa
atual C. Para pré-requisitos, uso, custo e consumo, os valores de B são iguais à produção
53
Algoritmo 3 Algoritmo de valoração de tarefas em um estado I0 segundo uma estratégiaO.1: procedimento valoresTarefas(I0, O, δo, δr, δp, δc, δm)2: inicial← pesosIniciais(δo, δr, I0, O)3: pesos← inicial4: grafo← grafoInicial(S)5: podarGrafo(prerequisitos)6: podarGrafo(uso)7: ponderarGrafo(grafo, I0, δp, δc, δm)8: para todo i ∈ T faça
9: se inicial[i] > 0 então10: passarValores(i, δp, δc, δm, pesos)11: �m se
12: �m para
13: para todo i ∈ T faça
14: se impossivel(I0, i) então15: inicial[i]← −∞16: �m se
17: �m para
18: diferenca← greatestNegative(pesos)19: add(pesos, diferenca)20: normalizar(pesos, x > 0)21: retorne pesos22: �m procedimento
do recurso s (Pas). A necessidade C é igual a Prtr, Botr, Cttr, Cmtr, respectivamente.
Nestes casos, r = s. Porém quando a tarefa a gera um recurso s que aumente o máximo do
recurso r produzido por t, o cálculo muda levemente. B passa a ser MUrs, a quantidade
de unidades de r que podem ser produzidas para cada unidade de s, e C é a produção de
s, Pas. Caso qualquer dos recursos s produza, através de eventos, o recurso necessário a t,
então o valor é dado por uma constante, uma vez que os cálculos envolvendo eventos se
tornam complicados. Utilizamos aqui a constante σ = 0, 3.
Para �nalizar o cálculo, é preciso saber do impacto que será causado pela tarefa
escolhida. Isto se dá com base num valor A, que depende do tipo de relação. Para pré-
requisito, A = Prtr − Ur0. Para uso, A = Botr − (Ur0 − Br0). Para custo e consumo,
A = Ur0. Para máximos, A = maxr(I0) − Ur0. Com isto, o valor da aresta e se dá pela
função 4.1, onde σ indica a produção cíclica de necessidades, a tangente hiperbólica indica
um valor referente à razão da produção pela demanda, e a última razão indica a in�uência
da produção dos recursos necessários no estado atual.
we = δ
[σ +
(tanh
(Be
Ce
)Be
Be + Ae
)2]
(4.1)
54
Quando todos os elementos do grafo possuírem um valor, as tarefas que possuem um
valor de contribuição inicial maior que zero serão selecionadas. Para cada uma dessas
tarefas, o valor inicial de uma tarefa-origem o é passado para suas dependências, de forma
que a tarefa-destino t possua um valor �nal vt = vt + wev0o , onde we é o peso da aresta
e v0o é o valor inicial da tarefa que está repassando seu peso. Isto é feito para todas as
tarefas que possuem um valor inicial maior que zero, isto é, que possuem uma contribuição
aceitável no estado I0.
Após este cálculo, as tarefas impossíveis de serem feitas no estado I0 recebem valor
−∞. O maior valor negativo, não in�nito, é somado a todos os valores. Então, os valores
positivos são normalizados, pois apenas estes serão considerados na hora de selecionar a
próxima tarefa da solução. Esta soma se dá para que apenas tarefas que apresentem um
benefício maior que seu prejuízo estejam no conjunto selecionável.
4.2 Criação de Soluções
Uma vez que o algoritmo de valoração é feito para selecionar uma tarefa a partir de um
único estado inicial I0, um método iterativo é necessário para produzir uma solução viável
para a estratégia O. O algoritmo 4 mostra o processo de criação de soluções. Para guiar o
algoritmo, os valores para restrições e objetivos são aumentados a cada iteração por um
fator ∆. O algoritmo seleciona uma tarefa aleatoriamente, através de uma roleta, dentre as
tarefas valoradas positivamente pelo algoritmo anterior. Este processo é repetido até que a
solução seja válida ou o tempo de início da última tarefa (Smax(x)) exceda o tempo limite
UB de�nido na estratégia O. Caso o tempo seja maior, o algoritmo reduzirá o tamanho
da solução progressivamente para tentar corrigir erros, que podem ser causados por um
posicionamento tardio de alguma dependência (como pré-requisitos). Este algoritmo supõe
um modelo com soluções válidas. Caso o tempo seja curto demais para uma solução válida
aparecer, o algoritmo entrará em um loop, sem conseguir adicionar nenhuma tarefa à
solução.
Este algoritmo também pode ser utilizado para correção de soluções inválidas. A mu-
dança de soluções através de operações de vizinhança comumente as torna inválidas, e.g.
troca de posição entre requisito e requerente. Para validar uma solução, sua cauda é cor-
tada: a partir da primeira solução inválida até o �nal da solução. Então, a solução é
reconstruída usando o algoritmo de criação, passando o estado �nal da solução podada
como estado inicial. Como o foco desta aplicação é a validação de uma solução, é reco-
55
Algoritmo 4 Algoritmo de geração de soluções para um estado I0 e uma estratégia O.1: procedimento criar(I0, O, δo, δr, δp, δc, δm, ∆o, ∆r)2: x← {}3: r ← 14: enquanto naoValido(x, O) faça5: valores← valoresTarefas(I0, O, δo, δr, δp, δc, δm)6: δo ← δo∆o
7: δr ← δr∆r
8: x← x ∪ roleta(valores)9: se Smax(x) > UB então
10: tamanho← x.tamanho11: x.redimensionar(tamanho− r)12: r ← r + 113: se r > x.tamanho então
14: r ← 115: �m se
16: �m se
17: �m enquanto
18: retorne x19: �m procedimento
mendado o uso de pesos maiores para restrições em relação aos pesos dos objetivos, para
que a solução cumpra cada restrição mais rápido.
56
5 Meta-heurísticas
Quatro otimizadores foram implementados para o problema de produção de recursos
com eventos cíclicos e comparados em um experimento computacional: (a) NSGA-II (DEB
et al., 2002), (b) uma versão do NSGA-II com um algoritmo de ordenação baseado nos
ângulos entre as soluções (BRANKE et al., 2004), (c) uma colônia de formigas multiob-
jetivo, ou MOACO (LÓPEZ-IBÁÑEZ, 2004) e (d) GRASP multiobjetivo, ou MOGRASP
(REYNOLDS; CORNE; IGLESIA, 2009). Embora seja possível encontrar as soluções ótimas
através de um algoritmo exato, otimizadores heurísticos foram escolhidos pelo tempo que
os algoritmos exatos consomem, tornando-os inviáveis para uso em um cenário real para
inteligências arti�ciais de jogos. Neste capítulo, as versões usadas nos experimentos serão
explicadas.
Todos os algoritmos utilizados possuem uma forma de paralelismo. Nos algoritmos
genéticos, esse paralelismo se dá na criação e mutação das soluções, no MOACO e MO-
GRASP na criação de soluções e na busca local. Este paralelismo foi utilizado para acessar
todo o poder de processamento de modernas CPU que possuem mais de um núcleo pro-
cessador.
Além disto, todos os algoritmos utilizam uma única operação de vizinhança: a simples
troca de posição entre duas tarefas aleatórias diferentes de uma solução, o que pode
resultar em uma solução inválida. Caso a nova solução seja inválida, uma operação de
conserto é utilizada até que uma solução válida seja encontrada, baseada no algoritmo de
criação de solução aplicado à metaheurística.
5.1 NSGA-II
Dois algoritmos genéticos foram implementados, ambos baseados numa simpli�cação
da meta-heurística NSGA-II. Estas versões diferem apenas no funcionamento do método
de ordenação, avaliar_ordenar, onde foram usados o método original baseado em distância
entre soluções e um método alternativo baseado nos ângulos entre as soluções do conjunto
57
Algoritmo 5 NSGA-II Simpli�cado1: procedimento NSGAII(I0, O, δo, δr, ∆o, ∆r, c, δFo , δ
Fr , ∆F
o , ∆Fr , it)
2: x← gerarParalelo(c, δo, δr, ∆o, ∆r)3: avaliar_ordenar(x, O)4: para i = 1 até it faça5: x← selecionar(x)6: x← ∅7: para todo s ∈ x em paralelo faça8: x← x ∪ mutar(s, δFo , δFr , ∆F
o , ∆Fr )
9: �m para
10: x← x ∪ x11: avaliar_ordenar(x, O)12: �m para
13: �m procedimento
de aproximação. A operação de seleção, selecionar, é a mesma para os dois casos, isto é, a
partir de uma população com o dobro do tamanho permitido L, seleciona-se as melhores
L soluções. Em ambos os casos, a operação de mutação é uma simples troca de posição
entre duas tarefas.
O algoritmo base (ver Algoritmo 5) recebe como entrada o estado inicial I0, a estratégia
O, os valores de contribuição δo, δr e os valores de incremento ∆o,∆r para o algoritmo
de criação, o tamanho n do arquivador, os valores δFo , δFr ,∆
Fo ,∆
Fr para o algoritmo de
reconstrução, além da quantidade de iterações it. Inicialmente são geradas aleatoriamente
as soluções, e então o algoritmo as avalia e ordena. Dentro do laço iterativo, o algoritmo
seleciona as soluções do conjunto, seguindo a seleção do NSGA-II em que as N melhores
soluções são selecionadas de acordo com o algoritmo de ordenação, onde N é o tamanho
do arquivador. A implementação utilizada para o NSGA-II não possui um operador de
cruzamento nem uma chance de mutação. Ao invés disto, novas gerações são criadas a
partir de todas as soluções do conjunto atual através de uma simples mutação. Finalmente,
o conjunto de soluções é avaliado e ordenado no �m do laço. Para acelerar o desempenho
do algoritmo, a criação e a mutação das soluções são feitas em paralelo.
5.1.1 �Knee�
Em seu trabalho sobre a busca de joelhos em otimização multiobjetivo, Branke et
al. (2004) apresentaram duas abordagens para o otimizador: (a) otimizador focado em
ângulo e (b) otimizador focado em utilidade. Estas alterações se dão como substituição
do algoritmo de ordenação do NSGA-II, crowding distance. Os experimentos feitos aqui
mostraram resultados para o otimizador focado em ângulo. Esta abordagem veri�ca o
58
Algoritmo 6 Algoritmo de ordenação baseada em ângulos1: procedimento KneeSort(x, O)2: x′ ← ordenarNaoDominado(x, O) . Mesma ordenação usada no NSGA-II3: para todo I ∈ x′ faça4: metrica← {0, . . . , 0}5: para todo m ∈M ∪N faça
6: ordernarDescendente(I, m) . Ordena pelo objetivo m7: metrica[I[1]]← metrica[I[|I|]]←∞ . Valores extremos são selecionados8: �m para
9: para i = 2 até |I| − 1 em paralelo faça10: se metrica[i] = 0 então11: A← {v ∈ I| 6 ∃v′ ∈ I \ {I[1], I[|I|], I[i]}, ||v′ − i|| < ||v − i||}12: B ← {v ∈ I|Ortante(v − I[i]) 6= Ortante(A− I[i])}13: B ← {v ∈ B| 6 ∃v′ ∈ I \ {I[1], I[|I|], I[i], A}, ||v′ − i|| < ||v − i||}14: A← A− i15: B ← B − i16: metrica[i]← 2π − arccos
(A·B||A||||B||
)17: �m se
18: �m para
19: ordernarDescendente(I, metrica)20: �m para
21: �m procedimento
ângulo que existe entre dois pontos e um determinado eixo. Essa comparação é feita
usando cada um dos pontos como eixo.
Inicialmente, o algoritmo de ordenação (ver algoritmo 6) classi�ca as soluções de
acordo com o seu grau de dominância, utilizando o mesmo método do NSGA-II. Estas
soluções estão divididas em conjuntos de forma que cada conjunto domine todos os se-
guintes. Então, para cada conjunto I serão calculados valores para cada solução, referentes
à métrica de ordenação. Os valores são inicializados em zero, e os pontos extremos para
cada função objetivo recebem o valor in�nito, para que eles sejam sempre selecionados.
Os demais pontos utilizarão o ângulo entre os pontos mais próximos que não estão no
mesmo ortante em relação ao eixo i. Isto é feito selecionando o ponto mais próximo da
solução i, e o segundo ponto mais próximo de i que não esteja no mesmo ortante que o
anterior.
5.2 MOGRASP
A versão multiobjetivo do GRASP utilizada neste trabalho (algoritmo 7) utiliza con-
juntos de aproximação ao invés de soluções, tanto para o algoritmo de criação quanto
59
Algoritmo 7 GRASP multiobjetivo1: procedimento MOGRASP(I0, O, δo, δr, ∆o, ∆r, c, n, δFo , δ
Fr , ∆F
o , ∆Fr , it)
2: x∗ ← ∅3: para i = 1 até it faça4: x← gerarParalelo(c, δo, δr, ∆o, ∆r)5: x∗ ← x ∗ ∪ x6: x∗ ← {x′ ∈ x ∗ | 6 ∃xi ∈ x∗, xi � x′}7: x∗ ← buscaLocal(x∗, n, δFo , δFr , ∆F
o , ∆Fr )
8: x∗ ← {x′ ∈ x ∗ | 6 ∃xi ∈ x∗, xi � x′}9: �m para
10: retorne x∗11: �m procedimento
para o algoritmo de busca local. A cada iteração, o algoritmo gera c novas soluções pa-
ralelamente, usando o mesmo processo de criação que o NSGA-II. Essas soluções são
adicionadas ao conjunto de aproximação e as soluções não-dominadas são �ltradas. En-
tão, um algoritmo de busca local baseado em conjuntos inicia sua busca a partir deste
conjunto, e as soluções encontradas são colocadas no conjunto de aproximação e �ltradas.
O algoritmo 7 utiliza a busca local baseada em conjuntos (BASSEUR et al., 2013),
onde a busca local trabalha em conjuntos de soluções ao invés de soluções individuais.
A relação de vizinhança utilizada foi N(?,?), uma vez que um número n de vizinhos é
calculado para cada solução do conjunto atual. A operação de vizinhança usada foi uma
simples troca entre duas tarefas. O algoritmo de conserto de soluções é aplicado após a
operação de vizinhança, caso a solução �nal seja inválida. Como o algoritmo de conserto
possui necessidades diferentes das necessidades do algoritmo de criação, pesos diferentes
são passados para cada um deles. Estes pesos são δFo , δFr , ∆F
o e ∆Fr .
Para encontrar a melhor fronteira de aproximação, o MOGRASP utilizou uma ver-
são paralela do arquivador de grade adaptativa, ou Adaptive Grid Archiver (KNOWLES;
CORNE, 2003). Esta versão utiliza threads diferentes para selecionar os vetores unicamente
extremos e para calcular os limites do hipercubo.
5.3 MOACO
Os otimizadores descritos até agora utilizaram o método de criação de soluções mos-
trado no capítulo anterior. Para usar um algoritmo baseado em formigas, um novo al-
goritmo de criação é proposto, que se baseia em um grafo que conecta todas as tarefas
entre si e com um outro vértice que aponta para o início da solução (veja Figura 6). Este
60
Algoritmo 8 Criação de soluções através de formigas1: procedimento criarFormiga(I0, O, δo, δr, ∆o, ∆r, τ , α, β)2: x← ∅3: r ← 14: enquanto não valido(x) faça5: η ← pesosIniciais(δo, δr, I0, O)6: δo ← δo∆o
7: δr ← δr∆r
8: x← x ∪ escolhaFormiga(τ , η, α, β)9: se Smax(x) > UB então . Caso a última tarefa seja inválida10: tamanho← x.tamanho11: x.redimensionar(tamanho− r) . Reduz o tamanho da solução12: r ← r + 113: se r > x.tamanho então
14: r ← 115: �m se
16: �m se
17: �m enquanto
18: retorne x19: �m procedimento
grafo indica os passos que uma formiga tomaria para chegar à última tarefa. Para aplicar
a criação de formigas ao problema de produção de recursos, o algoritmo de criação, ex-
posto no algoritmo 8, utiliza um único tipo de feromônio (LÓPEZ-IBÁÑEZ, 2004). Assim,
um grafo deste tipo é utilizado para guardar as informações dos feromônios, enquanto as
informações heurísticas não dependeriam da última tarefa escolhida.
O algoritmo de criação recebe como entrada o estado inicial I0, a estratégia O, os
pesos e multiplicadores δo, δr,∆o,∆r, a taxa de evaporação τ , a in�uência dos feromônios
α e a in�uência da heurística β. A partir de uma solução vazia, o algoritmo escolhe uma
tarefa baseado nos pesos iniciais e nos feromônios deixados por formigas anteriores. O
algoritmo 8 utiliza informações heurísticas e de feromônio da mesma maneira que o Ant
Sstart
T0
T1
T2
Figura 6: Grafo para um algoritmo de criação de soluções baseado em formigas.
61
Algoritmo 9 Colônia de formigas multiobjetivo1: procedimentoMOACO(I0, O, δo, δr, ∆o, ∆r, ρ, α, β, n, δFo , δ
Fr , ∆F
o , ∆Fr , formigas,
it)2: x∗ ← ∅3: inicializar(τ)4: para i = 1 até it faça5: x← ∅6: para f ∈ formigas em paralelo faça7: x← criarFormiga(I0, O, δo, δr, ∆o, ∆r, τ , α, β)8: x← buscaLocal(x, n, δFo , δ
Fr , ∆F
o , ∆Fr )
9: x← x ∪ x10: �m para
11: x∗ ← x∗ ∪ x12: x∗ ← {x′ ∈ x ∗ | 6 ∃xi ∈ x∗, xi � x′}13: atualizar(τ , ρ)14: �m para
15: retorne x∗16: �m procedimento
System, como na equação 7.1.
pij(t) =[τij(t)]
α[ηij]β∑
k[τik(t)]α[ηik]β
(5.1)
Como este problema possui um ou mais objetivos, o feromônio re�ete a sequência de
tarefas em cada solução da fronteira de aproximação atual. A cada iteração, o feromônio
τij(t) é igual ao número total de transições da tarefa i para a tarefa j em cada solução
da fronteira no tempo t − 1. A informação heurística re�ete os pesos dados pela função
initialWeights descrita no capítulo 6, que não requer uma sequência de tarefas.
O algoritmo continua escolhendo até que a solução seja válida ou que uma tarefa
seja alocada num tempo superior ao horizonte do projeto. Neste caso, ele retira uma
quantidade de tarefas incremental do �m da solução e continua a alocar mais tarefas. A
cada iteração, os valores dos pesos são aumentados pelas taxas ∆o e ∆r, o que direciona
as escolhas da formiga.
O algoritmo de busca local utilizado é o mesmo usado pelo MOGRASP, usando a
mesma relação de vizinhança N(?,?). O arquivador utilizado pelo foi o arquivador de grade
adaptativa, ou Adaptive Grid Archiver, na versão paralela utilizada pelo MOGRASP.
Uma vez que a execução de uma formiga não interfere nos resultados das outras
formigas da mesma iteração, cada formiga pode ser executada em processos paralelos
(PEDEMONTE; NESMACHNOW; CANCELA, 2011). O método de busca local utilizado faz
62
uma varredura na vizinhança de cada formiga, também em paralelo: há uma thread di-
ferente para cada vizinho de cada solução do conjunto. Desta forma, todas as soluções
vizinhas do conjunto atual são visitadas paralelamente a cada iteração.
63
6 Experimentos Computacionais
Para de�nir alguns parâmetros de cada otimizador, uma corrida iterativa (LÓPEZ-
IBÁÑEZ et al., 2011) foi usada em sete casos diferentes ao longo de 840 experimentos.
Os parâmetros que permaneceram estáticos para ambos otimizadores foram: o tamanho
do arquivador, o número de iterações e os valores δp, δc, δm. Cada otimizador rodou 10
iterações, com um arquivador de tamanho 8. Estes números baixos foram escolhidos para
capturar o ambiente de tempo-real de uma inteligência arti�cial para jogos. Os valores
para as variáveis de pré-requisito, custo e máximo são δp = 2, δc = 0, 5 e δm = 1.
Assim, a corrida iterativa otimizou os seguintes parâmetros comuns a todos os oti-
mizadores: δo, δr, ∆o, ∆r, δFo , δFr , ∆F
o , ∆Fr . Os valores encontrados (Tabela 10) tanto
pelo NSGA-II como pela sua variante �Knee� possuem valores mais baixos para todas as
variáveis de conserto δFo , δFr , ∆F
o , ∆Fr em relação às variáveis de criação δo, δr, ∆o, ∆r,
enquanto o MOACO e o MOGRASP possuem valores mais variados para as variáveis de
conserto. Os intervalos dados para estas variáveis estão na Tabela 9.
Além dos parâmetros comuns, parâmetros especí�cos a cada otimizador foram en-
contrados pela corrida iterativa (Tabela 12). Tanto o MOACO quanto o MOGRASP
encontraram os mesmos valores para iterações da busca local e para o número de vizinhos
visitados pela busca local. Embora não houvesse tanto espaço para variação na quantidade
Tabela 9: Intervalos de valores dos parâmetros comuns utilizados pelo irace.
δo δr ∆o ∆r δFo δFr ∆Fo ∆F
r
[0,01; 10] [1,01; 15] [1; 2,6] [1,2; 4] [0,01; 7] [1,01; 10] [1; 3] [1,2; 4]
Tabela 10: Parâmetros comuns encontrados para os otimizadores pelo irace.
Otimizador δo δr ∆o ∆r δFo δFr ∆Fo ∆F
r
NSGA-II 2.73 2.81 2.1 2.44 1.48 1.66 1.63 1.78Knee 2.85 12.76 1.64 1.77 1.87 2.34 1.76 1.83MOACO 3.84 6.93 2.27 3.13 3.71 4.45 2.96 3.47MOGRASP 4.19 6.26 1.79 2.11 2.86 8.78 1.56 2.09
64
Tabela 11: Intervalos de valores dos parâmetros especí�cos utilizados pelo irace.
Otimizador c ants Iter. B.L. Viz. B.L. α β ρNSGA-II [1; 100] � � � � � �Knee [1; 100] � � � � � �MOACO � [1; 10] [1; 10] [1; 2] [0; 5] [0,5; 10] [0,01; 1]MOGRASP [1; 10] � [1; 10] [1; 2] � � �
Tabela 12: Parâmetros especí�cos encontrados para os otimizadores pelo irace.
Otimizador c ants Iterações B.L. Vizinhos B.L. α β ρNSGA-II 34 � � � � � �Knee 72 � � � � � �MOACO � 7 3 2 0,73 3,4 0,6MOGRASP 15 � 3 2 � � �
de vizinhos (Tabela 11), a quantidade de iterações aponta que uma quantidade baixa de
iterações na busca local seja melhor para estes algoritmos.
O desempenho de cada otimizador foi mensurado pelo seus tempos de execução e
pelo indicador de hipervolume (BEUME et al., 2009), após normalizar os valores de cada
objetivo. Esta normalização teve como base os pontos extremos do conjunto não-dominado
de todas as soluções produzidas pelo experimento. Os casos de teste foram baseados na
raça Zerg de StarCraft, e utilizaram o estado inicial padrão do jogo. Testes estatísticos
foram feitos para o hipervolume utilizando o teste U de Mann-Whitney.
Os experimentos foram executados numa máquina com Debian 8.4 64-bit, Intel i7-
4790K @ 4.00GHz, 16GB RAM. O código-fonte foi implementado em C++11 e compilado
com g++ 4.9.2 usando a biblioteca OpenMP e a opção -Ofast. O processador possui quatro
núcleos físicos e oito núcleos virtuais para processamento paralelo.
Para avaliar o desempenho dos algoritmos, quinze casos de teste foram criados (ver
Tabela 13), baseados na raça Zerg e procuram medir a qualidade tanto de buscas em
largura quanto das buscas em profundidade de cada otimizador. Na Tabela 13, a primeira
coluna mostra o caso de teste, as funções objetivo adicionais estão relacionadas na segunda
coluna, e a terceira coluna mostra as restrições adicionais. Estes casos foram criados para
este trabalho como uma forma de mostrar, num cenário real, as capacidades dos algoritmos
de fazer buscas em profundidade e em largura. Por isto, eles variam seus objetivos e
restrições entre as unidades de maior nível tecnológico e a primeira unidade militar da
raça. A maior parte dos casos de teste são versões de uma estratégia mono-objetivo e
busca otimizar a quantidade de minérios utilizáveis, uma vez que é preciso ter um plano
para caso o ataque seja bem sucedido ou não. Maximizando o estoque de minérios garante
65
Tabela 13: Funções objetivo e restrições adicionais para os casos de teste dos experimentos.
Caso de Teste Funções Obj. Restrições
(a) - Guardian uti. ≥ 1(b) max. Minérios utilizáveis Guardian uti. ≥ 1
(c) -Mutalisk uti. ≥ 1Zergling uti. ≥ 1
(d) max. Minérios utilizáveisMutalisk uti. ≥ 1Zergling uti. ≥ 1
(e)max. Minérios utilizáveismax. Mutalisk utilizáveis
Mutalisk uti. ≥ 1Zergling uti. ≥ 1
(f) - Ultralisk uti. ≥ 1(g) max. Minérios utilizáveis Ultralisk uti. ≥ 1
(h) max. Hydralisk utilizáveisHydralisk uti. ≥ 1
Grooved Spines uti. ≥ 1
(i)max. Minérios utilizáveismax. Hydralisk utilizáveis
Hydralisk uti. ≥ 1Grooved Spines uti. ≥ 1
(j) max. Minérios utilizáveisHydralisk uti. ≥ 1Hatchery uti. ≥ 3
(k) -Zergling uti. ≥ 1
MetabolicBoost uti. ≥ 1
(l) max. Minérios utilizáveisZergling uti. ≥ 1
MetabolicBoost uti. ≥ 1
(m)max. Minérios utilizáveismax. Zergling utilizáveis
Zergling uti. ≥ 1MetabolicBoost uti. ≥ 1
(n)max. Minérios utilizáveismax. Zergling utilizáveis
Zergling uti. ≥ 1
66
Tabela 14: Ranking dos algoritmos baseado nas medianas de cada indicador. Menoresindicadores mostram os melhores resultados.
NSGA-II Knee MOACO MOGRASP
Hipervolume 1,86 1,5 2,86 3,57Tempo 1,07 2,71 3,64 2,57
que há economia para manter produções de unidades e estruturas após a série de tarefas.
Os casos (a) e (b) restringem o jogador a um ou mais Guardians. Eles são as unidades
militares voadoras de mais alto nível tecnológico, e requerem que outra unidade �Mutalisk
� evolua em um Guardian. Mutaliss é o primeiro tipo de unidade aérea dos Zerg e �ca no
meio da árvore tecnológica. Elas foram utilizadas pelos casos (c), (d) e (e). Os casos (f) e
(g) requerem pelo menos um Ultralisk, que é uma unidade militar terrestre do último nível
tecnológico. Os casos (h), (i) e (j) requerem Hydralisks, que são o segundo tipo de unidade
militar terrestre, capazes de atirar em unidades terrestres e aéreas. Seu aprimoramento de
alcance (Grooved Spines) é obrigatória para um uso e�ciente da unidade. O caso (j) requer
a criação de duas Hatcheries adicionais, e serve para avaliar o desempenho das buscas
em largura. Para ser capaz de produzir uma Hydralisk, é necessário ser capaz de produzir
Zerglings. Zerglings, requeridos por todos os casos de teste, são a primeira unidade militar
da raça e são normalmente usados em conjunto com Mutalisks. Seu aprimoramento de
movimentação (Metabolic Boost) também é mandatória para o uso da unidade. Destes
casos de teste, os casos (k), (l), (m) e (n) também foram utilizados na corrida iterativa
como casos de aprendizado, em conjunto com outros dez casos.
Os resultados de hipervolume (ver Figura 7) mostram a diferença entre os algoritmos.
O desempenho dos otimizadores foi classi�cado na Tabela 14. Quanto menor o valor dado
ao otimizador, melhor ele foi no respectivo indicador. Nos testes feitos, o algoritmo que
obteve melhor desempenho pelas medianas do indicador de hipervolume foi a variante do
NSGA-II, �Knee�. Enquanto o NSGA-II possui o melhor ranking das medianas dos tem-
pos (ver Tabela 14), e o segundo melhor desempenho em hipervolumes. Um dado que os
rankings escondem é a discrepância entre os tempos que o �Knee� apresenta em casos que
requerem Spire1 e possuam funções-objetivo adicionais (ver Figura 8). Os tempos destes
casos, (b) e (d), possuem medianas 1505, 99s e 1048, 01s. Esta discrepância pode ser ex-
plicada pelo algoritmo de ordenação, que possui complexidade maior que o algoritmo de
ordenação do NSGA-II. Porém, apenas a ordenação não consegue explicar os tempos si-
milares que o algoritmo obteve nas instâncias que envolvem Hydralisks e Zerglings. Então,
1Estrutura que permite a criação de Mutalisks.
67
Figura 7: Hipervolumes para as meta-heurísticas utilizadas.
68
Figura 8: Tempo em segundos para os otimizadores testados. Asterisco indica que o algo-ritmo demorou mais que 500 segundos, mas retornou o conjunto de aproximação.
69
Tabela 15: Resultado dos p-valores para o teste U de Mann-Whitney. O teste foi feito nosconjuntos de hipervolumes de cada um dos otimizadores em comparação com os outros,para cada caso de teste. Valores em negrito indicam resultados estatisticamente diferentes.
(a) Knee MOACO MOGRASP (b) Knee MOACO MOGRASPNSGA-II 0,7618 0,09611 0,3291 NSGA-II 7,38E-6 3,21E-16 2,2E-16
Knee 0,09037 0,3477 Knee 1,17E-4 3,63E-12
MOACO 0,7282 MOACO 4,58E-9
(c) Knee MOACO MOGRASP (d) Knee MOACO MOGRASPNSGA-II 0,5247 0,09611 0,3291 NSGA-II 0,3074 1,11E-5 1,55E-14
Knee 0,7957 0,01435 Knee 1,99E-10 2,2E-16
MOACO 0,001507 MOACO 1,99E-10
(e) Knee MOACO MOGRASP (f) Knee MOACO MOGRASPNSGA-II 0,5229 8,9E-5 1,4E-5 NSGA-II 0,3254 0,9175 0,7171Knee 2,8E-5 8,68E-6 Knee 0,1152 0,5741
MOACO 0,8891 MOACO 0,6572
(g) Knee MOACO MOGRASP (h) Knee MOACO MOGRASPNSGA-II 3,25E-5 3,12E-13 2,2E-16 NSGA-II 0,8087 0,02415 3,98E-9
Knee 3,78E-5 2,2E-16 Knee 0,1393 4,67E-8
MOACO 2,2E-16 MOACO 8,06E-10
(i) Knee MOACO MOGRASP (j) Knee MOACO MOGRASPNSGA-II 0,7412 2,23E-5 9,16E-8 NSGA-II 0,4492 3,09E-10 1,29E-11
Knee 2,67E-6 2,42E-9 Knee 2,6E-5 6,64E-9
MOACO 0,04621 MOACO 5,43E-5
(k) Knee MOACO MOGRASP (l) Knee MOACO MOGRASPNSGA-II 0,1395 2,19E-1 8,35E-1 NSGA-II 1,63E-9 3,21E-16 2,2E-16
Knee 0,8259 0,1777 Knee 5,96E-8 5,75E-6
MOACO 0,2294 MOACO 0,0008691
(m) Knee MOACO MOGRASP (n) Knee MOACO MOGRASPNSGA-II 0,592 2,48E-12 1,37E-8 NSGA-II 0,04789 2,2E-16 8,78E-2
Knee 3,89E-13 2,42E-9 Knee 2,2E-16 0,0008691
MOACO 0,2539 MOACO 2,2E-16
é mais provável que uma combinação das variáveis de geração de soluções e o algoritmo
de ordenação tenha causado essa discrepância. O MOGRASP apresentou tempos pareci-
dos com os tempos dos algoritmos genéticos, sendo mais lento pelo uso da busca local.
Embora use busca local, seu desempenho nos hipervolumes foi o pior. MOACO por sua
vez, foi consistentemente lento em todas as instâncias, embora tenha conseguido melhores
resultados nos hipervolumes.
Uma análise dos resultados dos hipervolumes (ver Tabela 15) mostra que não há dife-
rença estatística entre a maior parte dos pares de otimizadores em casos mono-objetivo,
(a), (c) e (f). É possível observar que na maior parte dos casos, os algoritmos genéticos
acabam produzindo resultados estatisticamente similares. Os resultados são mais diferen-
tes conforme a quantidade de objetivos e a profundidade da busca aumentam, como nos
casos (g), (l) e (n). Desta forma, pode-se perceber que o desempenho dos algoritmos,
quando produzem resultados diferentes, favorece o NSGA-II. Ao mesmo tempo que nos
70
Figura 9: Soluções encontradas pelas meta-heurísticas para o caso de teste (l). O eixovertical indica o estoque de minérios, enquanto o eixo horizontal indica o makespan emsegundos.
casos que não há diferença estatística, o NSGA-II produz resultados mais rápidos.
A �gura 9 mostra todas as soluções encontradas por cada otimizador ao longo de suas
30 execuções. É possível observar que os algoritmos genéticos possuem uma distribuição
mais uniforme das soluções, enquanto o MOACO e o MOGRASP tendem a se concentrar
na região próxima do tempo mínimo. O algoritmo �Knee� possui uma abertura logo após
esta região, e em seguida uma aglomeração de soluções. Este comportamento pode se dar
pelo algoritmo de ordenação baseado em ângulos, que provavelmente identi�cou ângulos
maiores na região da aglomeração, e ângulos menores na região vazia.
Era esperado que algoritmos que possuem busca local terminassem em tempos mai-
ores que os algoritmos genéticos, porém os resultados dos hipervolumes foram piores.
Uma possível explicação se encontra no treinamento dado aos algoritmos, que pode ter
resultado em valores ruins para as variáveis de criação e reconstrução de soluções. Os
algoritmos MOACO e MOGRASP possuem um conjunto maior de variáveis que os algo-
ritmos genéticos, então o iterated race poderia ter diversi�cado a otimização em todas as
variáveis, ao invés de intensi�car nas variáveis de criação e reconstrução.
71
7 Conclusão
Este trabalho mostrou um novo problema de otimização multiobjetivo, motivado por
jogos de estratégia em tempo real. Este novo modelo visa preencher a lacuna deixada por
modelos anteriores, que não conseguem capturar certos aspectos envolvidos nos recursos
de RTS. O modelo possui três variáveis, o sistema, o estado inicial e a estratégia. Um
conjunto de otimizadores foi selecionado para veri�car a factibilidade do modelo, e a
viabilidade do modelo em ambientes reais.
O modelo se mostrou factível, uma vez que quatro otimizadores foram criados com
sucesso para resolver o modelo. A viabilidade do modelo, no entanto, depende do tipo de
otimizador que é considerado. O algoritmo �Knee�, modi�cação do NSGA-II que busca
�joelhos�, não apresenta melhoras estatísticas no desempenho para a maioria dos casos, e
ainda possui um tempo de processamento muito alto para determinados casos. Algoritmos
com busca local produziram resultados por vezes melhor, mas com um tempo previsivel-
mente superior aos algoritmos genéticos. O algoritmo que conseguiu se manter de forma
consistente em boas colocações tanto no desempenho dos hipervolumes quanto no tempo
de execução foi o NSGA-II, que �cou com o melhor tempo de execução e o segundo melhor
desempenho em hipervolumes.
O NSGA-II utilizado possui apenas o operador de mutação que é aplicado à toda a
população, sem chance de falha. Este algoritmo, bem mais simples que os algoritmos de
busca local, conseguiu, em ummesmo número de iterações, obter melhores resultados. Esta
liderança pode ser explicada pela quantidade de variáveis que cada otimizador precisou
otimizar na iterated race.
Os experimentos também mostraram o comportamento dos casos de teste e o que
esperar do tempo de execução em cada um deles. Casos com um único objetivo se mostra-
ram não só mais simples de resolver mas os otimizadores também entregaram respostas
muito próximas entre si. É possível observar que a complexidade de cada caso depende não
só da quantidade de objetivos mas da profundidade da busca. Esta profundidade pode ser
72
vista nos casos que precisam de tarefas no �m da árvore tecnológica, e.g. (b), ou tarefas
que demoram excepcionalmente mais que a média de tarefas, e.g. (j). Porém, os únicos
casos que possuem tempo de execução aceitável em um ambiente de tempo real são os
casos de baixa profundidade, ou os casos (k) a (n). Desta forma, é aconselhável escolher
uma aprendizagem o�ine para estratégias que exijam tarefas avançadas, enquanto um
processo online pode ser implementado para estratégias imediatas. Para o sistema utili-
zado, a raça Zerg de StarCraft, isto signi�ca estratégias para até cinco minutos à frente
do tempo.
Trabalhos futuros neste tema incluem:
• criação de métodos de tomada de decisão e comparação com métodos mono-objetivo
para a mesma estratégia;
• a utilização de otimizadores em inteligências arti�ciais para jogos e a comparação
do impacto dos otimizadores no desempenho destas inteligências arti�ciais;
• uma comparação mais minuciosa entre os otimizadores, por exemplo utilizando os
mesmos parâmetros de criação e reconstrução de soluções;
• utilização de operadores mais complexos nos algoritmos genéticos;
• comparação entre outros otimizadores.
Com este trabalho esperamos estimular pesquisas adicionais em otimização multiob-
jetivo e problemas de escalonamento para RTS, a pesquisa em produção de recursos para
ambientes dinâmicos, bem como a utilização de otimizadores em inteligências arti�ciais
para jogos.
73
Referências
BASSEUR, M. et al. On set-based local search for multiobjective combinatorialoptimization. In: Proceeding of the Fifteenth Annual Conference on Genetic andEvolutionary Computation. [S.l.]: ACM, 2013. p. 471�478.
BEUME, N. et al. On the complexity of computing the hypervolume indicator. IEEETransactions on Evolutionary Computation, v. 13, p. 1075�1082, 2009.
BLACKFORD, J. M. Online Build-Order Optimization for Real-Time Strategy AgentsUsing Multi-Objective Evolutionary Algorithms. Dissertação (Mestrado) � Air ForceInstitute of Technology, mar. 2014.
BOUZY, B.; CAZENAVE, T. Computer go: an ai oriented survey. Arti�cial Intelligence,Elsevier, v. 132, n. 1, p. 39�103, 2001.
BOYD, S.; VANDENBERGHE, L. Convex Optimization. Cambridge: CambridgeUniversity, 2009.
BRANKE, J. et al. Finding knees in multi-objective optimization. In: SPRINGER.Parallel Problem Solving from Nature-PPSN VIII. [S.l.], 2004. p. 722�731.
BRANQUINHO, A. A. B.; LOPES, C. R. Planning for resource production in real-timestrategy games based on partial order planning, search and learning. In: Systems Manand Cybernetics (SMC), 2010 IEEE International Conference on. [S.l.: s.n.], 2010. p.4205�4211.
BRUCKER, P. et al. Resource-constrained project scheduling: Notation, classi�cation,models, and methods. European Journal of Operational Research, Elsevier, v. 112, n. 1,p. 3�41, 1999.
BURO, M. Real-time strategy games: A new ai research challenge. In: 2003 InternationalJoint Conference on Arti�cial Intelligence Proceedings. [S.l.: s.n.], 2003. p. 1534�1535.
CHAN, H. et al. Extending online planning for resource production in real-time strategygames. In: Workshop on Planning in Games, ICAPS 2007. [S.l.: s.n.], 2007.
CHAN, H. et al. Online planning for resource production in real-time strategy games. In:International Conference on Automated Planning and Scheduling 2007. [S.l.: s.n.], 2007.p. 65�72.
CHURCHILL, D.; BURO, M. Build order optimization in starcraft. AAAI Conferenceon Arti�cial Intelligence and Interactive Digital Entertainment, 2011. Disponível em:<http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4078>.
74
COELHO, J.; VANHOUCKE, M. The multi-mode resource-constrained projectscheduling problem. In: Handbook on Project Management and Scheduling Vol. 1. [S.l.]:Springer, 2015. p. 491�511.
DEB, K. et al. A fast and elitist multiobjective genetic algorithm: Nsga ii. IEEETransactions on Evolutionary Computation, IEEE, v. 6, n. 2, p. 182�197, 2002.
FIKES, R. E.; NILSSON, N. J. Strips: A new approach to the application of theoremproving to problem solving. Arti�cial intelligence, Elsevier, v. 2, n. 3-4, p. 189�208, 1971.
HAGELBÄCK, J. A Multiagent Potential Field-Based Bot for Real-Time Strategy Game.Tese (Doutorado) � Blekinge Institute of Technology, Karlskrona, Suécia, jan. 2012.
HERROELEN, W.; DEMEULEMEESTER, E.; REYCK, B. D. A classi�cation schemefor project scheduling. [S.l.]: Springer, 1999.
KNOWLES, J. D.; CORNE, D. W. Properties of an adaptive archiving algorithm forstoring nondominated vectors. IEEE Transactions on Evolutionary Computation, IEEE,v. 7, n. 2, p. 100�116, 2003.
KÖSTLER, H.; GMEINER, B. A multi-objective genetic algorithm for build orderoptimization in starcraft ii. KI-Künstliche Intelligenz, Springer, v. 27, n. 3, p. 221�233,2013.
KOVARSKY, A.; BURO, M. A �rst look at build-order optimization in real-timestrategy games. In: Proceedings of the GameOn Conference. [S.l.: s.n.], 2006. p. 18�22.
KUCHEM, M.; PREUSS, M.; RUDOLPH, G. Multi-objective assessment of pre-optimized build orders exempli�ed for starcraft 2. In: IEEE. Computational Intelligencein Games (CIG), 2013 IEEE Conference on. [S.l.], 2013. p. 1�8.
LÓPEZ-IBÁÑEZ, M. Multi-objective Ant Colony Optimization. Dissertação (Mestrado)� Intellectics Group, Computer Science Department, Technische Universität Darmstadt,Germany, 2004.
LÓPEZ-IBÁÑEZ, M. et al. The irace package, Iterated Race for Auto-matic Algorithm Con�guration. Bruxelas, Bélgica, 2011. Disponível em:<http://iridia.ulb.ac.be/IridiaTrSeries/IridiaTr2011-004.pdf>.
MCDERMOTT, D. A heuristic estimator for means ends analysis in planning. In:DRABBLE, B. (Ed.). Proceedings of the Third International Conference on Arti�cialIntelligence Planning Systems (AIPS96). Edimburgo, Escócia: [s.n.], 1996. p. 150�157.
NAVES, T. F. Uma abordagem para maximização da produção de recursos em jogosRTS. Dissertação (Mestrado) � Universidade Federal de Uberlândia, jul. 2012.
NAVES, T. F.; LOPES, C. R. Maximization of the resource production in rts gamesthrough stochastic search and planning. In: IEEE. Systems, Man, and Cybernetics(SMC), 2012 IEEE International Conference on. [S.l.], 2012. p. 2241�2246.
NEWELL, A.; SHAW, J. C.; SIMON, H. A. Report on a general problem solvingprogram. In: Proceedings of the International Conference on Information Processing.Paris: UNESCO, 1959. p. 256�264.
75
OLIVEIRA, C. de; GOLDBARG, E. F. G.; GOLDBARG, M. C. Multiobjective modelto address planning in a rts game. In: IEEE. 2016 IEEE Congress on EvolutionaryComputation (CEC). [S.l.], 2016.
ONTAÑÓN, S. et al. A survey of real-time strategy game ai research and competitionin starcraft. IEEE Transactions on Computational Intelligence and AI in Games, IEEE,v. 5, n. 4, p. 293�311, 2013.
PEDEMONTE, M.; NESMACHNOW, S.; CANCELA, H. A survey on parallel antcolony optimization. Applied Soft Computing, Elsevier, v. 11, n. 8, p. 5181�5197, 2011.
REYNOLDS, A. P.; CORNE, D. W.; IGLESIA, B. de la. A multiobjective grasp for ruleselection. In: Proceedings of the 11th Annual Conference on Genetic and EvolutionaryComputation. [S.l.]: ACM, 2009. p. 643�650.
SAJJAD, M.; ISLAM, M. M. ul. Asymmetric Potential Fields: Implementation ofAsymmetric Potential Fields in Real Time Strategy Game. Dissertação (Mestrado) �School of Computing, Blekinge Institute of Technology, Karlskrona, Suécia, jan. 2011.
WEINBERGER, M. Now that google's arti�cial brain is conquering go, this classiccomputer game from 1998 could be next. Business Insider, Mar 2016. Disponívelem: <http://www.businessinsider.com/google-deepmind-could-play-starcraft-2016-3>.Acesso em: 23 mar. 2016.
ZAMANI, R.; SHUE, L.-Y. Solving project scheduling problems with a heuristiclearning algorithm. The Journal of the Operational Research Society, Palgrave MacmillanJournals, v. 49, p. 709�716, jul. 1998.
ZITLER, E.; LAUMANNS, M.; BLEULER, S. A tutorial on evolutionary multiobjectiveoptimization. In: Lecture Notes in Economics and Mathematical Systems. [S.l.: s.n.],2004. v. 535, p. 3�37.
76
APÊNDICE A -- Descrição do jogo StarCraft
Todo jogo de StarCraft tradicionalmente começa com uma base inicial e quatro tra-
balhadores situados numa região com alta quantidade de minérios e pelo menos um gêiser
de gás vespeno, como mostrado na Figura 10. No canto superior direito, estão expostos
os recursos com os quais o jogador trabalha: minérios, gás vespeno e suprimentos (ver
Figura 11). Suprimentos possuem a quantidade utilizada e a quantidade total expostas
lado a lado, o primeiro no lado esquerdo e o segundo no lado direito. Minérios e gás ves-
peno podem ser considerados recursos naturais, pois eles estão presentes no mapa (campo
de batalha) para serem coletados, enquanto suprimentos são construídos com estruturas
especializadas utilizando esses recursos naturais.
Desses recursos naturais, os minérios são os principais, usados para produção de todas
as unidades, estruturas e pesquisas dentro do jogo. O gás vespeno, por sua vez, é usado
para unidades especiais e pesquisas tecnológicas. Para aquisição desses recursos são neces-
sários trabalhadores, que se encarregarão de coletar os recursos a partir de alguma fonte
e entregá-los à base mais próxima.
Além de recursos naturais, o jogador precisa de suprimentos, sem os quais não é
possível produzir unidades. Cada unidade consome uma quantidade pré-determinada de
Figura 10: Base inicial em StarCraft após poucos minutos de jogo.
77
Figura 11: Recursos na interface grá�ca de StarCraft.
suprimentos, e para poder produzir mais unidades é necessária a criação de mais fon-
tes de suprimento, até que se chegue à capacidade máxima determinada pelo jogo. Um
recurso que pode ser considerado secundário é o tempo, uma vez que toda produção e
movimentação está restrita ao tempo de conclusão.
A criação de unidades, incluindo trabalhadores, é feita em estruturas de produção.
Essas estruturas podem ter pré-requisitos estruturais, isto é, o jogador pode necessitar
de uma ou mais estruturas já construídas para que possa construir uma determinada
estrutura. Unidades também podem ter esses pré-requisitos, isto é, o jogador pode precisar
de outra estrutura além da estrutura produtora para produzir um determinado tipo de
unidade. As estruturas de produção possuem uma �la de produção com a qual pode-se
antecipar a ordem de construção de alguma unidade, isto é, sem precisar futuramente
mandar a estrutura produzir no tempo exato de término da última tarefa. Isso ajuda o
jogador a otimizar o tempo em algumas situações, como quando ele quer produzir muitas
unidades.
Unidades possuem tipos, tamanhos e visibilidades. Os tipos possíveis são: (a) mecâ-
nico, (b) robótico e (c) biológico. Unidades mecânicas possuem componentes mecânicos,
normalmente sendo algum tipo de veículo. Unidades robóticas são controladas por alguma
inteligência arti�cial e por isso são imunes a certas habilidades que atigem unidades mecâ-
nicas. Unidades biológicas são compostas primariamente de componentes não-mecânicos,
como as unidades que representam seres de cada uma das raças. Unidades também pos-
suem tamanhos: (a) pequeno, (b) médio e (c) grande. O tamanho das unidades é levemente
relacionado ao seu tamanho real, sendo mais próximo da qualidade da armadura que ela
usa. Unidades também podem ser camu�adas ou detectoras. Unidades camu�adas fazem
o jogador inimigo precisar de uma estrutura ou unidade detectora para revelá-las para o
jogador. Apenas uma unidade é tanto detectora como camu�ada: o observer dos Protoss.
Além disso, unidades podem ser voadoras ou terrestres. Unidades voadoras não possuem
restrição de movimento, enquanto as terrestres estão restritas ao terreno do mapa.
Unidades e estruturas podem possuir energia. Este recurso é usado para ativar cer-
tas habilidades, e o estoque de cada unidade/estrutura aumenta com o tempo até um
limite máximo pré-determinado. Em alguns casos, é possível aumentar o limite máximo
78
Figura 12: Matriz psiônica dos Protoss.
de energia de algumas unidades com a pesquisa de tecnologias relacionadas.
Antes de cada partida, o jogador deve escolher uma entre três raças, cada uma com
suas próprias árvores tecnológicas e peculiaridades. A seguir, cada uma das raças será
descrita, com sua árvore tecnológica.
A.1 Protoss
Protoss são uma raça de alienígenas tecnologicamente bem desenvolvidos, e com uma
sociedade de castas rígida. Os poderes e ataques de suas unidades misturam conceitos
de alta tecnologia e magia. As estruturas desta raça necessitam estar localizadas dentro
de uma �matriz psiônica�, uma área elíptica ao redor de uma estrutura fornecedora de
energia (ver Figura 12). Estruturas também são construídas automaticamente, isto é,
trabalhadores são necessários apenas para iniciar o processo de construção, podendo voltar
à coleta de recursos depois. Além disso, Protoss são a única raça que possui escudos de
energia. Todas as suas estruturas e unidades possuem algum tipo de proteção de escudo
além dos pontos de vida comuns. Estes pontos de escudo regeneram, enquanto os pontos de
vida não. Esta raça também não possui nenhum meio de conserto de unidades mecânicas
ou robóticas.
A.1.1 Estruturas
•Nexus : estrutura-base que produz os trabalhadores. Ela não necessita de uma matriz
psiônica para funcionar.
79
Figura 13: Árvore tecnológica dos Protoss. Estruturas estão representadas dentro de re-tângulos e unidades aparecem em cima de círculos. Unidades estão ligadas às estruturasque as produzem por linhas azuis, enquanto dependências são representadas por setasvermelhas que saem da dependência para o dependente.
80
•Pylon: estrutura fornecedora de suprimento, que também serve de gerador de energia
para as outras estruturas.
•Assimilator : estrutura que permite a coleta de gás vespeno dos gêiseres. Ela não
necessita de matriz psiônica.
•Forge: estrutura de pesquisa para melhoramentos de ataque e defesa das unidades
terrestres.
•Photon Cannon: estrutura de defesa detectora, capaz de atirar em unidades terres-
tres e aéreas.
•Gateway : estrutura de produção de unidades biológicas terrestres.
•Shield Battery : estrutura que regenera escudos de unidades próximas ao custo de
energia.
•Cybernetics Core: estrutura de pesquisa para melhoramentos de ataque e defesa das
unidades voadoras.
•Robotics Facility : estrutura de produção de unidades robóticas.
•Robotics Support Bay : estrutura de pesquisa de tecnologias para unidades robóticas.
•Observatory : estrutura de habilitação e pesquisa de tecnologias relacionadas ao ob-
server.
•Stargate: estrutura de produção de unidades aéreas.
•Fleet Beacon: estrutura de habilitação e pesquisa de tecnologias relacionadas ao
carrier.
•Citadel of Adun: estrutura de pesquisa de tecnologias relacionadas ao zealot.
•Templar Archives : estrutura de habilitação e pesquisa de tecnologias relacionadas ahigh templar e dark archon.
•Arbiter's Tribunal : estrutura de habilitação e pesquisa de tecnologias relacionadas
ao arbiter.
81
A.1.2 Unidades
•Probe: unidade trabalhadora, capaz de coletar recursos e iniciar construções.
•Zealot : unidade biológica pequena corpo-a-corpo. Primeira unidade militar da raça.
•Dragoon: unidade mecânica grande de ataques à distância.
•High Templar : unidade biológica pequena. Possui habilidades ao invés de ataques,
e uma grande quantidade de energia. Sua principal habilidade é psionic storm, que
causa grande quantidade de dano em área.
•Dark Templar : unidade biológica pequena corpo-a-corpo camu�ada. Possui um ata-
que de alto dano, sendo capaz de destruir trabalhadores em um único golpe. Isto
pode ser potencialmente perigoso, pois o jogo não avisa quando uma unidade morre
após um único golpe.
•Archon: unidade grande de ataques à distância, sem nenhum outro tipo. Feito da
combinação de dois high templar, é uma unidade que possui quantidade ín�ma
de pontos de vida, mas um dos maiores escudos da raça. Seu alcance é reduzido.
comparado a outras unidades de ataque à distância, mas causa grande dano em área
a cada golpe.
•Dark Archon: unidade grande, sem nenhum outro tipo. Feito da combinação de dois
dark templar, essa unidade não possui nenhum ataque, sendo um conjurador como
o high templar. Sua habilidade característica é feedback, que exaure o estoque de
energia de uma unidade e causa a mesma quantidade em dano seus pontos de vida.
Tal qual o archon, ela possui uma grande quantidade de escudos e poucos pontos
de vida.
•Shuttle: unidade robótica aérea grande. O shuttle serve de transportadora para a
raça. Possui oito vagas para transporte, como todos os transportadores, mas cada
unidade exige uma quantidade de vagas diferente. É possível aumentar a velocidade
do transporte com uma tecnologia especializada.
•Reaver : unidade robótica terrestre de ataques à distância. Os ataques devastadorese em área do reaver possuem um custo bem de�nido. Cada unidade é capaz de
armazenar cinco tiros, porém ela é criada sem nenhum tiro. Cada tiro custa 25
minérios e tempo para ser feito. É possível aumentar o dano e a quantidade de tiros
armazenada por unidade com tecnologias.
82
•Observer : unidade robótica aérea detectora camu�ada pequena. Não possui ataques,apenas uma grande área de visão.
•Scout : unidade mecânica aérea grande de ataques à distância. Consegue atirar em
unidades terrestres e aéreas com dois ataques distintos.
•Corsair : unidade mecânica aérea de ataques à distância. Consegue atacar apenas
outras unidades aéreas. Possui uma habilidade que desabilita o ataque à distância
de unidades que estiverem em uma determinada área.
•Carrier : unidade mecânica aérea grande de ataques à distância. Como o reaver, esta
unidade não consegue atacar por si só, ela precisa produzir interceptors. Estas são
unidades que atacam pelo carrier. Elas são produzidar ao custo de 25 minérios e o
carrier pode acomodar quatro ao mesmo tempo. A capacidade pode ser aumentada
com tecnologia especilizada.
•Arbiter : unidade mecânica aérea grande de ataques à distância. Apesar de ser capaz
de atacar, seu dano e cadência de tiro são baixos. A unidade compensa com habi-
lidades. A primeira habilidade, cloaking �eld, camu�a todas as unidades ao redor
do arbiter. Recall teleporta unidades em uma área pequena para debaixo do arbi-
ter. Stasis �eld desabilita unidades em uma área, impedindo elas de moverem ou
atacarem, mas também impedindo de serem atacadas ou serem alvos de habilidades.
A.2 Terran
Os humanos, ou Terran, possuem a maior versatilidade na composição de suas tropas.
Tropas biológicas podem ser regeneradas com a unidade médica, e tropas mecânicas po-
dem ser consertadas pelos trabalhadores. Os trabalhadores também precisam construir as
estruturas até o �nal, ao contrário dos Protoss, sem poder superar o limite de um traba-
lhador por estrutura. Por ter esta limitação, os Terran podem construir livremente pelo
mapa. Algumas estruturas podem possuir add-ons, que são utilizados para aprimorar suas
capacidades. Estes add-ons podem servir de estruturas de pesquisa ou para possibilitar
uso de habilidades.
A.2.1 Estruturas
•Command Center : estrutura-base que produz os trabalhadores.
83
Figura 14: Árvore tecnológica dos Terran. Estruturas estão representadas dentro de retân-gulos sobre o terreno e unidades aparecem em quadrados negros. Unidades estão ligadasàs estruturas que as produzem por linhas azuis, add-ons estão ligados às estruturas que asproduzem por linhas verdes, enquanto dependências são representadas por setas vermelhasque saem da dependência para o dependente.
84
•Supply Depot : estrutura fornecedora de suprimento.
•Re�nery : estrutura que permite coleta de gás vespeno.
•Engineering Bay : estrutura de pesquisa para melhoramento de ataque e defesa de
unidades biológicas.
•Missile Turret : estrutura de defesa contra unidades aéreas.
•Barracks : estrutura de produção de unidades biológicas terrestres.
•Bunker : estrutura de defesa que não ataca sozinha. Ela possui espaço para unidadesbiológicas terrestres, e seu poder de fogo depende das unidades que estão abrigadas.
•Academy : estrutura de pesquisa de melhoramentos e habilidades para unidades bi-
ológicas terrestres.
•ComSat Station: add-on do command center que permite escanear uma área no
mapa, revelando unidades e estruturas mesmo camu�adas.
•Factory : estrutura de produção de unidades mecânicas terrestres.
•Machine Shop: add-on da factory que permite produção de unidades mais avança-
das, além de ser uma estrutura de pesquisa para as unidades mecânicas terrestres.
•Armory : estrutura de pesquisa de melhoramentos de ataque e defesa das unidades
mecânicas, aéreas e terrestres.
•Starport : estrutura de produção de unidades mecânicas voadoras.
•Control Tower : add-on do starport que permite produção de unidades mais avança-
das, além de fornecer pesquisa para unidades mecânicas voadoras.
•Science Facility : estrutura de pesquisa para a unidade science vessel.
•Physics Lab: add-on da science facility que permite a produção de battlecruisers,
além de fornecer pesquisa para estas unidades.
•Covert Ops : add-on da science facility que permite a produção de ghosts, além de
fornecer pesquisa para estas unidades.
•Nuclear Silo: add-on da command center que permite o uso da habilidade nuclear
strike, da unidade ghost.
85
A.2.2 Unidades
•SCV : unidade trabalhadora, capaz de coletar recursos e construir estruturas.
•Marine: unidade biológica pequena de ataque à distância. Possui melhoramento,
stimpack, que aumenta seu poder de fogo por um curto tempo ao custo de seus
pontos de vida.
•Firebat : unidade biológica pequena corpo-a-corpo. Seu ataque é em área e efetivo
contra unidades pequenas. Ataca apenas unidades terrestres. Também é possui a
habilidade stimpack.
•Medic: unidade biológica pequena. Não possui ataques, mas regenera vida de uma
unidade próxima por vez, ao custo de energia.
•Ghost : unidade biológica pequena. Possui várias habilidades como nuclear strike,
além de poder �car camu�ada ao custo de energia.
•Vulture: unidade mecânica de ataque à distância. Possui um melhoramento que
a torna a unidade mais rápida da raça, e outro que a permite plantar minas de
proximidade pelo mapa.
•Siege Tank : unidade mecânica grande de ataque à distância. Ataca apenas unidades
terrestres. Possui dois modos de ataque. No modo normal, a unidade possui uma
cadência de tiros média e atinge um alvo por vez. No modo de cerco, a cadência de
tiros é bem inferior, mas causa uma grande quantidade de dano em uma pequena
área à uma distância enorme. Este modo torna a unidade imóvel.
•Goliath: unidade mecânica grande de ataque à distância. Possui um grande dano
contra unidades aéreas, e seu alcance anti-aéreo pode ser aumentado para um dos
maiores alcances do jogo.
•Dropship: unidade mecânica aérea grande de transporte.
•Wraith: unidade mecânica aérea grande de ataque à distância. Possui melhoramento
para camu�agem ao custo de energia.
•Valkyrie: unidade mecânica aérea grande de ataque à distância. Ataca apenas uni-
dades aéreas. Seus ataques são em área.
•Science Vessel : unidade mecânica aérea grande detectora. Não possui ataques. Suas
habilidades ofensivas são voltadas a cada uma das outras raças. EMP shockwave
86
Figura 15: Gosma dos Zerg.
elimina os escudos de todas as unidades em uma grande área, e irradiate causa
dano ao longo do tempo em unidades biológicas em volta da unidade atingida.
•Battlecruiser : unidade mecânica aérea grande de ataques à distância. Possui a ha-
bilidade yamato cannon, que causa grande dano em um único alvo ao custo de
energia.
A.3 Zerg
Os Zerg são criaturas que possuem uma mentalidade de enxame, controlada por um
cérebro central � Overmind. Como os Protoss, as estruturas Zerg precisam de uma �fonte
de energia�. Ao invés de algo invisível, os Zerg alteram o terreno com a creep, ou gosma
(ver Figura 15). A gosma é espalhada ao redor das estruturas-base e de estruturas es-
pecializadas: creep colony. Apenas Zerg conseguem construir num terreno contaminado
pela gosma. Para construir estruturas, um trabalhador é consumido, ao invés de serem
construídas de maneira separada dos trabalhadores. Ao contrário das outras raças, as
unidades Zerg não são feitas em estruturas especializadas, mas pela estrutura-base. Esta
estrutura produz de maneira cíclica larvas, unidades que são utilizadas para produção das
outras unidades Zerg. Também não há estrutura que forneça grandes quantidades de su-
primentos, mas uma unidade, overlord. Estruturas-base fornecem apenas um suprimento,
enquanto overlords fornecem 8. As unidades Zerg possuem uma taxa de regeneração de
vida, ao contrário das unidades das outras raças. Porém não possuem nenhuma maneira
de regeneração ativa de pontos de vida.
87
Figura 16: Árvore tecnológica dos Zerg. Estruturas estão representadas dentro de retân-gulos sobre o terreno e unidades aparecem em quadrados negros. Unidades estão ligadasàs estruturas que as produzem por linhas azuis, evoluções estão ligadas às estruturas ori-ginais por linhas verdes, enquanto dependências são representadas por setas vermelhasque saem da dependência para o dependente.
88
A.3.1 Estruturas
•Hatchery : estrutura-base que produz larvas. Não precisa de creep para ser cons-
truída, mas espalha creep.
•Extractor : estrutura que permite coleta de gás vespeno. Não precisa de creep para
ser construída.
•Creep Colony : estrutura que espalha creep no mapa.
•Sunken Colony : evolução da creep colony, estrutura de defesa contra unidades ter-
restres.
•Spore Colony : evolução da creep colony, estrutura detectora e de defesa contra uni-
dades aéreas.
•Evolution Chamber : estrutura de pesquisa para melhoramentos de ataque e defesa
das unidades terrestres.
•Spawning Pool : estrutura de habilitação e pesquisa relacionada ao zergling.
•Hydralisk Den: estrutura de habilitação e pesquisa relacionada ao hydralisk e lurker.
•Lair : evolução da hatchery. Possui mais pontos de vida e habilita novas estruturas.
•Spire: estrutura de habilitação de unidades aéreas de ataque, além de servir de
estrutura de pesquisa de ataque e defesa para unidades aéreas.
•Queen's Nest : estrutura de habilitação e pesquisa relacionada à queen.
•Hive: última evolução da hatchery. Possui ainda mais pontos de vida do que a lair
e habilita o último nível de estruturas.
•Nydus Canal : estrutura que serve de ponte para as unidades. São necessárias duas
estruturas interconectadas para que a ponte seja utilizável.
•Ultralisk Den: estrutura de habilitação e pesquisa relacionada ao ultralisk.
•Greater Spire: evolução da spire, habilita o uso de guardians e devourers.
•De�ler Mound : estrutura de habilitação e pesquisa relacionada ao de�ler.
89
A.3.2 Unidades
•Larva: unidade que serve de ponto de partida para produção de todas as outras
unidades.
•Drone: unidade trabalhadora, capaz de coletar recursos e se sacri�car para dar inícioàs estruturas.
•Overlord : unidade detectora aérea grande. É a unidade que fornece suprimentos
para a raça. Embora a hatchery forneça também, o overlord fornece 8 suprimen-
tos em contraste com o único suprimento oferecido pela estrutura. Pode servir de
transporte, caso uma tecnologia seja pesquisada.
•Zergling : unidade pequena corpo-a-corpo. Primeira unidade militar da raça. Uma
larva produz um par de zerglings. Possui um upgrade de movimentação que a torna
uma das unidades mais rápidas do jogo.
•Hydralisk : unidade de ataque à distância. Pode evoluir para o lurker, caso o jogadortenha feito a pesquisa necessária.
•Lurker : unidade grande de ataque à distância. Não possui ataques normalmente,
precisando se enterrar para atacar. Ao �car enterrado, o lurker �ca camu�ado,
forçando o inimigo a produzir um detector.
•Mutalisk : unidade pequena aérea de ataque à distância. Possui grande mobilidade,
e seus ataques ricocheteam em até outras duas unidades, um terço do dano anterior
em cada alvo adicional.
•Scourge: unidade pequena aérea corpo-a-corpo. Essa unidade é destruída no contatocom outras unidades aéreas, causando enorme dano no alvo. Como o zergling, essa
unidade é produzida aos pares.
•Queen: unidade aérea. Essa unidade não possui ataques, mas habilidades. Sua ha-
bilidade principal é spawn broodling, que atinge unidades terrestres biológicas ou
mecânicas. A unidade é instantaneamente destruída e duas unidades, broodlings,
nascem no lugar. Elas são unidades pequenas corpo-a-corpo e possuem tempo de
vida limitado.
•Ultralisk : unidade grande corpo-a-corpo. Ao contrário das outras unidades da raça,ultralisks custam caro e possuem muitos pontos de vida e armadura. Esta armadura
pode ser melhorada além do limite normal através de pesquisas especializadas.
90
•Guardian: unidade grande aérea de ataques à distância. Evolução da mutalisk que
consegue atirar apenas em unidades e estruturas terrestres. Possui um alcance muito
alto, sendo usada como unidade de cerco semelhante às artilharias num exército
moderno.
•Devourer : unidade grande aérea de ataques à distância. Outra evolução da mutalisk,mas ao contrário do guardian, ela só consegue atirar em outras unidades aéreas.
Seu ataque é em área e causa um efeito corrosivo que intensi�ca o dano de outros
ataques à mesma unidade. Este efeito possui um limite máximo de esporos numa
mesma unidade.
•De�ler : unidade terrestre sem outros tipos. Não possui ataques, mas habilidades.
Duas habilidades são chave para a unidade. A primeira é dark swarm, que impede o
dano de ataques à distância em uma grande área no campo de batalha. A segunda
é plague, que atinge todas as unidades numa área e causa dano contínuo até que a
unidade �que com apenas um único ponto de vida ou receba 295 pontos de dano.
91
APÊNDICE B -- Hipervolume
O indicador de hipervolume (também chamado de métrica-S ou medida de Lebesgue) é
um dos indicadores de qualidade para problemas multiobjetivo. Estes problemas possuem
dois critérios informais de qualidade: (a) a proximidade dos pontos de uma fronteira de
aproximação em relação à fronteira de Pareto e (b) o quão distribuídos estão os pontos
da fronteira de aproximação ao longo da fronteira de Pareto. O indicador de hipervolume
é tido como uma métrica justa, uma vez que respeita estes critérios informais além de
possuir propriedades teóricas favoráveis.
Sem perda de generalidade, podemos considerar que problemas multiobjetivo procu-
ram maximizar d funções objetivo. Então, o indicador de hipervolume pode ser de�nido
formalmente da seguinte forma: dado um conjunto �nito P de pontos em um ortante posi-
tivo Rd≥0, o indicador de hipervolume é de�nido como o volume d-dimensional do polítopo
ortogonal sem buracos Πd correspondente ao espaço dominado por pelo menos um ponto
do conjunto P , dado pela equação B.1. A Figura 17 mostra gra�camente o hipervolume
de um problema biobjetivo.
Πd ={x ∈ Rd
≥0 : x � p para algum p ∈ P}
(B.1)
Figura 17: Hipervolume de um conjunto de pontos num espaço bidimensional.
92
O hipervolume dominado é calculado em relação a um ponto de referência r que,
na de�nição acima, é escolhido para coincidir com a origem. A de�nição também pre-
sume maximizar todos os objetivos e valores objetivos estritamente positivos. Sempre que
não for o caso, transformações a�ns adequadas podem ser aplicadas para cada objetivo
separadamente.