Ce projet à réaliser par binômes (de deux personnes!) et à rendre dans les conditions précisément décrites à la fin de ce document.

Ce projet a pour but de programmer un jeu de "nibbler" en réseau pour plusieurs utilisateurs, sur un modèle client-serveur. Chaque client peut entrer en communication avec le serveur pour établir une session par laquelle il va recevoir les informations nécessaires à la visualisation d'une zone de jeu (plateau). Cette zone (quadrillage, échiquier) est constituée de plusieurs éléments visualisés de manières distinctes:

• les "cases vides", où chaque serpent peut librement se déplacer;
• les "serpents": chaque serpent (celui du client et ceux des autres joueurs) est constitué d'un ensemble de cases contigues, de la tête à la queue). Initialement, un serpent est constitué d'une seule case (la tête). Chaque client devra pouvoir distinguer son serpent de ceux des autres.
• les "miams": lorsque la tête d'un serpent se déplace pour venir occuper une case "miam", il "grandit" (s'allonge) d'une case. Toute variante (optionnelle) peut être envisagée, pour créer des "miams" de valeurs différentes, des "miams" empoisonnés, etc.

Outre d'éventuelles informations initiales de configuration, des commandes de contrôle éventuelles au cours du jeu et des commandes liées à des variantes optionnelles de ce jeu, chaque client se contente de donner des ordres simples de déplacement pour que "son" serpent se déplace à gauche, à droite, en haut ou en bas. En fonction de ces commandes, et de celles de chacun des clients, le serveur doit centraliser les mouvements de chaque serpent et en informer chacun des clients pour rafraîchir leur zone de jeu.

L'objectif de ce jeu, pour chacun des clients, est de faire évoluer son serpent dans la zone de jeu de sorte qu'il consomme un maximum de "miams", pour devenir le plus long possible. Le serpent le plus long encore en vie sur la zone de jeu lorsqu'il n'y a plus de miams est le gagnant. En revanche, un serpent meurt immédiatement s'il se déplace sur une case contenant déjà un "bout" de serpent (que ce soit un bout du même serpent ou d'un autre). Pour les "sorties" de la zone de jeu par un bord, on pourra soit considérer qu'elle est fatale au serpent, soit qu'elle aboutit à une "entrée" à l'opposé de la zone de jeu (qu'on considère alors circulaire).

La principale problématique de ce projet est le choix du ou des protocoles réseaux à utiliser, et éventuellement à définir. En effet, on devra se poser la question de l'utilisation de TCP ou d'UDP dans l'implantation de NetSnake, en prenant en compte la fiabilité par rapport à la charge réseau occasionnée. On pourra également réfléchir à l'utilisation de groupe de diffusion avec du multicast UDP. Néanmoins, la vitesse de traitement de chaque ordre de déplacement et le rafraîchissement, ainsi qu'une certaine équité d'accès au serveur entre les différents clients doivent être considérés. En particulier, on pourra réfléchir au problème de l'ordre dans lequel les commandes sont émises par rapport à l'ordre dans lequel elles sont traitées.

Pour ce qui est des informations qui transitent entre le serveur et chaque client, un format et un protocole devra être établi. Ces derniers pourront varier en fonction du type d'information: rafraîchissement d'écran, ordre de déplacement, configuration d'un client, mort d'un serpent, etc.

La partie visuelle de l'application sur le client est accessoire. Même si elle peut avantageusement être réalisée en Java AWT/Swing, il ne faut pas perdre de vue que ce n'est pas le coeur de ce projet. Restez simples et n'y passez pas trop de temps.

Il vous est demandé de fournir votre travail sous la forme d'une archive compressée au format ZIP, par mail, à Etienne.Duris[at]univ-mlv.fr, au plus tard le dimanche 2 mars 2003 (date ferme et définitive). Cette archive compressée devra contenir de manière très distincte les quatres parties indépendantes suivantes:

• un rapport très succinct qui décrit et justifie vos choix dans les protocoles de communication utilisés et le format des données échangées entre clients et serveur. On pourra évoquer les défauts et les limitations de ces choix. Ce rapport devra être au format HTML;
• les programmes, nécessaires à l'exécution du serveur et des clients, sous la forme de deux archives Java (jar) exécutables indépendantes (idéalement de noms NetSnakeServer.jar et NetSnakeClient.jar). Chacun de ces programmes exécutables disposera d'une option -help décrivant les différents arguments éventuels acceptés ou attendus;
• les programmes sources Java correspondant à ces programmes. La programmation devra respecter au mieux les paradigmes de la programmation orientée objet;
• la documentation de ces sources au format Javadoc.

Etienne.Duris[at]univ-mlv.fr Remi.Forax[at]univ-mlv.fr Laurent.Marsan[at]univ-mlv.fr - © Université de Marne-La-Vallée - Janvier 2003