intro - screenshots - architecture et implémentation - mode d'emploi - download - le rapport écrit

Wip est un clone de Dyna Blaster et Bomberman, largement inspiré de X-blast. C'est donc un jeu temps-réel multijoueur orienté réseau, où il faut exploser tous les adversaires à coups de bombes. Chaque joueur est un pingouin, et dispose d'un certain nombre de bombes qu'il peut poser simultanément. Il y a aussi des bonus pour augmenter le nombre et la portée des bombes, etc...
En fait nous avons porté en réseau un jeu que nous avions déjà écrit pour notre projet C++. Pour en savoir plus sur la version 1 joueur, allez voir cette page.

Quelques screenshots:






Architecture et implémentation:

    L'architecture réseau mise en oeuvre suit le modèle client-serveur, avec un serveur unique, et plusieurs clients qui y envoient des requêtes, et en reçoivent les réponses. Le langage utilisé est C++, et chez le serveur comme chez le client, c'est la classe `server' qui s'occupe des communications sur le réseau. On retrouve de chaque côté des classes pour les personnages(classe `hero'), les bombes(classe `bomb'), etc... Mais la classe `server' est différente de chaque côté.

    Côté serveur, elle s'occupe de recevoir les requêtes de chaque client, de les traiter, et de tenir les autres client au courant dans le cas où c'est nécessaire. Le traitement des requêtes passe par plusieurs étapes:

  1. On regarde la première chaîne contenue par le message: si elle ne fait pas partie du protocole, on ignore le message;
  2. On vérifie que le message est au bon format, entre autres on vérifie la signature (unique) du client qui l'envoie.
  3. On met à jour la date de dernière communication avec le client (si cette date devient trop ancienne, il y a timeout, on supprime le client de la partie).
  4. A ce stade le paquet peut être soit de type "goto" (le joueur veut se déplacer), soit de type "drop" (le joueur veut poser une bombe). Si la requête est illégale (par exemple le joueur se déplace trop vite), on supprime le client. Sinon, on modifie le terrain de jeu et on envoie les nouvelles informations à tous les clients.
Si on n'a pas de nouvelles d'un client depuis trop longtemps, on lui envoie un message "ping" plusieurs fois. S'il ne répond toujours pas, on finit par le supprimer de la partie. Ce mécanisme ne bloque pas le jeu, car on vérifie les délais à chaque boucle de jeu (il y en a plusieurs centaines par seconde).


    Côté client, la classe serveur représente un niveau d'abstraction par rapport au réseau: c'est cette classe qui va envoyer toutes les requêtes qui passent par le réseau au serveur, et qui va traiter les messages reçus.
Le traitement des requêtes côté client passe également par plusieurs étapes, mais, contrairement au serveur, à aucun moment le client ne prendra de décision, il fera ce qui est indiqué dans le message, si celui-ci fait partie du protocole.
Les étapes:

  1. On regarde la première chaîne contenue dans le message: si elle ne fait pas partie du protocole, on l'ignore.
  2. Dans le cas d'un paquet all_p, on vérifie également que le paquet n'est pas périmé, grâce à son numéro.
  3. à ce stade, la requête est correcte et on exécute ce qu'elle nous dit de faire




Pour exécuter...

    Une fois le fichier wip.tar.gz décompressé, un répertoire est créé, de nom "wip"; dedans se trouvent un répertoire "wip_client" et un répertoire "wip_server". Taper "make" dans ce répertoire a pour effet de compiler le client et le serveur, chacun dans leur répertoire. Vous pouvez aussi les récupérer séparément, et taper "make" dans chacun des répertoires. Le répertoire wip_client contient un exécutable "wip_client", et le répertoire wip_server contient "wip_server".




Les fichiers nécessaires:



Le rapport écrit:

    Le voici au format postscript, écrit avec LaTeX.




Remerciements à Wizard et JoLeFou pour leur patience lors des tests :-)


intro - screenshots - architecture et implémentation - mode d'emploi - download - le rapport écrit