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 de
Planejamento para Produção de Recursos em
Jogos de Estratégia de Tempo Real
Caio Freitas de Oliveira
Natal-RN Agosto de 2016
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 e Computação do Departamento de Informá-tica e MatemáInformá-tica Aplicada da Universidade Federal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau de Mestre 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 told 'em I was claustrophobic, I gotta get outta here! SCV, StarCraft
Planejamento 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 arar-ti 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.
Scheduling 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 eective 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
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
δF
o Contribuição de objetivos, para o algoritmo de reconstrução de soluções
δrF 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,
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
M Cr Máximo coletável do recurso r a partir do estado inicial até o tempo t, para o
PPPR
M Urs 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 ˆ
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
U B 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,
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 I0segundo 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.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.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
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 Jerey 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 II1 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.
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.
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
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 de rami cação, b, e a profundidade do jogo, d, [...] , com uma complexidade total de bd. Em Xadrez, b ≈ 35 e d ≈ 80. Em jogos mais complexos, como
Go, 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 mente que a IA pode dar ações simultaneamente a quantas unidades no jogo for desejado. Então, considerando que, em um jogo típico, um jogador controla 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 uma unidade pode tomar é altamente dependente do contexto. [...] Agora, se tivermos em mente que ações possuem tempos de cool-down4, e assim
nem todas as unidades podem executar todas as ações a todo quadro, podemos tomar uma estimativa conservadora de cerca de 10 possíveis ações por unidade por quadro do jogo. Isto resulta em uma estimativa conservadora para o fator de rami cação entre b ∈ [1050, 10200], somente
considerando unidades (ignorando as ações que construções podem exe-cutar). Agora, para computar d, nós simplesmente consideramos o fato de que os jogos típicos duram em torno de 25 minutos, o que resulta em 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 e
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 produotimiza-çã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
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)
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-os 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.
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 porCHAN 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.
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;
• 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;
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 ˆ
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
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
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 = h ˇdim, ˇrikm, ˇnilmi, 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
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), onde m 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 (MP S|prec|Cmax) usando a
clas-si cação de Brucker et al. (1999), onde MP S 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.12.6.
minimizar Cmax (2.1) sujeito a ˇ Mi X m=1 LSi X t=ESi (t + ˇdim)ˇximt ≤ ˇ Mj X m=1 LSj X t=ESj tˇxjmt, ∀(i, j) ∈ E (2.2) ˇ Mi X m=1 LSi X t=ESi ˇ ximt = 1, ∀i ∈ V (2.3) X i∈V ˇ Mi X m=1 LSi X t=ESi nikmxˇims ≤ Nk, ∀k ∈ N (2.4) X i∈V ˇ Mi X m=1 t+ ˇdim−1 X s=t rikmxˇims ≤ Rk, ∀k ∈ R, ∀t ∈ {1, . . . , U B} (2.5) ˇ ximt ∈ {0, 1}, ∀i ∈ V, m ∈ {1, . . . , M }, t ∈ {1, . . . , U B} (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.
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
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.
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 = hR, T i é 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.
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 eses-toque 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, M Cr} (3.1)
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 ≤
s6=r
X
s∈R
M UrsUst (3.3)
M Urs 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 P rir.
• 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 P rir.
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, M Urs).
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 P rir, 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} ≥ P rir (3.4)
Urt− Brt≥ Ctir+ Cmir+ Boir (3.5)
3.1.3 Modelo
Este problema recebe como entrada o sistema S = hR, T i, o estado inicial I0 e a
des-crição da estratégia O = hM, N, U, V, K, L, UBi. A desdes-criçã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 = ∅. Os conjuntos 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, U B). 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.
O modelo simpli cado para otimização deste problema está descrito de 4.6 a 4.11.
minimizar min {Cmax, U B} (3.6)
maximizar ym, ∀m ∈ M (3.7) minimizar yn, ∀n ∈ N (3.8) sujeito a Smax ≤ U B (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é
U B.
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-os 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,
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 restrifun-çõ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+ X i∈x t X τ =1 xi(τ −di)Pir, ∀t ∈ {1, . . . , U B}, ∀r ∈ R (3.12) urt = ur0 + X i∈x t X τ =1 xi(τ −di)Cmir+ xiτCtir , ∀t ∈ {1, . . . , U B}, ∀r ∈ R (3.13) Brt= X i∈x t X τ =1
xiτ − xi(τ −di) (Boir+ Cmir) , ∀t ∈ {1, . . . , U B}, ∀r ∈ R (3.14)
Urt ≤ s6=r X s∈R M UrsUst, ∀t ∈ {1, . . . , U B}, ∀r ∈ R (3.15) max{Urt, EsrUst|s ∈ R} ≥ X i∈x xitP rir, ∀t ∈ {1, . . . , U B}, ∀r ∈ R (3.16) Urt− Brt≥ X i∈x xit(Ctir+ Cmir+ Boir), ∀t ∈ {1, . . . , U B}, ∀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, M Cr} − urt (3.18)
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
Tabela 3: Recursos do exemplo de produção de recursos. MU denota o máximo utilizável, M C o máximo coletável e ≡ denota equivalência.
Recurso Símbolo Atributos
Minérios m Gás Vespeno v Suprimentos s M Cs= 200 Larva l M Ulh = 3, M Ula = 3 Drone d M Udh = 18, M Uda = 18 Drone coletor de gás g M Uge = 3 Zergling z Overlord o Spawning Pool p Hatchery h Extractor e M Ueh = 1, M Uea = 1 Lair 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 d Morph Drone (gás) 2 1 d 1 g Morph Zergling 28 50 m, 1 l, 1 s 2 z Morph Overlord 40 100 m, 1 l 1 o, 8 s Morph Hatchery 120 300 m, 1 d, -1 s 1 h, 1 l, 1 s Morph Sp. Pool 80 200 m, 1 d, -1 s 1 h 1 p Morph Extractor 40 50 m, 1 d, -1 s 1 e Morph Lair 100 150 m, 100 v 1 h 1 a, 1 l Create Larva 14 1 h 1 l Gather Minerals 7 1 d 8 m Gather 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)
Tabela 5: Estado inicial I0 do exemplo de produção de recursos. m v s l d g z o p h e a Coletado 50 0 9 1 4 0 0 1 0 1 0 0 Consumido 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.
(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.
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 = hR, T, Ei é 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
