Projet de programmation réseau en Java
NetSnake
Ingénieurs 2000 - IR - 2ème année
Projet à réaliser en binôme et à rendre
selon les modalités décrites à
la fin de ce document.
L'idée
Ce projet a pour but de concevoir et 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).
L'essentiel (conception et programmation réseau)
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
et/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ées. 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é
-
Le sujet est volontairement succinct. Une partie importante de
votre travail devra être dédiée à la conception du protocole de
communication entre un serveur et ses clients. Cette réflexion
donnera lieu à la rédaction d'un document dans le genre d'une
RFC, qui décrit les modes de fonctionnement et les
protocoles de communication utilisés, sans aborder la partie
implantation. Comme dans une RFC, les descriptions exposées dans
ce document devront être suffisamment précises pour permettre à
toute implantation les respectant d'être compatibles entre
elles. Cependant, elles ne doivent pas rentrer dans les détails
de ce qui est du ressort de l'implantation. Ce "Draft" de
RFC NetSnake devra être rédigé dans un anglais simple, être
disponible au format texte (.txt), et ne pas dépasser
une dizaine de pages. Ce document doit être rendu, par mail, à
Etienne.Duris@univ-mlv.fr,
au plus tard le dimanche 19 février 2006.
-
Il est bien évident que vous devez débuter l'implantation du
client et du serveur avant de rendre le "Draft" de
RFC. Les tests et prototypes vous seront d'une grande aide dans
la rédaction de la spécification. Néanmoins, vous avez deux
semaines après le rendu du "Draft" pour vous consacrer
uniquement à l'implantation de ce qui est décrit dans le
"Draft" rendu. Il vous est demandé de fournir votre
travail sous la forme d'une
archive compressée au format ZIP, par mail, à Etienne.Duris@univ-mlv.fr,
au plus tard le dimanche 5 mars 2006. Cette archive
compressée devra contenir de manière très distincte les quatres
parties indépendantes suivantes :
-
un rapport succinct (au format HTML) qui doit lui-même
contenir :
- une partie 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 ;
- une partie qui sera dédiée à la mesure
des écarts entre les spécifications du "Draft" rendu
et les fonctionnalités implantées dans les programmes
livrés (incohérences, modifications, ajouts, manques,
etc.). Si ces écarts ne sont pas souhaitables (d'où
l'importance d'une bonne réflexion en amont, lors de la
rédaction du "Draft"), ils seront probablement
inévitables dans la pratique : il est alors important
de les identifier et de les justifier ;
-
une partie très synthétique qui liste, jour par jour, du 3
février où vous avez eu le sujet jusqu'au 5 mars où vous
rendez le document, les activités qu'ont eu chacun des
membres du binôme (réflexion sur tel ou tel point du
protocole, conception, codage ou test de telle ou telle
partie, rédaction ou correction de telle ou telle partie du
Draft ou du rapport, etc.). Il est évident que ce
compte-rendu d'activité doit être mis à jour
quotidiennement ;
-
les programmes, nécessaires à l'exécution du serveur et
des clients, sous la forme de deux archives Java
(jar) exécutables indépendantes (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.
- Chaque binôme présentera devant un correcteur son projet
lors d'une soutenance qui aura lieu l'après-midi du 7 mars
2006. Chacun des membres du binôme devra pouvoir répondre à
toute question relative au projet, que ce soit sur les
fonctionnalités décrites dans le "Draft" ou sur
l'implantation.
Etienne.Duris@univ-mlv.fr
Remi.Forax@univ-mlv.fr
Sebastien.Paumier@univ-mlv.fr -
© Université de Marne-La-Vallée - Février 2006