Projet IFT702 Simon Langevin Mathieu Poisson. Plan Introduction Problématique Plannificateur de...

Projet IFT702Simon LangevinMathieu 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 Pour représenter le monde et le problème

TLPlan 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.