Projet Allegro : Wild Forest Rapport STEFANSKI DELION THOMAS
I. Introduction 1. Présentation de l équipe p 2 2. Présentation du projet..p 3 II. Choix de programmation 1. Présentation de notre jeu vidéo p 4 2. Organigrammes de programmation.p 8 III. Organisation 1. Planning des étapes de programmation et des tests de validations..p 9 2. Contenus des tests de validation intermédiaires et finaux.p 11 IV. Notre conduite de projet 1. Points positifs...p 11 2. Points négatifs.p 12 V. Conclusion...p 13 THOMAS Samuel P a g e 1 2010-2011
Notre équipe est constituée de : Mathieu DELION, après une étude approfondie de l énoncé du projet, Mathieu a codé plusieurs parties du jeu vidéo et à contribuer à la rédaction de ce rapport. Il a participé à la définition des choix de programmation ainsi qu à l organisation et à la réalisation des tests de validation tout au long du projet. Mathieu a également contribué à l amélioration de plusieurs parties du code. Alexis STEFANSKI, après concertation sur les choix de programmation et l orientation du projet, Alexis a commencé par coder les éléments fondamentaux de notre jeux mais a également collaborer à la rédaction de ce rapport. Il a permis de définir les objectifs du projet, la répartition des tâches au sein du groupe et a contribué à l organisation du projet en participant à l élaboration du planning des étapes de programmation Samuel THOMAS, a participé à la rédaction de ce rapport en effectuant une analyse détaillée des éléments du cahier des charges et en décrivant les choix de pour le codage du jeu vidéo. Il a également contribué à l élaboration du projet en définissant les orientations du projet ainsi que les choix de programmation. Samuel a rédigé certaines parties du code et a participé à la planification et à la réalisation des différents tests de validation. THOMAS Samuel P a g e 2 2010-2011
Conformément à la méthode Modèle-Vue-Contrôleur nous avons effectué un tableau regroupant les principales données du cahier des charges : Données Traitements Monstres, bêtes Ecegore : personnage principal Pistolet à Laser-Ecologique (PLE). PLE à tête chercheuse. PLE Lance-flammes (PLE-PLF) Icone cerclée de rouge Sacs de pièces d or Cagnotte Caisses 3 vies Fleurs Assemblage de tuiles Zone objets Boîte de dialogue Surgissent de manière aléatoire, se déplace moins vite qu Ecegore mais dans sa direction Incarne le joueur, parcourt le monde sauvage transforme les ennemis en arbres immobiles, récupérable dans des caisses, existe en différents versions vise automatiquement les monstres permet de brûler les arbres, il est contenu dans une seule caisse indique par où vont surgir les ennemis disposés sur le terrain, augmentent la cagnotte constitue le score du joueur contiennent objets (ex : bombes arborisantes) diminuent selon si le joueur est touché par un ennemi permettent de regagner des vies (3 fleurs = 1 vie), sont issues de la transformation de certains monstres présentant arbres, personnages, objets, vies, contient tous les objets acquis par le joueur, permet de changer d arme en sélectionnant une autre arme permet de sauvegarder, charger (arrêter/reprendre) une partie, quitter le jeu THOMAS Samuel P a g e 3 2010-2011
Suite à l étude de l énoncé du projet, nous avons été amenés à faire certains choix concernant la programmation de ce jeu vidéo. Après concertation nous avons dès le départ décidé que notre jeu aurait l apparence d un jeu de plateforme en 2D mais avec un travail sur les graphismes des objets qui permettrait de donner une impression de 3D. Ce qui donnerait un résultat qui correspondant aux consignes du projet à savoir la réalisation d un jeu vidéo en 2D et demi. Dès le commencement, nous avons voulu appliquer les enseignements du cours en codant une Tile Map. Pour les graphismes de certains des objets du jeu nous avons recouru à la technique du Pixel Art, c est-à-dire que nous avons réalisé pixel par pixel, à l aide de logiciels de traitement d image (Paint et Photoshop), l image de l objet que nous voulions inclure dans le jeu en travaillant sur la perspective pour donner un effet de 3D. La capture d écran suivante montre un exemple du travail sur la perspective que nous avons mené pour donner une impression de 3D. En effet grâce à notre gestion des collisions, on peut observer sur la capture d écran suivante que le personnage principal passe derrière la table situé devant lui. Pour le personnage principal, nous avons recherché une séquence d images d un même personnage en mouvements sur des sites spécialisés dans la réalisation de RPG, ce qui nous permis de trouvé un personnage adapté à notre jeu mais aussi à inclure des personnages secondaires et des objets à THOMAS Samuel P a g e 4 2010-2011
ramasser comme on peut voir sur la capture d écran suivante qui correspond au 1 er niveau dans notre jeu vidéo. Concernant les personnages secondaires ils peuvent communiquer avec le personnage principal grâce à de zones de texte où sont inscris les messages De la même façon le personnage peut entrer en interaction avec un grand nombre d objets du jeu. En effet dès que l icône «entrer» s affiche en bas à gauche de l écran le joueur peut afficher des informations sur l objet situé en face de lui. THOMAS Samuel P a g e 5 2010-2011
Les différents objets récoltés sont stockés dans une zone objet où le joueur peut accéder. Cet inventaire est présenté dans une boîte de dialogue contenant une illustration du personnage en grand format, l ensemble des objets récoltés ainsi que des informations sur chacun d eux lorsqu ils sont sélectionnés (grâce aux flèches du clavier). Une jauge de vie est également présente dans tous les niveaux de jeux ainsi que dans les boîtes de dialogue. Nous avons décidé de faire plusieurs mondes correspondant à des regroupements de tiles-map différentes et créer ainsi plusieurs niveaux de jeu. On peut voir le 2 e niveau du jeu dans la capture d écran suivante : THOMAS Samuel P a g e 6 2010-2011
Le personnage dispose d une arme qui lui permet de tirer des boules de feu. Lorsque la boule de feu entre en collision avec un ennemi (pour l instant représenté par des lapins et des poules) celui-ci se transforme en arbre qui peut être de deux tailles différentes (voir capture d écran ci-dessous) Une musique de fond est présente dans notre jeu, c est un fichier au format midi. Nous voudrions à terme que le jeu contienne plusieurs musiques selon les niveaux de jeu, les actions du personnage, etc THOMAS Samuel P a g e 7 2010-2011
Dans notre programme, le main appelle successivement deux sous-programmes (intro_niveau1 et intro_niveau2) contenus chacun dans un fichier.c (lvl1.c et lvl2.c). main.c lvl1.c intro_niveau1 lvl2.c intro_niveau2 Par la suite chacun de ces deux sous programmes appelle plusieurs sous-programmes différents. Les graphes d appels suivants contiennent l ensemble des sous-programmes et fonctions appelés par int intro_niveau1 contenu dans lvl1.c et int intro_niveau2 contenu dans lvl2.c Persos.c Int interaction Hero.c deplacement Pause_menus.c ajouter_objet Pause_menu s.c void affich_invent Armes.c shoot Persos.c Int interaction lvl1.c int intro_niveau1 Armes.c bougertirs Pause_menu s.c affich_invent Affichage.c afficher_fond Pause_menu s.c affichjauges Affichage.c afficher_obj Hero.c afficher_pers o Persos.c affichgens THOMAS Samuel P a g e 8 2010-2011
Pause_menu s.c void affich_invent Persos.c Int interaction Hero.c deplacement Pause_menus.c ajouter_objet Ennemis.c afficher_enn emis Armes.c shoot Persos.c Int interaction lvl2.c int intro_niveau2 Armes.c bougertirs Pause_menu s.c affich_invent Affichage.c afficher_fond Pause_menu s.c affichjauges Affichage.c afficher_obj Hero.c afficher_pers o Persos.c affichgens Ennemis.c dep_ennemis Cette structure du code est amenée à être modifiée et optimisée au fur et à mesure que nous avançons dans la programmation de notre jeu vidéo. THOMAS Samuel P a g e 9 2010-2011
Ce diagramme de Gant résume le planning des principales étapes de programmations et de la réalisation des tests de validations. Cependant ce rapport étant à rendre pour une date antérieure à celle pour laquelle nous devons rendre le code du projet, la liste des différentes étapes de programmation n est pas exhaustive. En effet cette liste comporte les étapes que nous avons déjà réalisées ainsi que celles que nous prévoyons de réaliser, auxquelles s ajouterons certainement d autres étapes rendues nécessaires par la conduite du projet. THOMAS Samuel P a g e 10 2010-2011
L objectif des 3 tests de validation que nous avons organisé est principalement de vérifier la viabilité du jeu vidéo que nous créons en contrôlant qu il ait une synchronisation correcte des différentes parties du code et des modifications apportées par chaque membre de l équipe. Lors des séances de test nous avons passé la totalité de notre temps à contrôler chacune des parties du code, et à effectuer les modifications nécessaires. Le contenu des différents tests de validation est résumé de façon schématique ci-dessous : Test n 1: cohérence tile-map, déplacements et collisions personnage principal/objets. Test n 2 : collisions nouveaux éléments Tile-map (objets, batiments, perso 2aires), inventaire et saisies des objets, menu. Test n 3 : test de l'ihm (menu, écran de pause,...), des dernières modifications apportées au code, de l'execution de tous les sous-programmes Test final : viabilité du projet dans sa globalité et test de l'éxecution du projet sur les ordinateurs de l'ece THOMAS Samuel P a g e 11 2010-2011
Un des aspects positif de notre conduite de projet est que nous avons commencé rapidement à coder les éléments fondamentaux de notre jeu vidéo c est-à-dire les Tile-Map et les mouvements du personnage principal. Cette rapidité a été permise par le fait que nous nous sommes très vite mis d accord sur les choix de programmation. De plus la répartition des tâches entre les différents membres du groupe nous a permis d être efficaces. En effet, chaque membre du groupe a pu participer à l organisation du projet, à la rédaction du rapport et au codage du jeu vidéo. organisation du projet rédaction rapport codage jeu vidéo La synchronisation est un atout fondamental de notre conduite de projet. Grâce à des conversations de groupe sur Skype où nous pouvons également échanger des fichiers, ainsi qu à l envoi de mails de façon régulière. Lorsque nous avons planifié les différentes étapes de programmation, nous avons élaboré un planning (diagramme de Gantt) qui comporte des tâches assez générales ce qui nous a laissé une certaine liberté et nous permet de rajouter des étapes de programmation (ou d en enlever) sans trop perturber notre planning. Avec les différentes échéances auxquelles nous devions faire face (D.S, D.M, TD), nous n avons pas pu coder de façon régulière. Il est vrai que nous avons codé de façon «ponctuelle» mais en avançant de manière significative à chaque fois. La durée du projet étant limitée nous n avons pas eu le temps de créer tous les éléments graphiques de notre jeu, nous avons alors utilisé des images issues de sites spécialisés dans la réalisation de RPG. Ceci nous a permis d enrichir notre jeu de graphismes variés et d avancer plus rapidement dans notre projet THOMAS Samuel P a g e 12 2010-2011
Sources pour les images utilisées dans notre jeu : http://rgss-de-rmxp.software.informer.com/ http://www.rpg-maker.fr/ La création de ce jeu vidéo nous a permis de comprendre de manière approfondie les différentes possibilités qu offre la librairie graphique Allegro. Mais nous avons également appris à aller chercher des informations sur différents sites proposants des tutorats nous indiquant comment incorporer des éléments spécifiques dans notre jeu vidéo (musique avec des fichiers en midi, ). Ce projet allegro nous a permis de mettre en pratique ce que nous avons appris lors des cours magistraux. De plus ce projet, de par le volume important du code, nous a poussé à optimiser notre travail d équipe en synchronisant régulièrement les parties du code dont chacun était responsable et en se répartissant le travail de manière équitable. Grâce à ce projet nous avons pu apprendre à maîtriser les fonctions propres à la librairie graphique Allegro dans un contexte à la fois ludique et motivant. En effet, c est à travers la création de ce jeu vidéo que nous avons pu appliquer les connaissances acquises en cours de programmation. Nous avons pu également apprendre à nous organiser de manière efficace en établissant un planning définissant à l avance les différentes étapes de programmation. La répartition des tâches a été un élément déterminant de notre conduite de projet et nous a permis de relever le défi. THOMAS Samuel P a g e 13 2010-2011