Simon Langevin Mathieu Poisson Projet IFT702 Simon Langevin Mathieu Poisson

Plan Introduction Problématique Plannificateur de déplacement Plannificateur de combat Résultat Conclusion

Introduction Les RTS posent plusieurs problèmes Pathfinding Gestion de ressources Construction de bâtiment et d’unité Gestion des combats etc

Introduction C’est dans cette optique que le Planiart a décider de participer a la compétions AIIDE 2011 La solution présente utilise des FSMs pour la micro-gestion des unités

Introduction Les FSMs sont faciles d’utilisation et permette une très grande flexibilité. Problème: Cette flexibilité doit être hard-coder Très long Possibilité d’oublié des cas particuliers

Introduction C’est dans cette optique que nous avons décidé de tester la possibilité d’utiliser un planificateur.

Problématique Déplacement Le déplacement d’une unité dans un environnement hostile Il faut trouver un chemin optimal qui permette D’arriver rapidement D'éviter les dangers potentiels et De s'assurer d’avoir un chemin praticables.

Problématique

Problématique Combat Le but est de détruire l’ennemi conserver ses propres unités. Pour se faire, on doit prendre en compte les dommages infligés, la portée des attaques, les positions et les déplacements de chacune des unités participantes au conflit.

Problématique

Technique PDDL TLPlan BWAPI Pour représenter le monde et le problème Pour trouver un plan BWAPI Pour générer les fichier PDDL de problèmes

Plannificateur de déplacement Il contient trois prédicats isAlly qui dit si une unité est un allier. isNotMoving qui donne si une unité est en train de se déplacer isPosition qui dit si un objet est une position.

Plannificateur de déplacement Contient les fonctions positionX et positionY qui donnent les positions d’un objet. timeToMoveOneCase donne le temps de déplacement pour une division de la carte. Cost qui donne le cout de déplacement pour une case.

Plannificateur de déplacement Contient les fonctions (suites) TotalCost donne le cout total du déplacement jusqu’à maintenant et movementCost donne le cout d’un déplacement.

Plannificateur de déplacement Action move. Cette action permet de ce déplacé vers une case voisine et a une durée égale à la valeur spécifiée pour l’unité. Précondition, l’unité doit être un allié et elle ne doit pas être en mouvement. Effet, est de changer la position de l’unité.

Plannificateur de déplacement Les problèmes associés peuvent être générés par des situations de jeu réelles. A l’aide de BWAPI Pour nos besoins, les situations de tests montrées plus tôt on été simplifiées et utilisées pour tester la génération de plan

Plannificateur de combat 3 fonctions supplémentaires attackDamage attackRange health  

Plannificateur de combat Action Attack Permet à une unité de faire subir des dégâts à un ennemi. Si l’unité de l’ennemi n’a pas attaqué, elle va contre-attaquer et faire subir des dégâts à l’unité qui l’a attaqué. Cela permet de modéliser les réactions de l’adversaire même si PDDL ne permet pas de donner des actions contrôlées par un autre joueur.

Plannificateur de combat Action moveCloserToAttackRange permet à une unité alliée de s’approcher d’une unité ennemie. Elle va changer la position de l’unité pour s’approcher de celle de l’ennemi. Elle a aussi comme effet d’appliquer des dégâts à l’unité alliée si elle se déplace dans les champs de tir d’un ennemi.

Plannificateur de combat Le fichier de problème contient les informations de chacune des unités. contient aussi le but une contrainte de logique temporelle Une unité qui se déplace vers un ennemi doit le rejoindre avant de pouvoir se déplacer vers un autre ennemi. Permet d'éviter une « oscillation » entre 2 ennemis

Résultat Pathfinding Solution a un problème de grosseur moyen est générée en environ 3.6 secondes avec 960 nœuds.

Résultat

Résultat Combat Sans la formule de logique temporelle et sans précondition la solution n’est toujours pas trouvée après 300 secondes et 500000 nœuds visités. Avec une précondition plus contraignante Une solution est trouvée en 1 seconde et 7600 nœuds visités.

Résultat Avec la formule de logique temporelle la solution est trouvée en 3.7 secondes et 6300 nœuds visités  Dans des cas plus simples, la formule LTL permet un traitement 10 fois plus rapide que le traitement sans LTL.

Résultat

Conclusion L’exploration de l’utilisation d’un planificateur a démontré les limitations de PDDL et de TLPlan dans un milieu adversariel.

Conclusion Le fait que PDDL ne puisse représenter des actions prise par un second joueur limite extrêmement l’expressivité du domaine. Surtout dans la gestion du combat, si on veut avoir un modèle qui représente bien la réalité d’un RTS.

Conclusion La logique temporelle dans PDDL ne peut être appliquée que sur l’état du monde et non sur les actions ce qui limite encore l’expressivité du langage. Le fait que la logique temporelle diminue le nombre de nœuds est utile, mais son utilisation augmente le cout de traitement de chaque nœud.

Conclusion L’utilisation, dans un RTS, d'un planificateur devrait se faire à condition de trouver des heuristiques très efficaces qui permettent au calcul de se faire dans un temps respectable utiliser un langage mieux adapté au milieu ou les actions d’un joueur adverse ont aussi son incidence sur le monde.