Représentation des Stratégies 1.Opposition Tactique /Stratégie

S'il est déjà difficile de définir avec précision ce qu'on entend par stratégie, il est peut-être encore plus difficile de distinguer entre "tactiques" et "stratégie". Selon l'expérience du joueur, le niveau de description où l'on se place, telle manœuvre sera classée dans l'une où l'autre classe. Ainsi, par exemple, au Go, capturer un groupe ennemi est une manœuvre stratégique pour un débutant : il s'agit de coordonner la pose des pierres. Au contraire, cette même capture sera perçue par un bon joueur comme un simple outil tactique à sa disposition en vue de satisfaire des buts "plus élevés", comme faire du territoire par exemple. C'est la raison pour laquelle nous n'avons pas souhaité faire de distinction dans notre système entre les niveaux tactiques et stratégiques : les deux sont représentées par des plans. Ainsi, toute stratégie peut être vue comme une tactique par un plan plus élevé qu'elle et réciproquement, tout plan "tactique" est du point de vue de ses sous-plans, un plan stratégique. Ceci peut sembler en contradiction avec ce que nous avions dit en introduction sur les programmes de jeux actuels, pourtant, il n'en est rien : les systèmes d'apprentissage actuels se basent tous sur la capacité de reconnaître dans l’environnement quand une tactique/stratégie adverse a réussi (mat, prise d'une pièce, d'un groupe de pierres…). A ma connaissance, aucun d'eux n'est en mesure d'apprendre des stratégies au sens militaire du terme, c'est-à-dire un choix entre plusieurs options tactiques, qui ne se manifestera donc pas de manière visible sur l'échiquier/ le Goban.

3.2.Représentation des Plans Stratégiques

Nous avons mis en œuvre une nouvelle méthode de planification assez éloignée des modèles traditionnels tels que STRIPS ou HTN ([Willmott, 1997] et [Hu et al, 1997]) afin de représenter les tactiques/stratégies dans ce type de jeux. Chaque plan est constitué :

d'un "pattern logique" exprimé dans le même langage que les règles définissant le jeu, qui spécifie les conditions devant être vérifiées pour "essayer" le plan en mode simulation. Ainsi, dans le plan de la Figure3, le pattern logique exige qu'un groupe de pierres ennemies soit entouré par deux groupes amis plus "forts" que lui (la force d'un groupe étant mesurée par des règles de modélisation non présentées ici), pour que le plan soit essayé.

d'un arbre des sous-plans précisant les calculs devant être effectués en mode simulation lorsque le pattern logique a matché. d'un but représenté sous la forme d'un échange de ressources. Ainsi, dans le plan de la Figure 3, le joueur qui déclenche le plan échange NIL (= rien dans ce cas précis) contre du territoire ou de l'influence. Le but du plan sert à juger en mode simulation si le plan a réussi ou non en comparant la position initiale avec les positions terminales après simulation. Dans le cas du plan de la Figure 3, la simulation est considérée comme réussie si le territoire ou l'influence des positions terminales est supérieure à celle de la position initiale. Ceci permettra par la suite de distinguer les plans qui n'ont pas pu être correctement appliqués (les buts du plan n'ont pas été atteints) des plans faux (les buts du plan n'ont été atteints, mais la position après l'application du plan est une position perdante pour le joueur qui a appliqué le plan)

de diverses informations permettant de comparer les plans entre eux (risque/valeur d'un plan…)

de conséquences de l'échec d'un plan en mode simulation : en effet, si le pattern logique d'un plan a été vérifié, mais que le système est incapable de faire aboutir le plan en mode simulation, c'est que peut-être la modélisation de la position est en cause. Dans ce cas, le système applique l'action décrite par le champ SI_ECHEC (dans le plan Figure 3, si la simulation de la capture de G a échoué, c'est que G devait être plus fort que prévu initialement. En conséquence de quoi, on renforce son statut).

PLAN (COLOR C) capturer_un_groupe_ennemi_faible_coincé_entre_deux_groupes_amis_forts {

BUT : NIL >> territoire ou influence PATTERN LOGIQUE:

SI G ∈ groupe(~C). G est un groupe ennemi

SI statut(G) < 2 . G n’est pas inconditionnellement vivant IF G1 ∈ groupe(C). G1 est un groupe ami

IF géométrie(G1,G) = 1 G1 est à gauche de G IF statut (G) < statut (G1) . G1 est plus fort que G IF G2 ∈ groupe(C) . G2 est un groupe ami IF géométrie(G2,G) = (1,0). G2 est à droite de G IF statut (G) < statut(G2) . G2 est plus fort que G SCHEMAS : ENTOURER (G) { || FUIR(G) { ENTOURER(G) } || VIVRE(G) { CONNECTER (G1,G2) } || AUTRE{ TUER(G) } }

VALEUR : #G . la valeur du plan est proportionnelle au cardinal de G

RISQUE : statut (G) . le risque est proportionnel à la force de G SI_ECHEC : statut (G) := statut (G) + 1 . G est plus fort que prévu

}

3.3.Simulation d’un Plan :

L'idée de base de la représentation des tactiques/stratégies est illustrée par la Figure 4 :

Une stratégie est définie comme un chemin d'une position initiale vérifiant le pattern logique vers une ou plusieurs positions terminales satisfaisant le but du plan. Pour tester un plan dans une situation donnée, le système de planification appelle récursivement les sous-plans définis dans le schéma du plan qu'il essaye. Ainsi, dans le plan de la Figure 3, le système commence par appeler le sous-plan "ENTOURER" (non donné ici) pour savoir s'il peut parvenir à entourer le groupe G. Dans l'affirmative, le plan précise que seules 3 options sont ouvertes à l'ennemi :

- FUIR (= briser l'encerclement)

- VIVRE sur place (en faisant deux yeux)

- AUTRE (réponse ennemie non liée à l'attaque du groupe G, ce qui revient à sacrifier G)

Le système commence par appeler le sous-plan FUIR. Si ce sous-plan échoue (du point de vue de l'ennemi), le système considère que l'option FUIR n'est pas possible et passe à l'étude des options restantes. Si, au contraire, FUIR retourne un ou plusieurs coups susceptibles d'aider G à fuir, le système choisit le meilleur (grâce aux paramètre valeur/risque retournés par le sous-plan FUIR), joue ledit coup, et, après avoir appelé à nouveau les règles de modélisation sur la position ainsi obtenue, appelle le sous-plan ENTOURER à nouveau. Si ce dernier échoue, c'est que l'ennemi peut s'enfuir, et que le plan capturer_un_groupe_ennemi_faible_coincé_entre_deux_groupes_amis_forts a échoué. Le système passe alors à l'étude des plans restants de la bibliothèque. Si ENTOURER réussit, le système conclut comme précédemment que l'option FUIR n'est pas réalisable par l'ennemi, et passe à l'étude de l'option VIVRE sur place. Finalement, si cette option est également mauvaise pour l'adversaire, il passe à l'option AUTRE. Ce dernier sous-plan est un peu particulier, car il suppose que l'ennemi va passer son tour.

Lorsque la simulation dans le monde des plans est achevée, et que le plan est jugé applicable, le résultat (= l'arbre des coups joués de part et d'autre par les deux joueurs) de cette simulation est ensuite placé dans la liste des plans applicables.

3.4.Langage des Plans et Métaplans:

Afin de représenter des stratégies complexes, un langage de plan a été mis au point. Celui-ci permet en autre de faire des tests et des branchements à l'issue de l'appel d'un plan. Ainsi, par exemple, le plan Figure 3 suppose qu'une fois que le sous-plan ENTOURER a été appelé avec succès pour la deuxième fois, le groupe G n'est plus en mesure de FUIR à nouveau. En fait, le plan véritable est :

SCHEMAS :

ENTOURER (G) {

|| LABEL $1 : FUIR(G) { ENTOURER(G) { $1} } || VIVRE(G) { CONNECTER (G1,G2) }

|| AUTRE{ TUER(G) } }

Les sous-plans FUIR et ENTOURER sont ainsi appelés successivement jusqu'à ce que l'un d'eux ne soit plus réalisable. Ceci augmente considérablement la puissance d'expression des plans, mais peut engendrer des boucles infinies, en cas d'erreur dans un sous-plan. Pour le moment, le problème est géré manuellement.

Dans le paragraphe 2.1, nous avons expliqué pourquoi nous avions choisi de représenter dans un même formalisme tactiques et stratégies. Pourtant, notre intérêt premier est d'être en mesure d'apprendre des stratégies au sens militaire du terme, c'est à dire, des fonctions de choix entre plusieurs tactiques/stratégies. Pour cela, nous avons besoin d'être en mesure de représenter ces options dans le pattern logique. En d'autres termes, nous allons chercher à faire apprendre au système des Métaplans, c'est à dire, des plans qui vont coordonner d'autres plans, du type " Si on vient de jouer le plan 'Ouverture1' au coup précédent, il faut maintenant jouer de préférence le plan 'Créer_du_territoire' ", ou encore "Si plusieurs plans conseillent de jouer un même coup, alors, il faut accorder plus d'importance à ce coup"… Pour cela, nous avons introduit un aspect réflexif dans le système de planification : La simulation des plans elle-même, modifie la modélisation de la position en introduisant notamment :

l'historique des coups joués

l'historique des plans joués par le système (et d'une manière générale de tous les plans considérés comme réalisables pour une position donnée)

des informations sur les plans de la bibliothèque (leurs buts/valeurs/risques…)

Toutes ces informations pouvant être utilisées dans le pattern logique de nouvelles stratégies. Ripostes Ennemies

PATTERN

1^er Coup Ami

Contre Offensives Amies

Positions Victorieuses pour Ami (pour le but précisé par le plan)