3.3 Évaluation des performances de SHPE
3.3.3 Résultats
Les résultats de l’expérience sont présentés graphiquement en figure 3.6. Pour chaque série, ils représentent le temps moyen nécessaire pour retourner une solution. On peut voir qu’en moyenne SHPE est capable de résoudre les problèmes de planification posés en dix à quinze fois moins de temps que JSHOP2. De plus, ces résultats montrent que le temps d’exécution nécessaire atteint l’ordre de la milliseconde, ce qui permet de planifier en ligne pour une section composée d’une trentaine d’entités simultanément, soit l’effectif d’une section d’infanterie.
100
150
200
250
300
350
nombre de points d'intérêts
0
5
10
15
20
25
30
35
40
tem
ps
d'e
xé
cu
tio
n (
ms)
Comparaison des temps d'exécution entre SHPE and JSHOP2
SHPE
JSHOP2
Figure 3.6 – Comparaison des performances de SHPE et JSHOP2
Comparaison des performances de SHPE et JSHOP2 pour des problèmes de différentes tailles avec le domaine SimpleFPS. Les instances générées contiennent dix zones et un nombre variable de points d’intérêts. Pour ces scénarios, SHPE retourne une solution au
moins dix fois plus rapidement que JSHOP2.
Cependant, ces résultats n’indiquent rien sur la qualité des solutions. JSHOP2 n’étant pas suffisamment rapide pour permettre de planifier en ligne, il n’est pas apparu nécessaire de s’intéresser à la qualité des solutions qu’il pouvait retourner. Pour SHPE, une expérience supplémentaire a toutefois été conduite pour évaluer la capacité de ce système à retourner des solutions de bonne qualité rapidement. Cette expérience a été conduite uniquement sur la première série (celle avec 100 points d’intérêt), et en retournant pour chaque problème le meilleur plan obtenu au bout de 1000 secondes. Ce plan sert alors de référence pour déterminer le temps de calcul nécessaire pour retourner des plans dont le coût est 50 % puis 25 % plus coûteux. Aucune garantie ne prouve que le plan de référence est la solution optimale. Les résultats obtenus sont donc de nature optimiste, car ils sous-estiment la durée réelle nécessaire pour obtenir ces plans de qualités intermédiaires.
Les résultats sont donnés dans le tableau 3.1. Ainsi en moyenne, il faut au moins 1.6 secondes pour retourner une solution 50 % plus coûteuse que la meilleure solution, ce qui pourrait encore permettre de planifier en ligne pour une poignée de soldats. Toutefois il faut au moins 44 secondes pour obtenir une solution de bonne qualité, soit au plus 25 % plus coûteuse que la solution de référence, et cette durée n’est pas compatible avec la planification en ligne.
3.4
Conclusion
La première question traitée dans ce chapitre est la suivante : en quoi l’architecture de planification que nous avons proposée est-elle adaptée à la planification en ligne dans un environnement temps réel de type jeu vidéo ? L’architecture proposée permet de conserver une représentation à jour de l’environnement grâce à un composant assurant la perception
première solution solution à 50 % solution à 25 % solution de référence 3.84 ms 1.63 s 44.80 s 248.24 s
Table 3.1 – Temps de calculs pour retourner une solution sous-optimale
Temps de calcul moyens obtenus pour la première solution retournée, puis pour des solutions de coûts 50 % puis 25 % plus élevés que celui de la meilleure solution retournée au bout de 1000 secondes. Ces résultats correspondent à une série de problèmes générés aléatoirement avec 100 points d’intérêt.
de l’environnement et de la situation tactique. Le composant de contrôle de l’exécution proposé permet ensuite la détection des évènements qui requièrent une adaptation du plan actuel. Enfin, en proposant une séparation du module de planification en un planificateur de missions à long terme et un planificateur tactique à court terme, il devient possible de mettre à jour les plans tactiques en continue sans remettre en cause les objectifs principaux qui doivent être atteints pour accomplir une mission.
On a ensuite présenté le planificateur responsable des plans d’actions tactiques, appelé SHPE, ce qui nous permet de répondre à la question suivante : pourquoi l’implémentation de SHPE en fait un système de planification adapté aux contraintes posées par le fonctionnement d’un jeu vidéo ? La principale contrainte à laquelle il faut faire face est le temps d’exécution disponible. Or, nous avons montré qu’en précompilant les éléments d’un domaine de planification, à partir d’une description dans un langage nommé HTDL, en structure de données statiques et sous forme procédurale, il est possible d’optimiser l’implémentation du planificateur, et ainsi d’en réduire le temps d’exécution.
Enfin, la dernière question traitée porte sur les performances de ce système, à savoir si celles-ci sont bien suffisantes pour retourner des plans en ligne permettant d’animer une section entière ? Nous avons mesuré ces performances par rapport à des problèmes de planification représentatifs des jeux vidéo, et avons constaté que ce système était en mesure de retourner un plan d’actions pour un soldat en seulement quelques millisecondes, une échelle satisfaisante pour effectuer de la planification en ligne.
Toutefois, les performances de ce système ne sont pas encore suffisantes pour lui permettre de retourner des plans de bonne qualité (c’est-à-dire avec un coût raisonnable) pour de la planification en ligne. D’autres améliorations pourraient être implémentées au niveau du procédé de précompilation, comme une gestion dédiée des allocations dynamiques via des allocateurs spécialisés. Cependant, ces améliorations ne feraient que diviser le temps de calcul par un facteur constant, or une solution vraiment efficace devrait intervenir au niveau de l’explosion combinatoire.
À cet effet, les chapitres suivants étudient les possibilités d’exploiter la hiérarchie de niveaux de décision dans l’organisation de la section d’infanterie. Ainsi, ils proposent de les interpréter comme des niveaux d’abstraction permettant de guider la recherche de solutions à plusieurs niveaux, et ainsi améliorer l’efficacité de l’algorithme de recherche.
Chapitre 4
Planification HTN avec sémantique
d’exécution pour les tâches
composées
Une extension possible de SHPE consisterait à modéliser les tâches composées sous la forme de transitions d’états, et ainsi d’obtenir la capacité de calculer les états intermédiaires dans un plan non primitif. Une telle extension aurait au moins deux avantages. Le premier avantage est valable pour n’importe quel planificateur HTN : il devient possible de raisonner sur l’exécutabilité des plans avant d’atteindre le niveau primitif. Des plans partiels ne menant qu’à des plans non exécutables peuvent ainsi être identifiés en amont, et être élagués de l’espace de recherche, entrainant une réduction du temps de calcul. Le deuxième avantage est propre aux planificateurs HTN fondés sur SHOP. Ces planificateurs nécessitent d’accéder à l’état courant pour évaluer une méthode de décomposition, et sont donc limités à la stratégie de décomposition qui sélectionne les tâches dans l’ordre de leur exécution. Si l’état courant pouvait aussi être accédé en appliquant les tâches composées, les mêmes mécanismes pourraient être conservés tout en permettant d’implémenter des stratégies de décomposition des tâches plus adaptées pour résoudre certains problèmes. À titre d’exemple, il deviendrait possible de différer la décomposition de certaines tâches composées, pour décomposer en priorité des tâches dont l’exécution intervient plus tard, mais qui sont plus critiques vis-à-vis de la faisabilité du plan. Un autre exemple est la prise de décision multi-niveau, qu’il devient possible d’implémenter en décomposant un plan intégralement jusqu’à un niveau de décision donné, avant de le décomposer au niveau subordonné.
Bien que pour plusieurs systèmes de planification HTN, les tâches composées soient modélisables à l’identique des actions (par exemple dans NOAH ou NONLIN), c’est-à- dire avec préconditions et effets (ou postconditions), il n’est pour autant pas possible de les interpréter comme des actions déterministes, comme c’est le cas avec les actions primitives. En effet, une « action de haut niveau » est potentiellement décomposable en plusieurs séquences d’actions primitives qui n’atteignent pas nécessairement le même état final. Dans ces conditions, considérer que cette action de haut niveau est déterministe ne serait pas cohérent avec toutes ses décompositions. Au plus, les préconditions et postconditions peuvent être interprétées comme étant des contraintes à satisfaire par chaque décomposition primitive d’une action de haut niveau [9]. AHP [60] propose aussi de décrire les tâches composées sous la forme d’actions non-déterministes. Ainsi, une action de haut niveau peut accéder à l’ensemble des états correspondant aux états finaux atteints par chacune de ses décompositions primitives. Cependant, les descriptions de telles actions non-déterministes ne sont généralement pas compactes, ce qui amène AHP à introduire une paire d’approximations optimiste et pessimiste pour chacune d’entre elles.
Ce principe nous éloigne alors de notre intention initiale, qui est de compléter SHPE, et non pas d’implémenter un système alternatif capable de traiter ce type de description.
Dans ce chapitre, nous proposons une solution alternative qui s’appuie sur l’abstraction des états. L’abstraction permet de fusionner l’ensemble des états atteignables par une action de haut niveau sous la forme d’un unique état abstrait, et ainsi d’interpréter et de décrire les tâches composées comme des actions déterministes dans un espaces d’états abstrait. Comme nous allons le voir dans ce chapitre, cette solution à l’avantage de s’intégrer aisément avec des planificateurs comme SHOP ou SHPE.
Dans la première partie, nous proposons d’appliquer le principe des hiérarchies d’abstractions à la planification HTN, en définissant certaines tâches composées comme étant des tâches primitives vis-à-vis d’un niveau d’abstraction donné. Nous traitons alors la question des avantages de cette sémantique de transitions d’états abstraits pour la planification HTN. Dans la seconde partie, nous illustrons l’utilisation de ces effets abstraits dans un exemple appliqué au combat d’infanterie, et nous nous posons la question suivante : quel est le gain potentiel de performances que l’on peut obtenir grâce à ces effets abstraits ? Pour y répondre, nous comparons les temps d’exécution obtenus entre plusieurs stratégies de décomposition des tâches qui exploitent les effets abstraits pour vérifier l’exécutabilité des plans abstraits à des horizons différents.
Enfin en troisième partie, nous introduisons une nouvelle forme d’effets abstraits. Au lieu de reposer sur une hiérarchie d’espaces abstraits, la sémantique qui est présentée repose sur un système de transitions d’états défini à partir d’un langage du premier ordre reposant sur une logique trivaluée, où la troisième valeur exprime l’indéterminé introduit par l’abstraction. Nous verrons alors pourquoi cette définition alternative des
effets abstraits permet de résoudre certains problèmes introduits par les hiérarchies d’abstractions.
4.1
Planification HTN avec hiérarchie d’abstractions
Cette première partie introduit un système de planification hiérarchique qui combine la planification HTN avec la planification par hiérarchie d’abstractions. Ce système repose sur le langage ADL, et le procédé d’abstraction employé consiste à réduire le nombre de symboles de prédicats et de fonctions entre deux niveaux d’abstraction consécutifs. Le cadre théorique est introduit dans un premier temps, suivi par la description des fonctions d’abstraction ainsi que leur intégration dans HTDL, le langage de description HTN du système SHPE. Enfin, cette partie présente un algorithme adapté à ce nouveau cadre de planification hiérarchique.