Vincent Brévart
Vincent Brévart

Accueil

Maladie de Huntington

Logiciels
Belote

Bridge

Président

Whist

Hors Windows
Mac OS X

Linux

Informations utiles
Règles du jeu

Questions fréquentes

Battage des cartes

Coin Animateurs

Haut de la page

 

  Questions fréquentes

  Sommaire / Comment les joueurs machine prennent-ils leurs décisions ?

Page précédente  Page suivante
Comment les joueurs machine prennent-ils leurs décisions ?
__________
Bas de la page

Vaste question, mais qui normalement devrait vous intéresser et vous aider à abandonner ces idées de tricherie des joueurs, de distributions favorisant Est et Ouest, et que sais-je encore. Si vous comprenez un peu comment depuis plus de dix ans, avec l'aide des internautes, j'essaie d'améliorer le moteur de jeu; si vous ressentez ne serait-ce qu'un instant, la passion et l'intérêt qui m'animent dans la construction d'un jeu de bon niveau; si vous pouvez plus ou moins imaginer comment le programme est écrit et comment la réflexion des joueurs machine se bâtit au fil des années, alors vous aurez peut-être davantage de respect pour le travail accompli, et plus d'indulgence pour tous les défauts qui restent encore à corriger.

Je tiens à rendre hommage à tous les joueurs passionnés qui m'ont aidé depuis la sortie de Bel Atout. Avec patience, humour, gentillesse et intelligence, ils n'ont jamais cessé de m'envoyer leurs donnes, de me signaler les multiples fautes qu'ils trouvaient au cours de leurs parties, de me proposer leurs analyses éclairées et de m'encourager dans mes efforts d'amélioration. Vous pouvez d'ailleurs voir une grande partie des donnes qu'ils m'ont permis de corriger par le menu Exemples. Qu'ils en soient ici chaleureusement remerciés.

Quelques mots sur l'activité de programmation

S'il est une activité obscure pour le néophyte, c'est bien la programmation. Mais comment écrit-on un programme ? Et comment fait-on pour faire jouer les joueurs machine, et les faire progresser ? L'écriture d'un programme est relativement simple. Ce sont des lignes de texte, qui ensuite sont lues par un logiciel appelé compilateur, qui traduit ce texte en un fichier exécutable, les fichiers .exe que vous connaissez sûrement, comme belatout.exe. Le programmeur n'a qu'une chose à faire : écrire le texte du programme. Voici un petit exemple de 10 lignes tirées de Bel Atout :

int NombreCartesConnues(int vue, int fiable, int joueur, int couleur)
{
   int(*pAppart)[NombreHauteursDeCarte];
   int hauteur, nbrcar;

   if(VisionMaxCartesParCouleur[vue][fiable][joueur][couleur] == 0)
      return 0;       // sortie rapide car pas de carte

   pAppart = &VisionAppartenanceCarte[vue][fiable][couleur];
   nbrcar = 0;

   for(hauteur = ValetAtout; hauteur >= Sept; hauteur--)
      if(bAppartenanceJoueurSure(pAppart, hauteur, joueur))
         nbrcar++;

   return nbrcar;
}

Cet exemple montre une petite fonction, qui comme son nom (en violet) l'indique, calcule le nombre de cartes connues d'un joueur dans une couleur. Même si vous n'y connaissez rien en programmation, vous pouvez comprendre que les lignes en rouge vont regarder depuis la hauteur ValetAtout à la hauteur Sept quelles sont les cartes qui appartiennent de façon sûre au joueur. A chaque fois qu'on en trouve une, on augmente la variable nbrcar. Et à la fin, par le mot return, on retourne le total trouvé. Rien de sorcier dans une fonction de ce type. Et tout est plus ou moins comme cela. La seule difficulté, c'est que dans Bel Atout il y a maintenant plus d'un million de lignes comme celles-ci. Ça ne s'écrit pas en 5 minutes. Et surtout pas sans erreur...

En bleu, je vous signale les variables de vision. Ce sont des mémoires où sont indiquées par exemple le nombre maximum de cartes d'un joueur dans une couleur, selon une valeur de fiabilité et une vue (la vue par Tous, ou la vue du joueur en main). Ces variables de vision ne sont pas les mêmes que les variables dites d'interface. En gros, on comprend ici que la fonction ne triche pas. Elle ne va pas compter les cartes à partir de la mémoire de l'interface, qui connaît toutes les cartes, bien sûr. Mais elle va les compter à partir de variables actualisées par un module de stratégie, au cours d'une des parties les plus importantes du programme : la reconstitution des mains cachées.

Haut de la page
La reconstitution des mains cachées

Grossièrement, un joueur machine va se servir de trois variables pour prendre sa décision :

VisionMinCartesParCouleur
VisionMaxCartesParCouleur
VisionAppartenanceCarte

On comprend, par le nom de ces trois variables, qu'il s'agit du minimum et maximum de cartes des différents joueurs dans les quatre couleurs, et des appartenances de cartes. Ces dernières peuvent être soit connues (le joueur sait à qui appartient ou a appartenu la carte), soit inconnues (le joueur ne sait rien sur la carte), soit inconnues avec des non appartenances (par exemple, le joueur ne sait pas où est placée la carte, mais il sait qu'elle n'est pas en Ouest). Et toutes ces informations, il doit les avoir avec trois degrés de fiabilité : 100%, 90% et 70%.

Bien sûr, ces informations, il faut les analyser. C'est le rôle du module de reconstitution des mains cachées, qui a la charge d'analyser les enchères, les annonces et les cartes jouées précédemment pour en tirer le maximum d'informations.

Les joueurs machine ne gardent aucune mémoire de ce qu'ils ont analysé au tour précédent. Ils repartent de zéro à chaque fois que c'est à eux de jouer. C'est obligatoire pour permettre de remonter de coup en coup ou de pli en pli, ainsi que pour présenter une donne directement sur un coup d'enchère ou de carte. La seule liste des enchères faites, des annonces faites et des cartes jouées doit leur suffire pour tout reconstituer ce qui s'est passé et avoir la vision des mains la plus juste possible.

Haut de la page
L'analyse des critères

Une fois que le joueur a reconstitué les mains cachées, il va se servir de cette vision des mains pour analyser certains critères d'un niveau plus élevé que les simples variables de vision. C'est ce que fait aussi un joueur humain. Par exemple, si dans une couleur nous avons As-10-Roi, nous analysons d'un seul coup d'œil, sans presque nous en rendre compte, que nous avons 3 levées sûres dans cette couleur (si l'adversaire ne coupe pas). Pour un joueur machine, par contre, ce n'est pas aussi immédiat. Pour avoir la même analyse, il lui faut plusieurs critères sur cette couleur :

  • le nombre de cartes adverses au dessus de sa carte la plus forte
    (pour savoir si sa couleur est maîtresse).

  • Le nombre de cartes en séquence sur la plus forte
    (pour avoir le nombre de levées dans la couleur)

Certains critères seront beaucoup plus difficiles à analyser, comme ceux pour décider de jouer atout ou chercher à affranchir une couleur. Il y aura aussi les critères de tenue dans les différentes couleurs, les risques de coupe, les situations d'appel, les cartes de communication, les critères de fin de coup, et plein d'autres choses encore. Il y a dans Bel Atout plus de 300 critères différents pour le jeu de la carte. Soit autant de sources d'erreur...

Haut de la page
La prise de décision

Dernière étape de la réflexion d'un joueur machine : la prise de décision. La vision des mains est bien en place, les critères sont tous analysés, il est temps maintenant de choisir une carte ou une enchère.

Le moteur de jeu utilise des tables de règles pour prendre ses décisions. Ces tables contiennent des règles (en moyenne une dizaine par table) qui regroupent un ensemble de conditions écrites plus ou moins dans un langage naturel. Sans entrer dans les détails, une règle se présente un peu de cette façon :

Règle n°1 : relancer maître sans risque de coupe

Conditions
la couleur n'est pas l'atout
la couleur est maîtresse
la plus forte est en séquence de 3 au moins
l'adversaire n'a plus d'atout

Explication : relancer dans une couleur maîtresse
Préférences : la couleur avec le plus de levées sûres
              la carte la plus forte

Le principe est très simple. Ce que j'appelle les fonctions de filtrage passent en revue les règles les unes après les autres pour les différentes cartes (ou enchères), et ne s'arrêtent que si une règle s'est déclenchée. Dans ce cas, le moteur retrouve la carte (ou enchère) qui a déclenché la règle, et la décision est alors validée.

Haut de la page
Comment les joueurs machine progressent-ils ?

Supposons qu'un utilisateur m'envoie une donne avec une situation dans laquelle un joueur machine a oublié de couper gros. Je vérifie d'abord que le joueur devait effectivement couper gros, relativement à sa main et à sa vision des mains cachées. Puis, si la décision se confirme, je regarde la table de règles qui concerne cette technique, pour comprendre pourquoi aucune règle déjà écrite ne s'est déclenchée. S'il s'agit d'une condition un peu trop forte, je l'affaiblis en baissant telle ou telle valeur, ou j'ajoute une condition avec un OU, comme dans l'exemple ci-dessous :

l'adversaire n'a plus d'atout
OU
j'ai assez d'atouts pour couper et faire tomber ensuite tous les atouts adverses

Si finalement aucune règle ne convient à la situation montrée par la donne, c'est qu'il faut ajouter une nouvelle règle à la table. Il faudra peut-être analyser de nouveaux critères, si la situation le demande. Et si la situation de jeu semble concerner une technique très particulière, je définirai une nouvelle table, qui s'occupera précisément des décisions liées à cette technique de jeu.

Haut de la page
Comment la stabilité du moteur est-elle assurée ?

Toutes les donnes corrigées sont regroupées dans des fichiers de test, classés par situations de jeu et techniques diverses. Pour le jeu de la carte, j'ai plus de 600 fichiers de test, et pour les enchères, plus de 300 (chaque fichier contenant une moyenne de 20 donnes environ). Après chaque modification d'une règle, je lance une fonction de vérification sur tous les fichiers de test qui sont concernés. Dans un fichier de test pour le jeu de la carte, chaque donne est mémorisée sur une position de jeu précise, et s'accompagne d'un commentaire indiquant quelle carte jouer à ce moment-là. Par exemple :

  • AC : il faut jouer l'As de Cœur ici, car... etc.

  • 8T : petit Trèfle vers le partenaire, pour... etc.

  • #K : surtout pas Carreau dans cette situation, car... etc.

Le module de vérification peut donc vérifier qu'aucune des donnes de test n'a varié dans son choix de carte ou d'enchère à la suite de la modification que je viens de faire. Si une donne a changé de choix, je vérifie que le nouveau est acceptable. Et s'il ne l'est pas, il me faut corriger la règle que je viens de modifier.

Un module de jeu automatique me permet aussi de lancer le jeu automatique (parfois pendant toute une nuit) et récupérer toutes les donnes où une règle précise s'est déclenchée. Je garde ensuite les donnes les plus intéressantes et les ajoute aux fichiers de test. Et je vérifie que la règle à tester ne s'est pas déclenchée dans des situations inappropriées, ce qui arrive souvent si elle n'est pas bien écrite.

Haut de la page
Mon journal des versions

Je tiens à jour un journal des versions de Bel Atout, où chaque modification est reportée, avec si besoin un justificatif détaillé. En cas de problème sur une version (une faute de jeu soudainement apparue), je dois pouvoir retrouver les modifications récentes qui concernent le sujet et qui ont pu générer la faute. On peut passer beaucoup de temps à retrouver la cause d'une faute de jeu parmi les 300 à 400 règles de décision, les 250 fichiers du module stratégique et les quelques 2000 fonctions qu'ils contiennent. Il vaut mieux être bien organisé. Voici un petit extrait de mon journal, correspondant à un après-midi de travail, juste avant la sortie de Bel Atout 5.10 :

A partir de la version 2017

Dans la fonction S_TAPDEF_bCouleurAppelable, il fallait vérifier que la carte peut appartenir au joueur en vision par Tous à 70%. C'est sur cette vision que s'analyse la situation d'appel. Sur la donne TAP4 n°44, Sud voit VC en Ouest à 70% (par Tous), et comme il est d'accord pour recevoir les autres couleurs, il défausse un Cœur, sans faire d'appel. Mais il ne faut pas ensuite qu'Est et surtout Nord traduisent cette première défausse à 90%, empêchant VC d'être donné à Ouest. Donc, un appel à 90% ne peut se faire que si à 70% il serait possible aussi. Voir l'illustration carte en ILL01 n°19. Tests cartes OK.

Dans la table T_DEFSPE_DefausserGros_PourOuvrirCoupe, on a renforcé la règle n°2, en demandant qu'il n'y ait pas qu'une seule carte dehors. Voir la donne DG06 n°9. Tests cartes OK.

Dans la table T_FOUPET_FournirPetit_EnMontant, les préférences de la règle n°2 ont été changées, en demandant, après la plus grande séquence, la carte la plus maîtresse. Voir la donne FP03 n°23 où la règle était bien déclenchée, mais où elle choisissait le 9 de Trèfle. Tests cartes OK. La règle a été retestée en automatique.

Dans la table T_DEFPET_DefausserPetit_SansPerte, la règle n°11 a été assouplie, en acceptant la défausse dans une couleur maîtresse d'une carte non maîtresse, si le joueur a trop de levées de tête par rapport au maximum de levées hors atout. Voir la donne DP01 n°42, où c'est le Roi de Trèfle qui était choisi. Tests cartes OK.

Dans la table T_DEFPET_DefausserPetit_AvecPerteLimitee, ajout d'une règle en position n°18, pour accepter de perdre un arrêt s'il n'y a plus qu'une seule levée hors atout. Dans ce cas, en effet, les arrêts sont inutiles. Voir la donne DP02 n°51. Tests cartes OK.

Dans la fonction S_FOUGRO_bSituationFournirPetitPourDerniereHypothetique, on utilise maintenant la table T_FOGSPE_FournirGros_DerniereHypothetiqueInterdite qui permet d'étoffer un peu plus l'analyse. On préfère interdire la dernière hypothétique (qui dépend des cartes inconnues de Nord) si l'adversaire n'est pas sûr de faire une levée dans la couleur. Voir la donne FGSPE10 n°2 où la dernière hypothétique était déjà bien trouvée. Mais voir aussi la donne FGSPE10 n°5 où elle faisait perdre la donne d'une manière difficile à accepter, puisque le jeu naturel fait gagner. On préfère éviter le jeu sophistiqué dans ces cas-là, qui serait mal compris par un bon nombre d'utilisateurs. Tests cartes OK.

Dans la table T_RELCOU_RelancerPourFaireCouper_EntamePartenaire, on a changé la préférence de la règle n°1. On avait indiqué de repartir petit car "pas d'urgence". Mais en défense, après l'entame du partenaire, il y a au contraire urgence. Voir la donne RC08 n°7. Les donnes RC08 n°3 et 5 ont changé de choix, mais on préfère le nouveau. Tests cartes OK.

Haut de la page
Un travail passionnant

Voilà donc un peu mon quotidien de programmeur de jeux de cartes. Et je dois dire qu'il est très agréable. J'ai travaillé quelque temps sur la résolution systématique, où le moteur de jeu rend son résultat en ayant étudié toutes les possibilités de jeu. C'était beaucoup moins amusant. Alors que le principe des critères et de l'écriture des règles de décision est très épanouissant. Il procure un sentiment de stabilité indispensable au programmeur. Ce qui est fait n'est plus à faire, et ne sera pas détruit par la suite de la construction. Et il offre aussi un potentiel de travail presque illimité. On a l'impression qu'on peut toujours en rajouter. Il y a une faute ici. Ce n'est pas grave, on analyse un nouveau critère, on définit une nouvelle table, de nouvelles règles. Et la faute va être corrigée.

Alors, pas de magie, pas de sorcellerie, et surtout pas de tricherie. Uniquement de l'analyse à partir de nos propres modes de réflexion. C'est cela qui m'intéresse et me passionne. Et qui fait peut-être le succès de Bel Atout, même si le bon jeu n'est pas toujours apprécié de la même manière. En fait, certains voudraient que Nord joue mieux, et qu'Est et Ouest jouent moins bien. Mais ce ne serait pas digne d'un logiciel honnête.

Question suivante :

Pourquoi, en coinchée, faut-il faire +2 que le contrat annoncé ?

  -  Accueil  -  Sommaire  - Haut de la page