ecole informatique
L'école  >  Le cursus  >  La culture Projet  >  Tek2 - metaworms

Metaworms (Tek 2)

Jeu metanibbleRéalisation du jeu Metanibble supportant plusieurs couches graphiques ayant le maximum de code en commun.

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 30x20). 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.
differents couches

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.

EPITECH en France

EPITECH en France

Témoignage

Au départ un projet, aujourd'hui mon entreprise

photo de CAMILLE MIREY "Un des éléments déclencheurs fut la possibilité de consacrer entièrement le stage de 3ème année au développement du projet."
CAMILLE MIREY
ancien
Promotion 2007

D'abord MMORPG (jeu de rôle en ligne), en 2003, puis moteur de jeu pour mondes persistants en 2004, et enfin middleware destiné à la production d'univers immersifs en 2006, le projet HellHeaven a accompagné tout notre cursus depuis la fin de la 1ère année. Il a d'abord évolué au gré des opportunités (projet libre de 2ème année, objectif de projet de fin d'études dès la 3ème année) et de l'équipe (jusqu'à 9 personnes) puis s'est progressivement orienté vers des besoins professionnels réels : la fibre entrepreneuriale commençait à s'exprimer.

Un des éléments déclencheurs fut la possibilité de consacrer entièrement le stage de 3ème année au développement du projet. Une chance inespérée et un argument décisif pour fonder, dès janvier 2005, Persistant Studios SARL qui regroupe quatre associés.

En 2006, une première prestation pour une société d'architecture nous donne une vision plus large des problématiques réelles de production. Une refonte complète du moteur est entamée cette même année afin de proposer une solution flexible pour la création d'applications 3D temps réel.

Une étape importante dans la consolidation de l'activité fut franchie avant même la fin de notre cursus, avec l'arrivée de Persistant Studios à la tête du laboratoire de développement de jeux vidéo. Une manière agréable et efficace de faire profiter les étudiants de notre expérience. L'activité de Persistant Studios, encore scindée en 2 parties (prestations d'un côté, R&D de l'autre) commence à se structurer et HellHeaven arrive à maturité.