- décision de prise

éléments certains = le jeu en main , la carte retournée qui sera prise
éléments incertains = le jeu du partenaire, les jeux des adversaires, ce qui reste à distribuer dans la pile.
stratégie possible = estimation des points « sûrs » (cartes maîtresses et annonces) et utilisation d’un coefficient de risque basé sur un calcul de probabilité sur le jeu du partenaire. Éventuellement, à terme, prise en compte des parties passées , de la situation comptable dans la manche courante, d’un niveau de risque dépendant du type d’IA (plus ou moins de prise de risque sur les probas). Un des points critiques est la gestion des cartes non maîtresses mais coûteuses en point (les 10 tout le temps, les As à l’atout)

- décision de jouer une carte

éléments certains = le jeu en main , toutes les cartes sont distribuées
éléments incertains = la répartition de ces cartes entre adversaires et partenaire
stratégie possible = construction apriori de combinaisons de jeux stéréotypées plus ou moins prioritaires en fonction de la situation courante. Exemple de combinaison type: « le preneur est mon partenaire, je suis le premier à jouer -> je joue à l’atout ». Exemple de contre-ordre: « j’ai le 9 sec à l’atout -> je ne lance jamais à l’atout »

A y réfléchir, le jeu de belote me parait de plus en plus intéressant: Au moment de la prise, le système est très ouvert, dans le sens où l’IA n’a qu’une connaissance partielle du système et qu’une distribution (semi)aléatoire va venir ensuite compléter le système. Au moment de jouer la carte, le système est fermé (toutes les cartes sont en jeu ou ont été jouées) mais la connaissance est toujours partielle (jeu du partenaire, jeux des adversaires). Du coup, ça parait peut-être moins intéressant de se baser sur des algorithmes de recherche exhaustive?

En tout cas, dans un premier temps, je pense que je vais me baser surtout sur des règles de comportement et moins sur des probabilités comme je le pensais au départ. C’est surtout la décision de prise qui nécessitera les calculs, comme l’estimation des points sûrs et la probabilité que le partenaire ait « les cartes qu’il faut ».

La phase de déroulement de jeu serait plutôt basée sur des comportements simples permettant de minimiser la prise de risque par rapport au jeu du partenaire, avec des mini schémas correspondant à des situations de jeu et de cartes en main. Les calculs consisteraient surtout à compter les atouts et à estimer en fin de partie la stratégie pour faire les dix points de bonus du dernier pli. Mais là encore, l’utilisation de probabilités brutes me parait limitée car entre joueurs humains, on arrive souvent à deviner ce que le partenaire a dans la main aux derniers tours en fonction de ce qu’il a joué précédemment.

J’aimerais également aborder plus tard le rapport au jeu de l’adversaire humain en utilisant un fichier mémoire des parties précédentes, où il y aurait des paris de l’IA sur la stratégie habituelle du profil humain.

La grande difficulté que je pressens, c’est l’articulation entre les mini-schémas et la situation de jeu.

Reprenons l’exemple précédent, pour les amateurs de belote, soit la situation: preneur = partenaire, 1er tour de jeu = moi. A priori, on commence souvent par un tour d’atout. La situation à potentiel maximal est de commencer par le roi ou le 10 si on l’a, car l’adversaire suivant doit monter et donc arrive directement dans les gros points (10, As ou 9), le partenaire assure le pli en jouant le valet (carte maîtresse à l’atout) et le dernier adversaire doit fournir en atout (et là encore, si le preneur en a suffisamment, il y a une bonne probabilité que le dernier adversaire doive lâcher un atout à forte valeur). Donc potentiellement, ça peut être un pli à 49 ou 55 points (sur les 162 que comporte le jeu à un atout).

Maintenant, imaginons que le preneur ait pris sans le valet. La même situation peut s’avérer très mauvaise en fonction de la distribution: je joue le roi ou le 10, le premier adversaire joue l’As, le partenaire doit monter et doit fournir le 9 et le dernier adversaire empoche la mise avec le valet. Le bilan est inversé avec – 49 ou – 55 et de plus, un tour d’atout a été fait pour rien pour la partie prenante, alors que justement, dans cette situation, le preneur part généralement sur une stratégie de coupe des gros points hors atout, volant ainsi des cartes normalement maîtresses (les As non atout) en sauvant lui même ses gros points d’atout non maîtres (10, As et 9).

Beaucoup de travail ces derniers temps et donc pas de temps pour BeloteMaster. Tout de même quelques avancées:

– A la suite de mon passage sous mac, je me suis dit que ça serait sympa que le jeu tourne aussi sous MacOS X, donc j’ai fait quelques petites modifs pour que ce soit possible au niveau de la gestion des fichiers surtout.

– A part ça, ben pas grand chose, toujours englué dans le graphisme et le moteur du jeu, donc en vrac: sélection d’une carte, ordonnancement des phases de jeu, tri des cartes une fois la distribution terminée.

Avec toujours en tête de garder en permanence une représentation symbolique des cartes pour que le code de l’IA soit le plus proche possible du déroulement classique de la partie.

Pour l’instant, la partie graphique est vraiment réduite au strict minimum pour fonctionner. Comprendre par là: les cartes sont stockées sous forme de collections d’image à afficher en batterie, ce qui n’est pas très élégant pour du Smalltalk, j’aimerais bien faire un objet graphique = une vue, mais je n’ai pas le temps et je voudrais arriver le plus vite à la programmation de l’IA !

Deux petits screenshots pour voir l’étendue des dégâts J’ai quelques fonds de fenêtre possibles, mais je n’ai pas encore codé leur affichage…

Basiquement, les instances de BeloteJoueur devront répondre aux questions de l’ordonnanceur, en fonction de la phase de jeu, les deux principales étant:
– Est ce que je prend à l’atout en cours? Est ce que j’attends le tour suivant pour proposer une autre couleur, prendre sans atout ou tout atout?
– Quelle carte jouer?

Pour répondre à ces questions, BeloteJoueur va devoir s’en poser d’autres. Exemple: Quelles sont mes cartes à l’atout? A quelle position suis je dans le tour de jeu? Quel est le score? Qui a joué quoi? Mon partenaire est il maître dans le tour courant? etc…etc…

Et pour répondre à ces questions plus précises, l’IA va devoir combiner des éléments de logique (« j’ai valet et 9 à l’atout, je prend » ; « mon partenaire a coupé, je peux me défausser » par exemple) mais aussi des éléments quantitatifs permettant la prise en compte du risque (calcul de la probabilité que le joueur suivant ait cette carte, calcul de la probabilité que mon partenaire possède la carte qui me manque par exemple).

La base de connaissance du joueur pourrait prendre plusieurs formes:
– une forme statique, qui constituerait l’ensemble des règles indépendantes du contexte du jeu (roi et dame à l’atout me donne belote = + 20 points)
– une forme dynamique, qui pourrait s’adapter en fonction d’un niveau de risque calculé à partir des évènements passés, comme par exemple, la mise en mémoire des pourcentages de fois où un évènement s’est produit ( du type,  » 78% des fois où mon partenaire a pris à pique, il avait le valet »)

Bien sûr, tout cela paraît idéal quand on le décrit avec des mots, et c’est l’implémentation de tout cela qui va poser problème.

Une des premières choses à faire est bien entendu de trouver les règles les plus simples et les plus génériques et pour cela, il faut à la fois observer les bons joueurs de belote mais aussi essayer d’identifier des raccourcis « mathématiques » qui permettront de donner un comportement à peu près réaliste, sans être trop gourmand en temps de calcul, tout en restant relativement invisible pour un joueur lambda.

Pour la décision de « prise » par exemple, il va me falloir trouver un moyen de calculer un estimateur de gain que BeloteJoueur produira avant sa prise de décision. Je pense pondérer les décisions par un facteur « risque » qui sera le comportement face à la prise de décision: au lieu d’avoir une décision binaire basée sur des seuils, il pourrait y avoir un tirage aléatoire de chiffre combinant le facteur de risque acceptable / risque réel calculé (exemple: p = 0.3 de réussir le contrat, p = 0.5 de prise de risque dans ces conditions, c’est à dire que le joueur prend une fois sur deux la décision d’aller contre son estimation et de prendre le risque lorsque sa proba de réussite est estimée à 0.3 (30% de chances de succès, ça serait une sorte de tête brûlée celui là :D). Cela donnera plus de flexibilité au joueur et moins de répétitions apparentes (les comportements types qu’on finit par identifier lorsqu’on joue beaucoup).

Bref, l’œuvre s’annonce gargantuesque !

Dans le projet, les cartes sont sous deux formes:
– une forme physique: format.png. Il s’agit du jeu de cartes de David Bellot disponible en svg, que j’ai découpé et transformé en cartes de 103×150 pixels sous format png.
– une forme symbolique: par exemple: #As_of_Hearts ou #King_of_Spades.

Le programme stocke donc un dictionnaire ayant en clé le symbole et en valeur l’image. (cards at: #As_of_Hearts -> renvoie l’image de l’as de coeur).

La méthode firstDistrib consiste donc à tout d’abord mélanger aléatoirement les symboles pour constituer une liste de symboles (pile) qui est ensuite distribuée aux 4 joueurs.

Voici le code commenté, et !! non optimisé pour en faciliter la lecture !!

BeloteModel, BeloteView, BeloteController constituent le MVC qui s’affiche dans la fenêtre principale. BeloteManager est une sous classe d’ApplicationModel, une des classes pilier de Visual Works. Généralement, c’est elle qui gère l’affichage de la fenêtre et qui distribue la main aux éléments internes par son contrôleur.

Pour faire simple, on instancie BeloteManager et on envoie ainsi un message au constructeur d’interface qui construit la fenêtre à partir de la spécification donnée par BeloteManager. BeloteManager instancie à son tour BeloteModel qui instancie sa vue BeloteView, qui se référence auprès de BeloteManager pour être affichable dans la fenêtre. Entre temps, BeloteView a instancié BeloteController qui se référence automatiquement à BeloteModel. BeloteModel instancie durant son initialisation également 4 BeloteJoueur ( qui ne sont pas référencés par BeloteManager contrairement à ce que dit le schéma !).

D’un point de vue fonctionnel:
– BeloteManager est la classe qui permet d’intégrer le tout dans une fenêtre et de la faire communiquer avec l’OS.
– BeloteModel est l’ordonnanceur du jeu, à savoir qu’il gère le déroulement de la partie en fonction des actions venant du controleur, updatant la vue lorsque nécessaire.
– BeloteView gère l’affichage
– BeloteController gère les actions de l’utilisateur (clic souris, frappe clavier)
– BeloteJoueur représente un joueur (IA ou non, défini par automat qui est un booléen).

Étant un grand passionné de la belote dominicale, j’ai commencé à décortiquer le jeu sous forme d’algorithmes amusants et puis à la lecture de certains livres d’intelligence artificielle, je me suis dit: pourquoi ne pas tenter de programmer une IA jouant à la belote? Ça me permettra i) de revoir les bases du paradigme Modèle-Vue-Contrôleur pour la partie graphique, ii) de coder les choses que je connais en IA et iii) de jouer enfin à la belote pendant la semaine, devant mon ordi

Ce qui m’intéresse particulièrement, au delà de la prise de décision de l’agent, c’est la possibilité de coder des « tempéraments » qui évoluent en fonction des expériences rencontrées par l’IA.

L’idée est d’en faire profiter la communauté, pour mieux faire connaître Smalltalk, un langage assez sympa pour coder ce genre de choses, et aussi pour donner des exemples sur le fonctionnement de VisualWorks, en français, ce qui est assez rare j’ai l’impression. A priori, je compte partager tout le code ici, y compris l’executable final, sous une licence à déterminer mais gratuite.

A l’heure actuelle, je code la GUI, l’architecture du programme est définie, le prochain billet sur ce projet sera un diagramme descriptif du projet.

Wu_Wei