Laser Lemming

File:LaserLemming-Logo.png

Logo

• Encadrants:
• Elèves RICM3: Augustin Husson (Chef de projet), Lionel Boey, Nafissa Dia, Mehdi Nait-Sidous, Julien Navails

• File:LaserLemming-Flyer.pdf
• File:LaserLemming-Poster.pdf
• File:LaserLemming-Presentation.pdf
• File:LaserLemming-ScreenCast.wav
• Dépôt des sources

Description (Contrat)

Lemmings est un jeu vidéo de réflexion développé par le studio écossais DMA Design, aujourd'hui Rockstar North et édité par Psygnosis en 1991. Le projet est mené par Dave Jones. Le joueur doit guider des dizaines de lemmings, minuscules créatures écervelées, dans des niveaux alambiqués truffés de dangers mortels... (extrait de la page wikipedia : [1] )

Le but de notre projet était de reprendre le concept de base de ce jeu, et d'en donner une version améliorée en terme de gameplay.

Nous avions donc établit le contrat suivant :

• creusement, escaliers, zone incrusable etc...
• image de fond
• Ennemi équipé de laser mortel
• sauvegarde et chargement de fichier.
• zone de mort (acide, lave...)

avec comme possibilité d'extension :

• zombis
• action lemming médecin

Map

Manuel Développeur

INTRODUCTION

Ce manuel est destiné à tous les développeurs qui souhaiteraient découvrir le fonctionnement de Lemmings afin de l’améliorer ou de le personnaliser. Il vous permettra notamment de comprendre l’architecture générale de notre logiciel, les méthodes de développement utilisées et de vous familiariser avec les spécificités du jeu. Libre à vous de vous approprier le code, de le modifier et de l'améliorer !

1. Organisation du logiciel

L’architecture que nous avons choisi d’utiliser est basée sur une architecture trois tiers, basée sur trois couches :

• La couche présentation, gérée par Java.
• La couche métier, gérée par XML.
• La couche d’accès aux données, gérée par Caml.

Dans ce type d’architecture, chaque couche communique seulement avec ses couches adjacentes. Par exemple, le couche de données et la couche présentation ne communiquent jamais ensemble. Une telle séparation permet de rendre le code plus lisible et compréhensible. De plus, cette méthode est adaptée aux projets volumineux nécessitant beaucoup de programmeurs.

Caml est utilisé pour créer les automates qui modélisent les comportements de base des lemmings, les automates sont ensuite « parsés » dans un fichier XML. L’utilisateur ne doit pas pouvoir modifier ni le fichier Caml parser.ml, ni le fichier XML automate.xml. Si vous voulez ajouter des fonctionnalités à vos lemmings, il vous faut modifier le fichier parser.ml.

XML est le langage utilisé pour décrire les automates, sous forme de langage balisé. Dans notre logiciel, c’est la tâche du package parser de décoder le XML.

2. Description des différentes couches du logiciel

      a- La couche d'accès aux données:

Le fichier parser.ml n'est pas destiné à être utilisé par l'utilisateur. On trouve dans ce fichier toutes les descriptions des automates permettant le fonctionnement des lemmings.

      b- La couche métier:

Cette partie permet de faire la transition entre le XML et la création des données en Java. Les classes du package parser utilisent la librairie JDOM pour parser facilement les fichiers XML.

Format du fichier XML : <Automates> <Automate>

   		<Nom>Lemmings</Nom>
   		<Transitions>
       			<Transition>
           			<EtatCourant>0</EtatCourant>
           			<Conditions>
               				<Condition>obstacleDessous</Condition>
               				<Condition>nonObstacleDevant</Condition>
               				<Condition>nonBlocDevant</Condition>
           			</Conditions>
           			<Actions>
               				<Action>avancerDuneCase</Action>
           			</Actions>
           			<EtatFinal>1</EtatFinal>
       			</Transition>

</Transitions> </Automate> <Automate> ….... </Automate> </Automates>

Nous avons choisi de ne pas intégrer pour l’instant la récupération d’erreur dans le parsage. Cependant, tout a été mis en place pour faciliter l’affichage des erreurs pour l’utilisateur au niveau de l’interface graphique. En effet les classes d’exceptions ont été crées et les exceptions engendrées, placées dans dans endroits stratégiques du code. De ce fait il ne reste plus qu’à mettre en place des boîtes de dialogue permettant de dire à l’utilisateur qu’il y a eu une erreur.

Par exemple, au niveau de l’ordonnanceur, lorsque nous parsons les primitives, une exception est levée lorsque la primitive parsée n’existe pas.