Informations
    Actualités & évènements
      Loading...

      Metaworms (Tech 2)

      15.04.06

      But du projet : réaliser un worm pour au moins trois couches graphiques ayant le maximum de code en commun.

      Description du projet :

      Il s’agit de réaliser un Worm pour au moins trois couches graphiques (à choisir dans la liste ci-dessous) avec le maximum de code en commun.

      Le jeu de Worm demandé en lui-même est ici très simple : la map doit être de dimensions variables (par défaut 30×20). Le jeu est entouré de murs. Le ver mesure 6 unités au départ.

      Un fruit est affiché au hasard sur la map dans un espace libre avec une valeur de 1 à 9. Chaque fois que le ver mange un fruit, il grandit de la valeur correspondante.

      Le ver meurt quand il heurte un mur ou son propre corps.
      Il faut gérer les actions move-right, move-left, pause et quit. Il est aussi possible d’utiliser les directions move-up, move-left, move-right, move-down (ce n’est pas le même ‘gameplay’).

      Au choix, voici les couches possibles :

      • Termcap,
      • Curses,
      • Xlib,
      • Xt en cannevas,
      • Widget Xt,
      • GTK en cannevas,
      • Widget GTK,
      • OpenGL,
      • OpenGL embarqué dans du Xt,
      • OpenGL embarqué dans du GTK,
      • SDL pour Unix.

      Réalisation :

      Le programme doit se lancer de la manière suivante :

      metaworm [-d widthxheight] lib.so

      Lib.so est une librairie dynamique avec un nom évocateur qui contient la partie spécifique à la couche graphique.

      Vous devez donc rendre trois librairies dynamiques, une pour chaque couche. Exemple:

      • mw_termcap.so
      • mw_xlib.so
      • mw_opengl.so

      Le programme Metaworm ne doit pas être linké avec des librairies graphiques, seule la libc est autorisée.

      Il est possible de ne faire que deux couches si les étudiants partagent une troisième couche avec un autre groupe. Cela impose d’établir un même protocole de communication et d’affichage et de le respecter à la lettre afin que cela puisse fonctionner.

      L’API doit être documentée et doit justifier les choix réalisés.

      Un minimum d’interaction est demandé comme par exemple la réalisation d’une IHM permettant de configurer le jeu par des options.