Vous êtes sur la page 1sur 14

Ceci est un extrait lectronique d'une publication de Diamond Editions :

http://www.ed-diamond.com

Retrouvez sur le site tous les anciens numros en vente par correspondance ainsi que les tarifs d'abonnement. Pour vous tenir au courant de l'actualit du magazine, visitez :

http://www.gnulinuxmag.com
Ainsi que :

http://www.linux-pratique.com
et

http://www.miscmag.com

Ceci est un extrait lectronique d'une publication de Diamond Editions

http://www.ed-diamond.com

Creative Commons
Paternit - Pas d'Utilisation Commerciale - Pas de Modification

2.0 France
Vous tes libres :

de reproduire, distribuer et communiquer cette cration au public. Paternit. Vous devez citer le nom de l'auteur original de la manire indique par l'auteur de l'oeuvre ou le titulaire des droits qui vous confre cette autorisation (mais pas d'une manire qui suggrerait qu'ils vous soutiennent ou approuvent votre utilisation de l'oeuvre). Pas d'Utilisation Commerciale. Vous n'avez pas le droit d'utiliser cette cration des fins commerciales.

Pas de Modification. Vous n'avez pas le droit de modifier, de transformer ou d'adapter cette cration. A chaque rutilisation ou distribution de cette cration, vous devez faire apparatre clairement au public les conditions contractuelles de sa mise disposition. Chacune de ces conditions peut tre leve si vous obtenez l'autorisation du titulaire des droits. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs. Ceci est le Rsum Explicatif du Code Juridique. La version intgrale du contrat est attache en fin de document et disponible sur : http://creativecommons.org/licenses/by-nc-nd/2.0/fr/legalcode

ans le prcdent article de la rubrique I.A. [1], jai dcrit en dtail lalgorithme de Les jeux vido de Dijkstra qui permet de stratgie temps rel calculer relativement modernes ont des efficacement un chemin optimal dans exigences trs leves en un graphe. Jai aussi expliqu termes de rendu graphique et comment appliquer cet algorithme au dintelligence artificielle (I.A.). problme du calcul du chemin optimal Le joueur attend un jeu en 3D dune unit dans un jeu de stratgie construit partir de milliers de temps rel (STR). Nous avons vu en polygones, pour le plaisir de conclusion de larticle que, malgr une lil, mais il veut aussi un implmentation soigne, les temps de adversaire dun bon niveau, calcul thoriques restaient beaucoup pour le plaisir de lesprit. La trop levs pour une utilisation en brique de base de lI.A., le temps rel sur un terrain de jeu tendu pathfinding, cest--dire le et en prsence de nombreuses units. calcul des chemins suivis par les units, doit donc tre Une modification subtile et astucieuse rapide et donner de bons de lalgorithme de Dijkstra permet cependant de rduire de faon rsultats. Lalgorithme de importante son cot dexcution. Dijkstra, prsent dans Linux Lalgorithme modifi porte le nom Mag 53, garantit des rsultats dalgorithme A*. Il est massivement exacts, mais est en gnral utilis dans les jeux modernes, tel trop lent pour fonctionner dans point que certains spcialistes des conditions stressantes (un considrent que le problme de base grand nombre dunits, un du pathfinding est rgl (on utilise A*), terrain de jeu trs grand, etc.). seules les subtilits (rglages de Cependant, des modifications lalgorithme, choix des structures de minimes mais trs subtiles donnes, etc.) restant traiter pour permettent de conserver implmenter un jeu. lexactitude des chemins obtenus tout en acclrant Le but du prsent article est de dcrire notablement leur calcul. lalgorithme A* en illustrant ses Lalgorithme obtenu performances et en montrant porte le nom comment les gains de temps quil dalgorithme A*. induit (par rapport lalgorithme de Dijkstra) permettent denvisager des applications plus ambitieuses. Attention, larticle considre comme acquis les

Lalgorithme A* ou comment calculer rapidement un chemin optimal


dveloppements de [1] : je vous conseille donc vivement de relire larticle en question !

Pourquoi lalgorithme de Dijkstra est-il lent ?


Un exemple de lenteur

Mme si lalgorithme de Dijkstra fonctionne correctement, il donne parfois des rsultats dcevants. Bien entendu, Dijkstra a dmontr mathmatiquement lexactitude de lalgorithme : les chemins obtenus sont toujours optimaux. Par contre, lalgorithme met parfois beaucoup de temps trouver un chemin vident. Pour le voir, considrons un exemple trs simple, celui dune carte vide dans laquelle chaque case possde un cot de franchissement identique (gal 1, par exemple). Dans ce cas, le chemin optimal est bien entendu la ligne droite qui relie le point de dpart au point darrive, comme le montre lexemple de la figure 1 (le chemin est donn par la flche noire).

Figure 1

32

LM 54

Le problme est que pour arriver ce chemin optimal, lalgorithme de Dijkstra utilise beaucoup de ressources, comme lillustre la figure 2. On constate en effet que presque toutes les cases de la carte ont t explores (elles sont presque toutes dans la liste Ferms), alors quintuitivement, il est inutile dtudier les cases qui loignent du but !

cot du chemin optimal le reliant la case darrive, le calcul dun tel chemin optimal est trs simple. Il suffit dappliquer lalgorithme suivant : 1. point courant = point de dpart 2. chercher dans les voisins du point courant le plus proche du point darrive not pp 3. point courant = pp 4. si le point courant nest pas le point darrive, retourner en 2 Cet algorithme est extrmement efficace puisque le temps de calcul est proportionnel la longueur du chemin. En fait, on ne peut pas faire mieux, mais comme il faut faire tourner un autre algorithme pour obtenir les distances entre tous les points de la carte et le point darrive souhait, cela na pas beaucoup dintrt. Notons que lalgorithme de Dijkstra calcule en fait la distance entre le point de dpart et (presque) tous les points de la carte (cest le cot cumul), ce qui permet de dterminer le chemin optimal avec un algorithme similaire celui qui vient dtre prsent : la principale diffrence est quon construit le chemin lenvers, en partant du point darrive et en remontant par les points qui sont les plus proches du point de dpart. On doit donc oublier lide de modifier lalgorithme de Dijkstra pour quil tienne compte de la vritable distance entre un nud et le but. Cependant, en utilisant notre connaissance de la structure de la carte, il est possible de donner une estimation de cette distance. Pour la carte vide propose au-dessus, il suffit par exemple de calculer la distance (au sens classique du terme, cest--dire la distance vol doiseau, plus techniquement, la distance euclidienne) entre le point courant et le but. Bien entendu, la mise en place dobstacles ou de zones avec des cots de dplacement distincts rend lestimation propose assez fausse, mais ce nest pas trs important (nous verrons dans la suite du texte quelle proprit thorique doit tre satisfaite par lestimation). Lide nest pas dappliquer lalgorithme basique propos au-dessus, mais daider lalgorithme de Dijkstra en lui permettant dtudier en priorit les nuds qui le rapprochent du but.

Algorithme A*

Figure 2 Le comportement de lalgorithme de Dijkstra est pourtant compltement correct. En effet, la carte est traduite en graphe et lalgorithme ne sait pas que certaines cases peuvent le rapprocher du but alors que dautres len loignent. En fait, lexploration se fait selon deux critres : 1. Le prochain nud explor est celui qui possde le cot cumul le plus faible dans la liste Ouverts : ce cot cumul est en quelque sorte la distance entre le point de dpart et la case courante. On explore donc la carte en sloignant progressivement du point de dpart, sans tenir compte de la distance au but. 2. Pour placer de nouveaux nuds dans la liste Ouverts, lalgorithme tudie les voisins directs du nud explor. Encore une fois, la distance au but nest pas prise en compte. De mme, la structure de graphe trs particulire de la carte nest pas exploite. Tout ceci fait que lalgorithme de Dijkstra peut tre lent, car il explore un grand nombre de nuds du graphe. Or, lanalyse algorithmique voque dans [1] montre que le cot du calcul crot rapidement avec le nombre de cases explores.
Comment aider lalgorithme ?

Lalgorithme A*
nonc

On constate que le principal problme de lalgorithme de Dijkstra vient du fait quil ne tient pas compte de la distance au but pour choisir le prochain nud tudier. En fait, cela est parfaitement normal, car calculer la vritable distance au but est justement ce que fait lalgorithme (indirectement). En effet, si on connat la distance entre tout point de la carte et la case darrive souhaite, autrement dit, si on connat pour tout point de la carte le

Lalgorithme A* [2] est construit sur lalgorithme de Dijkstra associ une fonction qui estime la distance entre un nud quelconque du graphe et le nud cible (par distance, on entend bien sr le cot du chemin optimal reliant le nud concern et le nud cible). Lide fondamentale est de modifier le classement dans la liste Ouverts afin de favoriser les nuds les plus proches du but (au sens de lestimation). On suppose donc donne une fonction h qui un nud n associe h(n), une estimation du cot du chemin optimal Octobre 2003 33

de n au nud darrive. Cette fonction sappelle lheuristique associe lalgorithme. On calcule alors un chemin optimal de la faon suivante : 1. crer deux listes vides Ouverts et Ferms 2. insrer dans la liste Ouverts le quadruplet form du nud de dpart, de la valeur h(dpart), dune valeur arbitraire (null par exemple) comme nud parent et de la valeur 0 comme cot cumul, soit donc ( dpart,h (dpart),null,0). Le deuxime lment du quadruplet est une estimation du cot du chemin optimal partant du point de dpart et se terminant au nud arrive en passant par le premier lment du quadruplet. Cette estimation est obtenue comme la somme du cot cumul (cot du chemin optimal entre le nud de dpart et le nud courant) et de lestimation du cot du chemin optimal reliant le nud courant au nud cible 3. tant que la liste Ouverts nest pas vide : a. chercher dans Ouverts le quadruplet (N,f,p,c) dont le cot estim (f) est minimal (parmi les quadruplets contenus dans la liste) b. ajouter le quadruplet la liste Ferms (on peut se contenter du triplet (N,p,c)) c. si N est le nud darrive, quitter la boucle et passer ltape 4 d. supprimer le quadruplet de la liste Ouverts e. pour chaque successeur S de N (cest--dire chaque nud S pour lequel il existe une arte de N S dans le graphe) : i. calculer c comme la somme de c et du cot associ larte qui relie N S ii. si S est dans Ferms : 1. si le cot cumul de S dans Ferms est suprieur c, supprimer S de Ferms et ajouter le quadruplet (S,c+h(S),N,c) Ouverts 2. sinon passer au successeur suivant iii. si S est dans Ouverts avec un cot cumul suprieur c, mettre jour le cot cumul, le nud parent (qui est maintenant N) et le cot estim (qui devient c+h(S)) iv. sinon ajouter Ouverts le quadruplet (S,c,N) 4. si le nud darrive nest pas dans Ferms, terminer lalgorithme sur un chec : il nexiste pas de chemin depuis le nud de dpart vers le nud darrive 5. sinon, reconstruire le chemin en suivant linformation parent dans la liste Ferms
Comparaison avec lalgorithme de Dijkstra

1. Le classement des nuds dans la liste Ouverts nest pas ralis selon le mme critre. En effet, dans lalgorithme de Dijkstra, le prochain nud explor est le plus proche du point de dpart, ce qui explique le comportement dcevant de lalgorithme dans certains cas. Par contre, A* choisit dexplorer le nud par lequel passe le chemin le plus court menant du point de dpart au point darrive. Bien entendu, le cot exact du chemin nest pas connu, mais grce lheuristique, on possde une bonne estimation de celui-ci. A* favorise donc les nuds qui mnent au but. 2. Dans lalgorithme de Dijkstra, un nud plac dans Ferms nest jamais rexamin. Lintroduction dun ordre diffrent pour lexamen des nuds fait que A* tudie parfois plusieurs fois un mme nud. En effet, il arrive quon explore un nud sans connatre le chemin optimal qui y mne depuis le nud de dpart car les nuds qui le constituent sont mal nots par lheuristique. De ce fait, le cot cumul du nud est faux lors de la premire exploration. On doit donc stocker dans Ferms le cot cumul de chaque nud afin de pouvoir ventuellement rexaminer les nuds. Limplmentation de A* ne pose pas de problme particulier par rapport celle de lalgorithme de Dijkstra. Les algorithmes sont tellement proches que la traduction dune implmentation de celui de Dijkstra en A* ne prend que quelques minutes. Les structures de donnes utilises sont pratiquement les mmes et les remarques prsentes dans [1] restent valables. Il est donc judicieux dimplmenter Ouverts sous forme dun tas combin des annotations dans la carte. Ferms simplmente aussi trs efficacement et facilement sous forme dannotation dans la carte. La seule vritable diffrence avec les solutions prsentes dans [1] est que la liste Ferms doit maintenant contenir le cot cumul de chaque nud parcouru. Loccupation mmoire de lalgorithme A* est donc potentiellement plus importante que celle de lalgorithme de Dijkstra. Notons quil faut aussi pouvoir supprimer un nud de la liste Ferms, ce qui peut tre coteux dans certaines implmentations (mais pas dans celle propose dans [1]).
Exemples de mise en uvre

A premire vue, les deux algorithmes sont trs proches. Il est donc important dinsister sur les deux diffrences fondamentales :

Pour bien comprendre le fonctionnement de A*, tudions son comportement sur lexemple de la carte vide propose dans la section prcdente. Pour cette carte, nous choisissons comme heuristique la distance euclidienne entre le centre dune case et le centre de la case cible. Celleci est calcule simplement grce la formule suivante : . Dans cette formule, x et y sont les coordonnes du centre de la case considre, alors que a et b sont celles de la case cible. Dans les deux algorithmes, on commence par insrer le point de dpart dans la liste Ouverts. Le cot cumul est nul et donc, pour A*, le classement se fait partir de la distance entre le point de dpart et le point darrive (5 dans notre exemple). Comme dans les deux algorithmes, la liste Ouverts ne contient quun lment, la diffrence de critre de classement ne

34

LM 54

change rien et on commence donc par tudier les voisins de la case de dpart. Les diffrences entre les algorithmes apparaissent ds ltude des voisins. En effet, comme lillustre la figure 3, les cots estims changent radicalement la donne. Sur cette figure, une case contient un nombre en bleu qui est le cot cumul pour passer optimalement de la case de dpart celle-ci, ainsi quun nombre en rouge qui indique le cot estim pour aller optimalement de la case au but. Pour lalgorithme de Dijkstra, les quatre voisines directes (situes horizontalement et verticalement) de la case de dpart sont quivalentes (cot cumul 1) et lalgorithme tudiera donc une dentre elles plus ou moins au hasard. Au contraire, A* range les cases selon la somme du cot cumul et de lestimation du cot pour aller au but. Les valeurs approches indiques sur la figure permettent de voir que la prochaine case tudie est celle qui est situe juste droite de la case de dpart car son cot total est de 5, alors que les autres voisines non diagonales ont des cots plus levs (environ 6,10 et 7), de mme dailleurs que les voisines situes en diagonales (cots approximatifs 5,5 et 7,5).

Algorithme A*

Figure 4 Globalement, la tendance dA* se rapprocher du but en priorit donne un rsultat trs satisfaisant illustr par la figure 5. La comparaison avec la figure 2 est trs parlante : lalgorithme de Dijkstra a tudi 71 nuds alors que A* nen a tudi que 6 !

Figure 5 Figure 3 Les diffrences saccentuent ds la deuxime case tudie. Soyons en effet gnreux avec Dijkstra et considrons que lalgorithme choisit lui aussi la case situe juste droite de la case de dpart. La figure 4 donne les cots cumuls et les cots estims obtenus. Quand on tudie les cots cumuls, on constate que lalgorithme de Dijkstra va ncessairement tudier les trois autres cases de cot cumul 1 avant de passer des cases proches du but. En effet, les trois nouvelles cases explores ont toutes un cot cumul suprieur 1, ce qui est normal car on sloigne du point de dpart. Au contraire, on constate que pour A* les choses se prsentent sous un bien meilleur jour. En effet, la case situe directement droite de la nouvelle case possde un cot estim de 5 (2+3), ce qui en fait la nouvelle case prioritaire dans la liste Ouverts. De ce fait, la troisime case tudie par A* le rapproche encore du but. Bien entendu, jai choisi un exemple qui est particulirement favorable A*, mais en gnral, il est toujours plus efficace que Dijkstra. En fait, on peut dmontrer que si lheuristique vrifie une proprit thorique que nous verrons dans la section suivante, A* est un algorithme optimal, au sens o tout nud explor par A* doit tre explor par tout algorithme capable de trouver un chemin optimal ( condition que lalgorithme nutilise pas dautres informations que le graphe et lheuristique). La marge de manuvre rside donc dans le choix de lheuristique et dans limplmentation proprement dite. Cette dernire doit tre particulirement soigne pour viter tout surcot par rapport lalgorithme de Dijkstra. Dans certaines situations, les deux algorithmes explorent presque le mme nombre de nuds. Considrons par exemple la figure 6 qui correspond une carte de cot uniforme dans laquelle on a ajout un obstacle infranchissable. On constate que lalgorithme de Dijkstra explore toutes les cases de la carte pour obtenir le chemin optimal. Octobre 2003 35

Charit bien ordonne : victime du syndrome du non invent ici, jai ralis ma propre implmentation pdagogique en Java, sous licence GPL, disponible lURL http://apiacoa.org/software/pathfinding. Lintrt de cette implmentation est de permettre une comparaison simple entre diverses stratgies, en faisant varier les heuristiques, les implmentations des listes Ouverts et Ferms, le modle de cot de la carte, etc. Le moteur libre (GPL) Stratagus (http://www.nongnu.org/stratagus/index.html), dont jai dj parl dans [1], contient une implmentation en C de A* ralis par votre serviteur, ainsi quune autre implmentation dune version hirarchique de A*, encore plus efficace, uvre dun certain Latimerius. Boson (http://boson.eu.org), lui aussi voqu dans [1], contient une implmentation libre (GPL) en C++ dun A* simple (les structures de donnes ne sont pas optimales). Heroic BattleField (http://hbf.tuxfamily.org), toujours voqu dans [1], propose aussi une implmentation simple dA* en C sous licence GPL. On trouvera dautres liens dans la section rfrence en fin darticle.

Figure 6 La figure 7 montre que dans une telle situation, A* ne gagne presque rien car il vite dexplorer seulement 10 cases sur 130. Il suffit donc que limplmentation de A* soit seulement 10% plus lente que celle de lalgorithme de Dijkstra pour que ce dernier prenne lavantage. Nous remarquons au passage que les chemins trouvs par les deux algorithmes sont diffrents, mme sils sont touts deux optimaux. Ce comportement est assez frquent, car lheuristique, en modifiant lordre dexploration, change aussi la structure de parents qui est utilise pour construire le chemin optimal.

Du bon choix de lheuristique


Ladmissibilit

Pour que A* fonctionne correctement, il faut que lheuristique qui estime le cot du chemin optimal dun nud quelconque au but soit admissible. En pratique, cela signifie que lheuristique doit sous-estimer le cot du chemin optimal. Dans ce cas, on montre que les chemins obtenus par A* sont bien optimaux. Au contraire, si lheuristique nest pas admissible et donc quelle surestime le cot de certains chemins, A* peut obtenir un chemin non optimal. Lheuristique que nous avons utilise dans la section prcdente est admissible. En effet, elle calcule le cot comme la distance euclidienne entre les deux cases considres. Or, le cot du passage dune case une de ses voisines est gal la distance (euclidienne) entre les centres des cases concernes (et ceci en tout point de la carte). Donc, lheuristique donne le cot exact pour le passage dune case une de ses huit voisines. Quand le but est plus loign, lheuristique sous-estime le cot. En effet, la distance euclidienne correspond la distance vol doiseau, alors que le chemin optimal passe par les centres des cases et est donc en gnral plus long, comme lillustre la figure 8. De plus, lintroduction dobstacles ne peut quallonger les chemins optimaux, alors que lheuristique nest pas modifie. Elle reste donc admissible.

Figure 7 Il est important de noter que A* nest pas un algorithme magique. Il est frquent que les dveloppeurs se plaignent de lalgorithme de Dijkstra et demandent comment passer A*. Pourtant, le premier rflexe devrait tre de vrifier limplmentation de Dijkstra, car lutilisation de structures de donnes inadaptes (en particulier une liste classique pour la liste Ouverts) rend lalgorithme trs lent. Or, cette lenteur se retrouvera sur A*...
Une implmentation ?

Il existe de nombreuses implmentations de lalgorithme A* disponibles sur Internet. Voici quelques pistes pour le lecteur curieux : 36 LM 54

rapproche ainsi du classement utilis par Dijkstra : A* explore donc plus facilement des nuds qui lloignent du but. La figure 9 illustre les rsultats de cette exploration moins focalise. Quand on compare avec les figures 2 et 5, on constate quon obtient une configuration intermdiaire : A* a tudi 23 cases, contre 71 pour Dijkstra et 6 pour A* avec une heuristique meilleure.

Algorithme A*

Figure 8 Notons quon peut amliorer lheuristique en tenant compte du fait que les chemins passent par les centres des cases. On obtient la formule suivante : 1,4 * Min(|x-a|,|yb|) + ||x-a|-|y-b||. Dans celle-ci, les barres verticales dsignent la valeur absolue, alors que 1,4 est une approximation de la racine carre de 2 (on peut dailleurs prendre une valeur plus prcise). Le premier terme de la formule correspond en fait la distance parcourue en diagonale, alors que le second correspond la distance franchie horizontalement ou verticalement. Comme cette heuristique est plus prcise que la distance euclidienne, elle amliore encore les performances de lalgorithme.
Sous-estimer...

Figure 9 Il est donc important dans la pratique que lheuristique sous-estime le moins possible les cots. Pour ce faire, on doit tre particulirement attentif au modle de mouvement choisi. En effet, dans [1], comme dans le dbut du prsent article, nous avons choisi de prendre en compte la distance parcourue pour passer du centre dune case au centre dune de ses voisines afin de calculer le cot du dplacement. Or, dans certains jeux, la distance nest pas prise en compte. Ainsi, un mouvement en diagonale est-il aussi coteux quun autre horizontal ou vertical. Dans dautres jeux, au contraire, les mouvements diagonaux sont interdits. Dans les deux cas, lheuristique de la distance euclidienne nest pas adapte. En effet, elle surestime les cots dans le cas o la distance nest pas prise en compte (ce qui est trs gnant, comme nous allons le voir dans la section suivante), et sous-estime les cots quand les mouvements diagonaux sont interdits, comme lillustre la figure 10 (le chemin bleu correspond aux dplacements diagonaux rapides, alors que le chemin vert correspond aux mouvements diagonaux interdits).

En fait, les performances de A* dpendent fortement de la qualit de lheuristique. Quand celle-ci donne une trs bonne estimation du cot (par le bas, cest--dire en sousestimant), A* fonctionne trs bien : non seulement il produit un chemin optimal, mais en plus il le fait vite, cest-dire en tudiant peu de nuds. Plus lheuristique sloigne du cot optimal (toujours par le bas), plus lalgorithme devient lent. Le chemin calcul reste optimal, mais A* tudie beaucoup plus de nuds. Le cas extrme est atteint quand lheuristique est uniformment nulle (le cot estim est alors toujours 0), car A* devient alors identique lalgorithme de Dijkstra. Nous avons dj observ la dgradation de performance dans la section prcdente. En effet, lintroduction dobstacles dans la carte dgrade la qualit de lheuristique qui sous-estime parfois fortement le cot du chemin optimal. Par exemple, le cot rel du chemin optimal entre le point de dpart et le point darrive sur la figure 7 est denviron 21,5, alors que lheuristique de la distance euclidienne estime ce cot 5 ! Pour mieux comprendre leffet de la sous-estimation, dgradons volontairement notre heuristique, par exemple en utilisant comme estimation la distance euclidienne divise par 2. Leffet mathmatique est bien entendu de changer le classement des nuds dans la liste Ouverts : limportance relative du cot cumul augmente avec la diminution du cot calcul par lheuristique. On se

Figure 10 Octobre 2003 37

Quand on interdit les dplacements diagonaux, la bonne heuristique consiste calculer la somme de |x-a|+|y-b| (il sagit de la distance Manhattan). On constate que la distance obtenue correspond au nombre de colonnes et de lignes qui sparent la case de dpart de la case darrive (en comptant la ligne et la colonne de la case darrive). Bien entendu, cette heuristique nest valable que si le cot de franchissement dune case est de 1 au minimum. Quand on autorise les dplacements diagonaux sans les pnaliser, cest--dire sans tenir compte de la distance rellement parcourue, on peut utiliser comme heuristique la formule suivante : max(|x-a|,|y-b|). Ceci correspond compter le nombre de colonnes et de lignes qui sparent la case de dpart de la case darrive, puis conserver le plus grand des deux nombres.
Ou surestimer ?

La figure 12 reprsente le chemin optimal quon obtient avec lalgorithme de Dijkstra ou encore avec A* et une heuristique admissible (par exemple 0,5 fois la distance euclidienne). Ce chemin a un cot de 6,4. En termes defficacit du calcul, lheuristique fausse est particulirement agrable car elle ne considre que 8 cases. Lheuristique admissible provoque lanalyse de 44 cases, alors que lalgorithme de Dijkstra tudie presque toute la carte (en fait 100 cases sur 132).

Nous venons donc de voir que la sous-estimation du cot dun chemin ne change pas la correction de A* qui continue dans une telle situation calculer un chemin optimal. Le seul effet pratique est le ralentissement de lalgorithme. La situation se complique en prsence de surestimation. En effet, on ne peut plus garantir dans ce cas que lalgorithme A* produit des rsultats corrects. Dans certaines situations, les chemins obtenus ne sont pas optimaux. Mais en payant ce prix (parfois exorbitant), on peut acclrer les calculs ! tudions un exemple simple pour lequel lalgorithme ne fonctionne pas. Dans une carte de cot uniforme 1, on ajoute une route de cot 0,5. On conserve le modle de voisinage classique dans lequel on tient compte de la distance parcourue pour calculer le cot du passage dune case une de ses voisines. Lheuristique adapte est donc celle base sur la distance euclidienne. Cependant, celle-ci nest pas admissible. En effet, un chemin sur la route ne cote que 0,5 fois la distance parcourue. Donc, une estimation du cot par la simple distance surestime celui-ci. La figure 11 donne le chemin optimal obtenu en utilisant lheuristique euclidienne simple. Ce chemin a un cot de 7.

Figure 12 Il est assez difficile de prdire leffet dune surestimation du cot dun chemin optimal. Sur lexemple propos, le chemin obtenu est totalement diffrent de celui cherch. On pourrait dailleurs faire en sorte que les chemins soient encore plus loigns, en jouant avec les cots de dplacement et la forme du trac. Cependant, on constate que les cots des deux chemins sont trs proches. Or, en pratique, le trac du chemin nest pas toujours important, cest avant tout le temps quon met atteindre le but qui compte. Si lutilisation dune heuristique non admissible permet dacclrer les calculs, on peut imaginer que lunit va commencer son dplacement plus tt que dans le cas dun calcul lent et donc finalement arriver aussi vite bon port quavec un chemin vritablement optimal. Le problme est que rien ne permet daffirmer que lalgorithme ne va pas proposer un chemin totalement dlirant quand il utilise une heuristique non admissible. Cest pourquoi leur utilisation doit tre rserve des cas bien matriss.
Comment faire en pratique ?

La mise au point dune heuristique efficace est un problme assez dlicat. Je suggre donc de commencer par une heuristique simple, adapte au modle de dplacement choisi, comme la distance euclidienne ou la distance Manhattan. On peut ensuite utiliser diverses astuces pour amliorer lheuristique et donc les performances de A* : Dans certaines situations, la prise en compte de caractristiques particulires de la carte est un plus indniable. Un exemple assez parlant est celui dune carte divise en deux zones, avec un seul point de passage entre

Figure 11 38 LM 54

celles-ci. On pense par exemple une le relie au continent par un pont, comme sur la figure 13. Si on tente de calculer un chemin optimal entre le continent et lle, la distance euclidienne sous-estime normment le cot de ce dernier, car elle fonctionne vol doiseau et utilise donc un chemin (en rouge sur la carte) quune unit ne pourra pas emprunter. Le vrai chemin optimal passe en fait ncessairement par lunique point de passage (chemin vert sur la carte). Or, il est tout fait possible de construire une heuristique qui tient compte de cette situation. Lide est de dterminer dans quelle zone sont situs les points darrive et de dpart. Sils sont dans une mme zone, lheuristique reste la distance euclidienne. Par contre, sils sont situs dans des zones diffrentes, lheuristique value le cot comme la somme des distances au point de passage oblig entre les deux zones.

de lheuristique. Nous savons quune heuristique admissible attire A* vers les cases qui le rapprochent du but, ce qui lui permet de latteindre plus rapidement. Si nous augmentons le cot estim du chemin qui relie une case au but (sans changer lestimation pour les autres cases), nous repoussons le moment o cette case sera explore par lalgorithme. Au contraire, une rduction du cot favorise une exploration rapide de la case. Si on souhaite, par exemple, favoriser les lignes droites (car un chemin dans lequel une unit change en permanence de direction nest pas trs raliste), on peut augmenter lgrement le cot estim dun chemin qui effectue un tournant (grce au nud parent conserv dans la liste Ouverts, on sait do le chemin optimal provient et on peut donc calculer langle de rotation entre la direction prcdente et la direction induite par le passage par un voisin donn). La perte dadmissibilit induite par cette pnalisation a en gnral des effets compltement ngligeables, condition bien sr de lui donner une trs faible amplitude. On peut poursuivre dans cette voie en mettant en uvre des adaptations de A* qui produisent des chemins plus ralistes, mais les solutions obtenues sont assez volues (cf [5]).

Algorithme A*

Utilisations avances

La traduction du terrain en un graphe permet des applications volues qui dpassent le modle que jai dcrit jusqu prsent. Il nest pas question ici de faire une liste exhaustive des possibilits ouvertes par cette traduction (associe au gain algorithmique induit par A*), mais simplement de dvelopper deux thmes intressants parmi tant dautres. Figure 13 On peut montrer que cette heuristique amliore grandement les performances de A* qui tudie beaucoup moins de cases tout en trouvant toujours le chemin optimal. Lide se gnralise sans difficult au cas de plusieurs zones, comme par exemple les pices dune maison. Cependant, il faut rester attentif au temps de calcul de lheuristique. En effet, si le terrain tudi comporte de nombreuses zones et donc de nombreux points de passage, lvaluation de lheuristique devient un problme complexe, en fait cest un calcul de chemin optimal entre les zones ! On peut donc perdre en temps de calcul de lheuristique ce quon gagne en nombre de cases tudies. Lanalyse du terrain de jeu est un domaine en plein essor (cf [3]) qui vise entre autres produire automatiquement des aides lalgorithme de pathfinding (et plus gnralement lIA du jeu), en procdant par exemple un dcoupage du terrain en zones qui permettent dobtenir une heuristique efficace. Dans dautres situations, il est intressant de jouer avec ladmissibilit pour obtenir la fois un algorithme plus efficace et des effets matriss sur les chemins obtenus. Pour cela, il faut bien comprendre leffet dune modification
Prise en compte de laltitude

Le modle de terrain que jai choisi est extrmement simple et assez peu raliste. On peut amliorer notablement ce point en prenant en compte laltitude en plus de la nature de chaque case. Le cot du passage dune case une autre est ainsi obtenu comme une combinaison de deux facteurs. Comme dans le modle simple, on tient compte de la difficult de progression dans la case lie la nature de celle-ci, mais on ajoute ce cot une autre pnalit correspondant au changement daltitude. Le point intressant de cette pnalit est quelle nest pas symtrique. En effet, passer de la case A la case B ne cote pas la mme chose que passer de la case B la case A. Pour sen convaincre, il suffit dobserver les coureurs cyclistes dans une tape de montagne ! La vitesse de progression dans la monte est bien videmment trs faible par rapport celle atteinte dans la descente. Pour plus de ralisme, les cots peuvent dailleurs dpendre de la nature de lunit considre : un char est relativement lent, mais aussi assez peu sensible la nature du terrain, alors quune voiture de sport est trs rapide sur une piste et ne peut pas emprunter certains types de terrain. Lalgorithme de Dijkstra et A* sadaptent parfaitement ce nouveau modle car ils travaillent sur des graphes orients pour lesquels le cot de passage dun nud un Octobre 2003 39

autre est port par larte. Le modle choisi introduit donc 16 artes orientes entre chaque nud au lieu de 8 artes non orientes. Du point de vue de limplmentation, on ne change rien, except bien entendu le calcul du cot de passage dune case une autre.
Dplacements coordonns

propose dans la section prcdente, quand on introduisait un point intermdiaire sur le pont entre lle et le continent. On peut ainsi calculer le point a dintersection entre la ligne qui joint les deux units et la plage du continent. Le cot estim est alors la distance entre lunit la plus loigne du point a et ce dernier, laquelle on ajoute la distance entre a et la cible du fantassin sur le continent B, comme lillustre la figure 14 ( condition que la vitesse de dplacement des deux units soit la mme).

Dans de nombreux jeux RTS, les units de base ne sont pas amphibies et doivent donc utiliser des transports de troupes pour traverser une zone de mer. Or, il est rare que lalgorithme de pathfinding soit programm pour raliser cette opration automatiquement, mme dans les cas simples. Pourtant, cela ne pose aucun problme thorique. Considrons en effet le cas dun fantassin situ sur le continent A qui souhaite se rendre sur le continent B et dun transport de troupes situ quelque part en mer entre les deux continents. Le problme se dcompose en trois phases : 1. dplacer le fantassin et le transport de sorte quils se rencontrent sur les plages du continent A ; 2. dplacer le transport contenant le fantassin jusqu une plage du continent B ; 3. dplacer le fantassin sur le continent B vers son but. Pour traiter ce problme comme une exploration de graphe, il suffit de considrer que chaque nud correspond aux positions des deux units sur le terrain. Une arte du graphe modlise le dplacement simultan des deux units, ce qui signifie quelles seront nombreuses ! En effet, si on autorise les mouvements diagonaux, on a 9 mouvements possibles par unit (les 8 mouvements rels auxquels on ajoute limmobilit) et donc 80 mouvements possibles par tour (soit autant dartes), comme par exemple le mouvement simultan suivant : le fantassin se dplace dune case vers le nord, alors que le transport se dplace dune case vers le sud-ouest. On compte 80 mouvements au lieu de 81 car on interdit la combinaison dans laquelle les deux units restent immobiles. De mme, les nuds sont trs nombreux, en thorie N si N dsigne le nombre de cases dans le terrain de jeu (en fait moins car certaines combinaisons sont interdites, en particulier quand le fantassin est seul en mer ou quand le transport se retrouve sur le continent). On comprend donc que lalgorithme de Dijkstra risque dtre trs long sexcuter. A* permet dobtenir des rsultats, mais il faut envisager pour cela une implmentation spcifique pour les listes Ouverts et Ferms car lannotation du graphe nest plus possible en raison de sa taille. Il est aussi important de mettre en uvre une heuristique efficace, par exemple en demandant dans la premire phase aux deux units de se rapprocher : ce comportement peut tre obtenu en utilisant une technique proche de celle 40 LM 54

Figure 14 Grce la traduction en graphe, on obtient un algorithme qui calcule un chemin optimal mettant en jeu deux units qui coordonnent leurs actions. Lapport dA* est ici crucial car la taille du graphe interdit son exploration complte. On peut mme utiliser ici une heuristique non admissible car le plus important est dobtenir un chemin, mme sil nest pas optimal. Notons pour conclure sur cet exemple que les grands graphes sexplorent aussi avec dautres algorithmes, en particulier IDA* (cf [4]), moins efficaces en termes de nuds explors, mais trs conomes en mmoire.

Conclusion

Lalgorithme A* prsent dans cet article amliore radicalement lalgorithme de Dijkstra et permet le calcul de chemins optimaux dans des graphes beaucoup plus volumineux. Bien implment, cest--dire associ des structures de donnes efficaces et une heuristique adapte au problme, A* apporte donc une solution satisfaisante au problme du pathfinding, tel point que certains participants la table ronde sur lIA dans les jeux vido anime par Steven Woodcock [6] ont pu affirmer que les questions de base concernant le calcul de chemins optimaux avaient trouv une rponse. Cependant, de nombreuses questions restent ouvertes, comme par exemple : Comment construire une heuristique efficace ? Les

rponses sont chercher dans lanalyse de terrain (cf [3]) et dans les approches hirarchiques (cf [7]). Comment travailler sur des cartes ou des graphes gigantesques ? Les rponses sont aussi chercher dans les approches hirarchiques [7] ou dans les mthodes multirsolutions (comme celle utilise par Stratagus). Comment prendre en compte laspect dynamique du terrain ? Des solutions existent comme lalgorithme D* (cf [8]), mais elles sont assez coteuses en termes de stockage et les dveloppeurs prfrent en gnral des solutions trs simples, comme par exemple un dcoupage du chemin optimal en tronon, avec un recalcul systmatique (i.e., aprs chaque mouvement) du tronon le plus proche. Comment rsoudre les problmes de collisions entre units, ou plus gnralement les problmes de mouvements coordonnes (les formations par exemple) ? Diverses solutions ont t utilises, comme par exemple celles dcrites dans [9] et [10], qui consistent calculer un chemin optimal classique, puis lexcuter astucieusement grce des primitives de modification de la formation associes une gestion des priorits entre les units pour viter les inter-blocages. Comme nous lavons vu plus haut, il est aussi possible de formuler le problme comme une exploration de graphe, mais cette technique pose des problmes spcifiques. Dautres solutions, inspires de lintelligence collective, ont aussi t proposes pour raliser des mouvements coordonnes (cf [11]). Le domaine du pathfinding reste donc en perptuelle volution, pouss, comme toute lindustrie du jeu vido, par les exigences croissantes des joueurs, en particulier en matire de ralisme. Les jeux vido libres ont encore du mal concurrencer les jeux commerciaux, en particulier en termes de rendu graphique. Pourtant, lexprience ludique est un tout et lIA en gnral, et le pathfinding en particulier, sont souvent des lments en retrait dans les jeux commerciaux. Les jeux libres pourraient donc profiter de la richesse de la recherche dans ce domaine pour marcher sur les platesbandes de leurs concurrents gros budget.

Algorithme A*

Rfrences
Certaines rfrences en ligne proviennent de lexcellent site http://www.gamasutra.com. Ce site consacr lindustrie du jeu vido est une mine dinformations, mais son accs demande une inscription (gratuite). [1] Fabrice Rossi - Recherche des chemins optimaux pour les jeux vido, GNU/Linux Magazine France, No 53, Septembre 2003. [2] Stout, W. Bryan. - Smart Moves: Intelligent Pathfinding, October/November 1996. Disponible sur gamasutra.com lURL http://www.gamasutra.com/features/19970801/pathfinding.htm [3] Dave C. Pottinger - Ensemble Studios Terrain Analysis in Realtime Strategy. Disponible lURL http://www.ensemblestudios.com/news/devnews/terrain1.shtml [4] Mark Brockington - Pawn Captures Wyvern: How Computer Chess Can Improve Your Pathfinding, June 2000. Disponible sur gamasutra.com lURL http://www.gamasutra.com/features/20000626/brockington_01.htm [5] Marco Pinter - Toward More Realistic Pathfinding, mars 2001. Disponible sur gamasutra.com lURL http://www.gamasutra.com/features/20010314/pinter_01.htm [6] Steven Woodcock - AI Roundtable Moderators Report 2003, Game Developers Conference, March 6-8. Disponible lURL : http://www.gameai.com/cgdc03notes.htm [7] Robert Holte, M.B. Perez, Robert Zimmer, and Alan MacDonald Hierarchical A*: Searching Abstraction Hierarchies Efficiently, Technical report tr-95- Disponible lURL : 18. http://www.csi.uottawa.ca/~holte/Publications/tr-9518.ps [8] A. Stentz - The Focussed D* Algorithm for Real-Time Replanning, , Proceedings of IJCAI-95, August 1995. Disponible lURL : http://www.frc.ri.cmu.edu/~axs/doc/ijcai95.ps [9] Pottinger, Dave C. - Coordinated Unit Movement, January 1999. Disponible sur gamasutra.com lURL http://www.gamasutra.com/features/19990122/movement_01.htm [10] Pottinger, Dave C. - Implementing Coordinated Movement, February 1999. Disponible sur gamasutra.com lURL http://www.gamasutra.com/features/19990129/implementing_01.htm [11] Le site de Craig Reynolds (URL : http://www.red3d.com/cwr/boids/) est une rfrence en matire de simulation de troupeaux. [12] Le site de Amit Patel (URL : http://www-csstudents.stanford.edu/~amitp/gameprog.html) est une mine dinformations sur le pathfinding et les jeux vido (on y trouve entre autre une implmentation intressante en C++ de A*, ainsi que des liens vers dautres implmentations). [13] Le site de Steven Woodcok (URL : http://www.gameai.com/) est une autre mine dinformation sur lIA dans les jeux vido.

Fabrice Rossi Equipe AXIS INRIA Fabrice.Rossi@apiacoa.org http://apiacoa.org

Post Scriptum

Une petite erreur sest malencontreusement glisse dans larticle prcdent [1] : les figures 2 et 10 ont subrepticement chang leurs places !

Octobre 2003

41

Creative Commons
Paternit - Pas d'Utilisation Commerciale - Pas de Modification 2.0
Creative Commons n'est pas un cabinet d'avocats et ne fournit pas de services de conseil juridique. La distribution de la prsente version de ce contrat ne cre aucune relation juridique entre les parties au contrat prsent ci-aprs et Creative Commons. Creative Commons fournit cette offre de contrat-type en l'tat, seule fin d'information. Creative Commons ne saurait tre tenu responsable des ventuels prjudices rsultant du contenu ou de l'utilisation de ce contrat. Contrat L'Oeuvre (telle que dfinie ci-dessous) est mise disposition selon les termes du prsent contrat appel Contrat Public Creative Commons (dnomm ici CPCC ou Contrat ). L'Oeuvre est protge par le droit de la proprit littraire et artistique (droit d'auteur, droits voisins, droits des producteurs de bases de donnes) ou toute autre loi applicable. Toute utilisation de l'Oeuvre autrement qu'explicitement autorise selon ce Contrat ou le droit applicable est interdite. L'exercice sur l'Oeuvre de tout droit propos par le prsent contrat vaut acceptation de celui-ci. Selon les termes et les obligations du prsent contrat, la partie Offrante propose la partie Acceptante l'exercice de certains droits prsents ci-aprs, et l'Acceptant en approuve les termes et conditions d'utilisation. 1. Dfinitions a. Oeuvre : oeuvre de l'esprit protgeable par le droit de la proprit littraire et artistique ou toute loi applicable et qui est mise disposition selon les termes du prsent Contrat. b. Oeuvre dite Collective : une oeuvre dans laquelle l'oeuvre, dans sa forme intgrale et non modifie, est assemble en un ensemble collectif avec d'autres contributions qui constituent en elles-mmes des oeuvres spares et indpendantes. Constituent notamment des Oeuvres dites Collectives les publications priodiques, les anthologies ou les encyclopdies. Aux termes de la prsente autorisation, une oeuvre qui constitue une Oeuvre dite Collective ne sera pas considre comme une Oeuvre dite Drive (telle que dfinie ci-aprs). c. Oeuvre dite Drive : une oeuvre cre soit partir de l'Oeuvre seule, soit partir de l'Oeuvre et d'autres oeuvres prexistantes. Constituent notamment des Oeuvres dites Drives les traductions, les arrangements musicaux, les adaptations thtrales, littraires ou cinmatographiques, les enregistrements sonores, les reproductions par un art ou un procd quelconque, les rsums, ou toute autre forme sous laquelle l'Oeuvre puisse tre remanie, modifie, transforme ou adapte, l'exception d'une oeuvre qui constitue une Oeuvre dite Collective. Une Oeuvre dite Collective ne sera pas considre comme une Oeuvre dite Drive aux termes du prsent Contrat. Dans le cas o l'Oeuvre serait une composition musicale ou un enregistrement sonore, la synchronisation de l'oeuvre avec une image anime sera considre comme une Oeuvre dite Drive pour les propos de ce Contrat. d. Auteur original : la ou les personnes physiques qui ont cr l'Oeuvre. e. Offrant : la ou les personne(s) physique(s) ou morale(s) qui proposent la mise disposition de l'Oeuvre selon les termes du prsent Contrat. f. Acceptant : la personne physique ou morale qui accepte le prsent contrat et exerce des droits sans en avoir viol les termes au pralable ou qui a reu l'autorisation expresse de l'Offrant d'exercer des droits dans le cadre du prsent contrat malgr une prcdente violation de ce contrat. 2. Exceptions aux droits exclusifs. Aucune disposition de ce contrat n'a pour intention de rduire, limiter ou restreindre les prrogatives issues des exceptions aux droits, de l'puisement des droits ou d'autres limitations aux droits exclusifs des ayants droit selon le droit de la proprit littraire et artistique ou les autres lois applicables. 3. Autorisation. Soumis aux termes et conditions dfinis dans cette autorisation, et ceci pendant toute la dure de protection de l'Oeuvre par le droit de la proprit littraire et artistique ou le droit applicable, l'Offrant accorde l'Acceptant l'autorisation mondiale d'exercer titre gratuit et non exclusif les droits suivants : a. reproduire l'Oeuvre, incorporer l'Oeuvre dans une ou plusieurs Oeuvres dites Collectives et reproduire l'Oeuvre telle qu'incorpore dans lesdites Oeuvres dites Collectives; b. distribuer des exemplaires ou enregistrements, prsenter, reprsenter ou communiquer l'Oeuvre au public par tout procd technique, y compris incorpore dans des Oeuvres Collectives; c. lorsque l'Oeuvre est une base de donnes, extraire et rutiliser des parties substantielles de l'Oeuvre. Les droits mentionns ci-dessus peuvent tre exercs sur tous les supports, mdias, procds techniques et formats. Les droits cidessus incluent le droit d'effectuer les modifications ncessaires techniquement l'exercice des droits dans d'autres formats et procds techniques. L'exercice de tous les droits qui ne sont pas expressment autoriss par l'Offrant ou dont il n'aurait pas la gestion demeure rserv, notamment les mcanismes de gestion collective obligatoire applicables dcrits l'article 4(d). 4. Restrictions. L'autorisation accorde par l'article 3 est expressment assujettie et limite par le respect des restrictions suivantes : a. L'Acceptant peut reproduire, distribuer, reprsenter ou communiquer au public l'Oeuvre y compris par voie numrique uniquement selon les termes de ce Contrat. L'Acceptant doit inclure une copie ou l'adresse Internet (Identifiant Uniforme de Ressource) du prsent Contrat toute reproduction ou enregistrement de l'Oeuvre que l'Acceptant distribue, reprsente ou communique au public y compris par voie numrique. L'Acceptant ne peut pas offrir ou imposer de conditions d'utilisation de l'Oeuvre qui altrent ou restreignent les termes du prsent Contrat ou l'exercice des droits qui y sont accords au bnficiaire. L'Acceptant ne peut pas cder de droits sur l'Oeuvre. L'Acceptant doit conserver intactes toutes les informations qui renvoient ce Contrat et l'exonration de responsabilit. L'Acceptant ne peut pas reproduire, distribuer, reprsenter ou communiquer au public l'Oeuvre, y compris par voie numrique, en utilisant une mesure technique de contrle d'accs ou de contrle d'utilisation qui serait contradictoire avec les termes de cet Accord contractuel. Les mentions ci-dessus s'appliquent l'Oeuvre telle qu'incorpore dans une Oeuvre dite Collective, mais, en dehors de l'Oeuvre en ellemme, ne soumettent pas l'Oeuvre dite Collective, aux termes du prsent Contrat. Si l'Acceptant cre une Oeuvre dite Collective, la demande de tout Offrant, il devra, dans la mesure du possible, retirer de l'Oeuvre dite Collective toute rfrence au dit Offrant, comme demand. Si l'Acceptant cre une Oeuvre dite Collective, la demande de tout Auteur, il devra, dans la mesure du possible, retirer de l'Oeuvre dite Collective toute rfrence au dit Auteur, comme demand.

b. L'Acceptant ne peut exercer aucun des droits confrs par l'article 3 avec l'intention ou l'objectif d'obtenir un profit commercial ou une compensation financire personnelle. L'change de l'Oeuvre avec d'autres Oeuvres protges par le droit de la proprit littraire et artistique par le partage lectronique de fichiers, ou par tout autre moyen, n'est pas considr comme un change avec l'intention ou l'objectif d'un profit commercial ou d'une compensation financire personnelle, dans la mesure o aucun paiement ou compensation financire n'intervient en relation avec l'change d'Oeuvres protges. c. Si l'Acceptant reproduit, distribue, reprsente ou communique l'Oeuvre au public, y compris par voie numrique, il doit conserver intactes toutes les informations sur le rgime des droits et en attribuer la paternit l'Auteur Original, de manire raisonnable au regard au mdium ou au moyen utilis. Il doit communiquer le nom de l'Auteur Original ou son ventuel pseudonyme s'il est indiqu ; le titre de l'Oeuvre Originale s'il est indiqu ; dans la mesure du possible, l'adresse Internet ou Identifiant Uniforme de Ressource (URI), s'il existe, spcifi par l'Offrant comme associ l'Oeuvre, moins que cette adresse ne renvoie pas aux informations lgales (paternit et conditions d'utilisation de l'Oeuvre). Ces obligations d'attribution de paternit doivent tre excutes de manire raisonnable. Cependant, dans le cas d'une Oeuvre dite Collective, ces informations doivent, au minimum, apparatre la place et de manire aussi visible que celles laquelle apparaissent les informations de mme nature. d. Dans le cas o une utilisation de l'Oeuvre serait soumise un rgime lgal de gestion collective obligatoire, l'Offrant se rserve le droit exclusif de collecter ces redevances par l'intermdiaire de la socit de perception et de rpartition des droits comptente. Sont notamment concerns la radiodiffusion et la communication dans un lieu public de phonogrammes publis des fins de commerce, certains cas de retransmission par cble et satellite, la copie prive d'Oeuvres fixes sur phonogrammes ou vidogrammes, la reproduction par reprographie. 5. Garantie et exonration de responsabilit a. En mettant l'Oeuvre la disposition du public selon les termes de ce Contrat, l'Offrant dclare de bonne foi qu' sa connaissance et dans les limites d'une enqute raisonnable : i. L'Offrant a obtenu tous les droits sur l'Oeuvre ncessaires pour pouvoir autoriser l'exercice des droits accords par le prsent Contrat, et permettre la jouissance paisible et l'exercice licite de ces droits, ceci sans que l'Acceptant n'ait aucune obligation de verser de rmunration ou tout autre paiement ou droits, dans la limite des mcanismes de gestion collective obligatoire applicables dcrits l'article 4(e); b. L'Oeuvre n'est constitutive ni d'une violation des droits de tiers, notamment du droit de la proprit littraire et artistique, du droit des marques, du droit de l'information, du droit civil ou de tout autre droit, ni de diffamation, de violation de la vie prive ou de tout autre prjudice dlictuel l'gard de toute tierce partie. c. A l'exception des situations expressment mentionnes dans le prsent Contrat ou dans un autre accord crit, ou exiges par la loi applicable, l'Oeuvre est mise disposition en l'tat sans garantie d'aucune sorte, qu'elle soit expresse ou tacite, y compris l'gard du contenu ou de l'exactitude de l'Oeuvre. 6. Limitation de responsabilit. A l'exception des garanties d'ordre public imposes par la loi applicable et des rparations imposes par le rgime de la responsabilit vis--vis d'un tiers en raison de la violation des garanties prvues par l'article 5 du prsent contrat, l'Offrant ne sera en aucun cas tenu responsable vis--vis de l'Acceptant, sur la base d'aucune thorie lgale ni en raison d'aucun prjudice direct, indirect, matriel ou moral, rsultant de l'excution du prsent Contrat ou de l'utilisation de l'Oeuvre, y compris dans l'hypothse o l'Offrant avait connaissance de la possible existence d'un tel prjudice. 7. Rsiliation a. Tout manquement aux termes du contrat par l'Acceptant entrane la rsiliation automatique du Contrat et la fin des droits qui en dcoulent. Cependant, le contrat conserve ses effets envers les personnes physiques ou morales qui ont reu de la part de l'Acceptant, en excution du prsent contrat, la mise disposition d'Oeuvres dites Drives, ou d'Oeuvres dites Collectives, ceci tant qu'elles respectent pleinement leurs obligations. Les sections 1, 2, 5, 6 et 7 du contrat continuent s'appliquer aprs la rsiliation de celui-ci. b. Dans les limites indiques ci-dessus, le prsent Contrat s'applique pendant toute la dure de protection de l'Oeuvre selon le droit applicable. Nanmoins, l'Offrant se rserve tout moment le droit d'exploiter l'Oeuvre sous des conditions contractuelles diffrentes, ou d'en cesser la diffusion; cependant, le recours cette option ne doit pas conduire retirer les effets du prsent Contrat (ou de tout contrat qui a t ou doit tre accord selon les termes de ce Contrat), et ce Contrat continuera s'appliquer dans tous ses effets jusqu' ce que sa rsiliation intervienne dans les conditions dcrites ci-dessus. 8. Divers a. A chaque reproduction ou communication au public par voie numrique de l'Oeuvre ou d'une Oeuvre dite Collective par l'Acceptant, l'Offrant propose au bnficiaire une offre de mise disposition de l'Oeuvre dans des termes et conditions identiques ceux accords la partie Acceptante dans le prsent Contrat. b. La nullit ou l'inapplicabilit d'une quelconque disposition de ce Contrat au regard de la loi applicable n'affecte pas celle des autres dispositions qui resteront pleinement valides et applicables. Sans action additionnelle par les parties cet accord, lesdites dispositions devront tre interprtes dans la mesure minimum ncessaire leur validit et leur applicabilit. c. Aucune limite, renonciation ou modification des termes ou dispositions du prsent Contrat ne pourra tre accepte sans le consentement crit et sign de la partie comptente. d. Ce Contrat constitue le seul accord entre les parties propos de l'Oeuvre mise ici disposition. Il n'existe aucun lment annexe, accord supplmentaire ou mandat portant sur cette Oeuvre en dehors des lments mentionns ici. L'Offrant ne sera tenu par aucune disposition supplmentaire qui pourrait apparatre dans une quelconque communication en provenance de l'Acceptant. Ce Contrat ne peut tre modifi sans l'accord mutuel crit de l'Offrant et de l'Acceptant. e. Le droit applicable est le droit franais. Creative Commons n'est pas partie ce Contrat et n'offre aucune forme de garantie relative l'Oeuvre. Creative Commons dcline toute responsabilit l'gard de l'Acceptant ou de toute autre partie, quel que soit le fondement lgal de cette responsabilit et quel que soit le prjudice subi, direct, indirect, matriel ou moral, qui surviendrait en rapport avec le prsent Contrat. Cependant, si Creative Commons s'est expressment identifi comme Offrant pour mettre une Oeuvre disposition selon les termes de ce Contrat, Creative Commons jouira de tous les droits et obligations d'un Offrant. A l'exception des fins limites informer le public que l'Oeuvre est mise disposition sous CPCC, aucune des parties n'utilisera la marque Creative Commons ou toute autre indication ou logo affrent sans le consentement pralable crit de Creative Commons. Toute utilisation autorise devra tre effectue en conformit avec les lignes directrices de Creative Commons jour au moment de l'utilisation, telles qu'elles sont disponibles sur son site Internet ou sur simple demande. Creative Commons peut tre contact http://creativecommons.org/.