Rapport de projet Metal Slug

Université de Montpellier
                     Faculté des Sciences

                 Rapport de projet
                    Metal Slug
Thomas BONNIN   Jules GIRARD    Gilles SILOTIA     Pascal WAGNER

                        25 avril 2015

                           Sous la direction de M. Mickael Montassier.

Sommaire

1   Problématique                                                                                     3

2   Cahier des charges                                                                                 4

    2.1   Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      4
    2.2   Spécications fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       5
          2.2.1   Spécications fonctionnelles globales . . . . . . . . . . . . . . . . . . . .        5
          2.2.2   Spécications fonctionnelles du gameplay . . . . . . . . . . . . . . . . . .         5
    2.3   Storyboard    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    7
    2.4   Spécications non-fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . .       7
    2.5   Spécications bonus     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    7

3   Gestion de projet                                                                                  9

    3.1   Étapes du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       9
    3.2   Dicultés rencontrées     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   10

4   Analyse technique                                                                                 11

    4.1   Animations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      11
          4.1.1   Modèlisation des animations . . . . . . . . . . . . . . . . . . . . . . . . .       11
          4.1.2   Chargement des animations . . . . . . . . . . . . . . . . . . . . . . . . .         12
          4.1.3   Lecture des animations . . . . . . . . . . . . . . . . . . . . . . . . . . . .      12
          4.1.4   Les diérents modes de lecture des animations . . . . . . . . . . . . . . .         12
    4.2   Gestion des collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    13
          4.2.1   En quoi consiste la gestion des collisions ?    . . . . . . . . . . . . . . . . .   13
          4.2.2   Cas simple : collision de bords . . . . . . . . . . . . . . . . . . . . . . . .     13
          4.2.3   Cas complexe : collision de coins . . . . . . . . . . . . . . . . . . . . . . .     13

5   Rapport de bogues                                                                                 14

6   Conclusion                                                                                        15

                                                   1

Table des gures

 2.1   Cas d'utilisation général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     5
 2.2   Cas d'utilisation lié au gameplay    . . . . . . . . . . . . . . . . . . . . . . . . . .    6

 4.1   Sauvegarde des animations en XML . . . . . . . . . . . . . . . . . . . . . . . . .         11
 4.2   Diagramme de classe concernant les animations . . . . . . . . . . . . . . . . . .          12
 4.3   Deux résultats de collisions du même coin. . . . . . . . . . . . . . . . . . . . . .       13

 1     Diagramme de Gantt : Étape 0 et brainstorming . . . . . . . . . . . . . . . . . .          16
 2     Diagramme de Gantt : Développement et correction des bugs . . . . . . . . . . .            16
 3     Diagramme de Gantt : Écriture du rapport . . . . . . . . . . . . . . . . . . . . .         17
 4     Diagramme de Gantt : Vue d'ensemble . . . . . . . . . . . . . . . . . . . . . . .          18

                                               2

Chapitre 1

Problématique

  Au l des années, le jeu vidéo a évolué grâce à l'émergence de nouvelles gestions des graphismes,
de nouveaux types de jeu et de nouvelles technologies. Vers la n des années 80, le jeu vidéo voit
apparaître le shoot'em up avec le mythique Space Invaders. En 1996 voit le jour Metal Slug,
shoot'em up édité et développé par SNK, premier d'une longue série. Metal Slug est un jeu en
side-scrolling 1 qui a construit sa notoriété de par un gameplay nerveux, un humour parodique
et des graphismes riches et soignés pour l'époque grâce à l'utilisation du délement parallaxe 2
et à des sprites détaillés.

  À une époque où tant le matériel que la programmation étaient des contraintes, SNK réus-
sira tout de même à proposer un jeu très réussi à tout point de vue pour l'époque, disponible
originellement sur la borne d'arcade Neo-Geo MVS (microprocesseur cadencé à 12 mégahertz,
64 kilo-octets de mémoire vive, programmation en ASM 68K 3 ). Ecacité est l'un des maîtres
mots dans la programmation des jeux vidéos d'époque, bien souvent au détriment de la con-
ception. Ainsi, les premiers épisodes de la série ne présentaient pas les spécications et normes
requises aujourd'hui à savoir la maintenabilité et la lisibilité obtenus grâce aux langages de
programmation de plus haut niveau et à la programmation objet.

  Notre projet, proposé par M. Montassier dans le cadre de notre cursus de Licence Informa-
tique à la Faculté des Sciences de Montpellier, a pour but de concevoir et programmer un jeu
vidéo inspiré de la licence Metal Slug à l'aide des technologies actuelles.

  Après avoir mis au point dans le cahier des charges l'ensemble des besoins fonctionnels et des
spécications techniques, nous analyserons comment nous avons pu gérer ce projet au niveau
temporel et humain. Ensuite nous aborderons un point technique clé de notre programme.
Enn, nous conclurons après avoir évoqué les dicultés rencontrées lors du projet.

  1. Jeu à délement horizontal où le joueur se déplace de gauche à droite de manière générale.
  2. Simulation d'un eet de profondeur en appliquant une vitesse de délement diérente aux diérents plans.
  3. Assembleur dédié au microprocesseur.

                                                     3

Chapitre 2

Cahier des charges

2.1 Description
  Ce programme sera un jeu de type action qui s'inspirera de la série Metal Slug, en reprenant
le concept de base, tout en y ajoutant une touche personnelle. Il s'agira donc d'un beat'em all 1
à délement horizontal en deux dimensions.

  Le joueur sera plongé dans un univers plein d'actions et dynamique dans lequel il incarnera un
héros qui se déplacera dans un niveau, composé de trois phases dont une éventuelle en véhicule,
se concluant par l'arontement d'un boss puissant et massif. De par sa nervosité, le gameplay
fera appel aux reexes du joueur qui devra tirer sans cesse sur les ennemis ainsi qu'esquiver
les tirs ennemis. Au l du jeu, il pourra compter sur des armes de plus en plus puissantes et
destructrices grâces à des items, laissés par des ennemis, qu'il pourra récupérer.

  D'un point de vue graphique, le jeu s'appuiera sur des sprites du jeu original orant ainsi
des eets visuels dynamiques et détaillés, style dessin animé d'époque. L'utilisation de l'eet
parallaxe permettra une impression de profondeur lors du déroulement du décor. L'interface de
jeu sera soignée, et dans le même ton que les jeux d'arcade des années 90 et 2000.

  Le clavier sera le système de contrôle principal et donnera au joueur la possibilité d'exécuter
des actions semblables à Metal Slug. Le contrôle via un gamepad (contrôleur Microsoft) sera
envisagé si le temps le permet.

  Cette série est aussi connue pour son humour parodique et ses nombreux easter eggs 2 le jeu
en sera par conséquent pourvu.
  1. Type de jeu englobant le shoot'em up où le personnage doit combattre un grand nombre d'ennemis en
combat à mains nues ou à l'aide d'armes traversant ainsi les sections du niveau jusqu'au boss.
  2. Fonction cachée, clin d'oeil ou référence à un jeu vidéo ou à un lm.

                                                  4

CHAPITRE 2.      CAHIER DES CHARGES                                                             5

2.2 Spécications fonctionnelles
2.2.1 Spécications fonctionnelles globales
  D'un point de vue globale, voici les fonctionnalités proposées au joueur présentes dans le
diagramme ci-dessous (gure 2.1).

                            Figure 2.1     Cas d'utilisation général

  Les fonctionnalités globales de l'application sont basiques comme les jeux d'arcade d'époque.
En eet l'utilisateur pourra lancer une partie en solo où il pourra jouer seul à Metal Slug. À la
n de cette partie si son score est susamment élevé il sera alors ajouté aux meilleurs qui seront
consultables et réinitialisables à partir du menu principal . Une autre fonctionnalité prendra la
forme d'un menu disponible à tout moment an de régler divers paramètres comme le son, la
vidéo ou les commandes. Enn comme on peut le voir sur la gure 2.1, il est prévu, selon le
temps restant, l'implémentation d'un mode multi-joueur jouable sur une même machine et la
possibilité de choisir son personnage.

2.2.2 Spécications fonctionnelles du gameplay
  Dans cette partie, nous listerons les fonctionnalités oertes au joueur concernant les mouve-
ments et actions possibles de son personnage en nous appuyant sur la gure 2.2.

CHAPITRE 2.      CAHIER DES CHARGES                                                            6

                       Figure 2.2     Cas d'utilisation lié au gameplay

  Le joueur pourra déplacer son personnage dans le niveau en cours grâce aux deux dé-
placements principaux droite et gauche. Pour mener à bien les missions, il aura la possibilité
d'esquiver les attaques en sautant ou en s'accroupissant. Il est bien sur possible de se déplacer
en sautant.

  Pour se défendre, on pourra compter sur diérentes attaques comme le tir basique avec l'arme
courante ou encore le tir spécial où le personnage lance une grenade lors des phases à pieds. Le
personnage conserve toute les armes récupérées et le changement d'arme manuel sera possible.

  Un point important de Metal Slug, la destruction d'éléments accompagnée de belles anima-
tions et d'eets visuels dynamiques d'explosions en tout genre. On pourra donc détruire tout
un tas d'éléments du décor et les ennemis. Enn la destruction d'éléments ou d'ennemis causera
de manière aléatoire la génération d'items.

  Voici un récapitulatif des diérents éléments en relation avec le gameplay :

   Actions                Armes                 Items                  Ennemis
   Déplacer droite        Couteau               Vie                    Soldat simple
   Déplacer gauche        Grenade               Munitions              Soucoupe volante
   Sauter                 Pistolet              Arme                   Bowser
   S'accroupir            Fusil à pompe
   Tir                    Lance-ammes
   Tir spécial
   Changer d'arme
   Mettre en pause

CHAPITRE 2.        CAHIER DES CHARGES                                                          7

2.3 Storyboard
  Le joueur sera plongé dans une aventure extravagante. Le premier niveau sera présent. Des
niveaux supplémentaires seront réalisés si le temps le permet.

                       Niveau 1 : Base militaire de l'armée régulière

    Phase 1    En véhicule (avion), scrolling horizontal vers la droite. Nombreux ennemis
               volants, véhicules anti-aérien, missiles à éviter.
                       L'avion est détruit, et le héros est parachuté au sol.
    Phase 2    À pied ; fait face à de nombreux ennemis au sol, se bat au début avec un
               magnum et doit récupérer de meilleures armes et munitions sur les ennemis.
               Se conclut avec un mini-boss, le gardien de la base militaire.
    Phase 3    À pied, jusqu'au bureau du commandant, qui envoit un boss le défendre : un
               T-Rex robot qui tire des lasers par les yeux.
             Le commandant s'enfuit en fusée spatial, mais le héros arrive à le suivre.

2.4 Spécications non-fonctionnelles
  Dans le but de mettre en application l'apprentissage de la programmation objet eectuée lors
de notre cursus et d'avoir une programme évolutif et maintenable nous utiliserons le concept
de programmation orientée objet.

  Ainsi, le code source sera écrit en C++, avec une architecture MVC, et utilisera la biblio-
thèque SFML.

  La SFML(Simple and Fast Multimedia Library) permet la conception d'application multi-
media en 2D. Plus précisèment, elle permet de communiquer avec les diérents périphériques
d'une machine, comme l'écran, les hauts-parleurs ou la carte réseau. L'utilisation de cette bib-
liothèque est un très bon choix, celle-ci étant d'une grande simplicité d'apprentissage. De plus,
elle est sous licence zlib/png (open source).

  Le développement se fera sous Linux, mais l'utilisation de Cmake permettra une compilation
cross-plateform.

2.5 Spécications bonus
  Parmi les fonctionnalités non-essentielles au jeu, mais tout de même retenues, nous pourrions
proposer :
   • Gestion du multijoueur sur le même ordinateur, via des périphériques diérents (clavier
     et manette).
   • Ajout de nouveaux types d'ennemis.

CHAPITRE 2.      CAHIER DES CHARGES                                                         8

  •   Possibilité de choisir le personnage à incarner.
  •   Ajout de nouvelles armes.
  •   Ajout de véhicules (avions, tanks, etc...)
  •   Ajout de nouveaux niveaux.
  •   Ajout d'eets spéciaux.
  •   Portage du jeu sur d'autres systèmes (Windows, OSX).
  •   Continuer plus loin dans le scénario (il fût question de voyage spatial et temporel à un
      moment).

Chapitre 3

Gestion de projet

3.1 Étapes du projet
  An d'assurer le bon déroulement du projet, nous avons mis en place un diagramme de
Gantt(Annexe : Figure 4) possédant cinq grandes étapes : l'étape initiale, le brainstorming, le
codage du jeu, la correction des bugs et le rapport.
   Chaque étape fut très importante pour le maintien d'une bonne gestion et d'une bonne
organisation du dévelopement du jeu.

Étape initiale   : Étape essentielle et non négligeable qui a permis la prise de conscience du
     potentiel du sujet ainsi que la découverte du jeu Metal Slug pour les membres du groupe
     ne le connaissant pas. Nous avons de plus mis en place les diérents outils nécessaires au
     travail en groupe (Google Drive, Git).

Brainstorming et Conception         : Cette importante étape fut l'une des plus longues. Elle fut
     composée de plusieurs sessions de brainstorming, permettant la mise en commun des idées
     pour la rédaction du cahier des charges, suivies d'une phase de conception durant laquelle
     l'architecture du jeu fut dénie (diagrammes de classe, diagrammes de cas d'utilisation,
     etc...). Cette étape a également été consacrée à la prise en main de la SFML.
Programmation      : La programmation a durée environ 6 semaines. L'utilisation d'un dépôt
     Git 1 nous a aidée à organiser la partie développement en centralisant le code en un seul
     endroit.
Test et correction    : Une fois le codage achevé, nous avons eectué une phase de test an
     de corriger les bugs éventuels, connaître l'avis sur le rendu nal et ajouter des éventuels
     manques de notre part.

Rapport   : Cette étape se déroule sur toute la durée du projet. En eet, le rapport a été
     régulièrement complété. Il a toutefois été majoritairement rédigé après la phase de développe-
     ment.
  1. Adresse du dépôt du projet : https ://github.com/DocThomus/TER-MetalSlug

                                                9

CHAPITRE 3.      GESTION DE PROJET                                                            10

3.2 Dicultés rencontrées
    Durant l'élaboration de ce projet, nous avons connu quelques dicultés.

    La principale fût la dénition du cahier des charges : le sujet de notre projet étant partic-
ulièrement libre, nous avons eu du mal à nous limiter en terme de faisabilité et de temporalité.
Ceci explique que plusieurs des objectifs du cahier des charges n'ont pas pu être remplis dans
le temps imparti : notre niveau ne comporte par exemple qu'une seule phase au lieu des trois
prévues.

    Pour la même raison, certains éléments de l'architecture n'ont pas été parfaitement réal-
isés : premièrement, chaque ennemi aurait dû posséder sa classe propre, héritant d'une classe
abstraite représentant un ennemi. Or, nous n'avons développé qu'une seule classe pour tous les
ennemis du jeu. Deuxièmemement, la gestion des IA des ennemis devrait être gérée en suivant
un diagramme d'états simple propre à chaque ennemi ; or nous avons programmé celle-ci au
niveau de la classe gérant les collisions entre les diérents objets du niveau (le contrôleur).
Enn, nous n'avons pas eu le temps de développer une interface de jeu (santé du joueur, mu-
nitions...).

    Un seconde diculté est survenue lors de la phase de développement. Les niveaux en C++
des diérents membres du groupe étant assez disparates, la participation à cette phase fût assez
hétérogène.

Chapitre 4

Analyse technique

4.1 Animations
4.1.1 Modèlisation des animations
   Ce projet étant notre première application achant des animations 2D, nous nous sommes
rapidement demandés comment gérer celles-ci. Nous avions à notre disposition diérentes
feuilles de sprites 1 récupérées sur diérents sites.
   Deux informations sont nécessaires pour "trouver" une frame dans une feuille de sprite : sa
position (par convention la position du coin supérieur gauche) et sa taille. Nous avons décidé
de référencer les animations d'une image dans un chier XML (voir la gure 4.1.).

                        Figure 4.1      Sauvegarde des animations en XML

   L'attribut speed indique la vitesse de l'animation en frames par milliseconde. La position
d'une frame est représentée par les attributs x et y. La taille d'une frame est représentée par
les attributs w et h.

  1. Image contenant les frames d'une ou plusieurs animations.

                                                   11

CHAPITRE 4.       ANALYSE TECHNIQUE                                                           12

4.1.2 Chargement des animations
   C'est ensuite le programme qui, lors du chargement des diérentes ressources d'un niveau,
charge les textures et les animations correspondantes (donc les chiers XML). Pour parcourir
les documents XML, nous avons utilisé la librairie C++ rapidXML.

   Lors du chargement du chier XML, des objets Frame et Animation sont crées. Ces deux
objets sont assez simples à décrire : Frame contient la position et la taille d'une frame, tandis
qu'Animation contient une ensemble de frames ordonnés. Les objets Animations et les textures
sont ensuite attribués à un objet Drawable 2 . Tout ceci est présenté dans la gure 4.2.

                 Figure 4.2       Diagramme de classe concernant les animations

4.1.3 Lecture des animations
   La lecture des animations se fait ainsi simplement. À chaque mise à jour de l'objet, celui-ci
mesure le temps écoulé depuis le dernier changement d'image :

   • Si celui-ci est inférieur à la vitesse de l'animation, il n'y a rien a faire.
   • Sinon, il faut passer à la frame suivante de l'animation. Il faut appeler la procédure
     setNextFrame() qui va indiquer à l'animation courante qu'elle doit changer de frame.

Pour acher la frame courante, accessible via la méthode getFrame(), il sut de modier le
rectangle de selection de la texture pour selectionner la frame voulue.

4.1.4 Les diérents modes de lecture des animations
   Il est possible de lire une animation dans plusieurs modes de lecture diérents, en fonction
des paramètres passés à la méthode permettant de modier l'animation courante (changeAnimation()).

Lecture répétée      : C'est le mode par défaut. L'animation est lue en boucle jusqu'au prochain
     changement d'animation.
  2. les objets Drawable sont les objets qui s'achent à l'écran

CHAPITRE 4.       ANALYSE TECHNIQUE                                                                13

Lecture simple     : L'animation est lue une seule fois. Lorsqu'elle se termine, elle reste bloquée
       sur la dernière frame.
Lecture enchaînée      : L'animation est lue une seule fois, puis la lecture est enchaînée sur une
       autre animation en lecture répétée.

4.2 Gestion des collisions
4.2.1 En quoi consiste la gestion des collisions ?
    La gestion des collisions est l'une des parties générant le plus de calcul dans ce projet ; nous
considerons donc pour les collisions tous nos objets comme des carrés. A chaque tour de boucle
de jeu, nous vérions donc toutes les collisions possibles : personnages contre plateformes,
projectiles contre personnages, projectiles contre plateformes, bonus contre joueur, etc... Dans
le cas d'une collision entre personnage (joueur ou ennemi) et une plateforme, le personnage est
décalé pour ne pas superposer ou traverser cette plateforme. Dans les cas comme la collision
entre projectile et personnage ou entre bonus et joueur, le bonus ou la balle est détruit, et
entraine un changement d'état chez le personnage ou le joueur (dégâts, changement d'arme,
etc...).

4.2.2 Cas simple : collision de bords
    La collision entre le bord d'un personnage et d'une plateforme est le plus fréquent. Illustrons
ceci par un exemple : les pieds du joueur sont en collision avec la base d'une plateforme, il est
donc placé sur celle-ci ; inversement, si la tête du joueur est en collision avec le plafond d'une
plateforme, il est placé sous celle-ci et tombe. De même pour les collisions gauche et droite.

4.2.3 Cas complexe : collision de coins
    La collision entre l'angle de deux objets soulève une ambiguité : il faut choisir si le personnage
doit être poussé horizontalement ou verticalement. Le choix se fait de la façon suivante : il
sut de comparer la "taille" de la collision projetée sur l'axe horizontal à celle projetée sur
l'axe vertical. La gure (4.3) illustre cet exemple : pour le premier cas l'objet sera poussé vers
le haut ; pour la second cas il sera poussé vers la gauche.

                   Figure 4.3      Deux résultats de collisions du même coin.

Chapitre 5

Rapport de bogues

Certains bugs n'ont pas pu être corrigés :
 •   Les ammes du lance-ammes traversent les murs.
 •   L'image "tremble" quand le joueur marche contre un mur.
 •   Pas d'animation pour le joueur lançant une grenade.
 •   Le joueur peut se tenir debout sur le coin des murs, permettant de remonter les empillages
     de caisses.

                                             14

Chapitre 6

Conclusion

  Etant donné les problèmes rencontrés au niveau de la programmation de la classe Enemy et
de la gestion de leur intelligence articielle, il serait préférable de corriger quelques points de
l'architecture si la perspective d'une reprise du projet était envisagée.

  Des problèmes sont également survenus au niveau de la gestion du projet et résultent d'un
manque d'expérience : nous avons eu du mal à nous projeter dans le temps pour évaluer la
faisabilité du projet. Ceci explique que certaines fonctionnalités évoquées dans le cahier des
charges n'ont pas pu être développées dans les temps.

  Cependant, la reprise du projet est tout à fait possible ; seules quelques modications de
l'existant sont nécessaires, et seul le temps manque à l'ajout de nouveau niveaux, ennemis,
armes, et nouvelles fonctionnalités.

                                                15

Annexe

Diagramme de Gantt

          Annexe 1  Diagramme de Gantt : Étape 0 et brainstorming

     Annexe 2  Diagramme de Gantt : Développement et correction des bugs

                                     16

CHAPITRE 6.   CONCLUSION                                             17

               Annexe 3  Diagramme de Gantt : Écriture du rapport

CHAPITRE 6.   CONCLUSION                                          18

                 Annexe 4  Diagramme de Gantt : Vue d'ensemble