Jeu

La plupart des règles de tCHu ont été décrites dans les étapes précédentes mais sont résumées ici afin de vous en donner une vue d'ensemble.

La classe Game du paquetage ch.epfl.tchu.game, publique, finale et non instanciable, représente une partie de tCHu. Elle n'offre qu'une seule méthode publique et bien entendu statique :

• void play(Map<PlayerId, Player> players, Map<PlayerId, String> playerNames, SortedBag<Ticket> tickets, Random rng), qui fait jouer une partie de tCHu aux joueurs donnés, dont les noms figurent dans la table playerNames ; les billets disponibles pour cette partie sont ceux de tickets, et le générateur aléatoire rng est utilisé pour créer l'état initial du jeu et pour mélanger les cartes de la défausse pour en faire une nouvelle pioche quand cela est nécessaire ; lève IllegalArgumentException si l'une des deux tables associatives a une taille différente de 2.

Pour faire jouer une partie aux joueurs, la méthode play doit appeler les différentes méthodes de chacun des deux joueurs afin de savoir comment ils désirent jouer. Ces méthodes sont bien entendu celles de l'interface Player décrite à l'étape précédente.

Pour le début de la partie, les méthodes suivantes doivent être appelées, dans l'ordre donné :

• avant le véritable début de la partie, la méthode initPlayers de chaque joueur doit être appelée afin de lui communiquer sa propre identité, et le nom de chaque joueur — le sien inclus,
• une fois que le joueur qui jouera en premier a été tiré au hasard, la méthode receiveInfo doit être appelée afin de communiquer cette information à tous les joueurs, en lui passant la chaîne produite par la méthode willPlayFirst de la classe Info,
• la méthode setInitialTicketChoice de chaque joueur doit être appelée pour lui communiquer les billets qu'il reçoit initialement,
• la méthode chooseInitialTickets de chaque joueur doit être appelée pour savoir quels billets chaque joueur a décidé de garder,
• la méthode receiveInfo de chaque joueur doit être appelée pour communiquer à chacun le nombre de billets gardés par chaque joueur ; cette chaîne est produite par la méthode keptTickets de Info.

La partie commence ensuite. Jusqu'à sa fin, chaque joueur doit jouer à tour de rôle, et pour ce faire, la méthode play appelle les méthodes suivantes du joueur courant, dans l'ordre donné :

• la méthode nextTurn est appelée pour savoir quelle action le joueur courant désire effectuer parmi les trois possibles,
• si le joueur courant désire tirer des billets, alors :
  • la méthode chooseTickets est appelée afin de déterminer quels billets il garde parmi ceux tirés,
• si le joueur courant désire tirer des cartes, alors :
  • la méthode drawSlot est appelée une première fois pour savoir quelle carte il désire tirer en premier,
  • la méthode drawSlot est appelée une seconde fois pour savoir quelle carte il désire tirer en second,
• si le joueur courant désire (tenter de) s'emparer d'une route, alors :
  • la méthode claimedRoute est appelée pour déterminer de quelle route il s'agit,
  • la méthode initialClaimCards est appelée pour déterminer les cartes (initiales) à utiliser,
  • si la route est en tunnel, que les trois cartes du sommet de la pioche impliquent l'utilisation d'au moins une carte additionnelle, et que le joueur courant a dans sa main les cartes additionnelles nécessaires, alors :
    • la méthode chooseAdditionalCards est appelée pour déterminer s'il désire jouer des cartes additionnelles, et si oui, lesquelles.

De plus, la méthode receiveInfo de l'interface Player doit être appelée régulièrement pour informer les deux joueurs du déroulement de la partie. L'argument à passer à cette méthode est toujours obtenu au moyen d'une des méthodes de la classe Info, qui devrait être claire en fonction du contexte. À noter qu'il est nécessaire de créer une instance de cette classe par joueur, puisque son constructeur prend en argument le nom du joueur pour lequel les informations doivent être produites.

La méthode receiveInfo doit être appelée :

• (comme dit plus haut) dès que l'identité du premier joueur est connue — et avant de dire aux joueurs quels sont leurs cinq billets initiaux,
• (comme dit plus haut) dès que les joueurs ont choisi le nombre de billets qu'ils gardent initialement — mais seulement lorsque tous les joueurs ont fait leur choix, afin de ne pas donner un avantage au joueur choisissant en dernier,
• lorsque le tour d'un joueur commence,
• lorsqu'un joueur tire des billets,
• lorsqu'un joueur a choisi de garder un certain nombre de billets,
• lorsqu'un joueur tire une carte de la pioche ou une carte face visible,
• lorsqu'un joueur s'est emparé d'une route, en communiquant toutes les cartes utilisées — initiales et additionnelles dans le cas d'un tunnel,
• lorsqu'un joueur tente de s'emparer d'un tunnel,
• lorsqu'un joueur tente de s'emparer d'un tunnel et que les trois cartes du sommet de la pioche déterminant le nombre de cartes additionnelles à jouer ont été tirées,
• lorsqu'un joueur ne peut ou ne veut jouer les cartes additionnelles nécessaires pour s'emparer d'un tunnel,
• lorsque le dernier tour commence,
• lorsqu'un joueur obtient le bonus pour le plus long chemin,
• lorsqu'un joueur remporte la victoire, ou lorsque les deux joueurs sont ex æquo.

Finalement, la méthode updateState de chacun des deux joueurs doit être appelée régulièrement afin de leur communiquer les changements d'état de la partie. Cette méthode pourrait être appelée à chaque changement d'état, mais l'appeler dans les cas suivants suffit :

• juste avant d'appeler la méthode chooseInitialTickets pour demander aux joueurs de choisir leurs billets initiaux, afin qu'ils puissent faire ce choix en connaissant l'état actuel de la partie — en particulier les cartes initiales qui leur ont été distribuées,
• juste avant d'appeler la méthode nextTurn pour demander au joueur courant de choisir l'action qu'il désire effectuer, afin qu'il puisse faire ce choix en connaissant l'état actuel de la partie,
• juste avant d'appeler drawSlot pour la seconde fois lorsqu'un joueur tire des cartes, afin qu'il sache p.ex. quelle carte a remplacé la carte face visible qu'il a éventuellement tirée en premier,
• juste avant d'informer les joueurs du résultat final de la partie, afin qu'ils connaissent l'état dans lequel la partie s'est effectivement terminé.

Ces appels à updateState provoqueront la mise à jour de l'interface graphique lorsque celle-ci sera écrite, et il est donc important qu'ils soient faits au bon moment.

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