Projet de programmation réseau

NetSnake

IR 2ième année


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.


L'idée

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:

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).


L'essentiel

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.


L'accessoire

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.


Ce qui est demandé

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:


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