Programmes principaux
Javass – étape 11

1.1.1 Configuration

s h:Marie r:Céline:128.178.243.14 s::20000

1.1.2 Paramètres fixes

1.1.3 Gestion des erreurs

Utilisation: java ch.epfl.javass.LocalMain <j1>…<j4> [<graine>]
où :
<jn> spécifie le joueur n, ainsi:
  h:<nom>  un joueur humain nommé <nom>
…

bla bli blo blu

Erreur : spécification de joueur invalide : bla

2.1.1 Conseils de programmation

1. Arguments du programme
   

   Pour accéder aux arguments passés au programme depuis la méthode start, il faut utiliser la méthode getParameters() de Application, puis appeler getRaw() sur le résultat afin d'obtenir une liste de chaînes de caractères.

2. Gestion des erreurs
   

   Pour transformer une chaîne de caractères en un entier int, vous pouvez utiliser la méthode parseInt de la classe Integer. Notez qu'elle lève l'exception NumberFormatException si la chaîne ne représente pas un entier int valide, exception qu'il vous faut donc rattraper afin d'afficher un message d'erreur.

   Pour l'entier long représentant la graine, vous pouvez utiliser de la même manière la méthode parseLong de la classe Long.

   Lorsqu'une erreur de connexion au serveur se produit, le constructeur de votre classe RemotePlayerClient devrait lever l'exception IOException (indirectement, car en réalité c'est le constructeur de Socket qui la lève), qu'il vous faut également rattraper pour afficher un message d'erreur.

   Les autres erreurs ne sont pas signalées au moyen d'exceptions, il vous faut donc les détecter vous-même, et afficher un message d'erreur au besoin.

   Dans tous les cas, les messages d'erreurs doivent être affichés sur le flot System.err et pas System.out. En effet, le flot System.err est dédié aux messages d'erreur.

   De plus, lorsqu'une erreur est détectée, le programme doit se terminer immédiatement, ce qui peut se faire en appelant la méthode exit de la classe System, en lui passant 1 en argument. Cet argument est le code de retour du programme, et toute valeur différente de 0 indique par convention que le programme s'est terminé anormalement.

3. Graines de générateurs aléatoires
   

   Pour faciliter les tests, le programme principal permettant de jouer une partie locale prend un argument optionnel, qui représente une graine de générateur aléatoire.

   Le but de cette graine est d'être utilisée pour initialiser un générateur aléatoire principal, utilisé ensuite pour obtenir les graines des autres générateurs aléatoires du projet.

   Si l'argument optionnel représentant la graine est fourni au programme principal, alors le générateur aléatoire principal doit être obtenu en passant cette graine au constructeur de Random prenant une graine en argument. Par contre, si cet argument n'est pas fourni, alors le générateur aléatoire principal doit être obtenu au moyen du constructeur de Random ne prenant aucun argument, ce qui implique que sa graine sera aléatoire.

   Une fois construit, le générateur aléatoire principal doit être utilisé pour générer exactement 5 valeurs de type long, qui doivent être passées (dans l'ordre) :

   1. au constructeur de JassGame,
   2. au constructeur du joueur 1 (PLAYER_1) ssi il s'agit d'un joueur simulé,
   3. au constructeur du joueur 2 (PLAYER_2) ssi il s'agit d'un joueur simulé,
   4. au constructeur du joueur 3 (PLAYER_3) ssi il s'agit d'un joueur simulé,
   5. au constructeur du joueur 4 (PLAYER_4) ssi il s'agit d'un joueur simulé.

   On garantit ainsi qu'en passant la même graine au programme, on obtienne toujours la même partie. D'autre part, étant donné que la manière dont JassGame utilise la graine qu'on lui passe pour choisir l'atout et mélanger les cartes a été clairement spécifiée à l'étape 5, une graine donnée devrait produire une même distribution des cartes, et un même choix de l'atout pour tous les projets.

4. Ralentissement des joueurs simulés
   

   Pour garantir que les joueurs simulés ne jouent jamais une carte en moins de 2 secondes, il faut bien entendu utiliser la classe PacedPlayer écrite lors de l'étape 5.

5. Fil d'exécution
   

   Comme illustré dans le programme d'exemple donné à la fin de l'étape 10, la partie doit se dérouler dans un fil d'exécution séparé. Afin que l'application se termine correctement, il est nécessaire d'appeler la méthode setDaemon en lui passant true avant de démarrer le fil au moyen de la méthode start. En d'autres termes, le fil doit être créé et démarré ainsi :

   Thread gameThread = new Thread(/* … */);
   gameThread.setDaemon(true);
   gameThread.start();