Tutorat système & réseau : jeu graphique en réseau

1  Description générale du projet

1.1  Objectif

L’objectif est de créer un jeu en réseau où vous incarnez un globule de type pacman qui se déplace dans un labyrinthe 3D. Votre but est de chasser et de détruire les autres globules avec vos boules d’énergie.

2  Description des composants du projet

2.1  Architecture générale

Le projet produit deux exécutables, un exécutable serveur dont une seule instance est nécessaire et un exécutable client qui doit être lancé par tous les joueurs.

Le serveur se révèle aux clients par des diffusions, accepte les connexions des clients, permet au client administrateur de lancer le jeu puis traite les datagrammes des clients pour gérer la position des joueurs. C’est aussi le serveur qui envoie régulièrement aux clients les données leur permettant de dessiner ce que voit leur globule. Ces données sont des polygones pleins et des disques triés par profondeur. Dans la phase d’attente des joueurs, le serveur transmet à l’administrateur les pseudos des nouveaux inscrits. Un message confirme au client qu’il vient d’exploser et un message en fin de partie annonce le pseudo du vainqueur.

Le client lancé sur la même machine que le serveur est considéré comme étant l’administrateur. Les clients attendent la diffusion du serveur, demandent aux joueurs leur pseudo et les inscrivent auprès du serveur. Le client administrateur décide de lancer le jeu. Une fois prévenus du lancement du jeu, les clients démarrent une fenêtre graphique (bibliothèque SDL). Les appuis sur les touches de direction et sur la barre espace sont transmis au serveur, les objets graphiques envoyés par le serveur sont dessinés dans la fenêtre graphique. Les messages tapés dans la fenêtre texte sont transmis au serveur qui les transfère aux clients un par un. Ceci permet d’avoir un chat primitif. Certains messages sont interprétés pour déconnecter le client ou arrêter le jeu (dans ce dernier cas, seul l’administrateur en a le pouvoir).

2.2  Utilisation d’UDP et de TCP

UDP est utilisé pour que le serveur puisse se révéler aux clients, pour recevoir les déplacements des globules et pour envoyer les éléments à afficher aux clients.

TCP est utilisé pour l’inscription des joueurs, pour l’envoi de message sur le chat et pour diffuser les divers messages vers les joueurs.

2.3  Affichage des objets

Les murs du labyrinthe sont modélisés par des carrés perpendiculaires au sol y=0 et orientés suivant l’axe des x ou l’axe des z. Les globules sont représentés par une sphère de couleur. Les boules d’énergie sont aussi des sphères plus petites.

C’est le serveur qui va se charger de projeter en 2D les murs du labyrinthe, les globules et les boules d’énergie. Cette projection est réalisée pour chaque joueur en fonction de sa position et de son orientation. L’orientation est prise en compte par une rotation des éléments autour de la position du joueur. Par ailleurs, on utilise une projection de type perspective faible : x′=x/z et y′=y/z en notant (x′,y′) la projection sur l’écran et (x,y,z) les coordonnées en 3D.

Il faut prendre soin d’envoyer aux clients les éléments à afficher (murs, globules, boules) dans l’ordre décroissant de la distance au globule du joueur. Ceci pour que les éléments proches puissent cacher les éléments lointains. Il serait bon de n’envoyer aux clients que les éléments visibles par son globule. Cela nécessiterait de vérifier pour chaque élément s’il est occulté par des éléments plus proches.

Comme la partie graphique n’est pas le coeur du projet le code correspondant est donné. Il est disponible à l’URL http://rex.plil.fr/Enseignement/Systeme/Tutorat.IMA2a4.XMaze/xmazev2.tgz.

3  Précisions

3.1  Organisation modulaire

Il est demandé une arborescence modulaire pour votre projet. Les trois bibliothèques graphique, réseau et flux d’exécution doivent avoir leur propre répertoire ainsi que les deux exécutables, serveur de jeu et client graphique. Le projet doit pouvoir être compilé par la simple commande make tapée dans le répertoire principal du projet. Le Makefile principal doit aussi implanter la cible clean qui permet de nettoyer l’arborescence des fichiers objets, bibliothèques et exécutables.

Les bibliothèques doivent respecter les paradigmes de généricité et d’encapsulation :

• les bibliothèques ne doivent contenir que des objets réutilisables et rien de spécifique au projet courant, cependant un maximum de fonctions génériques doivent se trouver dans les bibliothèques ;
• l’utilisation d’une bibliothèque doit être possible sans tenir compte de son implémentation (pas d’autre include nécessaire que celui du .h de la bibliothèque, pas d’utilisation de type ou de structure utilisés par la bibliothèque et non défini dans son propre .h).

Ainsi, dans votre cas, la bibliothèque réseau doit totalement occulter l’utilisation de la bibliothèque socket, la bibliothèque flux d’exécution doit totalement occulter l’utilisation des pthreads et des pthreads_mutex et, enfin, la bibliothèque graphique doit totalement occulter l’utilisation de la bibiliothèque SDL2.

3.2  Structures de données

Les structures de données sont principalement utilisées par le serveur de jeu. Ce dernier doit stocker :

• l’état du jeu : inscriptions ou jeu en cours ;
• la liste des joueurs : identifiant, pseudo, position, dernières commandes, état, ...
• la liste des murs du labyrinthe en 3D ;
• la liste des tirs, un au maximum par joueur, avec la position de la boule d’énergie et son vecteur vitesse.

En cours de jeu, les 3 dernières structures de données sont fusionnées pour obtenir une liste d’éléments 3D pouvant être des rectangles ou des sphères (globules et boules d’énergie). Pour chaque joueur cette scène est traitée avant que le résultat soit envoyé en UDP au dit client :

• la scène est centrée sur la position du joueur ;
• une rotation d’axe y est appliquée à la scène selon l’orientation du joueur ;
• les éléments 3D sont triés pour afficher d’abord les éléments occultés ou partiellement occultés (si les éléments sont assez petits, un tri par distance du centre de gravité peut être une bonne approximation) ;
• les éléments sont projetés en 2D puis envoyés en UDP au client.

Le client n’a besoin que de la structure des éléments en 2D pour les récupérer dans le paquet UDP et les afficher.

3.3  Protocoles

Deux protocoles sont à concevoir et implémenter. Un protocole en mode connecté et un protocole en mode non connecté. Vous devez vous concerter avec les autres binômes pour que ces protocoles soient compatibles.

Le protocole en mode connecté va permettre de gérer les phases du jeu. Ce protocole doit fonctionner en mode ASCII avec un code par commande sur quelques caractères suivis d’éventuels arguments (e.g. JOIN <pseudo>).

Ce protocole doit permettre :

• de s’inscrire à un jeu s’il n’est pas démarré et de recevoir son identifiant de joueur ;
• de démarrer un jeu (uniquement pour les joueurs locaux) ;
• d’envoyer des messages aux autres joueurs ;
• de recevoir des messages des autres joueurs ;
• de recevoir des messages du serveur de jeu (départ ou arrêt du jeu, explosion d’un globule, arrêt du serveur, ...).

Lors de l’implantation de ce protocole un grand soin sera porté à la gestion des connexions et en particulier au traitement propre de la déconnexion non annoncée d’un client ou du serveur.

Le protocole en mode non connecté gère le transfert d’informations durant un jeu :

• messages réguliers du serveur en diffusion pour solliciter les inscriptions ;
• messages vers le serveur pour envoyer les contrôles du joueur (déplacement, rotation, tir) ;
• messages du serveur vers les clients pour donner la scéne 2D à afficher.

Les deux protocoles sont liés par l’identifiant qui permet de reconnaître le client dans les paquets UDP reçus par le serveur et qui permet au serveur de connaître comment contacter le client.

3.4  Travail à effectuer

Si vous ne voyez pas par où commencer voici quelques étapes que vous pourriez suivre :

• commencez par faire un schéma des flux d’exécutions qui sont nécessaires au bon fonctionnement des clients et du serveur, profitez-en pour voir quels flux nécessiteront des sémaphores pour garantir l’accès aux variables globales ;
• récupérez le projet fourni, ce projet contient un embryon de la bibliothèque graphique et une démonstration d’utilisation, installez les bibliothèques SDL2 si nécessaire, compilez le programme et exécutez-le ;
• examinez les sources du projet fourni pour vous en inspirer pour la modélisation du labyrinthe, sa manipulation, la projection 2D et l’affichage graphique ;
• concevez la bibliothèque réseau en vous appuyant sur les exemples de fonctions du cours, réalisez un premier exécutable du serveur qui n’implante qu’un simple serveur TCP ;
• concevez la bibliothèque des flux d’exécution, faite en sorte que votre serveur TCP puisse gérer plusieurs clients simultanément ;
• concevez collectivement les protocoles connectés et non connectés ;
• en utilisant les deux protocoles, faites en sorte que votre serveur s’annonce et gère correctement l’inscription de clients, écrivez la partie du client permettant de s’inscrire dès qu’un serveur est disponible ;
• vous pouvez ensuite implanter la partie d’envoi de messages aux autres joueurs en passant par la connexion TCP (le serveur sert de relai pour transmettre les messages à tous les joueurs connectés) ;
• il est conseillé de réaliser d’abord la partie client du jeu, à savoir transmettre les contrôles (déplacement, rotation et tir) au serveur, le serveur ne faisant qu’afficher la position des joueurs en mode texte (les coordonnées et l’angle) ;
• il n’est pas interdit de passer par une phase intermédiaire où le serveur transmet à tous les joueurs une scène 2D statique, vous pouvez ainsi tester l’affichage au niveau des clients ;
• enfin utilisez le code fourni pour calculer la scène 3D réelle puis la scène 2D ;
• terminez par la gestion des messages de contrôle (globule explosé, fin de partie, ...).

Ce document a été traduit de L^AT_EX par H^EV^EA