État d'une partie

L'interface PointsObserver du paquetage principal, publique, représente un « observateur de points », c.-à-d. un objet qui est informé chaque fois que les points d'un joueur changent. Chacune des méthodes de cette interface correspond donc à une situation dans laquelle un joueur peut gagner ou perdre des points, et elle est destinée à être appelée lorsque cela se produit effectivement.

Toutes les méthodes de PointsObserver sont des méthodes par défaut, qui ne font rien du tout, c.-à-d. que leur corps est vide. De la sorte, lorsque cette interface est implémentée par un objet, celui-ci peut simplement ne pas redéfinir certaines méthodes s'il n'est pas intéressé par certains types de gain ou perte de points.

Les méthodes de PointsObserver sont :

void newWallTile(PlayerId playerId, TileDestination.Pattern line, TileKind.Colored color, int points)

qui est destinée à être appelée lorsque le joueur d'identité playerId a ajouté à la ligne line de son mur une tuile de couleur color et remporté ainsi points points,

void floor(PlayerId playerId, int penalty)

qui est destinée à être appelée à la fin d'une manche lorsque le joueur d'identité playerId a perdu penalty (> 0) points en raison de la présence de tuiles sur sa ligne plancher,

void fullRow(PlayerId playerId, TileDestination.Pattern line, int points)

qui est destinée à être appelée à la fin de la partie lorsque le joueur d'identité playerId a gagné points (= 2) points de bonus car la ligne line de son mur est complète,

void fullColumn(PlayerId playerId, int column, int points)

qui est similaire à fullRow mais pour une colonne pleine,

void fullColor(PlayerId playerId, TileKind.Colored color, int points)

qui est similaire à fullRow mais pour une couleur pleine.

En plus de ces méthodes, PointsObserver offre l'attribut suivant :

PointsObserver EMPTY

qui est un observateur de points vide, c.-à-d. qu'aucune de ses méthodes ne fait quoi que ce soit.

Cet observateur vide est principalement destiné à être utilisé par l'intelligence artificielle, qui simulera un très grand nombre de parties sans être intéressée par la manière exacte dont les joueurs gagnent ou perdent des points. L'interface graphique du jeu utilisera quant à elle un observateur non vide qui affichera, directement sur le plateau des différents joueurs, les points qu'ils auront obtenus de différentes manières.

La classe MutableGameState du sous-paquetage gamestate, publique et finale, représente un état de partie non immuable. Elle implémente bien entendu l'interface ReadOnlyGameState.

MutableGameState offre deux constructeurs publics :

MutableGameState(ReadOnlyGameState initialState, PointsObserver pointsObserver)

le constructeur principal, qui retourne un nouvel état de partie ayant le même contenu que initialState, et auquel l'observateur pointsObserver est attaché — dans le sens où ses méthodes seront appelées lorsque les points d'un joueur changeront,

MutableGameState(ReadOnlyGameState initialState)

un constructeur secondaire qui appelle le premier en lui passant l'état initial initialState et un observateur de points vide.

De plus, MutableGameState offre des mises en œuvre concrètes des méthodes abstraites de ReadOnlyGameState, à savoir game, pkTileBag, pkTileSources, pkUniqueTileSources, pkPlayerStates et currentPlayerId. Notez que ces méthodes doivent être de simples méthodes d'accès, et ne doivent faire aucun calcul ! En particulier, pkUniqueTileSources ne doit rien faire d'autre que retourner la valeur d'un attribut privé, qui est gardé à jour par toutes les méthodes qui modifient le contenu des sources de tuiles.

À ces mises en œuvre concrètes des méthodes de ReadOnlyGameState, MutableGameState ajoute les méthodes publiques suivantes :

void fillFactories(RandomGenerator randomGenerator)

qui remplit les fabriques au moyen de la technique décrite à la §2.1.1, en utilisant randomGenerator pour obtenir les éventuelles valeurs aléatoires nécessaires,

void registerMove(short pkMove)

qui modifie l'état de la partie pour tenir compte du fait que le joueur courant a joué le coup (empaqueté) pkMove,

void endRound()

qui termine la manche en mettant à jour les lignes de motif, les murs et les lignes plancher de tous les joueurs, et en comptabilisant les points de fin de manche de tous les joueurs,

void endGame()

qui termine la partie en comptabilisant les points bonus de tous les joueurs.

Notez bien que les méthodes endRound et endGame, qui comptabilisent les points, doivent obligatoirement appeler les méthodes de l'observateur de points passé au constructeur lorsqu'elles ajoutent ou suppriment des points à un joueur.

Comme d'habitude, nous ne vous fournissons plus de tests mais un fichier de vérification de signatures à importer dans votre projet.

En dehors des tests JUnit, vous avez à présent la possibilité d'écrire un programme relativement simple vous permettant de jouer à Ajul entre plusieurs joueurs humains, au moyen d'une interface textuelle qui pourrait ressembler à ceci :

Fabriques : [1] A C DD    [2] A C D E   [3] A B C D
            [4] BB C D    [5] A BB C
   Centre : [0] 1

 Aline     . abcde | Bertrand  . abcde
 0 pts    .. eabcd | 0 pts    .. eabcd
         ... deabc |         ... deabc
        .... cdeab |        .... cdeab
       ..... bcdea |       ..... bcdea
                   |
 Pté 1 1 2 2 2 3 3 | Pté 1 1 2 2 2 3 3
                   |

Quel coup désirez-vous jouer, Aline ?

En plus d'afficher à l'écran l'état du jeu, votre programme doit demander au joueur courant le coup qu'il désire jouer, afin de faire évoluer l'état de la partie en fonction. Pour cela, il est utile d'avoir une représentation compacte d'un coup, et nous vous suggérons d'en utiliser une composée de trois caractères, qui sont :

1. l'index de la source (0 pour la zone centrale, 1 pour la première fabrique, etc.),
2. la lettre de la couleur des tuiles à jouer,
3. l'index modifié de la destination, où 0 désigne la ligne plancher, 1 la première ligne de motif, 2 la seconde, et ainsi de suite — cet index modifié étant probablement plus intuitif que celui utilisé en interne par notre programme.

Dans l'exemple ci-dessus, le coup consistant à prendre les 2 tuiles de couleur B de la fabrique 4 pour les placer sur la seconde ligne de motif s'écrirait donc 4B2.

La classe AjulTUI ci-dessous — TUI étant l'acronyme de textual user interface — constitue une ébauche d'un programme permettant de jouer à Ajul via une interface textuelle. Même si cela n'est bien entendu pas obligatoire, nous vous conseillons de la compléter afin de pouvoir jouer à votre jeu dès à présent. Vous pourrez ainsi tester votre projet de manière agréable et ludique, et jouer contre l'intelligence artificielle dès que vous l'aurez développée.

public final class AjulTUI {
  static void printState(ReadOnlyGameState gameState) {
    // à faire : imprimer l'état du jeu à l'écran
  }

  static Move queryNextMove(String playerName,
                            ReadOnlyGameState gameState) {
    // à faire : demander au joueur le coup qu'il désire jouer
  }

  // à faire : autres méthodes

  static void main() {
    RandomGenerator randomGenerator = /* à faire */;
    List<Game.PlayerDescription> playerInfos = /* à faire */;
    Map<PlayerId, String> playerNames = /* à faire */;
    Game game = new Game(playerInfos);

    MutableGameState gameState =
      new MutableGameState(ImmutableGameState.initial(game));
    gameState.fillFactories(randomGenerator);
    while (!gameState.isGameOver()) {
      printState(gameState);
      String playerName = playerNames
        .get(gameState.currentPlayerId());
      Move move = queryNextMove(playerName, gameState);
      gameState.registerMove(move.packed());
      if (gameState.isRoundOver()) {
        gameState.endRound();
        if (!gameState.isGameOver())
          gameState.fillFactories(randomGenerator);
      }
    }
    gameState.endGame();

    printState(gameState);
    print("Partie terminée ! Scores finaux :\n");
    // à faire : afficher les scores
  }
}