Rapport de projet Metal Slug

Université de Montpellier
Faculté des Sciences
Rapport de projet
Metal Slug
Thomas BONNIN
Jules GIRARD
Gilles SILOTIA
Pascal WAGNER
19 janvier 2016
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
3
4
2.3
Storyboard
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Spécications non-fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.5
Spécications bonus
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de projet
9
3.1
Étapes du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
Dicultés rencontrées
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
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
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
4.2
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éussira 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 conception. 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 Informatique à 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 mouvements et actions possibles de son personnage en nous appuyant sur la gure 2.2.
CHAPITRE 2.
6
CAHIER DES CHARGES
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 animations 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 bibliothèque SFML.
La SFML(Simple and Fast Multimedia Library) permet la conception d'application multimedia 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 bibliothè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
1
Git 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éveloppement.
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 particuliè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éalisé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, munitions...).
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
Lecture simple
13
: 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
Annexe 3 Diagramme de Gantt : Écriture du rapport
17
CHAPITRE 6.
CONCLUSION
Annexe 4 Diagramme de Gantt : Vue d'ensemble
18