WebCheckers
(Fourquet, Mahé, Sofia)
EN RESUME...
L'objectif de ce projet est d'implanter un jeu de dames réseau en Java.
Nous aurions pu réinventer la roue et gérer la répartition de l'application avec des sockets, mais cela n'avait pas un grand intérèt. Nous avons préféré utiliser une bibliothèque qui offre des possibilités plus intéressantes (de type collecticiel).
Cette bibliothèque, qui a gagné la JavaCup dans la catégorie 'Internet/Web Agents', s'appelle Como et utilise un serveur IRC pour les communications inter-joueurs.
Ce serveur IRC doit absolument tourner sur la meme machine que celle ou tourne le serveur http, c'est pour cela que nous avons utilisé le serveur Apache que nous avions installé pendant les TPs du module Internet, ainsi qu'un démon Ircd écrit en Java.
POUR JOUER...
La commlet n'est pas directement accessible, il faut passer par un ComoIRCClient, se loguer sur le serveur irc java, inviter un autre participant (ou soi-meme pour les tests) et clicker sur la dernière icone à droite (en fait celle qui ressemble à un damier ...) (les autres icones sont des exemples fournis avec le produit Como).
WebCheckers est sonorisé. Utilisez de préférence une machine qui a un haut-parleur.
Il est possible que l'un ou les deux serveurs (http et irc) soient indisponibles. Contactez nous dans ce cas.
Ici se trouve le code source.
Et la le répertoire zipe.
Plan du Projet :
ANALYSE ET CONCEPTION
Modèle Objet du jeu de dames
Voici le modele objet (selon le formalisme O.M.T.) de notre jeu de Dames :
Répartition du jeu
L'analyse initiale nous a mené à modéliser le problème en :
Un serveur de sockets
- allouant dynamiquement des sockets de communication sur le Serveur HTTP pour gérer les parties et communications inter-joueurs.
- servant en meme temps de relayeur de messages entre les participants (une thread par partie) puisqu'une communication inter-applets directe est impossible.
Un protocole de jeux
Nous avons choisi lors de la modélisation objet de placer toute l'intelligence du jeu dans les applets.
Chaque applet est derivée de la version non-répartie de l'application ce qui permet de faire évoluer les deux applets des deux participants en leur faisant parvenir uniquement les déplacements de l'adversaire quand celui-ci à la main.
Ainsi, tout les déplacements qui transitent entre les joueurs sont garantis corrects et la détection de terminaison du jeu est détectée séparement par chaque applet.
Les Problèmes de déconnection volontaire ou intempestive nécessitent une gestion particuliere dans ce protocole.
L'intérèt de cette approche est de diminuer les échanges de messages sur le réseau et d'améliorer le temps de réponse du jeu (les calculs se faisant sur la machine de l'utilisateur).
Nous avons choisi au lieu de tout redévelopper nous meme de nous appuyer sur une librarie existante qui offre une partie de ces fonctionnalités.
REALISATION
Application centralisée
Le Jeu en forme non-répartie a été développé tout d'abord.
Partie Graphique :
Le damier est un agrégat de cases, chaque case est un canvas et c'est elle qui gère les événements souris. Quand elle recoit un événement "MOUSE_DOWN", elle produit un nouvel événement qui contient la case elle-meme. C'est le damier qui récupere l'événement produit par la case et le traite. Le damier gère les mouvements, vérifie la validité de ceux-ci et les applique.
Calculs :
Les règles utilisées par notre applet (commlet), ne sont peut etre pas exactement les règles officielles mais elles ont le mérite d'etre cohérentes. Nous sommes partis du principe que tout pion en prise devait etre "mange". C'est à dire que chaque joueur est obligé de manger s'il le peut. L'applet doit donc etre capable de vérifier cela. Voici une liste non-exhaustive des règles que l'applet doit gérer:
Répartition
Como :
Ainsi qu'il a été dit dans le premier paragraphe, nous avons choisi d'effectuer un travail d'intégration plutot qu'un travail de totale réécriture en ce qui concerne la partie répartition du jeu.
Nous avons choisi Como (qui s'appelle maintenant Promondia : voir lien Ici) , une librairie facilitant l'écriture d'applications de type multiparticipants.
Cette librairie a gagné la Java cup catégorie 'Internet/Web Agents' en 1996.
Elle se compose d'un ensemble de packages dont :
- les commlets :
Il s'agit d'applets qui contiennent un objet de type CommObj qui sert d'intermédiaire entre tous les participants à une meme session.
Via cet objet, n'importe quel participant peut envoyer a un autre (si il connait son ID) ou à tous les autres participants, un message prédéfini ou défini par l'application.
Il a meme théoriquement la capacité de faire transiter des instances d'Objets sur le réseau (si ceux si implémentent l'interface Saveable du package Como)
Ce produit antérieur à la version 1.1 du JDK en contient deja certaines fonctionnalités.
Utilisation et Intégration du produit:
Prise en main du produit (docs, exemples)
La documentation de Como est disponible ici.
Le Javadoc de l'A.P.I. est assez complet malgré quelques inexactitudes.
Les classes WindowCommlet et MetaCommlet sont dérivées de la classe Commlet servent de base à l'écriture d'une application multiparticipants distribuée.
Elles contiennent un objet de type ComObj servant d'intermédiaire entre tous les participants. Il sert à propager des messages (classe Msg) prédéfinis ou créés par l'utlisateur. Une ou plusieurs fonctions (dont HandleMsg qui est générique) permet de 'catcher' les message à volonté pour effectuer un traitement. Une des Commlets est maitre du ComObj et a des privilèges par rapport aux autres joueurs connectés.
Les exemples fournis avec le produit (par exemple le WhiteBoard) démontrent le potentiel de cette bibliothèque.
Utilisation
L'applet 'jeu' de Dames' de la version centralisée a été transformée en MetaCommlet. Elle héberge ainsi pour démontrer les possibilités de réutilisabilité d'autres Commlets fournies avec le produit (Players et Superchat) accessibles par le menu View.
Comme indique dans l'analyse, les déplacements de pièces sont les principaux messages échangés entre les deux commlets.
Le tour entre les deux joueurs est un message particulier envoyé par le Maitre du ComObj à chaque fois que nécessaire.
Les problèmes d'initialisation, terminaison et limitation d'accès au deux joueurs concernés ont été résolus (messages prédéfinis a traiter).
Quelques Bugs
Nous avons essayé de transmettre des instances de déplacement (la classe Move de notre Damier) comme argument d'un message en la faisant 'dériver' de l'interface Saveable du package Como.
Sur ce point, la bibliothèque est buggée et nous avons du nous résoudre à transmettre les déplacements sous forme de String.
L'application finale.
Un essai étant plus parlant qu'un long discours : clickez donc Ici.
CONCLUSION
Ce Projet a permis pour deux d'entre nous au moins de faire connaissance avec Java. Le temps d'adaptation a été différent pour chaque binome selon notre origine, mais au final nous avons tous acquis une certaine maitrise de ce langage.
Les modules 'Conception Objet' et 'Conception d'Applications Réparties' que nous avons suivi au premier Terme ont trouvé ici une application pratique démontrant leur intéret. Le travail en équipe nécessaire en conception a été bien mené meme pendant le développement.
Pour terminer, il nous parait important de souligner l'autre facette du monde Objet que nous avons exploré : L'intégration de composants.
En effet, nous avons fait le choix de ne pas réinventer la roue, ce qui n'est pas aussi spectaculaire qu'une réécriture totale d'une librairie de communication, mais qui est un des arguments forts du modèle Objet : La réutilisabilité qui fournit réduction des couts et augmentation de la fiabilité des développements.
Il nous a paru tres important de nous former à ce domaine auquel nous sommes peu préparés.