SlideShare une entreprise Scribd logo
´Ecole pour l’informatique et les techniques avanc´ees
Rapport de projet
Un jeu de Mushroom Compiler
Ann´ee scolaire 2013-2014
Projet d’InfoSup
Villejuif, le 13 juin 2014
Alexandre Doussot Chady Dimachkie Benjamin R´echou
dousso a dimach c rechou b
chip-ninja() Page 2 sur 78
Sommaire
1 Introduction 5
2 Le groupe 6
2.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Architecture du code 9
3.1 H´eritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 ´Etats du personnage . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Moteur de Tuiles 13
4.1 Impl´ementions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Fonctionnalit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Moteur Physique 14
5.1 Physique des personnages . . . . . . . . . . . . . . . . . . . . . 14
5.2 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6 Moteur Graphique 22
6.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Rayons cr´epusculaires . . . . . . . . . . . . . . . . . . . . . . . . 31
6.3 Moteur `a particules . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4 Arri`ere-plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7 Gameplay 39
7.1 Le coeur du gameplay . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 Ajouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8 Contenu 41
8.1 Graphismes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.2 Niveaux Artisanaux . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Mushroom Compiler 2
chip-ninja() Page 3 sur 78
8.3 Generation Proc´edurale . . . . . . . . . . . . . . . . . . . . . . 43
8.4 Musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.5 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9 Outils de developpement 48
9.1 ´Editeur de niveau . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10 Intelligence Artificielle 49
10.1 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.3 Bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11 R´eseau 50
11.1 Multijoueur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.2 Pr´esentation du mode de jeu . . . . . . . . . . . . . . . . . . . 50
11.3 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12 Site Internet 55
12.1 Responsive Design . . . . . . . . . . . . . . . . . . . . . . . . . 55
12.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13 Conclusions personnelles 57
13.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . . . . 58
13.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . . . . 59
14 Conclusion 60
Annexes 61
A Comment lire ce rapport ? 61
B R´ef´erences 62
C Moteur Physique 63
C.1 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
D R´eseau 66
D.1 Formatage des donn´ees . . . . . . . . . . . . . . . . . . . . . . 66
Mushroom Compiler 3
chip-ninja() Page 4 sur 78
E Images 68
E.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 68
E.2 Ennemis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
E.3 Personnage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
F Glossaire 71
Mushroom Compiler 4
chip-ninja() Page 5 sur 78
1 Introduction
Dans le cadre de nos ´etudes `a ´Epita, nous avons eu `a r´ealiser un
projet libre en groupe pendant sept mois pour notre ann´ee d’Infosup.
Ce projet a pour but de nous permettre d’appliquer ce qui `a ´et´e vu
durant l’ann´ee, que ce soit en TP, en algorithmique, en m´ethodologie
ou en SI.
Notre groupe, Mushroom Compiler, est actuellement compos´e des
membres suivants : Alexandre Doussot, Chady Dimachkie, Benjamin
R´echou.
Le sujet ´etant libre, nous avons d´ecid´e de le d´edier `a une passion
qui nous est commune : un jeu vid´eo. C’est un sujet qui, en plus d’ˆetre
int´eressant `a un niveau personnel, requiert un tr`es vaste domaine de
comp´etence. Ce projet pluri-disciplinaire n’est donc qu’`a but purement
didactique.
Le jeu a ´et´e r´ealis´e en C# `a l’aide de la s´erie d’outils XNA.
Les multiples facettes interd´ependantes que composent un jeu
vid´eo sont ´egalement parfaites pour affˆuter notre sens de travail en
groupe. C’est ainsi que nous avons r´ealis´e des moteurs de tuile, gra-
phique, et physique, une architecture r´eseau, une intelligence artifi-
cielle, un gameplay, du contenu et des outils pour nous aider.
Mushroom Compiler 5
chip-ninja() Page 6 sur 78
2 Le groupe
2.1 Alexandre Doussot
Un jour, en 5e, m’a ´et´e pos´e la question suivante : ”Que vas-tu faire
plus tard ?”. Ayant longtemps refl´echi, et ne pouvant me d´ecider,
non pas par une trop grande h´esitation, mais plutˆot par une ab-
sence d’envies, je finis par ´ecrire ”Programmeur de jeux vid´eo”, ´etant,
comme la plupart de mes contemporains, assez vers´e dans le m´edium
vid´eoludique. C’est ainsi que je me mis `a m’interesser de plus pr`es `a
l’informatique et plus particuli`erement au langage C, un des langages
les plus vieux et les plus matures utilis´e aujourd’hui. Progressant donc
`a l’aide du Site du Z´ero, aujourd’hui renomm´e en OpenClassrooms, je
me mis ensuite au Java, qui me fit d´ecouvrir le potentiel ´eblouissant
de la Programmation Orient´ee Objet, dont je ne maˆıtrise, mˆeme au-
jourd’hui, qu’une infime fraction. C’est par la suite que je m’int´eressai
au C++, qui pour moi, r´eunit les avantages d’un langage fort dans un
environnement de d´eveloppement ´eprouv´e et de la Programmation
Orient´ee Objet.
`A mon grand d´epit, mon lyc´ee n’offrit pas l’option ISN. Cepen-
dant, ´etant en Terminale S-SI, je profitai du projet pluri-disciplinaire
pour effectuer un sujet le plus proche possible de l’informatique, et
finis par cr´eer un logiciel contrˆolant un robot Lego, et lui permettant
d’emprunter un trajet pr´ed´etermin´e.
C’est me rapprocher durant la fin de l’ann´ee-scolaire 2012-2013
de personnes faisant parti de la future promotion 2018 et de la pro-
motion 2017 qui me poussa `a essayer les syst`emes UNIX, et plus
particuli`erement GNU/Linux. Je fus conquis par la puissance du
syst`eme et suis aujourd’hui l’heureux possesseur d’une distribution
linux nomm´e Arch.
`A l’´Epita, j’ai d´ecouvert le Caml, et, nonobstant mon amour pour
l’orient´e objet, la programmation fonctionnelle m’a introduit `a un tout
nouveau mode de pens´ee que je trouve grandement int´eressant.
Mushroom Compiler 6
chip-ninja() Page 7 sur 78
Finalement, je suis tr`es heureux de pouvoir enfin r´ealiser un jeu
vid´eo, un de mes d´esirs les plus chers depuis des ann´ees, n’ayant pas
eu assez de temps libre au lyc´ee.
Dans ce rapport, tout ce que j’ai r´ealis´e sera en bleu.
2.2 Chady Dimachkie
Lors de ma jeunesse, je n’avais pas d’ordinateur chez moi, mais
une lassante console qui m’a d´etourn´e des appareils num´eriques. Heu-
reusement, en d´ebut de coll`ege, mes parents achet`erent un ordinateur
portable avec le fameux syst`eme Windows XP. Je fus fascin´e par la
complexit´e d’un tel syst`eme dans une si petite machine. Naturelle-
ment, je me suis int´eress´e au fonctionnement d’une telle machine,
ce qui m’a pouss´e, plus tard, vers les langages de programmation,
plus particuli`erement, le langage C. Celui-ci me permit d’exploiter les
possibilit´es de mon mat´eriel. Je compris, ainsi, tout ce que pouvais
m’offrir ma machine.
Plus tard, au lyc´ee, apr`es avoir fait assez de C, je me retirai une
couche d’abstraction pour aller plus bas, en assembleur et je d´ecouvris
l’architecture de ma machine et commenc¸ais `a essayer de comprendre
le fonctionnement des architectures de nos syst`emes d’information. Je
m’y int´eressais tellement, que je d´ecidais de commencer un syst`eme
d’exploitation tr`es basique en 16-bits avec Netwide Assembly (NASM).
Celui-ci disposait du syst`eme de fichier CAT16 et d’un mode graphique
VESA, avec certaines interruptions faites par moi-mˆeme.
Je quittai ce projet, bien trop long et complexe et je me remis `a faire
du C, pour enfin arriver au C++, me permettant d’utiliser les APIs
OpenGL et Direct3D avec leur langage de shaders respectifs. C’est
ainsi que j’ai acquis de l’exp´erience dans le domaine du rendu et que
je me mis `a rajouter des effets pour un rendu de meilleur qualit´e pour
notre projet. Bien sˆur, j’ai voulu essayer d’autres domaines, comme le
r´eseau ou le d´eveloppement d’une intelligence artificielle et mˆeme la
cr´eation de contenu pour le jeu. De cette mani`ere, j’essaye de toucher
Mushroom Compiler 7
chip-ninja() Page 8 sur 78
`a plusieurs domaines, tous diff´erents les uns des autres, pour acqu´erir
plus de comp´etences en informatique.
Dans ce rapport, tout ce que j’ai r´ealis´e sera en orange.
2.3 Benjamin R´echou
´Etant petit j’ai toujours voulu savoir pourquoi, cette ´eternelle ques-
tion m’a amen´e `a d´emonter la majorit´e des choses que j’ai pu trouver
`a l’´epoque. J’ai dans un premier temps pens´e `a m’orienter vers l’hor-
logerie. Mais une de mes grandes passions de l’´epoque ´etant les jeux
vid´eo je me suis donc int´eress´e `a l’informatique assez tˆot. D´es que j’eut
acc`es `a Internet je me mis `a faire mes recherches pour comprendre du
mieux que je pouvais ces jeux que j’aimais tant.
J’ai rapidement r´ealis´e les possibilit´es offertes par l’informatique et
j’ai donc commenc´e en 5eme `a coder de petit programmes en suivant
des tutoriels sur internet. Au lyc´ee j’ai rapidement arrˆet´e de coder car
j’ai ´et´e pris d’une nouvelle passion, la physique-chimie et la m´ecanique.
J’ai donc commenc´e a bricoler un peu ce que je pouvais chez moi et
en terminale j’ai choisi option Physique-Chimie, choix que je n’ai pas
regrett´e. Malgr´e tout cela je ne voyais aucune perspective d’avenir
que me satisfasse. Je me suis orient´e vers EPITA pour renouer avec
une vieille passion, de plus un ing´enieur est amen´e `a chercher et `a
comprendre le pourquoi et comment des choses ce qui me semble la
chose la plus adapt´e `a ma nature curieuse.
C’est donc en cherchant un moyen d’associer passion et avenir que
je me suis tourn´e vers l’EPITA. Pour le projet de premi`ere ann´ee, j’ai
trouv´e deux personnes qui aiment au moins autant que moi le jeu
vid´eo et de ce fait j’´etais tr`es motiv´e pour cet ambitieux projet. Malgr´e
mes lacunes en informatique je suis rest´e convaincu qu’il me suffirait
de m’y int´eresser suffisamment pour que c¸a se fasse. Notre projet me
permet de r´ealiser un rˆeve d’enfant tout en apprenant l’informatique,
que demander de plus ?
Dans ce rapport, tout ce que j’ai r´ealis´e sera en violet.
Mushroom Compiler 8
chip-ninja() Page 9 sur 78
3 Architecture du code
3.1 H´eritage
Dans ce projet, il a ´et´e d´ecid´e de repr´esenter chaque entit´e pr´esente
en jeu par une classe. Cependant, cela pose un probl`eme. En effet, cr´eer
une classe par ennemi a pour effet de dupliquer le code, car les ennemis
ont des similarit´es. Pour cela, `a ´et´e utilis´ee une notion fondamentale de
la programmation orient´ee objet, l’h´eritage. Elle permet entre autres la
r´eutilisabilit´e et l’adaptabilit´e des objets grˆace au polymorphisme. Elle
se nomme ainsi car le principe est en quelque sorte le mˆeme que celui
d’un arbre g´en´ealogique. Le principe est simple. Une classe m`ere est
d´efinie, avec ses attributs, dont toutes ses classes h´eritantes, appel´ees
classes filles , h´eritent. Cependant, une seule classe m`ere ne suffit
pas. C’est pour cela qu’a ´et´e utilis´e l’h´eritage multiple. Ainsi, chaque
entit´e h´erite d’une classe m`ere DrawableEntity qui h´erite elle-mˆeme
de Entity.
Figure 1 – H´eritage des entit´es
Mushroom Compiler 9
chip-ninja() Page 10 sur 78
3.2 Composants
Une des particularit´es d’XNA est de nous permettre de d´efinir
des composants. XNA en poss`ede principalement deux : les Game
Components et les DrawableGameComponent. Un objet h´eritant de la
classe GameComponent se verra mis `a jour `a chaque tour de la boucle
de jeu automatiquement par XNA, ce qui permet de ne pas surcharger
le code. Un objet h´eritant de DrawableGameComponent, quant `a lui, se
verra mis `a jour, mais ´egalement dessin´e automatiquement par XNA.
3.2.1 Gestionnaire d’entr´ees
Pour g´erer les entr´ees du joueur, lorsque celui-ci appuie sur un
bouton par exemple, il a fallu cr´eer une classe nomm´ee InputHandler.
Celle-ci permet, lorsque le joueur appuie sur un bouton, d’effectuer une
action correspondante. Ainsi, lorsque le joueur appuiera par exemple
sur le clic droit de la souris, le personnage sautera. Cependant, grˆace
`a l’impl´ementation d’un patron de conception (aussi appel´e design
pattern ) d´eriv´e du patron Commande , le gestionnaire peut, au
lieu de contrˆoler le personnage, permettre au joueur de contrˆoler un
ennemi. En effet, les ennemis comme le joueur h´eritent de la classe
nomm´ee GameActor. Ainsi, grˆace au polymorphisme, qui permet de
consid´erer une classe comme une de ses classes m`eres, le gestionnaire
prend en param`etre l’entit´e `a laquelle il demande de r´ealiser une
action, et non seulement le h´eros.
Comme il est imp´eratif de consid´erer les entr´ees du joueur `a chaque
tour de boucle, elle est ´evidemment consid´er´ee comme un composant,
et donc h´erite de la classe GameComponent.
`A chaque tour de boucle, le gestionnaire r´ecup`ere l’´etat du clavier,
l’´etat dans lequel se trouve le jeu, ainsi que l’entit´e sur laquelle il doit
agir. Cela permet d’avoir une plus grande flexibilit´e, et d’avoir des
actions contextuelles `a l’´etat du jeu. Par exemple, lorsque le joueur
appuie sur une touche fl´ech´ee, le gestionnaire effectuera des actions
diff´erentes selon l’´etat : le curseur se d´eplacera dans les menus si le
Mushroom Compiler 10
chip-ninja() Page 11 sur 78
joueur se trouve sur le menu de pause, et le personnage se d´eplacera
si le joueur est en jeu.
3.2.2 Gestionnaire d’´etats
Un jeu peut se trouver dans plusieurs ´etats, ou ´ecrans, comme
l’´ecran titre, le jeu, l’´ecran de fin de jeu, ou les options. Pour mod´eliser
cela, il a fallu cr´eer un syst`eme de gestion. En effet, a ´et´e cr´ee une classe
nomm´ee GameStateManager dont le rˆole est de g´erer les diff´erents
´ecrans. Cette classe poss`ede comme attribut un objet GameState qui
symbolise l’´ecran actuel. Celui-ci, repr´esent´e par une classe, se trouve
ˆetre en fait la classe m`ere de chacun des diff´erents ´etats. Ceux-ci
sont donc ´egalement repr´esent´es par des classes, avec chacune leurs
sp´ecificit´es, comme leurs attributs, ainsi que leurs m´ethodes de mise
`a jour et de dessin. C’est une technique efficace car elle permet la
m´emorisation des ´etats, ce qui est utile lorsque le joueur quitte les
options pour revenir au jeu.
3.2.3 Gestionnaire d’arri`ere-plans
Le temps accord´e `a la r´ealisation de ce projet, assez r´eduit pour
un jeu vid´eo, nous a incit´e `a mettre en place un certain nombre
de concepts. Ainsi, ont ´et´e impl´ement´es de diff´erents arri`ere-plans
pour chaque niveau, introduisant de la vari´et´e visuelle. Cependant, la
diff´erence n’est pas que visuelle, elle est ´egalement technique. En effet,
les arri`eres-plans n’utilisent pas les mˆeme techniques ; certains utilisent
des arri`ere-plans en parallaxe, d’autres des rayons cr´epusculaire, ou
d’autres encore du normal mapping. Ainsi, sur le mˆeme principe que
pr´ec´edemment, mais `a plus petite ´echelle, est pr´esent un gestionnaire
d’arri`ere-plans, repr´esent´e par une classe nomm´ee BackgroundManager.
Chaque arri`ere-est quant `a lui repr´esent´e par une classe correspon-
dante, sobrement nomm´ees Background1, Background2 et ainsi de
suite.
Mushroom Compiler 11
chip-ninja() Page 12 sur 78
3.3 ´Etats du personnage
Le personnage contrˆol´e par le joueur est un syst`eme complexe, `a
plusieurs ´etats. En effet, le joueur peut ˆetre en train de courir ou de
marcher, ainsi qu’il peut ˆetre en train de sauter ou mˆeme de double-
sauter. Pour visualiser ce syst`eme nous utilisons deux automates finis
imbriqu´es, ce qui correspond au patron ”´Etat”. Un automate fini,
´egalement appel´e machine avec un nombre fini d’´etats, est un syst`eme
compos´e d’´etats et de transitions. Leur particularit´e est que l’automate
ne peut avoir qu’un ´etat valide `a la fois, et qu’il passe d’un ´etat `a
l’autre selon certaines conditions.
Ainsi, l’automate d´ecrivant le personnage est compos´e de deux
automates imbriqu´es. Le premier, imbriqu´e dans le second, d´ecrit les
´etats du personnage au sol. De fac¸on similaire aux ´etats de jeu, ceux-ci
sont d´ecrits par des classes h´eritant de la classe PlayerState. Ils sont
au nombre de trois : <Arr^et,Marche,Course>.
Le second, quant `a lui, d´ecrit les ´etats du joueur sur le plan ho-
rizontal. Il comprend <Sur le sol, En saut, En double-saut>. Il a
fallu imbriquer les deux automates car le joueur ne saute pas de la
mˆeme fac¸on selon qu’il soit en train de courir ou de marcher.
Mushroom Compiler 12
chip-ninja() Page 13 sur 78
4 Moteur de Tuiles
Le projet a pour but de r´ealiser un jeu de plate-forme s’inspirant des
jeux iconiques. C’est pourquoi il a fallu impl´ementer ce qu’on appelle
un moteur de tuiles. Un moteur de tuiles permet fondamentalement
d’afficher un niveau compos´e de petits blocs, appel´es tuiles , d’une
taille pr´ed´efinie.
4.1 Impl´ementions
Dans notre projet, un niveau est d´efini par ses m´eta-donn´ees, ainsi
que l’emplacement et la nature des diff´erents blocs qui le composent
qui sont stock´es dans ce que nous appelons une tile map , ou
carte de tuile, qui est un tableau `a deux dimensions. Un niveau est
repr´esent´ee par un fichier contenant premi`erement les m´eta-donn´ees
correspondantes, puis sa tile map.
4.1.1 M´eta-donn´ees
Un niveau poss`ede plusieurs m´eta-donn´ees. Premi`erement, les di-
mensions du niveau. Deuxi`emement, la taille en pixels que mesure
une tuile. Ensuite, l’ensemble des images associ´es `a chacune des tuiles,
aussi appel´ee tileset , suivie de l’arri`ere-plan. Par la suite, la po-
sition `a laquelle le joueur commence. Derni`erement, les r`egles de
gameplay s’appliquant au niveau.
4.2 Fonctionnalit´es
Le moteur fait cependant plus que de charger et afficher des ni-
veaux. En effet, il permet de modifier le niveau en temps r´eel. Par
exemple, si un joueur attaque `a plusieurs reprises une tuile, celle-ci
pourra se briser, et disparaˆıtre.
Mushroom Compiler 13
chip-ninja() Page 14 sur 78
5 Moteur Physique
5.1 Physique des personnages
5.1.1 D´eplacement
Le personnage poss`ede diff´erents types de d´eplacement, qui d´epen-
dent de l’´etat dans lequel se trouve le joueur. En effet, il ne se d´eplace
pas de la mˆeme fac¸on selon qu’il soit sur le sol ou dans les airs. Ainsi,
lorsqu’il se d´eplace sur le sol, il se d´eplace `a une vitesse constante
et peut se retourner imm´ediatement, bien qu’il poss`ede une inertie `a
l’arrˆet.
Pour ajouter de l’inertie `a l’arrˆet, il suffit, en lieu de changer brus-
quement la vitesse du personnage en 0, de la multiplier par un nombre
symbolisant la perte de vitesse.
Ainsi, lorsque le joueur marche et s’arrˆete, on multiplie sa vitesse
par 0.8 `a chaque image, soit toutes les 1/60e de secondes. Cependant,
lorsque le joueur est dans les airs et se retourne, le joueur va changer
de direction progressivement. Il va d’abord ralentir horizontalement,
puis se d´eplacer dans une direction inverse. L’inertie est donc bien
plus prononc´ee dans cet ´etat.
5.1.2 Gravit´e
Le moteur physique permet ´egalement de jouer avec la gravit´e
des personnages. On peut en effet la modifier pour l’att´enuer ou au
contraire la renforcer, ou mˆeme l’inverser.
5.2 Collisions
Un syst`eme bas´e sur tuiles de fac¸on fluide a ´et´e utilis´e pour la
d´etection d’obstacles. C’est un syst`eme qui ´etait vastement utilis´e
sur les syst`emes 8 et 16 bits et qui reste pertinent aujourd’hui. Il
n’est pas tr`es dur `a impl´ementer, tr`es flexible, permet d’´editer des
niveaux simplement, et permet d’utiliser des inclinaisons. Le principe
Mushroom Compiler 14
chip-ninja() Page 15 sur 78
est simple : Lorsque le joueur se d´eplace, on regarde l’emplacement
de l’obstacle le plus proche dans la direction dans lequel le joueur se
meut.
Si obstacle il y a, alors on fera en sorte qu’il se d´eplace de la distance
minimale entre la distance dont il ´etait cens´e se d´eplacer et la distance
entre l’obstacle et lui. En pratique, il suffit de parcourir le tableau
symbolisant le niveau pour chaque rang´ee sur laquelle le joueur se
trouve pour obtenir la position de l’obstacle.
5.3 Attaque sp´eciale
Afin de placer une distinction entre notre personnage, qui est un
ninja, et les autres, il a fallu le doter d’une attaque sp´eciale vraiment
particuli`ere. Celle-ci se devait d’ˆetre impressionnante au point de
donner envie au joueur de l’ex´ecuter. Ainsi, nous avons pens´e `a une
attaque sp´eciale permettant de d´ecouper l’ennemi vis´e en autant de
morceaux que voulu, c’est-`a-dire, en un nombre virtuellement infini.
Pour cela, il fallait un algorithme capable de d´ecouper n’importe quel
polygone pour en recr´eer d’autres.
5.3.1 Sutherland-Hodgman
L’algorithme de Sutherland-Hodgman est, `a la base, utilis´e pour
faire du clipping . Le clipping est le proc´ed´e permettant de
d´eterminer la partie d’une r´egion d’un espace se trouvant dans une
autre r´egion d’un autre espace.
Ce genre de technique est fortement utilis´ee lorsqu’il y a un rendu
graphique `a l’´ecran et qu’il faut trouver quelles parties ne sont pas vi-
sibles `a l’´ecran pour ne pas les dessiner, et ainsi optimiser les temps de
calculs. Bien sˆur, son utilisation va en ˆetre diff´erente, mais le principe
reste le mˆeme.
Avec cet algorithme, en prenant une liste de sommets d’un poly-
gone et une liste de plans, ainsi qu’une liste de nouveau sommets
Mushroom Compiler 15
chip-ninja() Page 16 sur 78
Figure 2 – Clipping d’un cube par un plan
existant uniquement dans cet ensemble de plan, on peut appliquer du
clipping. Sachant que notre jeu est en deux dimensions (2D) et que
le personnage d´ecoupera l’ennemi avec un sabre, la liste de plans n’en
contiendra qu’un et sera une ligne.
Figure 3 – Clipping d’un rectangle par une droite
Pour ceci, il est utile de connaˆıtre le cˆot´e sur lequel le sommet
en cours de traitement se trouve par rapport au plan (`a la ligne) de
d´ecoupe. Ainsi, il suffit d’effectuer un simple produit scalaire, tel que :
Figure 4 – Distance d’un point par rapport `a un plan
Soient p2 un point quelconque sur le plan de d´ecoupe et n un
Mushroom Compiler 16
chip-ninja() Page 17 sur 78
vecteur normal au plan. Pour connaˆıtre la direction du point p1 par
rapport au plan, le signe du r´esultat d est utilis´e. Ensuite, il faut d´efinir
ce que repr´esentent l’avant et l’arri`ere du plan. L’avant est
dans la direction de la normale n du plan et l’arri`ere dans le sens
oppos´e. Apr`es cela, il faut pouvoir calculer une intersection d’un plan
et d’une ligne ou plutˆot d’un plan et d’un point d’une ligne. Cela est
fait grˆace `a une interpolation lin´eaire, telle que :
Lerp = d´ebut + alpha ∗ (fin − d´ebut). que l’on re-factorise en :
(1 − alpha) ∗ d´ebut + alpha ∗ fin
pour ´eviter les erreurs dues aux impr´ecisions sur les nombres `a vir-
gule flottante et pour pouvoir garantir l’existence du cas o`u le point
recherch´e est au mˆeme endroit que fin lorsque alpha vaut 1.
Finalement, il faudra une liste de sommets que l’on appellera
front .
Avec tout ceci, l’application de l’algorithme de Sutherland-Hodgman
est possible. Les ´etapes `a effectuer se r´esument facilement :
- Si p1 et p2 sont `a l’avant
- Mettre p2 dans front
- Si p1 est `a l’avant et p2 `a l’arri`ere
- Mettre le point d’intersection de la droite (p1,p2)
et du plan de d´ecoupe dans front
- Si p1 est `a l’arri`ere et p2 `a l’avant
- Mettre le point d’intersection de la droite (p1,p2)
et du plan de d´ecoupe dans front
- Mettre p2 dans front
Le probl`eme ici, c’est que l’on aura un polygone `a l’avant seulement,
alors que nous en voulons des deux cˆot´es pour donner un effet de
d´ecoupe. Il faut donc modifier tout cela et rajouter une deuxi`eme
liste que l’on appellera back . Il faut aussi d´efinir ce qu’est le fait
d’ˆetre dans le plan de d´ecoupe. De cette mani`ere, une ´epaisseur de
d´ecoupe pourra ˆetre simul´ee et on la nommera EPSILON. De ce fait,
Mushroom Compiler 17
chip-ninja() Page 18 sur 78
ˆetre sur le plan signifie : n’ˆetre ni `a l’avant, ni `a l’arri`ere du plan, c’est-
`a-dire que la distance du point sur le plan est inf´erieure `a EPSILON et
est sup´erieure `a −EPSILON. Il faut ´egalement ordonner les sommets
de ces listes, de telle mani`ere `a ce qu’ils puissent ˆetre trait´e par un
processeur graphique et donc avoir lors d’une d´ecoupe, des polygones
compos´es de la mani`ere suivante :
Figure 5 – D´ecoupe d’un triangle
Ainsi, l’algorithme devient :
- Si p1 et p2 sont `a l’avant
- Mettre p2 dans front
- Si p1 est dans le plan et p2 `a l’avant
- Mettre p2 dans front
- Si p1 est `a l’arri`ere et p2 `a l’avant
- Mettre le point d’intersection de la droite (p1,p2)
et du plan de d´ecoupe dans front et dans back
- Mettre p2 dans front
- Si p1 est `a l’avant et p2 `a l’arri`ere
- Mettre le point d’intersection de la droite (p1,p2)
et du plan de d´ecoupe dans front et dans back
- Mettre p2 dans back
- Si est p1 `a l’avant et p2 est dans le plan
- Mettre p2 dans front
- Si p1 et p2 sont dans le plan
- Mettre p2 dans front
- Si est p1 `a l’arri`ere et p2 est dans le plan
Mushroom Compiler 18
chip-ninja() Page 19 sur 78
- Mettre p2 dans front et dans back
- Si p1 est dans le plan et p2 `a l’arri`ere
- Mettre p1 et p2 dans back
- Si p1 et p2 sont `a l’arri`ere
- Mettre p2 dans back
Ces 9 cas permettent d’avoir ceci :
Figure 6 – D´ecoupe d’un rectangle par une ligne
Apr`es cela, ces listes de sommets sont donn´ees `a notre processeur
graphique. Celui-ci va pouvoir faire le rendu voulu si l’on utilise le
format de rendu triangle fan permettant d’avoir des polygones
compos´es de triangles partageant un mˆeme sommet.
Figure 7 – Assemblage de triangle
Enfin, il reste `a traiter les coordonn´ees de notre texture, pour qu’elle
ait l’air d’ˆetre appliqu´ee correctement `a notre ennemi d´ecoup´e. L’es-
pace de coordonn´ee des textures, nomm´e l’espace de coordonn´ees
UV , est tel que :
Mushroom Compiler 19
chip-ninja() Page 20 sur 78
Figure 8 – Coordonn´ees UV
Bien sˆur, ce n’est pas tout, puisque nous faisons un rendu mais avec
la mˆeme texture appliqu´ee `a chaque polygone de l’ennemi d´ecoup´e.
C’est-`a-dire qu’`a l’´ecran il y aura plusieurs fois la mˆeme texture,
comme si l’ennemi s’´etait multipli´e, mais avec une nouvelle forme `a
chaque fois.
Figure 9 – Bonne et mauvaise d´ecoupe
Comme est visible sur l’image, le r´esultat du haut est ce qui est
d´esir´e alors que celui du bas a rec¸u un traitement incorrect. Les tri-
angles sont mis en ´evidence pour montrer qu’il s’agit d’un traitement
o`u chaque polygone est pris individuellement. Pour r´esoudre cela, une
matrice de passage pourrait ˆetre utilis´ee, mais il y a plus simple pour
passer des coordonn´ee de l’espace ´ecran en coordonn´ees UV.
Pour calculer la coordonn´ee U, la longueur du cˆot´e du dessus
Mushroom Compiler 20
chip-ninja() Page 21 sur 78
du rectangle de base formant le personnage est utilis´ee, servant de
r´ef´erence. Ensuite, le cˆot´e le plus long entre le haut et le bas est pris
et la diff´erence entre la r´ef´erence et ce cˆot´e permettra d’avoir les co-
ordonn´ees de mani`ere assez pr´ecise. Pour la coordonn´ee V, la mˆeme
proc´edure est effectu´ee, mais avec les cˆot´e droit et gauche.
Avec tout ceci, la d´ecoupe est comme voulue initialement.
5.3.2 Ajout de physique
Pour donner un meilleur effet et pour que le tout ne soit pas sta-
tique, il fallait int´egrer un moteur physique aux morceaux d´ecoup´es
de l’ennemi. Ainsi, l’effet serait meilleur et celui-ci serait proche de ce
que propose le jeu vid´eo Metal Gear Rising : Revengeance, bien qu’en 2D.
Une longue r´eflexion `a ´et´e port´ee `a l’´etude et la reproduction
d’un mod`ele physique coh´erent et adapt´e, mais pour des raisons de
concision, le lecteur pourra retrouver le cheminement math´ematique
menant `a ce r´esultat en Annexe, partie C.1.
Ce mod`ele permet d’obtenir une physique cr´edible, comme il est
possible de le constater dans la capture d’´ecran suivante, o`u un ennemi
est d´ecoup´e en 26 morceaux, tous affect´es par leur environnement.
Figure 10 – Rendu non final
Mushroom Compiler 21
chip-ninja() Page 22 sur 78
6 Moteur Graphique
6.1 Normal Mapping
Pour des niveaux dans le noir, il fallait avoir de l’´eclairage pour
donner cet effet d’obscurit´e. De ce fait, pour avoir un tel effet, qui
soit ´egalement agr´eable `a regarder, il fallait une solution. Ainsi, la
technique du normal mapping a ´et´e choisie, permettant des effets
de r´eflections dynamiques en temps r´eel, en se basant sur un certain
mod`ele physique.
6.1.1 D´efinition
Le normal mapping est une technique permettant de simuler
des d´etails de tr`es haute qualit´e sur un mod`ele de faible qualit´e, en
termes de polygones. Tout ceci est r´ealis´e avec un coˆut, au niveau des
performances, tr`es acceptable. Cette technique est tr`es utilis´ee dans les
jeux vid´eos en 3D.
Dans ce projet, sont pr´esents des fonds, par exemple des murs,
auxquels sera appliqu´ee cette technique, ce qui permet d’avoir des
r´eflections dynamiques et en temps r´eel de lumi`ere.
En effet, le normal mapping se base sur la mani`ere dont les
r´eflections de lumi`eres sont d´ecrites pour donner une telle illusion. Et
c’est bien cette caract´eristique de l’effet que l’on va utiliser, ainsi il y
aura des r´eflections dynamiques et en temps r´eel lorsqu’une lumi`ere
qui passera devant un quelconque objet ou fond.
Figure 11 – Technique du normal mapping
Mushroom Compiler 22
chip-ninja() Page 23 sur 78
6.1.2 Principe
Pour cet effet, il faudra cr´eer une image appel´ee normal map, telle
que pour un texel (Texture ´el´ement, ´equivalent d’un pixel, mais pour
une texture), les composantes R, G et B encoderont un vecteur de
composante X, Y et Z, avec X vers la droite et Y vers le haut.
Figure 12 – Une texture et sa Normal map
Les composantes R, G et B sont comprises entre 0 et 1 et X,Y et Z
entre -1 et 1. Avec ce vecteur, il faut pouvoir retrouver une normale,
une tangente et une bitangente. Ceux-ci, vont nous permettre de cr´eer
une matrice d´efinissant un espace.
On peut facilement avoir la normale, en faisant :
ComposanteNormale = (2 ∗ composanteCouleur) − 1
Nous avons d´ej`a la normale, laquelle nous permet de trouver une
tangente. En th´eorie, pour choisir une tangente, il est possible de
prendre n’importe laquelle, vu qu’il y en a une infinit´e, et pourtant,
pour ´eviter des probl`emes qui d´et´erioreraient la qualit´e de certains
cˆot´es, il faut prendre la tangente (voir annexe- Normale et Tangente)
allant dans la mˆeme direction que les coordonn´ees de notre texture.
(Voir Annexe - Cˆot´es).
Et puisque qu’il nous faut un troisi`eme vecteur pour d´efinir un
espace, il faut cherche une bitangente (voir annexe - Bitangente), qui
sera perpendiculaire `a la tangente, pour faciliter les calculs.
Il faut, maintenant, exprimer nos deux vecteurs. Sachant que notre
texture est plaqu´ee sur des triangles, on peut poser DeltaPosition1
et DeltaPosition2, deux cˆot´es de l’un de nos triangle et deltaUV1 et
Mushroom Compiler 23
chip-ninja() Page 24 sur 78
deltaUV2, les diff´erences respectives des coordonn´ees UVs. Et ainsi,
poser :
DeltaPosition1 = (AbscissededeltaUV1) ∗ Tangente +
(Ordonn´eedeDeltaUV1) ∗ Bitangente
et DeltaPosition2 = (AbscissededeltaUV2) ∗ Tangente +
(Ordonn´eedeDeltaUV2) ∗ Bitangente
Il suffit de r´esoudre ces equations et, nous avons la tangente et
la bitangente. Ce qui nous permet d’avoir notre matrice qui d´ecrit le
changement d’espace entre l’espace bas´e sur les tangentes et l’espace
du mod`ele sur lequel est appliqu´e l’effet.





Tx Bx Nx
Ty By Ny
Tz Bz Nz





Il faut noter qu’il y a 3 dimensions, mˆeme en 2D, puisque l’effet
d’´eclairage donnera un effet de relief 3D.
Cette matrice permet donc de faire des transformations sur des
normales pour les adapter `a l’espace du mod`ele. Mais, nous voulons
faire l’inverse, il faut donc inverser la matrice. Sachant que c’est une
matrice qui repr´esente un rep`ere orthogonal, c’est-`a-dire que chaque
vecteur est perpendiculaire `a un autre, et que nous sommes en 2D et
qu’on n’applique pas de matrice de projection, on a simplement :





Tx Ty Tz
Bx By Bz
Nx Ny Nz





Avec tout ceci, il est possible d’impl´ementer deux shaders, qui,
employ´es avec une certaine m´ethode de rendu, permettra d’avoir
l’effet d´esir´e.
6.1.3 Le rendu
Le rendu d’un environnement qui doit exploiter un tel effet de
lumi`ere dynamique et en temps r´eel, n´ecessite une m´ethode de rendu
qui n’est pas habituelle en 2D.
Mushroom Compiler 24
chip-ninja() Page 25 sur 78
En effet, il va falloir traiter quatre versions de l’image `a laquelle on
veut appliquer l’effet. Il y aura donc : une Color map qui est la texture
´eclair´ee de mani`ere parfaite, puis la normal Map associ´ee. Apr`es
traitement de ces deux l`a, il y aura la shadow map et finalement, la
technique du blending sera utilis´ee, qui nous permet de m´elanger
plusieurs rendus, avec laquelle on m´elangera la shadow map et la
color map, pour obtenir l’image finale `a rendre `a l’´ecran.
6.1.3.a Valse des RenderTargets
Pour faire tout ces rendus, il va nous falloir plusieurs RenderTar-
gets, ceux-ci sont les ´el´ements sur lesquels le rendu sera fait. De mˆeme,
il faut des listes de textures, une liste de color maps et une autre
de normal maps. Finalement, une liste de coordonn´ees qui contient
les d´ecalages de positions entre chaque textures. Cette derni`ere sera
utilis´ee de la mˆeme fac¸on pour la liste de color map et de normal maps.
Remarque : Dans ce qui suit, il y aura beaucoup de changements de
RenderTargets. Il ne sera pas pr´ecis´e qu’`a chaque changement, il fau-
dra passer par le RanderTarget principal, dont l’identifiant est null .
Remarque 2 : Tous les RenderTargets ont les dimensions de l’´ecran.
Ce n’est pas forc´ement le cas des textures.
Premi`erement, toutes les couleurs du RenderTarget principal seront
mises en Noir, ce qui est utile pour nettoyer la zone de rendu. La
couleur noire est utilis´ee pour l’effet d’obscurit´e. Apr`es, on passe au
RenderTarget de color maps qui est nettoy´e en noir, pour pouvoir
dessiner toutes les color maps contenues dans la liste qui leur est
propre en tenant compte des d´ecalages de coordonn´ees pr´ecis´es dans
une liste. Ensuite, on prend le RenderTarget de normal maps dans
lequel on dessine nos normal maps aux mˆeme coordonn´ees que nos
color maps.
Mushroom Compiler 25
chip-ninja() Page 26 sur 78
Tout cela fini, on passe au RenderTarget de la shadow map o`u l’on
pourra rendre celle-ci. Cette ´etape est la plus complexe dans ce rendu
et n´ecessite un shader.
6.1.3.b Rendu de la shadow map
Pour cette ´etape, nous avons d´efini au pr´ealable une liste des
lumi`eres, contenant leur puissance, l’intensit´e de r´eflexion sp´eculaire,
la dur´ee de chaque rayon ´emis, leur position et couleur, ainsi qu’un
´el´ement d´efinissant la couleur et la puissance de la lumi`ere ambiante.
Ainsi, on effectue le traitement qui suit de la mˆeme mani`ere pour
chaque lumi`ere, en tenant compte des diff´erentes valeurs entre cha-
cune.
Tout d’abord, on met en place un vertex buffer, qui est un tableau
de coordonn´ees de sommets, contenant en plus, une couleur pour
chaque sommet (qui n’est pas utile ici, car la couleur finale est r´ealis´e
par interpolation lin´eaire, ce que l’on ne veut pas) et des coordonn´ees
UV de textures. Cette ´etape est tr`es importante, car on ne dessine plus
avec de simples SpriteBatch.
Apr`es cela, il faut utiliser notre shader.
Notre shader va, `a chaque it´eration, prendre la couleur qui se
trouve `a certaines coordonn´ees sur la color map donn´ee au shader.
Apr`es cela, il extrait une normal de la normal map, avec la formule
donn´ee ci-dessus :
Normale.X = (2 ∗ Couleur.R) − 1.0
Normale.Y = (2 ∗ Couleur.G) − 1.0
Normale.Z = (2 ∗ Couleur.B) − 1.0
Ensuite, on convertit les coordonn´ees actuelles, utilis´ees pour par-
courir la color map et la normal map, en coordonn´ees sur l’espace
´ecran :
Mushroom Compiler 26
chip-ninja() Page 27 sur 78
PositionPixel.X = LongueurEcran ∗ AbscisseActuelle
PositionPixel.Y = HauteurEcran ∗ Ordonn´eeActuelle
PositionPixel.Z = 0, car nous sommes en 3D.
Avec c¸a, on peut connaˆıtre la direction de la lumi`ere avec une
soustraction de vecteurs :
DirectionLumi`ere = PositionLumi`ere − PositionPixel
On doit pouvoir normaliser ce vecteur :
DirectionLumi`ereNormlis´e.X = DirectionLumi`ereNormalis´e.X
longueur(DirectionLumi`ere)
DirectionLumi`ereNormlis´e.Y = DirectionLumi`ereNormalis´e.Y
longueur(DirectionLumi`ere)
DirectionLumi`ereNormalis´e.Z = 0
Il faut ´egalement calculer la quantit´e de lumi`ere projet´ee, avec un
produit scalaire :
Quantit´eLumi`ere = Maximum(Normale·Dir´ectionLumi`ereNormalis´e, 0)
Grˆace `a cela, le calcul de l’att´enuation conique nous permet de
donner une projection de la lumi`ere dans le noir en forme de cˆone en
3D et donc de cercle en 2D :
Att´enuationConique = saturate(1.0 −
longueur(DirectionLumi`ere)
Dur´eeDesRayonsDeLumi`ere )
Remarque : La fonction saturate permet de mettre le r´esultat dans
l’intervalle [0, 1].
Ensuite, il faut obtenir le vecteur d´ecrivant la r´eflexion en 3D, par :
R´eflexion = Normaliser(2 ∗ Quantit´eLumi`ere∗
(normale − DirectionLumi`ereNormalis´e))
Mushroom Compiler 27
chip-ninja() Page 28 sur 78
Il reste une derni`ere ´etape avant de pouvoir exprimer la compo-
sante sp´eculaire de notre ´eclairage. Il faut d´efinir ce qu’est, un half
vector :
Dans le fragment shader, les coordonn´ees de sommets qui sont
trait´ees peuvent ˆetre consid´er´ee comme un vecteur qui va de la cam´era
(ou l’oeil du spectateur) jusqu’au fragment (´el´ement contenant toutes
les donn´ees n´ecessaires afin de g´en´erer ou non un pixel). Ainsi, en
inversant la direction de ce vecteur, c’est-`a-dire, en multipliant toutes
ses composantes par -1, le vecteur donnant la direction du regard du
spectateur est obtenu. Sachant que la sc`ene est en 2D, il suffit
d’avoir une composante `a 1 :
HalfVector =





0
0
1





On peut donc maintenant trouver la composante sp´eculaire de
notre ´eclairage :
Sp´eculaire = Minimum((saturate(R´eflexion·HalfVector))10, Quantit´eLumi`ere)
Figure 13 – R´eflexion
Et finalement trouver la couleur que le shader doit renvoyer, qui
est :
Mushroom Compiler 28
chip-ninja() Page 29 sur 78
R´esultat = Att´enuationConique∗CouleurLumi`ere∗Intensit´eLumi`ere
R´esultat = R´esultat +
(Sp´eculaire ∗ Intensit´eSp´eculaire ∗ Att´enuationConique).
Nous avons l`a, la shadow map rendue dans son propre RenderTar-
get.
Bien sˆur, ce n’est pas fini et il reste quelques ´etapes.
6.1.3.c Blending
Apr`es cela, le RenderTarget de base est remit et un deuxi`eme sha-
der est utilis´e pour combiner toutes les maps cr´e´ees pr´ec´edemment.
Ce shader va avoir besoin de toutes les maps cr´e´ees, ainsi, il y
aura besoin de la couleur `a une certaine coordonn´ee des color map et
shadow map. Pour la normal map, il va falloir combiner les couleurs
pour n’obtenir qu’une seule valeur. Il faudra, ´egalement, la couleur,
l’intensit´e et la quantit´e de lumi`ere ambiante, qui seront des valeurs
diff´erentes de pr´ec´edemment car, il y aura d´ej`a eu plusieurs rendus
avec le shader.
De ce fait, la couleur finale sera :
- Si la combinaison des composantes de la couleur de la normal map
aux coordonn´ees actuelles est sup´erieure `a 0.0 )
CouleurFinale = colorMap∗couleurAmbiente∗Intensit´eAmbiante.
Et donc :
CouleurFinale = CouleurFinale + shadowMap ∗ colorMap ∗
Quantit´eLumi`ereAmbiante.
- Sinon :
Mushroom Compiler 29
chip-ninja() Page 30 sur 78
CouleurFinale =








0
0
0
0








= Noir
Tout cela, permet de faire le blending de nos maps et ainsi, le rendu
voulu est obtenu.
6.1.3.d Finalisation
Pour finir et ajuster l’effet le plus proche possible de l’id´ee d’origine,
un BlendState sera d´efini au niveau du GraphicDevice. Celui-ci, va
nous permettre d’ajuster le niveau de noir sur les bords du cercle afin
d’obtenir un effet de qualit´e plus professionnelle .
Figure 14 – Plusieurs sortes de BlendState
On cr´e´ee donc ce BlendState, tel que :
La fonction de blend des couleurs ainsi que de l’alpha sera d’ad-
ditionner les couleurs. La couleur de la destination et de la source,
ainsi que l’alpha de la destination seront multipli´es par :
Blend.One =








1
1
1
1








Et l’alpha de la source sera mis au carr´e et s’il d´epasse 255, il est
ramen´e `a 255. On peut donc poser :
Mushroom Compiler 30
chip-ninja() Page 31 sur 78
CouleurFinale = ((CouleurSource + AlphaSource) ∗








1
1
1
1








)
Et ainsi :
CouleurFinale = CouleurFinale + ((CouleurDestination ∗








1
1
1
1








) +
Saturate(Minimum(AlphaDestination2, 255)))
Nous pouvons, enfin, avoir le rendu en temps r´eel que nous vou-
lions :
Figure 15 – Rendu Final
6.2 Rayons cr´epusculaires
Le ciel est une partie trop souvent statique dans les jeux vid´eos. Il
a donc fallu rajouter un ´el´ement comblant ce d´efaut. L’id´ee d’int´egrer
un effet de rayons cr´epusculaire qui soit `a la fois dynamique et r´ealis´e
en temps r´eel, rendrait le tout agr´eable `a regarder de par son niveau
artistique et technique.
Mushroom Compiler 31
chip-ninja() Page 32 sur 78
6.2.1 Ph´enom`ene
Les rayons cr´epusculaires apparaissent lorsque la propagation de
la lumi`ere du soleil est bloqu´ee par un ´el´ement entre le soleil et le
spectateur. Ceux-ci paraissent diverger directement du soleil. Mais, ils
sont en fait parall`eles, c’est l’effet de perspective qui donne cet effet.
Ils sont intensifi´es par la lumi`ere ambiante. Ces derniers sont surtout
caus´es lorsque l’atmosph`ere contient des particules de poussi`eres, des
mol´ecules de gaz ou autres particules sur lesquels sont projet´ees des
ombres form´ees par ces rayons.
6.2.2 R´ealisation
6.2.2.a Rendu
Afin d’obtenir cet effet, il faut effectuer un rendu en diff´erentes
´etapes.
Premi`erement, on doit prendre une texture repr´esentant un facteur
de flare positionn´ee d’une certaine mani`ere, qui sera rendue dans le
Render Target de base. Un Render Target est un espace o`u le rendu
s’effectue. Deuxi`emement, on dessine tous les ´el´ements de la sc`ene en
noir dans un Render Target s´epar´e. Ceux-ci serviront de masque pour
notre shader, et ainsi seront les objets bloquants le flux de lumi`ere. Il
est `a not´e, qu’il faut des images ayant un format supportant le canal
alpha, tel que le PNG. Ainsi, pour l’instant, le rendu donne ceci :
Figure 16 – Rendu Interm´ediaire
Mushroom Compiler 32
chip-ninja() Page 33 sur 78
Par la suite, le Render Target r´esultant (image ci-dessus) sera donn´e
au Post-Processing Manager qui va traiter le Render Target pour qu’il
soit utilisable par le shader du soleil.
6.2.2.b Le Shader
Pour calculer les rayons cr´epusculaires, il faut se baser sur un
mod`ele physique.
Le mod`ele utilis´e est celui de Hoffman and Mitchell (2002), appuy´e
par celui de Hoffman and Preetham (2003). Le premier mod`ele (2003)
est celui-ci :
, avec D(φ) : la proportion d’´echantillons qui se placent devant la
r´egion ´emettant de la lumi`ere, par rapport `a ceux qui intersectent les
rayons ´emis, nous donne le pourcentage d’occlusion.
Avec s, la distance parcoure sur l’´ecran. θ, l’angle entre le rayon et
le soleil. Esun, l’illumination du soleil. βex, la constante d’extinction
du rayon, compos´ee des propri´et´e d’absorption de la lumi`ere et de sa
dispersion vers un environnement ext´erieur. βsc, la propri´et´e angulaire
du rayon. Le premier terme de cette ´equation calcule la quantit´e de
lumi`ere absorb´ee depuis le point d’´emission jusqu’au point o`u il est
vu. Le second terme calcule la somme des quantit´es de lumi`eres qui
intersectent avec nos rayons de soleil.
Mushroom Compiler 33
chip-ninja() Page 34 sur 78
Apr`es, on simplifie en divisant l’illumination des ´echantillons par
le nombre d’´echantillons et ainsi, on a plus simplement :
Ensuite, on introduit des coefficients pour contrˆoler notre ´equation :
O`u exposure contrˆole l’exposition de l’effet. Ainsi que weight, contrˆolant
l’intensit´e lumineuse de chaque ´echantillon. Puis, decay dans l’inter-
valle [0, 1] r´eduisant l’apport en lumi`ere de chaque rayon, plus leur
distance est grande par rapport `a la source de lumi`ere.
Ensuite, un sous´echantillonnage est effectu´e, c’est-`a-dire que l’on
r´eduit la taille de l’image trait´ee, pour am´eliorer les performances,
sachant qu’un tel effet en temps r´eel est coˆuteux. Apr`es ceci, il faut
rendre la sc`ene actuelle en couleur dans un autre Render Target, puis
utiliser la technique du blending permettant de m´elanger deux
Render Target, pour obtenir le r´esultat voulu.
Pourtant, une artefact en forme de cercle apparaˆıt au centre du
soleil, ce qui est gˆenant. Une m´ethode a ´et´e impl´ement´ee, permettant
de faire disparaˆıtre le probl`eme, tout en am´eliorant l’effet.
Cette m´ethode se base sur un autre mod`ele physique qui va permettre
de d´ecrire la dispersion du rayonnement lumineux dans l’atmosph`ere.
On se base sur le mod`ele de Henyey et Greenstein adapt´ee par
Nishita. On a donc la fonction de phase , telle que :
Mushroom Compiler 34
chip-ninja() Page 35 sur 78
Avec θ l’angle entre le spectateur (la cam´era) et le rayon de lumi`ere
π et g une constante qui affecte la sym´etrie de la diffusion des rayons.
Cette constante g est pr´ed´efinie `a l’avance, en valant 0 on peut ap-
proximer l’effet de diffusion de Rayleigh et entre 0,75 et 0,999 pour
approximer l’effet de la diffusion de Mie . La couleur r´esultante est
donc multipli´ee par F(θ,0) et on ajoute F(θ, 0,85). Pour trouver la
valeur de cos θ, un produit scalaire entre la position du soleil sur
l’´ecran et la direction vers laquelle la cam´era regarde suffit. Le tout
sera divis´e par la norme de la direction. Pour la cam´era, puisque le
jeu est en 2D, le vecteur


0
45

 fourni au shader donnait de bon r´esultat.
Avec tout ce qui pr´ec`ede, on a un soleil en temps r´eel, simulant le
rayonnement dans l’atmosph`ere, qui est, ici, le fond.
Pour finir, il est possible de rajouter quelques ´el´ements pour finaliser
l’effet.
6.2.2.c High Dynamic Range
Le High Dynamic Range ou Grande Gamme Dynamique est un
effet qui simule la r´etine afin d’obtenir un effet d’´eblouissement.
On applique donc cette formule `a la couleur :
1.0−exp (Exposure ∗ LDR), avec Exposure valant un nombre sup´erieur
ou ´egal `a 0.15 + 0.3 et LDR valant la couleur r´esultante juste avant
le calcul du mod`ele physique de Henyey et Greenstein adapt´e par
Nishita appell´ee Color, on a donc :
LDR = Color ∗ F(θ, 0.85) + F(θ, 0.76) ∗ 0.3 ∗





0.713
0.494
0.356





Mushroom Compiler 35
chip-ninja() Page 36 sur 78
Avec





0.713
0.494
0.356





, ´etant la couleur d’un soleil vers 12h et plus.
6.2.2.d Tone mapping
Cet effet permet de reproduire la gamme de couleurs pr´esentes
dans la nature.
On applique cette formule `a l’HDR :
HDR/(HDR + 0.5)
Ainsi, grˆace `a tout ce qui pr´ec`ede, nous avons l’effet voulu :
Effet final
6.3 Moteur `a particules
Le moteur `a particules est un autre type d’effet, bien qu’il soit assez
sobre, il est utilisable dans un bon nombre de situations. C’est pour
cela, que nous avons d´ecid´e d’impl´ementer cette sorte d’effet.
6.3.1 M´ethode
Tout d’abord, il faut connaˆıtre les caract´eristiques que doit avoir
le moteur. Il doit avoir un nombre initial de particule et un nombre
de particules par secondes. Celui-ci doit donner un angle minimal et
maximal vers lesquels les particules pourront se diriger. La vitesse
Mushroom Compiler 36
chip-ninja() Page 37 sur 78
minimale et maximale de chacune des particules doit ˆetre connue,
ainsi que leur temps de vie, leur taille, leur coordonn´ees en 2D et leur
texture.
6.4 Arri`ere-plan
Pour varier les environnements, changer l’atmosph`ere du jeu et
avoir un jeu artistique, il faut s’occuper des Arri`ere-plans et autres
´el´ements dans le fond avec lesquels le joueur n’interagit pas directe-
ment.
Les arri`ere-plans auront chacun une profondeur qui nous permettra
de simuler un effet de parallaxe lors du d´eplacement du joueur.
6.4.1 M´ethode
Pour arriver `a cet effet, une liste d’arri`ere-plans va devoir ˆetre cr´e´ee,
contenant, pour chaque arri`ere-plan, une texture et une profondeur.
Grˆace `a ces informations, une vitesse de d´efilement va en ˆetre calcul´ee
et ainsi, l’effet de parallaxe va pouvoir ˆetre simul´e.
Pour chaque fond de la liste, il y aura un autre fond correspondant
dans une autre liste qui sera d´ecal´e, pour donner un effet de d´efilement
sans interruption. ´Egalement, lors du mouvement du personnage et
donc de la texture, on aurait les fonds plus en arri`ere bougeant plus
lentement que ceux de devant.
6.5 Animation
Pour donner l’impression au joueur que les diff´erents personnages
se d´eplacent, le principe de persistence r´etinienne est utilis´e. Fonda-
mentalement, le principe de persistence r´etinienne se base sur une
des propri´et´es de la r´etine selon laquelle une image reste un certain
temps ”imprim´ee” sur la r´etine pour une dur´ee se rapprochant `a
1/25e de seconde sur la r´etine. Ainsi, en enchaˆınant plusieurs images
assez rapidement, une illusion de mouvement est cr´e´ee. Concr`etement,
Mushroom Compiler 37
chip-ninja() Page 38 sur 78
Figure 17 – D´emonstration des arri`eres-plans en parallaxe
l’image contenant l’ensemble d’images composant une animation est
commun´ement appel´e une ”Sprite Sheet”. Il s’agit d’un ensemble
de sprites, d’images, qui peuvent aussi ˆetre appel´es lutins. Pour en
faire une animation, il suffit de consid´erer la sprite sheet comme un
ensemble de rectangles, chaque image ayant sa propre coordonn´ee.
Ensuite, il suffit de faire d´efiler les images `a une vitesse donn´ee, qui
est ici de 50 millisecondes par image. Notre projet comporte plusieurs
sprite sheets pour le personnage, qui correspondent `a ses diff´erents
´etats (Arrˆet, Marche, Course, Saut...).
Mushroom Compiler 38
chip-ninja() Page 39 sur 78
7 Gameplay
7.1 Le coeur du gameplay
Peu importe les diff´erentes strates rajout´ees, le jeu reste un jeu de
plate-forme, avec ses propri´et´es intrins`eques. Ainsi, le personnage se
verra attribuer des vies et l’objectif est d’arriver `a la fin des niveaux.
Ceci permet au jeu d’avoir des courbes de progression et d’interˆet
satisfaisantes.
7.2 Ajouts
Un certain nombre de m´ecaniques `a ´egalement ´et´e ajout´e.
7.2.1 Le combat
Dans l’univers du jeu, le personnage est un ninja. Ainsi, le per-
sonnage est ´equip´e d’un sabre et de shurikens, qu’il peut lancer. Le
personnage peut ainsi blesser des ennemis et progresser dans le ni-
veau. Ces armes, qui donnent plus de puissance au joueur, permettent
´egalement un rythme de jeu plus rapide.
7.2.2 La technique Sp´eciale
Le personnage poss`ede ´egalement une technique sp´eciale, appel´ee
, qui permet de d´ecouper un adversaire en plusieurs morceaux. Elle se
d´eclenche lorsque le personnage a vaincu assez d’ennemis et poss`ede
plusieurs b´en´efices. Premi`erement, elle cr´ee pour le joueur un senti-
ment de puissance et de m´erite. Dans un second temps, cela permet
de briser la routine du jeu et de pr´esenter une exp´erience plus vari´ee.
7.2.3 Manipulation de la gravit´e
Le personnage `a ´egalement, en fonction des r`egles du niveau, le
droit d’inverser la gravit´e. Cela permet, une fois de plus, de diversifier
le gameplay et le rythme du jeu.
Mushroom Compiler 39
chip-ninja() Page 40 sur 78
7.2.4 Contrˆoles
7.2.4.a Clavier
Il a ´et´e d´ecid´e que le jeu se jouerait `a la paire clavier-souris. Le
joueur se d´eplacerait `a l’aide des touches Z-Q-D, sauterait `a l’aide du
clic-gauche de la souris, et attaquerait `a l’aide du droit.
7.2.4.b Manette
Quant `a la manette, le joueur se d´eplacerait `a l’aide du stick analo-
gique gauche, sauterait `a l’aide du bouton A, et attaquerait `a l’aide du
bouton X.
Mushroom Compiler 40
chip-ninja() Page 41 sur 78
8 Contenu
8.1 Graphismes
8.1.1 Personnage
Les diff´erents sprites pour le personnage proviennent du jeu Su-
per House Of Dead Ninjas . C’est un design efficace, qui correspond
au personnage du projet. Pour pouvoir r´ecup´erer les sprites, il a fallu
d´ecompiler l’ex´ecutable du jeu, et en assembler les diff´erents morceaux.
8.1.2 Tileset
Les diff´erents tilesets ont des origines diff´erentes. En effet, la plu-
part sont de composition personnelle, mais certains ont ´et´e r´ecup´er´es
d’Internet.
8.1.3 Arri`ere-plans
Les arri`ere-plans ont tous ´et´e r´ealis´es par les membres du projet, `a
l’exception de l’arri`ere-plan du menu, qui provient du jeu Sword &
Sworcery .
8.1.4 Facteurs de flare
Les images repr´esentants le facteur de flare ont toutes ´et´e r´ecup´er´ees
d’Internet.
8.2 Niveaux Artisanaux
Le jeu, en tant que projet de sup, pr´esente trois niveaux fondamen-
talement diff´erents, en plus de la g´en´eration proc´edurale.
8.2.1 Under The Pin
Le premier niveau, d´enomm´e Under The Pin de par la ressem-
blance des arches en arri`ere-plan avec des broches de processeur. C’est
un niveau simple, qui introduira le joueur au jeu.
Mushroom Compiler 41
chip-ninja() Page 42 sur 78
Figure 18 – Niveau : Under The Pin
8.2.2 Ram Jam
Ram Jam est le second niveau de chip-ninja(). Le niveau se
d´eroule dans la RAM (Random Access Memory) d’un ordinateur, o`u
se passe des choses ´etranges. Son nom est un hommage au groupe de
Rock Ram Jam qui a notamment compos´e la chanson Black Betty.
Figure 19 – Niveau : Ram Jam
8.2.3 Ohm My God
Ohm My God est le troisi`eme niveau de chip-ninja(). Son nom
est une r´ef´erence `a l’unit´e de mesure de la r´esistance d’un dipˆole.
Figure 20 – Niveau : Ohm My God
8.2.4 Transisterrific
Transisterrific est le nom donn´e `a tous les niveaux g´en´er´es
proc´eduralement.
Mushroom Compiler 42
chip-ninja() Page 43 sur 78
Figure 21 – Niveau : Under The Pin
8.3 Generation Proc´edurale
Pour permettre au joueur de faire l’exp´erience d’une infinit´e de
niveaux, il a fallu impl´ementer de la g´en´eration proc´edurale. La
g´en´eration proc´edurale de niveaux est le processus consistant `a cr´eer
des niveaux `a l’aide d’un algorithme aux r`egles pr´ecises.
Il faut g´en´erer un niveau ressemblant `a l’int´erieur d’un transistor,
c’est `a dire dans un espace ferm´e. En effet, sans cela, nous ne pourrions
jouer sur la verticalit´e des niveaux sans rendre le joueur confus.
8.3.1 Agencement
La premi`ere ´etape est de cr´eer une succession de salles qui for-
meront le parcours du joueur. On essaie d’obtenir quelque chose
ressemblant `a ceci :
Figure 22 – Agencement d’un niveau
Mushroom Compiler 43
chip-ninja() Page 44 sur 78
Concr`etement, ceci est repr´esent´e en m´emoire en utilisant un ta-
bleau `a deux dimensions d’objets salles . L’algorithme se d´eroule
comme suit :
R1. Prendre des coordonn´ees al´eatoires parmi les limites (20x20).
R2. Prendre al´eatoirement une salle adjacente.
R3. Si elle est occup´ee, revenir `a R2. Sinon, l’ajouter au tableau.
R4. Recommencer R3 tant que le nombre de salles minimum n’est pas atteint.
Lorsque cet algorithme est fini, on se retrouve avec un agencement
de salles parfaitement exploitable.
8.3.2 Solution
Il faut maintenant g´en´erer un sch´ema de solution. C’est l`a la partie
la plus difficile de la g´en´eration proc´edurale. En effet, il est tr`es simple
de produire des niveaux impossibles. Il faut donc donner au joueur
le moyen de naviguer `a travers toutes ces salles, jusqu’`a la derni`ere.
Comme le mouvement du joueur est d´efini par la physique du jeu, il
convient de s’assurer que les parties verticales (soit deux salles ou plus
connect´ees verticalement) soient toujours accessibles.
Apr`es diverses consid´erations, il a ´et´e d´ecid´e de cr´eer un parcours
de solution, c’est-`a-dire un ensemble de plateformes et d’´echelles qui
conduisent directement le joueur `a la sortie. Cela permet quelques
avantages : En effet, cela permet souvent plusieurs chemins alternatifs,
et garantit qu’au moins une solution existe. Cela paraˆıt peut-ˆetre trop
´evident pour le joueur, mais le chemin parfait est ensuite camoufl´e.
Nous utilisons la m´ethode suivante :
G´en´erer une position al´eatoire dans chaque salle, et connecter chacune
d’elle en utilisant une ´echelle et une plateforme.
Mushroom Compiler 44
chip-ninja() Page 45 sur 78
On obtient alors ce r´esultat :
Figure 23 – Le chemin de solution
8.3.3 Peupler
Ensuite, il nous faut g´en´erer des plateformes. Pour cela, un algo-
rithme est utilis´e qui produit les r´esultats suivants : Pour chaque tuile
vide, il y a une chance que celle-ci cr´ee une plateforme d’une longueur
al´eatoire. Il faut ´egalement faire attention `a ce qu’une plateforme
nouvellement g´en´er´ee ne bloque pas le chemin du joueur.
8.3.4 Faire pousser des ´echelles
Finalement, il nous faut g´en´erer des ´echelles. En ce but, une ´echelle
est plac´ee `a une position al´eatoire de chaque plateforme g´en´er´ee. On
les fait ensuite pousser vers le bas, jusqu’`a ce qu’elles touchent le
sol, ou une autre plateforme.
8.4 Musique
En r´ef´erence `a l’`ere des consoles de troisi`eme et quatri`eme g´en´eration,
sur lesquelles le genre plate-forme s’est d´emocratis´e, mais ´egalement
pour rester fid`ele au th`eme de notre jeu, nous avons choisi d’utiliser
de la chiptune.
Mushroom Compiler 45
chip-ninja() Page 46 sur 78
8.4.1 Menu
Le titre du menu, d´enomm´e Sad Robot, compos´e par le groupe
Allemand Pornophonique, qui diffuse de la musique libre de droit. Nous
avons trouv´e ce morceau particuli`erement adapt´e, car son utilisation
d’une guitare en plus de sons electroniques transmet une impression
de solitude, mais aussi une certaine chaleur, ce qui laisse une grande
impression sur le joueur lors de son premier contact avec le jeu, l’´ecran-
titre.
8.4.2 Under The Pin
La musique s´electionn´ee pour le niveau Under The Pin , dont
le titre est The Trials of MAN est une piste de Big Giant Circles sur son
album The Glory Days. Cette chiptune va `a merveille avec le d´ecor du
niveau, et donne un r´eel plaisir au joueur.
8.4.3 Ram Jam
La musique du niveau Ram Jam est nomm´ee Hybrid Funky Stars
qui est un morceau de Dubmood, un compositeur su´edois faisant partie
d’un des plus grand groupe pr´esent sur la sc`ene warez, Razor1911.
8.4.4 Transisterrific !
Pour les niveaux Transisterrific ! , plusieurs musiques sont
pr´esentes.
8.5 Menu
Dans nos versions pr´ec´edentes, nous avions un menu, mais qui
ne proposait que de jouer ou d’acc´eder au multijoueur. Bien sˆur, il
y avait les sous-menus pour le multijoueur et une gestion du texte,
pour entrer une adresse IP et le num´ero du joueur, mais ce n’´etait pas
suffisant.
Ainsi, nous avons rajout´e un menu d’options.
Mushroom Compiler 46
chip-ninja() Page 47 sur 78
8.5.1 Options
Dans ce menu, il y a la possibilit´e de modifier certains param`etres
du jeu.
Menu des Options
On peut, de cette mani`ere, r´eduire la qualit´e graphique du jeu, pour les
machines peu performantes, ou alors exploiter les effets `a leur maxi-
mum sur les machines qui en sont capables. Le nombre de d´ecoupes
des ennemis peut ˆetre r´eduit pour ´economiser les performances puis-
qu’un grand nombre de d´ecoupes implique beaucoup de calculs, sur-
tout pour la physique, de ce fait, le nombre de d´ecoupes sera limit´e `a
50, sinon il sera virtuellement infini. Le joueur peut ´egalement mettre
en Pause et Reprendre la musique en cours, ainsi que changer la
langue du jeu dans les menus et ailleurs.
Il y a aussi, une description de chaque ´el´ement des options au
dessus des choix, pour permettre au joueur de comprendre ce qu’il va
modifier.
Mushroom Compiler 47
chip-ninja() Page 48 sur 78
9 Outils de developpement
9.1 ´Editeur de niveau
Pour pouvoir r´ealiser facilement des niveaux, il a fallu coder un
´editeur.
9.1.1 Interface
L’interface est compos´ee de plusieurs ´el´ements.
Pour visualiser le niveau, il a fallu cr´eer un contexte XNA dans le
Windows Forms. Ainsi, par simple clic, nous pouvons ajouter une ou
plusieurs tuiles.
Sur le bord gauche est pr´esent la liste des tuiles disponibles. Les
diff´erentes tuiles sont repr´esent´ees individuellement et par l’image qui
leur correspond.
9.1.2 Fonctionnement
Concr`etement, l’´editeur r´ecup`ere le fichier de la map, et le stocke
dans un tableau `a deux dimensions. Apr`es les modifications faites, la
tilemap est r´e´ecrite dans le fichier.
Mushroom Compiler 48
chip-ninja() Page 49 sur 78
10 Intelligence Artificielle
Pour ce projet, il a fallu cr´eer des ennemis, avec chachun leur
intelligence propre. Ceux-ci sont au nombre de trois.
10.1 Mettoru
Mettoru est l’ennemi basique, repris de la s´erie classique
Megaman. Il ne se d´eplace qu’en marchant. Cependant, il se d´eplace
constamment en direction du joueur, `a condition qu’il ne rencontre
aucun pr´ecipice. En ce cas l`a, il s’arrˆete et fixe le joueur. Ainsi, il faut
veiller `a ce qu’il ne tombe pas du pr´ecipice. Pour cela, un mettoru
consid`ere toujours la tuile devant lui, d’une mani`ere similaire `a celle
des collisions. Si elle est vide, sa v´elocit´e devient nulle.
10.2 Sniper Mettoru
Sniper Mettoru est le nom du second ennemi. Lui aussi repris
de Megaman, c’est une version ´evolu´ee du Mettoru. En effet, il remarque
lorsque le joueur se trouve proche de lui, et tire sur l’ennemi lorsque
celui-ci est `a port´ee. Son projectile ne part qu’en ligne droite, mais
peut ˆetre renvoy´e par le joueur.
10.3 Bat
Le dernier ennemi est une chauve souris. Lorsque le joueur se
trouve assez proche – lorsque le joueur peut voir la chauve souris –
elle se lance `a petite vitesse dans sa direction. Si elle se trouve bloqu´ee
par le terrain, elle prendra un autre itin´eraire, de fac¸on `a toujours
suivre le joueur de fac¸on efficace.
Mushroom Compiler 49
chip-ninja() Page 50 sur 78
11 R´eseau
11.1 Multijoueur
Nous savons tous que les jeux vid´eos sont amusants `a jouer, mais
ils le sont encore plus `a plusieurs. C’est ainsi, qu’un mode multijoueur
a ´et´e int´egr´e au jeu.
Le jeu, ayant une architecture pens´ee comme ´etant polyvalente
depuis le d´ebut, a permit la mise en place d’un multijoueur en r´eseau
avec une grande simplicit´e sans avoir `a changer quoi que ce soit. Pour
cela, nous prenons avantage du syst`eme d’´ecrans appel´es GameS-
creens . Il suffit de cr´eer un ´ecran pour le multijoueur. Il ne reste plus
qu’`a construire le syst`eme client-serveur utilis´e ici.
Il a ´et´e d´ecid´e d’utiliser l’UDP (User Datagram Protocol) pour les
communications sur le r´eseau. Les raisons de ce choix sont que l’UDP
est rapide, assez simple `a mettre en place et est performant dans le cas
o`u il y a de nombreuses connections sur un mˆeme port.
11.2 Pr´esentation du mode de jeu
Pour ce mode multijoueur, nous avons opt´e pour un jeu `a plusieurs,
diff´erent de celui du mode `a un joueur. Ce mode de jeu oppose plu-
sieurs joueurs les uns contre les autres dans un combat `a mort.
Prenons 2 joueurs, chacun sera compos´e d’une couleur unie comme
le blanc ou le noir. Le fonds sera constitu´e d’´el´ements de mˆeme couleur
que les personnages et changera `a des intervalles irr´eguliers.
Dans ce mode, les joueurs auront la possibilit´e d’utiliser le d´ecors
en tant que camouflage pour parvenir `a leur fin. Bien-sˆur, le tout est
rendu dynamique par le fond qui change, rendant (ou pas) les person-
nages visibles aux yeux des autres. Ce gameplay permet de jouer de
mani`ere amusante, tout en am´eliorant ses comp´etences au combat et
ses r´eflexes dans le jeu.
Mushroom Compiler 50
chip-ninja() Page 51 sur 78
Figure 24 – L’arri`ere-plan dynamique
11.3 R´ealisation
Comme dit plus haut, le mode exploite l’architecture client-serveur
achev´ee `a l’aide de l’UDP.
Lors du lancement du jeu, le joueur a le choix entre plusieurs modes,
dont le multijoueur. Apr`es avoir choisi ce mode, on prend la charge
du serveur ou d’un client.
11.3.1 Cˆot´e Client
On cr´ee un client, que le mode choisi soit client ou serveur. Le client
prend un nom et une IP. Ce que va faire le client lors de sa cr´eation,
est de cr´eer un UdpClient puis de cr´eer un Thread dans lequel on
´ecoutera sur le port 80 les donn´ees `a recevoir du serveur. Ce Thread
ayant la plus haute priorit´e par rapport aux autres. Le client envoi
ensuite un paquet contenant la chaˆıne de caract`ere connect ainsi
que le nom du joueur et en fonction de la r´eponse, on continue.
Remarque : la mani`ere dont sont organis´ees les donn´ees envoy´es
et rec¸ues sera expliqu´ee plus bas.
Lors de la r´eception, le client va lire le flux entrant de donn´ees qui
sont un tableau de bytes, puis va les convertir en un format ad´equat
pour le client. On lis ces donn´ees en regardant d’abord le nom. Le
client ayant une liste de tous les clients connect´es, il va v´erifier si le
nom existe :
Mushroom Compiler 51
chip-ninja() Page 52 sur 78
-S’il existe, on met `a jour les donn´ees.
-Sinon, on rajoute le nouveau client ainsi que ses donn´ees.
Lors de l’envoi des donn´ees, qui s’effectue dans la fonction Update()
du client, on envoi les donn´ees du client actuel qui sont :
-Le nom
-L’´etat, c’est-`a-dire que l’on apprend si le joueur attaque ou autre.
-La position
-L’indice de background, cette donn´ee va permettre de connaˆıtre quel
background devra ˆetre sur chaque clients
Celles-ci sont envoy´ees au serveur pour ˆetre trait´ees.
11.3.2 Formatage des donn´ees
Les donn´ees envoy´es et rec¸ues sont format´ees de mani`ere pr´ecise.
Cette partie est trait´ee en annexe, partie D.1.
11.3.3 Cˆot´e Serveur
Au d´ebut, chez le client, il y a le choix entre ˆetre client ou serveur.
Si le serveur est choisi, il est lanc´e en tant que processus externe et
donc la personne qui lance le serveur est cliente de son propre serveur.
Lors de sa cr´eation, le serveur affiche son adresse IPv4 puis cr´e´ee
un UdpClient sur le port 80 et deux Thread, l’un pour la r´eception et
l’acceptation de nouveaux clients et l’autre pour recevoir des informa-
tions depuis les clients et pour renvoyer les informations de chaque
clients aux autres.
Lorsque le serveur lit le flux entrant et trouve la chaˆıne connect ,
il va v´erifier si ce nouveau client n’a pas un pseudo existant d´ej`a, ou
Mushroom Compiler 52
chip-ninja() Page 53 sur 78
que le nombre de joueurs pr´esents est d´epass´es et si les donn´ees sont
correctement format´ees et en fonction de cela, il sera accept´e ou refus´e.
Figure 25 – Le serveur
En mˆeme temps, il traite les donn´ees rec¸ues des autres clients. Ces
donn´ees rec¸ues sont ensuite renvoy´ees, lorsque leur formatage est bon,
`a tous les clients sauf la source. Le serveur ne sert que de relais, c’est
un interm´ediaire entre les clients. Il ne fait aucune v´erification sur ce
qui pourrait ˆetre de la triche ou autre.
Le serveur va ´egalement g´erer le changement de l’image de fond.
Il va, en fonction de formules bas´ees sur un facteur de temps, ´emettre
un indice de background `a tous les clients qui vont, ainsi, avoir tous la
mˆeme image de fond.
Remarque : Chaque client v´erifie lui-mˆeme les collisions et autres
et envoi ces informations, il n’y a donc aucun traitement externe, si ce
n’est une derni`ere v´erification, par le client distant, des collisions pour
plus de sˆuret´e.
11.3.4 Probl`emes
Plusieurs probl`emes se sont pos´es lors de la cr´eation de ce mode.
Le plus notable est celui o`u les adversaires des clients, pr´esentaient
du flickering . Ceux-ci gardaient la position de leur d´epart et alter-
Mushroom Compiler 53
chip-ninja() Page 54 sur 78
naient entre cette derni`ere et la leur position actuelle.
Le fait que la position de d´epart soit gard´ee ´etait dˆu au fait qu’une
liste et un dictionnaire d’´el´ements ´etaient utilis´es en mˆeme temps.
Pour r´egler ceci, il fallait garder la derni`ere position qui n’´etait pas
celle de d´epart temporairement et la comparer avec les coordonn´ees
de la position de d´epart. Cette position temporaire devenait donc, la
position actuelle de l’adversaire si elle ne valait pas celle de d´epart.
Remarque : la probabilit´e d’avoir exactement la mˆeme position que
celle de d´epart est faible. Et pourtant le cas est g´er´e `a l’aide de la
fr´equence de la mˆeme position sur une p´eriode donn´ee.
Mushroom Compiler 54
chip-ninja() Page 55 sur 78
12 Site Internet
Nous avons donc tout recommenc´e avons voulu reprendre les qua-
lit´es d’autres sites tout en allant `a l’essentiel. Nous sommes donc
arriv´es `a ce r´esultat :
Figure 26 – Le Site Web
Avec ce nouveau design, il suffit de d´efiler vers le bas pour avoir
toutes les informations souhait´ees. Le site est moderne et respecte les
standards actuels en terme d’esth´etique.
Le site dispose de boutons permettant guider le visiteur en se
d´eplac¸ant d’un point `a un autre de mani`ere fluide.
Le site ayant un design moderne, il va `a l’essentiel. On a du
texte descriptif de notre jeu `a cˆot´e d’une image qui doit ˆetre assez
repr´esentative du texte.
12.1 Responsive Design
Le site adopte ´egalement le responsive design permettant au
site de s’adapter `a tous les ´ecrans possibles, que ce soit sur smart-
phones, tablettes ou ordinateurs, en mode paysage ou portrait.
Mushroom Compiler 55
chip-ninja() Page 56 sur 78
Ainsi, nous avons une vision agr´eable du site sur n’importe quel
appareil, quel que soit le format de l’´ecran.
12.2 Communication
Dans le soucis de connaˆıtre les attentes et r´eactions des visiteurs de
notre site, nous voulions un moyens qui permettrait une interaction.
Ainsi, nous avons rajout´e un syst`eme de message, dans lequel le
visiteur laisse son nom ou pseudo, son adresse e-mail et son message
qu’il nous envoie.
Au bas du site, se trouvent des liens vers les r´eseaux sociaux Twitter
et Facebook. Ceux-ci servent `a faire connaˆıtre le jeu aupr`es du monde,
puisque ces r´eseaux sont tr`es connus et utilis´es.
Mushroom Compiler 56
chip-ninja() Page 57 sur 78
13 Conclusions personnelles
13.1 Alexandre Doussot
´Etant atir´e par la cr´eation de jeux vid´eos depuis un certain temps,
trouver ce projet `a ´et´e un grand soulagement ainsi qu’une grande joie.
J’avais en effet, depuis un certain nombre d’ann´ees, l’envie de cr´eer
moi aussi un jeu vid´eo, et de mieux connaˆıtre les tenants et aboutis-
sants de la cr´eation d’une partie d’un medium qui prend toujours plus
d’ampleur. Ce projet, en me permettant de me placer de l’autre cˆot´e
de l’´ecran, m’a permis d’enrichir drastiquement mes connaissances
sur le sujet, qu’il s’agisse de connaissances purement techniques, ou
au contraire, th´eoriques. J’ai ainsi pu d´ecouvrir et mettre en pratique
plusieurs ´el´ements de la discipline du Game Design, ou Conception
de Jeu.
De plus, en tant que chef de projet, j’ai d´ecouvert un certain nombre
de facettes de la r´ealisation d’un projet qui m’´etaient ´etrang`eres. En
effet, nous avons ´et´e confront´es `a des attentes similaires `a celle d’un
milieu entrepreneurial. J’ai ´egalement appris que travailler en groupe
n’´etait pas si facile qu’il semblait au premier abord, et garder les
diff´erents membres motiv´es a ´et´e un vrai challenge.
Se confronter `a des d´efis tels que ceux qui nous ont ´et´e present´es
m’ont sans aucun doute fait mˆurir, et m’ont permis d’am´eliorer ma
maˆıtrise du langage C#, math´ematique et humain.
Mushroom Compiler 57
chip-ninja() Page 58 sur 78
13.2 Chady Dimachkie
Mon int´erˆet pour le rendu a ´et´e ´enorm´ement suscit´e lors de ce
projet. En effet, j’ai pu exploiter le langage de shaders HLSL et la s´erie
d’outil d’XNA `a leur maximum, pour arriver `a des rendus d’une telle
qualit´e sans pour autant r´eduire nettement les performances. Lors de
ce projet, j’ai appris `a me questionner sur ce qui pouvait am´eliorer le
jeu, tout en restant coh´erent.
Ce projet m’a donn´e l’occasion de travailler en ´equipe, et donc
d’avoir plusieurs mani`eres de penser dans un mˆeme projet. Cela m’a
permit de concevoir des solutions s’adaptant `a une architecture com-
prise et adopt´ee par tous les membres du groupe et ainsi, j’ai pu
am´eliorer mes m´ethodes de d´eveloppement
J’ai du apprendre `a fournir des produits, cr´e´es avec des m´ethodes
efficaces et ceci rapidement, pour les remettre en temps et en heure.
Tous ces changements, m’ont permet d’´evoluer, en tant que pro-
grammeur et en tant que personne. De ce fait, pour de futurs projets
en ´equipe, je pourrais m’adapter plus facilement aux besoins d’une
´equipe et prendre des d´ecisions relatives `a ceux-ci.
Mushroom Compiler 58
chip-ninja() Page 59 sur 78
13.3 Benjamin R´echou
N’ayant jamais cod´e, ce projet me semblait irr´ealisable au d´ebut
de l’ann´ee. Je n’avais `a l’´epoque pas les outils n´ecessaire pour r´ealiser
un tel projet. Ayant pourtant beaucoup jou´e, je pensais avoir une
id´ee de comment un jeu est fait, grande a ´et´e ma surprise lorsque
mon groupe et moi mˆeme avons du r´ealiser par nous mˆeme tout les
´el´ements qui composent un jeu vid´eo. J’avais en effet l’id´ee g´en´eral du
fonctionnement des ´el´ements d’un jeu mais j’´etais loin d’en imaginer
la complexit´e. Ce projet a donc ´et´e une longue succession de blocage
et de casse-tˆete mais toute la d´emarche de recherche et de r´eflexion
que nous avons du fournir nous `a ´et´e b´en´efique.
Apr`es nous ˆetre r´epartit les taches afin de travailler plus effica-
cement, nous nous sommes chacun attel´e `a la tache. Chose qui n’a
pas ´et´e simple au d´ebut car il est dur de se lancer dans un projet
si imposant sans avoir les outils n´ecessaire. Je pense que la partie la
plus dur fˆut d’acqu´erir les bons outils et d’apprendre `a les utiliser. Je
ne me serais jamais cru capable de pouvoir participer a la cr´eation
d’un site WEB ou encore r´ealiser un moteur a particules fonctionnel.
La lecture des cartes du jeux est ce qui m’a demand´e le plus grand
temps de r´eflexion, il me fallait trouver un moyen simple mais effi-
cace de lire et g´en´erer des cartes jouable. Apr`es m’ˆetre entretenu avec
Alexandre et Chady une solution fˆut rapidement trouv´ee. Il en est all´e
de mˆeme pour quasiment l’ensemble du projet, nous avons rencontr´e
des probl`emes mais ensemble nous avons su les surmonter.
Je fˆut surprit du peu de tension qu’il y a eu au sein du groupe, nous
partageons tout trois la mˆeme passion du jeu vid´eo et de ce fait nous
n’avions pas tant de divergence de points de vue, ce qui `a grandement
particip´e a la bonne r´ealisation de ce projet. Tout le temps que nous ne
perdions pas `a essayer de trouver un commun accord nous le passions
a travailler le projet pour finalement arriver `a un r´esultat final dont
nous pouvons ˆetre fiers.
Mushroom Compiler 59
chip-ninja() Page 60 sur 78
14 Conclusion
Ce projet s’est r´ev´el´e tr`es enrichissant pour chacun d’entre nous
dans la mesure o`u nous avons pu d´ecouvrir et r´ealiser les diff´erentes
facettes qui composent le divertissement que nous utilisons tous. Ce
fut enrichissant d’un point de vue culturel, mais aussi immens´ement
d’un point de vue technique, car nous avons dˆu mettre en pratique
tout ce qui nous a ´et´e enseign´e durant l’ann´ee, et mˆeme plus.
En effet, ce projet incite ´enorm´ement `a l’autonomie. Nous avons dˆu
r´ealiser un certain nombre de recherches par nous-mˆeme, sans l’aide
de nos professeurs, et avons dˆu apprendre `a nous arranger par nous
mˆeme, sans avoir quelqu’un sur qui forc´ement compter, si ce n’est
sur nous-mˆeme, membres de ce groupe. Effectivement, la gestion de
groupe a ´et´e une facette tr`es importante de ce projet. Nous devions
nous aider, et ne pas lˆacher lors des temps durs. Il y a bien eu quelques
altercations, mais nous n’en sommes que ressortis grandis et plus
soud´es.
De plus, ce projet nous a mis face aux contraintes du milieu en-
trepreneurial, comme le fait que nous ayons un cahier des charges `a
respecter, tout en travaillant dans une entente cordiale.
Ce fut d´efinitivement un projet tr`es int´eressant qui nous a permis
de mˆurir en tant qu’´etudiants, mais ´egalement en tant que personnes.
Mushroom Compiler 60
chip-ninja() Page 61 sur 78
Annexes
A Comment lire ce rapport ?
Ce rapport se pr´esente sous la forme requise, `a savoir qu’il d´ebute
par un sommaire, suivi de l’introduction ainsi que l’explication du
travail r´ealis´e, enchaˆınant ensuite sur les Annexes, compos´ees de la
bibliographie, des ressources, ainsi qu’une table des mati`eres.
Le corps de ce document est divis´e en diff´erentes parties pr´ec´ed´ees
d’une barre de couleur. Cette couleur correspond `a l’´etudiant qui a
r´ealis´e le travail dont il est question dans la partie correspondante.
Voici les couleurs correspondantes `a chaque ´etudiant.
Alexandre Doussot
Chady Dimachkie
Benjamin R´echou
Mushroom Compiler 61
chip-ninja() Page 62 sur 78
B R´ef´erences
-Tomoyuki Nishita, Yasuhiro Miyawaki et Eihachiro Nakamae, Com-
puter Graphics (A SHADING MODEL FOR ATMOSPHERIC SCATTE-
RING CONSIDERING LUMINOUS INTENSITY DISTRIBUTION OF
LIGHT SOURCES), Assn for Computing Machinery, Volume 21, Num-
ber 4, Juillet 1997
- Mitchell, Light Shafts : Rendering Shadows in Participating
Media. , Presentation at Game Developers Conference 2004.
-Y.Dobashi, T. Yamamoto , T.Nishita, Interactive Rendering Method
for Displaying Shafts of Light, Proc.Pacific Graphics 2000, 2000p.
-Sean O’Neil, GPU Gems 2 ,Chapitre 16, 2005.
-Kenny Mitchell, Electronic Arts, GPU Gems 3 Chapitre 13, 2006.
-NVIDIA Corp, The Cg Tutorial, Chapter 8. Bump Mapping,.
-Tomas Akenine-M¨oller, Eric Haines, Naty Hoffman, Real-Time
Rendering, Third Edition, Chapitre 6.7 Bump Mapping, 10.7 Particle Systems,
10.10 Color Correction, 10.11 Tone Mapping, 25 Juillet 2008, 1045p
-Christer Ericson, Real-Time Collision Detection (The Morgan Kauf-
mann Series in Interactive 3-D Technology), Chapitres 8.3.4 Splitting Poly-
gons Against a Plane, 7.4.2 Uniform Grid Intersection Test, 22 D´ecembre
2004, 632p,
- XNA GPA. [EN LIGNE]. 10 F´evrier 2012. [Consult´e le 8 Avril
2014]. Disponible sur : http ://xnagpa.net/about.php
-Game Programming Patterns. [EN LIGNE]. Bob Nystrom. [Consult´e
le 4 Mars 2014]. Disponible sur : http ://gameprogrammingpatterns.com
-Schell Jesse, The Art of Game Design - A Book of Lenses., CRC Press,
2008, 464p.
Mushroom Compiler 62
chip-ninja() Page 63 sur 78
C Moteur Physique
C.1 Attaque sp´eciale
C.1.1 D´etection de collisions
Pour avoir une bonne physique apr`es d´ecoupe, il nous faut des
collisions. Nous allons, pour l’instant, utiliser des AABB.(Axis Ali-
gned Bounding Boxes) qui nous serviront `a r´ealiser des formes plus
complexes et ainsi avoir de la d´etection de collisions entre polygones
complexes.
Une AABB est un rectangle dont les cˆot´es sont align´es avec les
axes de son syst`eme de coordonn´ee. Pour repr´esenter une AABB, son
sommet est marqu´e ayant la plus petite abscisse et ordonn´ee et son
sommet ayant la plus grande abscisse et ordonn´ee, c’est-`a-dire, le som-
met en haut `a gauche et son sommet en bas `a droite
Pour une AABB, le SAT (Separating Axis Theorem ou encore Sup-
porting Hyperplane Theorem) est utilis´e. Il est appel´e Th´eor`eme de
s´eparation des convexes par hyperplan, en franc¸ais.
Concr`etement, le th´eor`eme implique qu’il n’y a pas collision lors-
qu’on peut tracer un axe entre deux polygones, si ce n’est pas le cas,
alors il y a collision.
Figure 27 – Separatin Axis Theorem
Mushroom Compiler 63
chip-ninja() Page 64 sur 78
C.1.2 Apr`es collision
On suppose que l’on a deux donn´ees apr`es le moment o`u la col-
lision est d´etect´ee :la normale du point de collision et la profondeur
de p´en´etration. Elles sont utilis´ees pour pouvoir appliquer une force `a
chacun des polygones afin de les projeter apr`es collision.
On note VAB la v´elocit´e entre les points A et B, donc pour connaˆıtre
la v´elocit´e entre A et B sur la normale de collision, un produit scalaire
suffit : VAB.n = (VB − VA).n. Ensuite, il nous faut le coefficient de
restitution (ou encore le coefficient de Newton) not´e e. La restitution
est l’´energie cin´etique g´en´er´ee apr`es collision. Elle est calcul´ee en
prenant le minimum de l’attribut restitution des deux objets entr´es
en collision.
On a donc, d’apr`es la loi de restitution de Newton : V = e ∗ V,
et dans notre cas : VAB.n = −e ∗ (VB − VA).n. Le signe est n´egatif car
la projection des objets se fait dans le sens oppos´e.
On doit, ensuite, pouvoir exprimer ces v´elocit´es avec l’aide d’un
scalaire j repr´esentant un moment. Ce qui donne : V = V + j ∗ n,
j = masse ∗ V ´elocit´e et V ´elocit´e = Impulse
masse , de ce fait : V = V + j∗n
masse.
Apr`es, pour A et B : VA = VA + j∗n
masseA
et VB = VB − j∗n
masseB
.
On peut d´evelopper le produit scalaire en :
(VA − VB + j∗n
masseA
+ j∗n
masseB
) ∗ n = −e ∗ (VB − VA) · n, qui est ´equivalent
`a
(VA − VB + j∗n
masseA
+ j∗n
masseB
) ∗ n + e ∗ (VB − VA) · n = 0.
Apr`es d´eveloppement :
(VB − VA) · n + j ∗ ( j∗n
masseA
+ j∗n
masseB
) ∗ n + e ∗ (VB − VA) · n = 0,
(1 + e)((VB − VA) · n) + j ∗ ( j∗n
masseA
+ j∗n
masseB
) ∗ n = 0,
Donc, j =
−(1+e)((VB−VA)·n)
1
masseA
+ 1
masseB
. On a le moment j exprim´e en fonction de
param`etres connus, ce qui nous permet d’avoir une collision d’objets
et une projection de ces objets dans des directions en fonction de leur
sens d’arriv´ee.
Mushroom Compiler 64
chip-ninja() Page 65 sur 78
Grˆace `a tout ce qui pr´ec`ede, il est possible de d´efinir une gravit´e
qui permettra de faire tomber un objet de mani`ere cr´edible.
Une gravit´e 4 fois sup´erieure `a celle trouv´ee sur Terre permet
d’avoir une vitesse de chute appr´eciable. Cette gravit´e d´ependra
´egalement de ce qui a ´et´e calcul´e pr´ec´edemment. Si l’on prend une
AABB quelconque, cette gravit´e sera appliqu´ee `a chacun de ses som-
mets, ainsi, lors d’une collision ou autre, simuler des rotations sera
ais´e, ce qui rend le concept de AABB obsol`ete en gagnant un degr´e de
libert´e, en plus des translations sur les axes X et Y, et donc nous fourni
un mod`ele physique plus ´elabor´e.
Mushroom Compiler 65
chip-ninja() Page 66 sur 78
D R´eseau
D.1 Formatage des donn´ees
Les donn´ees sont une structure appel´ee Data. Elle contient tous les
´el´ements n´ecessaires au bon d´eroulement du jeu.
Comme dit dans la partie 11.3.1 du rapport, le nom, l’´etat et les
coordonn´ees enti`eres x et y du client sont envoy´es. Sur cette structure,
on force un formatage sp´ecial. En C#, fournir un objet dit ma-
nag´e `a une structure non manag´ee force la structure `a avoir
une repr´esentation non manag´ee de cet objet. C’est-`a-dire que ces
objets peuvent avoir une repr´esentation en m´emoire, inattendue, ce
qui est mauvais pour notre architecture. Pour cela, on ajoute en en-tˆete
de la structure (juste au dessus de public struct Data ) :
[StructLayout(LayoutKind.Sequential, Pack = 1)]
Illustration :
Figure 28 – Structure de types de donn´ee
Mushroom Compiler 66
chip-ninja() Page 67 sur 78
Et on force nos chaˆınes se cataractes, que sont l’´etat et le nom, `a
une taille fix´ee de par exemple 10 caract`eres avec :
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 10)]
Ainsi, lors de la conversion `a la r´eception et `a l’envoi, il n’y aura
aucun probl`eme. Sachant que le tableau de bytes rec¸u est convertit en
une donn´ee de type Data et inversement pour les donn´ees envoy´ees.
Mushroom Compiler 67
chip-ninja() Page 68 sur 78
E Images
E.1 Normal Mapping
E.1.1 Cˆot´es
Figure 29 – Ce que l’on ne veut pas
Figure 30 – Ce que l’on veut
Mushroom Compiler 68
chip-ninja() Page 69 sur 78
E.1.2 Tangente
Figure 31 – Normale en bleu, tangente en rouge
E.1.3 Bitangente
Figure 32 – Bitangente en vert
E.2 Ennemis
Figure 33 – Mettoru
Mushroom Compiler 69
chip-ninja() Page 70 sur 78
Figure 34 – Sniper Mettoru
E.3 Personnage
Figure 35 – Tilesheet du personnage
Mushroom Compiler 70
chip-ninja() Page 71 sur 78
F Glossaire
-XNA : Une s´erie d’outil permettant de simplifier l’utilisation de
DirectX et donc de permettre un d´eveloppent de jeux vid´eos plus
simplifi´e.
- H´eritage : Notion de programmation orient´ee objet, qui permet `a
une classe dite fille de b´en´eficier de toutes les attributs et m´ethodes
de sa classe m`ere .
- Design Pattern ou Patron de conception : Technique de pro-
grammation qui permet une optimisation du code, qu’il s’agisse de
performances ou de practicit´e.
- Polymorphisme : Notion de programmation orient´ee objet qui
permet entre autres de consid´erer une classe fille comme sa classe
m`ere.
-Render Target : Un espace dans lequel le processeur graphique
fait un rendu
-Buffer : Une zone m´emoire contenant des donn´ees
-Vertex Buffer : Un buffer contenant des sommets de polygones.
-SpriteBatch : Un objet fournit par XNA qui permet de d´essiner,
tr`es simplement, des textures `a l’´ecran.
-Shader : Un programme qui sera trait´e dans les unit´es de calcul
du processeur graphique.
-Blending : Une technique permettant de m´elanger deux rendus.
-Color Map : Une texture ´eclair´ee de mani`ere parfaite depuis tous
les angles possibles.
-Normal Map : Une texture d´ecrivant les r´eflexions de la lumi`ere
d’une Color Map.
-Shadow Map : Le r´esultat du rendu effectu´e lors de l’utilisation
de la technique de Normal Mapping.
Mushroom Compiler 71
chip-ninja() Page 72 sur 78
Table des figures
1 H´eritage des entit´es . . . . . . . . . . . . . . . . . . . . . . 9
2 Clipping d’un cube par un plan . . . . . . . . . . . . . . . 16
3 Clipping d’un rectangle par une droite . . . . . . . . . . 16
4 Distance d’un point par rapport `a un plan . . . . . . . . 16
5 D´ecoupe d’un triangle . . . . . . . . . . . . . . . . . . . . 18
6 D´ecoupe d’un rectangle par une ligne . . . . . . . . . . . 19
7 Assemblage de triangle . . . . . . . . . . . . . . . . . . . 19
8 Coordonn´ees UV . . . . . . . . . . . . . . . . . . . . . . . 20
9 Bonne et mauvaise d´ecoupe . . . . . . . . . . . . . . . . . 20
10 Rendu non final . . . . . . . . . . . . . . . . . . . . . . . . 21
11 Technique du normal mapping . . . . . . . . . . . . . . . 22
12 Une texture et sa Normal map . . . . . . . . . . . . . . . 23
13 R´eflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14 Plusieurs sortes de BlendState . . . . . . . . . . . . . . . . 30
15 Rendu Final . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16 Rendu Interm´ediaire . . . . . . . . . . . . . . . . . . . . . 32
17 D´emonstration des arri`eres-plans en parallaxe . . . . . . 38
18 Niveau : Under The Pin . . . . . . . . . . . . . . . . . . . 42
19 Niveau : Ram Jam . . . . . . . . . . . . . . . . . . . . . . . 42
20 Niveau : Ohm My God . . . . . . . . . . . . . . . . . . . . 42
21 Niveau : Under The Pin . . . . . . . . . . . . . . . . . . . 43
22 Agencement d’un niveau . . . . . . . . . . . . . . . . . . 43
23 Le chemin de solution . . . . . . . . . . . . . . . . . . . . 45
24 L’arri`ere-plan dynamique . . . . . . . . . . . . . . . . . . 51
25 Le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
26 Le Site Web . . . . . . . . . . . . . . . . . . . . . . . . . . 55
27 Separatin Axis Theorem . . . . . . . . . . . . . . . . . . . 63
28 Structure de types de donn´ee . . . . . . . . . . . . . . . . 66
29 Ce que l’on ne veut pas . . . . . . . . . . . . . . . . . . . 68
30 Ce que l’on veut . . . . . . . . . . . . . . . . . . . . . . . . 68
Mushroom Compiler 72
chip-ninja() Page 73 sur 78
31 Normale en bleu, tangente en rouge . . . . . . . . . . . . 69
32 Bitangente en vert . . . . . . . . . . . . . . . . . . . . . . . 69
33 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
34 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . 70
35 Tilesheet du personnage . . . . . . . . . . . . . . . . . . . 70
Mushroom Compiler 73
chip-ninja() Page 74 sur 78
Table des mati`eres
1 Introduction 5
2 Le groupe 6
2.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . 8
3 Architecture du code 9
3.1 H´eritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Composants . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Gestionnaire d’entr´ees . . . . . . . . . . . . . . . . 10
3.2.2 Gestionnaire d’´etats . . . . . . . . . . . . . . . . . 11
3.2.3 Gestionnaire d’arri`ere-plans . . . . . . . . . . . . . 11
3.3 ´Etats du personnage . . . . . . . . . . . . . . . . . . . . . 12
4 Moteur de Tuiles 13
4.1 Impl´ementions . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 M´eta-donn´ees . . . . . . . . . . . . . . . . . . . . . 13
4.2 Fonctionnalit´es . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Moteur Physique 14
5.1 Physique des personnages . . . . . . . . . . . . . . . . . . 14
5.1.1 D´eplacement . . . . . . . . . . . . . . . . . . . . . 14
5.1.2 Gravit´e . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1 Sutherland-Hodgman . . . . . . . . . . . . . . . . 15
5.3.2 Ajout de physique . . . . . . . . . . . . . . . . . . 21
6 Moteur Graphique 22
6.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . 22
Mushroom Compiler 74
chip-ninja() Page 75 sur 78
6.1.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1.3 Le rendu . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3.a Valse des RenderTargets . . . . . 25
6.1.3.b Rendu de la shadow map . . . . 26
6.1.3.c Blending . . . . . . . . . . . . . . 29
6.1.3.d Finalisation . . . . . . . . . . . . . 30
6.2 Rayons cr´epusculaires . . . . . . . . . . . . . . . . . . . . 31
6.2.1 Ph´enom`ene . . . . . . . . . . . . . . . . . . . . . . 32
6.2.2 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . 32
6.2.2.a Rendu . . . . . . . . . . . . . . . . 32
6.2.2.b Le Shader . . . . . . . . . . . . . . 33
6.2.2.c High Dynamic Range . . . . . . . 35
6.2.2.d Tone mapping . . . . . . . . . . . 36
6.3 Moteur `a particules . . . . . . . . . . . . . . . . . . . . . . 36
6.3.1 M´ethode . . . . . . . . . . . . . . . . . . . . . . . . 36
6.4 Arri`ere-plan . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4.1 M´ethode . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7 Gameplay 39
7.1 Le coeur du gameplay . . . . . . . . . . . . . . . . . . . . 39
7.2 Ajouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.1 Le combat . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.2 La technique Sp´eciale . . . . . . . . . . . . . . . . 39
7.2.3 Manipulation de la gravit´e . . . . . . . . . . . . . 39
7.2.4 Contrˆoles . . . . . . . . . . . . . . . . . . . . . . . 40
7.2.4.a Clavier . . . . . . . . . . . . . . . 40
7.2.4.b Manette . . . . . . . . . . . . . . . 40
8 Contenu 41
8.1 Graphismes . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1.1 Personnage . . . . . . . . . . . . . . . . . . . . . . 41
8.1.2 Tileset . . . . . . . . . . . . . . . . . . . . . . . . . 41
Mushroom Compiler 75
chip-ninja() Page 76 sur 78
8.1.3 Arri`ere-plans . . . . . . . . . . . . . . . . . . . . . 41
8.1.4 Facteurs de flare . . . . . . . . . . . . . . . . . . . 41
8.2 Niveaux Artisanaux . . . . . . . . . . . . . . . . . . . . . . 41
8.2.1 Under The Pin . . . . . . . . . . . . . . . . . . . . 41
8.2.2 Ram Jam . . . . . . . . . . . . . . . . . . . . . . . . 42
8.2.3 Ohm My God . . . . . . . . . . . . . . . . . . . . . 42
8.2.4 Transisterrific . . . . . . . . . . . . . . . . . . . . . 42
8.3 Generation Proc´edurale . . . . . . . . . . . . . . . . . . . 43
8.3.1 Agencement . . . . . . . . . . . . . . . . . . . . . . 43
8.3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . 44
8.3.3 Peupler . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.3.4 Faire pousser des ´echelles . . . . . . . . . . . . . . 45
8.4 Musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.4.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4.2 Under The Pin . . . . . . . . . . . . . . . . . . . . 46
8.4.3 Ram Jam . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4.4 Transisterrific ! . . . . . . . . . . . . . . . . . . . . 46
8.5 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.5.1 Options . . . . . . . . . . . . . . . . . . . . . . . . 47
9 Outils de developpement 48
9.1 ´Editeur de niveau . . . . . . . . . . . . . . . . . . . . . . . 48
9.1.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . 48
10 Intelligence Artificielle 49
10.1 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.2 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . 49
10.3 Bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11 R´eseau 50
11.1 Multijoueur . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.2 Pr´esentation du mode de jeu . . . . . . . . . . . . . . . . 50
11.3 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Mushroom Compiler 76
chip-ninja() Page 77 sur 78
11.3.1 Cˆot´e Client . . . . . . . . . . . . . . . . . . . . . . 51
11.3.2 Formatage des donn´ees . . . . . . . . . . . . . . . 52
11.3.3 Cˆot´e Serveur . . . . . . . . . . . . . . . . . . . . . 52
11.3.4 Probl`emes . . . . . . . . . . . . . . . . . . . . . . . 53
12 Site Internet 55
12.1 Responsive Design . . . . . . . . . . . . . . . . . . . . . . 55
12.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . 56
13 Conclusions personnelles 57
13.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . 57
13.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . 58
13.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . 59
14 Conclusion 60
Annexes 61
A Comment lire ce rapport ? 61
B R´ef´erences 62
C Moteur Physique 63
C.1 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . 63
C.1.1 D´etection de collisions . . . . . . . . . . . . . . . . 63
C.1.2 Apr`es collision . . . . . . . . . . . . . . . . . . . . 64
D R´eseau 66
D.1 Formatage des donn´ees . . . . . . . . . . . . . . . . . . . 66
E Images 68
E.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . 68
E.1.1 Cˆot´es . . . . . . . . . . . . . . . . . . . . . . . . . . 68
E.1.2 Tangente . . . . . . . . . . . . . . . . . . . . . . . . 69
E.1.3 Bitangente . . . . . . . . . . . . . . . . . . . . . . . 69
E.2 Ennemis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Mushroom Compiler 77
chip-ninja() Page 78 sur 78
E.3 Personnage . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
F Glossaire 71
Mushroom Compiler 78

Contenu connexe

Tendances

Sout3
Sout3Sout3
Sout33on
 
Poly
PolyPoly
101trucsexcel2007
101trucsexcel2007101trucsexcel2007
101trucsexcel2007
Allaeddine Makhlouk
 
Rapport Projet Virtual Robots
Rapport Projet Virtual RobotsRapport Projet Virtual Robots
Rapport Projet Virtual Robots
aliotard
 
ZFS et BTRFS
ZFS et BTRFSZFS et BTRFS
ZFS et BTRFS
Stéphane Legrand
 
Guide latex.
Guide latex.Guide latex.
Guide latex.
AbdullahOmar64
 
Architectures logicielles et materielles
Architectures logicielles et materiellesArchitectures logicielles et materielles
Architectures logicielles et materiellesAdnane Farid
 
The Ring programming language version 1.4 book - Part 1 of 30
The Ring programming language version 1.4 book - Part 1 of 30The Ring programming language version 1.4 book - Part 1 of 30
The Ring programming language version 1.4 book - Part 1 of 30
Mahmoud Samir Fayed
 
The Ring programming language version 1.4.1 book - Part 1 of 31
The Ring programming language version 1.4.1 book - Part 1 of 31The Ring programming language version 1.4.1 book - Part 1 of 31
The Ring programming language version 1.4.1 book - Part 1 of 31
Mahmoud Samir Fayed
 
Performances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiPerformances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiprivateperso
 
Guide utilisateur IPAQ 3715
Guide utilisateur IPAQ 3715Guide utilisateur IPAQ 3715
Guide utilisateur IPAQ 3715
Esserentais
 
Développez en java
Développez en javaDéveloppez en java
Développez en java
socrat2
 
Bedhboperation r41 fr
Bedhboperation r41 frBedhboperation r41 fr
Bedhboperation r41 fr
ben aissa chokri
 
Le petit livre_du_hacker_2013
Le petit livre_du_hacker_2013Le petit livre_du_hacker_2013
Le petit livre_du_hacker_2013
bbbooda
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
Support formation vidéo: Tout savoir sur Windows 10
Support  formation vidéo: Tout savoir sur Windows 10Support  formation vidéo: Tout savoir sur Windows 10
Support formation vidéo: Tout savoir sur Windows 10
SmartnSkilled
 

Tendances (20)

Sout3
Sout3Sout3
Sout3
 
Poly
PolyPoly
Poly
 
101trucsexcel2007
101trucsexcel2007101trucsexcel2007
101trucsexcel2007
 
Rapport Projet Virtual Robots
Rapport Projet Virtual RobotsRapport Projet Virtual Robots
Rapport Projet Virtual Robots
 
ZFS et BTRFS
ZFS et BTRFSZFS et BTRFS
ZFS et BTRFS
 
Memoire_final
Memoire_finalMemoire_final
Memoire_final
 
Guide latex.
Guide latex.Guide latex.
Guide latex.
 
Architectures logicielles et materielles
Architectures logicielles et materiellesArchitectures logicielles et materielles
Architectures logicielles et materielles
 
Excel2010.guide.complet
Excel2010.guide.completExcel2010.guide.complet
Excel2010.guide.complet
 
The Ring programming language version 1.4 book - Part 1 of 30
The Ring programming language version 1.4 book - Part 1 of 30The Ring programming language version 1.4 book - Part 1 of 30
The Ring programming language version 1.4 book - Part 1 of 30
 
The Ring programming language version 1.4.1 book - Part 1 of 31
The Ring programming language version 1.4.1 book - Part 1 of 31The Ring programming language version 1.4.1 book - Part 1 of 31
The Ring programming language version 1.4.1 book - Part 1 of 31
 
Algo
AlgoAlgo
Algo
 
Performances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxiPerformances d’un système virtualisé avec v mware esxi
Performances d’un système virtualisé avec v mware esxi
 
Guide utilisateur IPAQ 3715
Guide utilisateur IPAQ 3715Guide utilisateur IPAQ 3715
Guide utilisateur IPAQ 3715
 
Développez en java
Développez en javaDéveloppez en java
Développez en java
 
Bedhboperation r41 fr
Bedhboperation r41 frBedhboperation r41 fr
Bedhboperation r41 fr
 
Ids
IdsIds
Ids
 
Le petit livre_du_hacker_2013
Le petit livre_du_hacker_2013Le petit livre_du_hacker_2013
Le petit livre_du_hacker_2013
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
Support formation vidéo: Tout savoir sur Windows 10
Support  formation vidéo: Tout savoir sur Windows 10Support  formation vidéo: Tout savoir sur Windows 10
Support formation vidéo: Tout savoir sur Windows 10
 

En vedette

André Citröen
André Citröen André Citröen
André Citröen
Alexmartinezristol
 
Tour Bus Juego
Tour Bus JuegoTour Bus Juego
Tour Bus Juego
Jugar Con Juegos
 
03 expo reforma 2011 matemáticas
03 expo reforma 2011 matemáticas03 expo reforma 2011 matemáticas
03 expo reforma 2011 matemáticas
JOSÉ AGUSTÍN LEGARRETA RODRÍGUEZ
 
Incorporación de TIC en la Universidad Católica de Colombia
Incorporación de TIC en la Universidad Católica de ColombiaIncorporación de TIC en la Universidad Católica de Colombia
Incorporación de TIC en la Universidad Católica de Colombia
Proyecto AVA
 
Sistemas contra incendio
Sistemas contra incendioSistemas contra incendio
Sistemas contra incendio
vizion2k1
 
Fruugo - Ouvrez-vous à l'International
Fruugo - Ouvrez-vous à l'InternationalFruugo - Ouvrez-vous à l'International
Fruugo - Ouvrez-vous à l'International
Fruugo
 
Les meilleurs hôtels à sousse,tunisie
Les meilleurs hôtels à sousse,tunisieLes meilleurs hôtels à sousse,tunisie
Les meilleurs hôtels à sousse,tunisie
Tunisie Booking
 
Solution modulaire pour stockage - Algeco
Solution modulaire pour stockage - AlgecoSolution modulaire pour stockage - Algeco
Solution modulaire pour stockage - Algeco
algecoFR
 
Presentacion ultima
Presentacion ultimaPresentacion ultima
Presentacion ultima
Deusto
 
Avoir un site web sexy ou rentable?
Avoir un site web sexy ou rentable? Avoir un site web sexy ou rentable?
Avoir un site web sexy ou rentable?
Planitou.ca
 
Juego Gilera Runner
Juego Gilera RunnerJuego Gilera Runner
Juego Gilera Runner
Jugar Con Juegos
 
Solutions modulaires pour bureaux - Aogeco
Solutions modulaires pour bureaux - AogecoSolutions modulaires pour bureaux - Aogeco
Solutions modulaires pour bureaux - Aogeco
algecoFR
 
Chemises sur mesure
Chemises sur mesureChemises sur mesure
Chemises sur mesure
balmoryfrench
 
Cónica número 15
Cónica número 15Cónica número 15
Cónica número 15
Luis Bados Ramirez
 
Ha2 nm50 eq#4-metodología espiral
Ha2 nm50 eq#4-metodología espiralHa2 nm50 eq#4-metodología espiral
Ha2 nm50 eq#4-metodología espiral
Luis Pérez
 
Etude de cas
Etude de casEtude de cas
Etude de cas
dody63
 
davask web limited - presentation - français
davask web limited - presentation - françaisdavask web limited - presentation - français
davask web limited - presentation - français
davask web ltd
 
Robert doisneau
Robert doisneauRobert doisneau
Robert doisneau
Ana Prieto González
 

En vedette (20)

André Citröen
André Citröen André Citröen
André Citröen
 
Tour Bus Juego
Tour Bus JuegoTour Bus Juego
Tour Bus Juego
 
03 expo reforma 2011 matemáticas
03 expo reforma 2011 matemáticas03 expo reforma 2011 matemáticas
03 expo reforma 2011 matemáticas
 
Incorporación de TIC en la Universidad Católica de Colombia
Incorporación de TIC en la Universidad Católica de ColombiaIncorporación de TIC en la Universidad Católica de Colombia
Incorporación de TIC en la Universidad Católica de Colombia
 
Sistemas contra incendio
Sistemas contra incendioSistemas contra incendio
Sistemas contra incendio
 
Fruugo - Ouvrez-vous à l'International
Fruugo - Ouvrez-vous à l'InternationalFruugo - Ouvrez-vous à l'International
Fruugo - Ouvrez-vous à l'International
 
Fortune Article
Fortune ArticleFortune Article
Fortune Article
 
Les meilleurs hôtels à sousse,tunisie
Les meilleurs hôtels à sousse,tunisieLes meilleurs hôtels à sousse,tunisie
Les meilleurs hôtels à sousse,tunisie
 
Solution modulaire pour stockage - Algeco
Solution modulaire pour stockage - AlgecoSolution modulaire pour stockage - Algeco
Solution modulaire pour stockage - Algeco
 
Presentacion ultima
Presentacion ultimaPresentacion ultima
Presentacion ultima
 
Avoir un site web sexy ou rentable?
Avoir un site web sexy ou rentable? Avoir un site web sexy ou rentable?
Avoir un site web sexy ou rentable?
 
Dessins
DessinsDessins
Dessins
 
Juego Gilera Runner
Juego Gilera RunnerJuego Gilera Runner
Juego Gilera Runner
 
Solutions modulaires pour bureaux - Aogeco
Solutions modulaires pour bureaux - AogecoSolutions modulaires pour bureaux - Aogeco
Solutions modulaires pour bureaux - Aogeco
 
Chemises sur mesure
Chemises sur mesureChemises sur mesure
Chemises sur mesure
 
Cónica número 15
Cónica número 15Cónica número 15
Cónica número 15
 
Ha2 nm50 eq#4-metodología espiral
Ha2 nm50 eq#4-metodología espiralHa2 nm50 eq#4-metodología espiral
Ha2 nm50 eq#4-metodología espiral
 
Etude de cas
Etude de casEtude de cas
Etude de cas
 
davask web limited - presentation - français
davask web limited - presentation - françaisdavask web limited - presentation - français
davask web limited - presentation - français
 
Robert doisneau
Robert doisneauRobert doisneau
Robert doisneau
 

Similaire à Chip_Ninja____Rapport_soutenance_finale

S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdfS2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
louise645546
 
Rapport final
Rapport finalRapport final
Rapport final
DrunkenMoron
 
PFA___Hlabba_Bacem.pdf
PFA___Hlabba_Bacem.pdfPFA___Hlabba_Bacem.pdf
PFA___Hlabba_Bacem.pdf
BacemHlabba
 
Projet de-recherche-Tuteuré
Projet de-recherche-TuteuréProjet de-recherche-Tuteuré
Projet de-recherche-Tuteuré
Rullier Anthony
 
Yassine Otmane voiture commandée à distance (XBEE)
Yassine Otmane voiture commandée à distance (XBEE)Yassine Otmane voiture commandée à distance (XBEE)
Yassine Otmane voiture commandée à distance (XBEE)
Othmane Yassine
 
Automatisation d'une maison intelligente via une application android
Automatisation d'une maison intelligente via une application androidAutomatisation d'une maison intelligente via une application android
Automatisation d'une maison intelligente via une application android
Abderrahim Bouharaoua
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
Adobe Photoshop CS5
Adobe Photoshop CS5Adobe Photoshop CS5
Adobe Photoshop CS5
Claudio Montoni
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard RoulleauRapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Nicolas Roulleau
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Haytam EL YOUSSFI
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
Mohamed Boubaya
 
Lavorare con java 6
Lavorare con java 6Lavorare con java 6
Lavorare con java 6
Pi Libri
 
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...Hadjer BENHADJ DJILALI
 
Projet réalisé par ameny Khedhira & Arij Mekki
Projet réalisé par  ameny Khedhira & Arij MekkiProjet réalisé par  ameny Khedhira & Arij Mekki
Projet réalisé par ameny Khedhira & Arij Mekki
Ameny Khedhira
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP SoftphoneHamza Lazaar
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
safwenbenfredj
 
notes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdfnotes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdf
CoulibalyYoussoufngo
 

Similaire à Chip_Ninja____Rapport_soutenance_finale (20)

S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdfS2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
S2_Projet_-_Groupe_18_-_Cahier_des_charges.pdf
 
Rapport final
Rapport finalRapport final
Rapport final
 
PFA___Hlabba_Bacem.pdf
PFA___Hlabba_Bacem.pdfPFA___Hlabba_Bacem.pdf
PFA___Hlabba_Bacem.pdf
 
Projet de-recherche-Tuteuré
Projet de-recherche-TuteuréProjet de-recherche-Tuteuré
Projet de-recherche-Tuteuré
 
Yassine Otmane voiture commandée à distance (XBEE)
Yassine Otmane voiture commandée à distance (XBEE)Yassine Otmane voiture commandée à distance (XBEE)
Yassine Otmane voiture commandée à distance (XBEE)
 
Automatisation d'une maison intelligente via une application android
Automatisation d'une maison intelligente via une application androidAutomatisation d'une maison intelligente via une application android
Automatisation d'une maison intelligente via une application android
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
Adobe Photoshop CS5
Adobe Photoshop CS5Adobe Photoshop CS5
Adobe Photoshop CS5
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard RoulleauRapport Projet Application Web De Domotique Arduino - Liotard Roulleau
Rapport Projet Application Web De Domotique Arduino - Liotard Roulleau
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
QQCOQP-Document_animateur_Tome1_Thésée
QQCOQP-Document_animateur_Tome1_ThéséeQQCOQP-Document_animateur_Tome1_Thésée
QQCOQP-Document_animateur_Tome1_Thésée
 
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...Deep Learning : Application à la reconnaissance d’objets de classes multiples...
Deep Learning : Application à la reconnaissance d’objets de classes multiples...
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Lavorare con java 6
Lavorare con java 6Lavorare con java 6
Lavorare con java 6
 
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
Mémoire Parallélisation d'algorithmes de graphes avec MapReduce sur un cluste...
 
Projet réalisé par ameny Khedhira & Arij Mekki
Projet réalisé par  ameny Khedhira & Arij MekkiProjet réalisé par  ameny Khedhira & Arij Mekki
Projet réalisé par ameny Khedhira & Arij Mekki
 
Android VoIP/SIP Softphone
Android VoIP/SIP SoftphoneAndroid VoIP/SIP Softphone
Android VoIP/SIP Softphone
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
 
notes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdfnotes-de-cours-de-fouille-de-donnees.pdf
notes-de-cours-de-fouille-de-donnees.pdf
 

Chip_Ninja____Rapport_soutenance_finale

  • 1. ´Ecole pour l’informatique et les techniques avanc´ees Rapport de projet Un jeu de Mushroom Compiler Ann´ee scolaire 2013-2014 Projet d’InfoSup Villejuif, le 13 juin 2014 Alexandre Doussot Chady Dimachkie Benjamin R´echou dousso a dimach c rechou b
  • 2. chip-ninja() Page 2 sur 78 Sommaire 1 Introduction 5 2 Le groupe 6 2.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Architecture du code 9 3.1 H´eritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 ´Etats du personnage . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Moteur de Tuiles 13 4.1 Impl´ementions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2 Fonctionnalit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Moteur Physique 14 5.1 Physique des personnages . . . . . . . . . . . . . . . . . . . . . 14 5.2 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 Moteur Graphique 22 6.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2 Rayons cr´epusculaires . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3 Moteur `a particules . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4 Arri`ere-plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7 Gameplay 39 7.1 Le coeur du gameplay . . . . . . . . . . . . . . . . . . . . . . . 39 7.2 Ajouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8 Contenu 41 8.1 Graphismes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.2 Niveaux Artisanaux . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Mushroom Compiler 2
  • 3. chip-ninja() Page 3 sur 78 8.3 Generation Proc´edurale . . . . . . . . . . . . . . . . . . . . . . 43 8.4 Musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.5 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 9 Outils de developpement 48 9.1 ´Editeur de niveau . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10 Intelligence Artificielle 49 10.1 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.2 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.3 Bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 11 R´eseau 50 11.1 Multijoueur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.2 Pr´esentation du mode de jeu . . . . . . . . . . . . . . . . . . . 50 11.3 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 12 Site Internet 55 12.1 Responsive Design . . . . . . . . . . . . . . . . . . . . . . . . . 55 12.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 13 Conclusions personnelles 57 13.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . . . . 58 13.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . . . . 59 14 Conclusion 60 Annexes 61 A Comment lire ce rapport ? 61 B R´ef´erences 62 C Moteur Physique 63 C.1 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 D R´eseau 66 D.1 Formatage des donn´ees . . . . . . . . . . . . . . . . . . . . . . 66 Mushroom Compiler 3
  • 4. chip-ninja() Page 4 sur 78 E Images 68 E.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 68 E.2 Ennemis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 E.3 Personnage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 F Glossaire 71 Mushroom Compiler 4
  • 5. chip-ninja() Page 5 sur 78 1 Introduction Dans le cadre de nos ´etudes `a ´Epita, nous avons eu `a r´ealiser un projet libre en groupe pendant sept mois pour notre ann´ee d’Infosup. Ce projet a pour but de nous permettre d’appliquer ce qui `a ´et´e vu durant l’ann´ee, que ce soit en TP, en algorithmique, en m´ethodologie ou en SI. Notre groupe, Mushroom Compiler, est actuellement compos´e des membres suivants : Alexandre Doussot, Chady Dimachkie, Benjamin R´echou. Le sujet ´etant libre, nous avons d´ecid´e de le d´edier `a une passion qui nous est commune : un jeu vid´eo. C’est un sujet qui, en plus d’ˆetre int´eressant `a un niveau personnel, requiert un tr`es vaste domaine de comp´etence. Ce projet pluri-disciplinaire n’est donc qu’`a but purement didactique. Le jeu a ´et´e r´ealis´e en C# `a l’aide de la s´erie d’outils XNA. Les multiples facettes interd´ependantes que composent un jeu vid´eo sont ´egalement parfaites pour affˆuter notre sens de travail en groupe. C’est ainsi que nous avons r´ealis´e des moteurs de tuile, gra- phique, et physique, une architecture r´eseau, une intelligence artifi- cielle, un gameplay, du contenu et des outils pour nous aider. Mushroom Compiler 5
  • 6. chip-ninja() Page 6 sur 78 2 Le groupe 2.1 Alexandre Doussot Un jour, en 5e, m’a ´et´e pos´e la question suivante : ”Que vas-tu faire plus tard ?”. Ayant longtemps refl´echi, et ne pouvant me d´ecider, non pas par une trop grande h´esitation, mais plutˆot par une ab- sence d’envies, je finis par ´ecrire ”Programmeur de jeux vid´eo”, ´etant, comme la plupart de mes contemporains, assez vers´e dans le m´edium vid´eoludique. C’est ainsi que je me mis `a m’interesser de plus pr`es `a l’informatique et plus particuli`erement au langage C, un des langages les plus vieux et les plus matures utilis´e aujourd’hui. Progressant donc `a l’aide du Site du Z´ero, aujourd’hui renomm´e en OpenClassrooms, je me mis ensuite au Java, qui me fit d´ecouvrir le potentiel ´eblouissant de la Programmation Orient´ee Objet, dont je ne maˆıtrise, mˆeme au- jourd’hui, qu’une infime fraction. C’est par la suite que je m’int´eressai au C++, qui pour moi, r´eunit les avantages d’un langage fort dans un environnement de d´eveloppement ´eprouv´e et de la Programmation Orient´ee Objet. `A mon grand d´epit, mon lyc´ee n’offrit pas l’option ISN. Cepen- dant, ´etant en Terminale S-SI, je profitai du projet pluri-disciplinaire pour effectuer un sujet le plus proche possible de l’informatique, et finis par cr´eer un logiciel contrˆolant un robot Lego, et lui permettant d’emprunter un trajet pr´ed´etermin´e. C’est me rapprocher durant la fin de l’ann´ee-scolaire 2012-2013 de personnes faisant parti de la future promotion 2018 et de la pro- motion 2017 qui me poussa `a essayer les syst`emes UNIX, et plus particuli`erement GNU/Linux. Je fus conquis par la puissance du syst`eme et suis aujourd’hui l’heureux possesseur d’une distribution linux nomm´e Arch. `A l’´Epita, j’ai d´ecouvert le Caml, et, nonobstant mon amour pour l’orient´e objet, la programmation fonctionnelle m’a introduit `a un tout nouveau mode de pens´ee que je trouve grandement int´eressant. Mushroom Compiler 6
  • 7. chip-ninja() Page 7 sur 78 Finalement, je suis tr`es heureux de pouvoir enfin r´ealiser un jeu vid´eo, un de mes d´esirs les plus chers depuis des ann´ees, n’ayant pas eu assez de temps libre au lyc´ee. Dans ce rapport, tout ce que j’ai r´ealis´e sera en bleu. 2.2 Chady Dimachkie Lors de ma jeunesse, je n’avais pas d’ordinateur chez moi, mais une lassante console qui m’a d´etourn´e des appareils num´eriques. Heu- reusement, en d´ebut de coll`ege, mes parents achet`erent un ordinateur portable avec le fameux syst`eme Windows XP. Je fus fascin´e par la complexit´e d’un tel syst`eme dans une si petite machine. Naturelle- ment, je me suis int´eress´e au fonctionnement d’une telle machine, ce qui m’a pouss´e, plus tard, vers les langages de programmation, plus particuli`erement, le langage C. Celui-ci me permit d’exploiter les possibilit´es de mon mat´eriel. Je compris, ainsi, tout ce que pouvais m’offrir ma machine. Plus tard, au lyc´ee, apr`es avoir fait assez de C, je me retirai une couche d’abstraction pour aller plus bas, en assembleur et je d´ecouvris l’architecture de ma machine et commenc¸ais `a essayer de comprendre le fonctionnement des architectures de nos syst`emes d’information. Je m’y int´eressais tellement, que je d´ecidais de commencer un syst`eme d’exploitation tr`es basique en 16-bits avec Netwide Assembly (NASM). Celui-ci disposait du syst`eme de fichier CAT16 et d’un mode graphique VESA, avec certaines interruptions faites par moi-mˆeme. Je quittai ce projet, bien trop long et complexe et je me remis `a faire du C, pour enfin arriver au C++, me permettant d’utiliser les APIs OpenGL et Direct3D avec leur langage de shaders respectifs. C’est ainsi que j’ai acquis de l’exp´erience dans le domaine du rendu et que je me mis `a rajouter des effets pour un rendu de meilleur qualit´e pour notre projet. Bien sˆur, j’ai voulu essayer d’autres domaines, comme le r´eseau ou le d´eveloppement d’une intelligence artificielle et mˆeme la cr´eation de contenu pour le jeu. De cette mani`ere, j’essaye de toucher Mushroom Compiler 7
  • 8. chip-ninja() Page 8 sur 78 `a plusieurs domaines, tous diff´erents les uns des autres, pour acqu´erir plus de comp´etences en informatique. Dans ce rapport, tout ce que j’ai r´ealis´e sera en orange. 2.3 Benjamin R´echou ´Etant petit j’ai toujours voulu savoir pourquoi, cette ´eternelle ques- tion m’a amen´e `a d´emonter la majorit´e des choses que j’ai pu trouver `a l’´epoque. J’ai dans un premier temps pens´e `a m’orienter vers l’hor- logerie. Mais une de mes grandes passions de l’´epoque ´etant les jeux vid´eo je me suis donc int´eress´e `a l’informatique assez tˆot. D´es que j’eut acc`es `a Internet je me mis `a faire mes recherches pour comprendre du mieux que je pouvais ces jeux que j’aimais tant. J’ai rapidement r´ealis´e les possibilit´es offertes par l’informatique et j’ai donc commenc´e en 5eme `a coder de petit programmes en suivant des tutoriels sur internet. Au lyc´ee j’ai rapidement arrˆet´e de coder car j’ai ´et´e pris d’une nouvelle passion, la physique-chimie et la m´ecanique. J’ai donc commenc´e a bricoler un peu ce que je pouvais chez moi et en terminale j’ai choisi option Physique-Chimie, choix que je n’ai pas regrett´e. Malgr´e tout cela je ne voyais aucune perspective d’avenir que me satisfasse. Je me suis orient´e vers EPITA pour renouer avec une vieille passion, de plus un ing´enieur est amen´e `a chercher et `a comprendre le pourquoi et comment des choses ce qui me semble la chose la plus adapt´e `a ma nature curieuse. C’est donc en cherchant un moyen d’associer passion et avenir que je me suis tourn´e vers l’EPITA. Pour le projet de premi`ere ann´ee, j’ai trouv´e deux personnes qui aiment au moins autant que moi le jeu vid´eo et de ce fait j’´etais tr`es motiv´e pour cet ambitieux projet. Malgr´e mes lacunes en informatique je suis rest´e convaincu qu’il me suffirait de m’y int´eresser suffisamment pour que c¸a se fasse. Notre projet me permet de r´ealiser un rˆeve d’enfant tout en apprenant l’informatique, que demander de plus ? Dans ce rapport, tout ce que j’ai r´ealis´e sera en violet. Mushroom Compiler 8
  • 9. chip-ninja() Page 9 sur 78 3 Architecture du code 3.1 H´eritage Dans ce projet, il a ´et´e d´ecid´e de repr´esenter chaque entit´e pr´esente en jeu par une classe. Cependant, cela pose un probl`eme. En effet, cr´eer une classe par ennemi a pour effet de dupliquer le code, car les ennemis ont des similarit´es. Pour cela, `a ´et´e utilis´ee une notion fondamentale de la programmation orient´ee objet, l’h´eritage. Elle permet entre autres la r´eutilisabilit´e et l’adaptabilit´e des objets grˆace au polymorphisme. Elle se nomme ainsi car le principe est en quelque sorte le mˆeme que celui d’un arbre g´en´ealogique. Le principe est simple. Une classe m`ere est d´efinie, avec ses attributs, dont toutes ses classes h´eritantes, appel´ees classes filles , h´eritent. Cependant, une seule classe m`ere ne suffit pas. C’est pour cela qu’a ´et´e utilis´e l’h´eritage multiple. Ainsi, chaque entit´e h´erite d’une classe m`ere DrawableEntity qui h´erite elle-mˆeme de Entity. Figure 1 – H´eritage des entit´es Mushroom Compiler 9
  • 10. chip-ninja() Page 10 sur 78 3.2 Composants Une des particularit´es d’XNA est de nous permettre de d´efinir des composants. XNA en poss`ede principalement deux : les Game Components et les DrawableGameComponent. Un objet h´eritant de la classe GameComponent se verra mis `a jour `a chaque tour de la boucle de jeu automatiquement par XNA, ce qui permet de ne pas surcharger le code. Un objet h´eritant de DrawableGameComponent, quant `a lui, se verra mis `a jour, mais ´egalement dessin´e automatiquement par XNA. 3.2.1 Gestionnaire d’entr´ees Pour g´erer les entr´ees du joueur, lorsque celui-ci appuie sur un bouton par exemple, il a fallu cr´eer une classe nomm´ee InputHandler. Celle-ci permet, lorsque le joueur appuie sur un bouton, d’effectuer une action correspondante. Ainsi, lorsque le joueur appuiera par exemple sur le clic droit de la souris, le personnage sautera. Cependant, grˆace `a l’impl´ementation d’un patron de conception (aussi appel´e design pattern ) d´eriv´e du patron Commande , le gestionnaire peut, au lieu de contrˆoler le personnage, permettre au joueur de contrˆoler un ennemi. En effet, les ennemis comme le joueur h´eritent de la classe nomm´ee GameActor. Ainsi, grˆace au polymorphisme, qui permet de consid´erer une classe comme une de ses classes m`eres, le gestionnaire prend en param`etre l’entit´e `a laquelle il demande de r´ealiser une action, et non seulement le h´eros. Comme il est imp´eratif de consid´erer les entr´ees du joueur `a chaque tour de boucle, elle est ´evidemment consid´er´ee comme un composant, et donc h´erite de la classe GameComponent. `A chaque tour de boucle, le gestionnaire r´ecup`ere l’´etat du clavier, l’´etat dans lequel se trouve le jeu, ainsi que l’entit´e sur laquelle il doit agir. Cela permet d’avoir une plus grande flexibilit´e, et d’avoir des actions contextuelles `a l’´etat du jeu. Par exemple, lorsque le joueur appuie sur une touche fl´ech´ee, le gestionnaire effectuera des actions diff´erentes selon l’´etat : le curseur se d´eplacera dans les menus si le Mushroom Compiler 10
  • 11. chip-ninja() Page 11 sur 78 joueur se trouve sur le menu de pause, et le personnage se d´eplacera si le joueur est en jeu. 3.2.2 Gestionnaire d’´etats Un jeu peut se trouver dans plusieurs ´etats, ou ´ecrans, comme l’´ecran titre, le jeu, l’´ecran de fin de jeu, ou les options. Pour mod´eliser cela, il a fallu cr´eer un syst`eme de gestion. En effet, a ´et´e cr´ee une classe nomm´ee GameStateManager dont le rˆole est de g´erer les diff´erents ´ecrans. Cette classe poss`ede comme attribut un objet GameState qui symbolise l’´ecran actuel. Celui-ci, repr´esent´e par une classe, se trouve ˆetre en fait la classe m`ere de chacun des diff´erents ´etats. Ceux-ci sont donc ´egalement repr´esent´es par des classes, avec chacune leurs sp´ecificit´es, comme leurs attributs, ainsi que leurs m´ethodes de mise `a jour et de dessin. C’est une technique efficace car elle permet la m´emorisation des ´etats, ce qui est utile lorsque le joueur quitte les options pour revenir au jeu. 3.2.3 Gestionnaire d’arri`ere-plans Le temps accord´e `a la r´ealisation de ce projet, assez r´eduit pour un jeu vid´eo, nous a incit´e `a mettre en place un certain nombre de concepts. Ainsi, ont ´et´e impl´ement´es de diff´erents arri`ere-plans pour chaque niveau, introduisant de la vari´et´e visuelle. Cependant, la diff´erence n’est pas que visuelle, elle est ´egalement technique. En effet, les arri`eres-plans n’utilisent pas les mˆeme techniques ; certains utilisent des arri`ere-plans en parallaxe, d’autres des rayons cr´epusculaire, ou d’autres encore du normal mapping. Ainsi, sur le mˆeme principe que pr´ec´edemment, mais `a plus petite ´echelle, est pr´esent un gestionnaire d’arri`ere-plans, repr´esent´e par une classe nomm´ee BackgroundManager. Chaque arri`ere-est quant `a lui repr´esent´e par une classe correspon- dante, sobrement nomm´ees Background1, Background2 et ainsi de suite. Mushroom Compiler 11
  • 12. chip-ninja() Page 12 sur 78 3.3 ´Etats du personnage Le personnage contrˆol´e par le joueur est un syst`eme complexe, `a plusieurs ´etats. En effet, le joueur peut ˆetre en train de courir ou de marcher, ainsi qu’il peut ˆetre en train de sauter ou mˆeme de double- sauter. Pour visualiser ce syst`eme nous utilisons deux automates finis imbriqu´es, ce qui correspond au patron ”´Etat”. Un automate fini, ´egalement appel´e machine avec un nombre fini d’´etats, est un syst`eme compos´e d’´etats et de transitions. Leur particularit´e est que l’automate ne peut avoir qu’un ´etat valide `a la fois, et qu’il passe d’un ´etat `a l’autre selon certaines conditions. Ainsi, l’automate d´ecrivant le personnage est compos´e de deux automates imbriqu´es. Le premier, imbriqu´e dans le second, d´ecrit les ´etats du personnage au sol. De fac¸on similaire aux ´etats de jeu, ceux-ci sont d´ecrits par des classes h´eritant de la classe PlayerState. Ils sont au nombre de trois : <Arr^et,Marche,Course>. Le second, quant `a lui, d´ecrit les ´etats du joueur sur le plan ho- rizontal. Il comprend <Sur le sol, En saut, En double-saut>. Il a fallu imbriquer les deux automates car le joueur ne saute pas de la mˆeme fac¸on selon qu’il soit en train de courir ou de marcher. Mushroom Compiler 12
  • 13. chip-ninja() Page 13 sur 78 4 Moteur de Tuiles Le projet a pour but de r´ealiser un jeu de plate-forme s’inspirant des jeux iconiques. C’est pourquoi il a fallu impl´ementer ce qu’on appelle un moteur de tuiles. Un moteur de tuiles permet fondamentalement d’afficher un niveau compos´e de petits blocs, appel´es tuiles , d’une taille pr´ed´efinie. 4.1 Impl´ementions Dans notre projet, un niveau est d´efini par ses m´eta-donn´ees, ainsi que l’emplacement et la nature des diff´erents blocs qui le composent qui sont stock´es dans ce que nous appelons une tile map , ou carte de tuile, qui est un tableau `a deux dimensions. Un niveau est repr´esent´ee par un fichier contenant premi`erement les m´eta-donn´ees correspondantes, puis sa tile map. 4.1.1 M´eta-donn´ees Un niveau poss`ede plusieurs m´eta-donn´ees. Premi`erement, les di- mensions du niveau. Deuxi`emement, la taille en pixels que mesure une tuile. Ensuite, l’ensemble des images associ´es `a chacune des tuiles, aussi appel´ee tileset , suivie de l’arri`ere-plan. Par la suite, la po- sition `a laquelle le joueur commence. Derni`erement, les r`egles de gameplay s’appliquant au niveau. 4.2 Fonctionnalit´es Le moteur fait cependant plus que de charger et afficher des ni- veaux. En effet, il permet de modifier le niveau en temps r´eel. Par exemple, si un joueur attaque `a plusieurs reprises une tuile, celle-ci pourra se briser, et disparaˆıtre. Mushroom Compiler 13
  • 14. chip-ninja() Page 14 sur 78 5 Moteur Physique 5.1 Physique des personnages 5.1.1 D´eplacement Le personnage poss`ede diff´erents types de d´eplacement, qui d´epen- dent de l’´etat dans lequel se trouve le joueur. En effet, il ne se d´eplace pas de la mˆeme fac¸on selon qu’il soit sur le sol ou dans les airs. Ainsi, lorsqu’il se d´eplace sur le sol, il se d´eplace `a une vitesse constante et peut se retourner imm´ediatement, bien qu’il poss`ede une inertie `a l’arrˆet. Pour ajouter de l’inertie `a l’arrˆet, il suffit, en lieu de changer brus- quement la vitesse du personnage en 0, de la multiplier par un nombre symbolisant la perte de vitesse. Ainsi, lorsque le joueur marche et s’arrˆete, on multiplie sa vitesse par 0.8 `a chaque image, soit toutes les 1/60e de secondes. Cependant, lorsque le joueur est dans les airs et se retourne, le joueur va changer de direction progressivement. Il va d’abord ralentir horizontalement, puis se d´eplacer dans une direction inverse. L’inertie est donc bien plus prononc´ee dans cet ´etat. 5.1.2 Gravit´e Le moteur physique permet ´egalement de jouer avec la gravit´e des personnages. On peut en effet la modifier pour l’att´enuer ou au contraire la renforcer, ou mˆeme l’inverser. 5.2 Collisions Un syst`eme bas´e sur tuiles de fac¸on fluide a ´et´e utilis´e pour la d´etection d’obstacles. C’est un syst`eme qui ´etait vastement utilis´e sur les syst`emes 8 et 16 bits et qui reste pertinent aujourd’hui. Il n’est pas tr`es dur `a impl´ementer, tr`es flexible, permet d’´editer des niveaux simplement, et permet d’utiliser des inclinaisons. Le principe Mushroom Compiler 14
  • 15. chip-ninja() Page 15 sur 78 est simple : Lorsque le joueur se d´eplace, on regarde l’emplacement de l’obstacle le plus proche dans la direction dans lequel le joueur se meut. Si obstacle il y a, alors on fera en sorte qu’il se d´eplace de la distance minimale entre la distance dont il ´etait cens´e se d´eplacer et la distance entre l’obstacle et lui. En pratique, il suffit de parcourir le tableau symbolisant le niveau pour chaque rang´ee sur laquelle le joueur se trouve pour obtenir la position de l’obstacle. 5.3 Attaque sp´eciale Afin de placer une distinction entre notre personnage, qui est un ninja, et les autres, il a fallu le doter d’une attaque sp´eciale vraiment particuli`ere. Celle-ci se devait d’ˆetre impressionnante au point de donner envie au joueur de l’ex´ecuter. Ainsi, nous avons pens´e `a une attaque sp´eciale permettant de d´ecouper l’ennemi vis´e en autant de morceaux que voulu, c’est-`a-dire, en un nombre virtuellement infini. Pour cela, il fallait un algorithme capable de d´ecouper n’importe quel polygone pour en recr´eer d’autres. 5.3.1 Sutherland-Hodgman L’algorithme de Sutherland-Hodgman est, `a la base, utilis´e pour faire du clipping . Le clipping est le proc´ed´e permettant de d´eterminer la partie d’une r´egion d’un espace se trouvant dans une autre r´egion d’un autre espace. Ce genre de technique est fortement utilis´ee lorsqu’il y a un rendu graphique `a l’´ecran et qu’il faut trouver quelles parties ne sont pas vi- sibles `a l’´ecran pour ne pas les dessiner, et ainsi optimiser les temps de calculs. Bien sˆur, son utilisation va en ˆetre diff´erente, mais le principe reste le mˆeme. Avec cet algorithme, en prenant une liste de sommets d’un poly- gone et une liste de plans, ainsi qu’une liste de nouveau sommets Mushroom Compiler 15
  • 16. chip-ninja() Page 16 sur 78 Figure 2 – Clipping d’un cube par un plan existant uniquement dans cet ensemble de plan, on peut appliquer du clipping. Sachant que notre jeu est en deux dimensions (2D) et que le personnage d´ecoupera l’ennemi avec un sabre, la liste de plans n’en contiendra qu’un et sera une ligne. Figure 3 – Clipping d’un rectangle par une droite Pour ceci, il est utile de connaˆıtre le cˆot´e sur lequel le sommet en cours de traitement se trouve par rapport au plan (`a la ligne) de d´ecoupe. Ainsi, il suffit d’effectuer un simple produit scalaire, tel que : Figure 4 – Distance d’un point par rapport `a un plan Soient p2 un point quelconque sur le plan de d´ecoupe et n un Mushroom Compiler 16
  • 17. chip-ninja() Page 17 sur 78 vecteur normal au plan. Pour connaˆıtre la direction du point p1 par rapport au plan, le signe du r´esultat d est utilis´e. Ensuite, il faut d´efinir ce que repr´esentent l’avant et l’arri`ere du plan. L’avant est dans la direction de la normale n du plan et l’arri`ere dans le sens oppos´e. Apr`es cela, il faut pouvoir calculer une intersection d’un plan et d’une ligne ou plutˆot d’un plan et d’un point d’une ligne. Cela est fait grˆace `a une interpolation lin´eaire, telle que : Lerp = d´ebut + alpha ∗ (fin − d´ebut). que l’on re-factorise en : (1 − alpha) ∗ d´ebut + alpha ∗ fin pour ´eviter les erreurs dues aux impr´ecisions sur les nombres `a vir- gule flottante et pour pouvoir garantir l’existence du cas o`u le point recherch´e est au mˆeme endroit que fin lorsque alpha vaut 1. Finalement, il faudra une liste de sommets que l’on appellera front . Avec tout ceci, l’application de l’algorithme de Sutherland-Hodgman est possible. Les ´etapes `a effectuer se r´esument facilement : - Si p1 et p2 sont `a l’avant - Mettre p2 dans front - Si p1 est `a l’avant et p2 `a l’arri`ere - Mettre le point d’intersection de la droite (p1,p2) et du plan de d´ecoupe dans front - Si p1 est `a l’arri`ere et p2 `a l’avant - Mettre le point d’intersection de la droite (p1,p2) et du plan de d´ecoupe dans front - Mettre p2 dans front Le probl`eme ici, c’est que l’on aura un polygone `a l’avant seulement, alors que nous en voulons des deux cˆot´es pour donner un effet de d´ecoupe. Il faut donc modifier tout cela et rajouter une deuxi`eme liste que l’on appellera back . Il faut aussi d´efinir ce qu’est le fait d’ˆetre dans le plan de d´ecoupe. De cette mani`ere, une ´epaisseur de d´ecoupe pourra ˆetre simul´ee et on la nommera EPSILON. De ce fait, Mushroom Compiler 17
  • 18. chip-ninja() Page 18 sur 78 ˆetre sur le plan signifie : n’ˆetre ni `a l’avant, ni `a l’arri`ere du plan, c’est- `a-dire que la distance du point sur le plan est inf´erieure `a EPSILON et est sup´erieure `a −EPSILON. Il faut ´egalement ordonner les sommets de ces listes, de telle mani`ere `a ce qu’ils puissent ˆetre trait´e par un processeur graphique et donc avoir lors d’une d´ecoupe, des polygones compos´es de la mani`ere suivante : Figure 5 – D´ecoupe d’un triangle Ainsi, l’algorithme devient : - Si p1 et p2 sont `a l’avant - Mettre p2 dans front - Si p1 est dans le plan et p2 `a l’avant - Mettre p2 dans front - Si p1 est `a l’arri`ere et p2 `a l’avant - Mettre le point d’intersection de la droite (p1,p2) et du plan de d´ecoupe dans front et dans back - Mettre p2 dans front - Si p1 est `a l’avant et p2 `a l’arri`ere - Mettre le point d’intersection de la droite (p1,p2) et du plan de d´ecoupe dans front et dans back - Mettre p2 dans back - Si est p1 `a l’avant et p2 est dans le plan - Mettre p2 dans front - Si p1 et p2 sont dans le plan - Mettre p2 dans front - Si est p1 `a l’arri`ere et p2 est dans le plan Mushroom Compiler 18
  • 19. chip-ninja() Page 19 sur 78 - Mettre p2 dans front et dans back - Si p1 est dans le plan et p2 `a l’arri`ere - Mettre p1 et p2 dans back - Si p1 et p2 sont `a l’arri`ere - Mettre p2 dans back Ces 9 cas permettent d’avoir ceci : Figure 6 – D´ecoupe d’un rectangle par une ligne Apr`es cela, ces listes de sommets sont donn´ees `a notre processeur graphique. Celui-ci va pouvoir faire le rendu voulu si l’on utilise le format de rendu triangle fan permettant d’avoir des polygones compos´es de triangles partageant un mˆeme sommet. Figure 7 – Assemblage de triangle Enfin, il reste `a traiter les coordonn´ees de notre texture, pour qu’elle ait l’air d’ˆetre appliqu´ee correctement `a notre ennemi d´ecoup´e. L’es- pace de coordonn´ee des textures, nomm´e l’espace de coordonn´ees UV , est tel que : Mushroom Compiler 19
  • 20. chip-ninja() Page 20 sur 78 Figure 8 – Coordonn´ees UV Bien sˆur, ce n’est pas tout, puisque nous faisons un rendu mais avec la mˆeme texture appliqu´ee `a chaque polygone de l’ennemi d´ecoup´e. C’est-`a-dire qu’`a l’´ecran il y aura plusieurs fois la mˆeme texture, comme si l’ennemi s’´etait multipli´e, mais avec une nouvelle forme `a chaque fois. Figure 9 – Bonne et mauvaise d´ecoupe Comme est visible sur l’image, le r´esultat du haut est ce qui est d´esir´e alors que celui du bas a rec¸u un traitement incorrect. Les tri- angles sont mis en ´evidence pour montrer qu’il s’agit d’un traitement o`u chaque polygone est pris individuellement. Pour r´esoudre cela, une matrice de passage pourrait ˆetre utilis´ee, mais il y a plus simple pour passer des coordonn´ee de l’espace ´ecran en coordonn´ees UV. Pour calculer la coordonn´ee U, la longueur du cˆot´e du dessus Mushroom Compiler 20
  • 21. chip-ninja() Page 21 sur 78 du rectangle de base formant le personnage est utilis´ee, servant de r´ef´erence. Ensuite, le cˆot´e le plus long entre le haut et le bas est pris et la diff´erence entre la r´ef´erence et ce cˆot´e permettra d’avoir les co- ordonn´ees de mani`ere assez pr´ecise. Pour la coordonn´ee V, la mˆeme proc´edure est effectu´ee, mais avec les cˆot´e droit et gauche. Avec tout ceci, la d´ecoupe est comme voulue initialement. 5.3.2 Ajout de physique Pour donner un meilleur effet et pour que le tout ne soit pas sta- tique, il fallait int´egrer un moteur physique aux morceaux d´ecoup´es de l’ennemi. Ainsi, l’effet serait meilleur et celui-ci serait proche de ce que propose le jeu vid´eo Metal Gear Rising : Revengeance, bien qu’en 2D. Une longue r´eflexion `a ´et´e port´ee `a l’´etude et la reproduction d’un mod`ele physique coh´erent et adapt´e, mais pour des raisons de concision, le lecteur pourra retrouver le cheminement math´ematique menant `a ce r´esultat en Annexe, partie C.1. Ce mod`ele permet d’obtenir une physique cr´edible, comme il est possible de le constater dans la capture d’´ecran suivante, o`u un ennemi est d´ecoup´e en 26 morceaux, tous affect´es par leur environnement. Figure 10 – Rendu non final Mushroom Compiler 21
  • 22. chip-ninja() Page 22 sur 78 6 Moteur Graphique 6.1 Normal Mapping Pour des niveaux dans le noir, il fallait avoir de l’´eclairage pour donner cet effet d’obscurit´e. De ce fait, pour avoir un tel effet, qui soit ´egalement agr´eable `a regarder, il fallait une solution. Ainsi, la technique du normal mapping a ´et´e choisie, permettant des effets de r´eflections dynamiques en temps r´eel, en se basant sur un certain mod`ele physique. 6.1.1 D´efinition Le normal mapping est une technique permettant de simuler des d´etails de tr`es haute qualit´e sur un mod`ele de faible qualit´e, en termes de polygones. Tout ceci est r´ealis´e avec un coˆut, au niveau des performances, tr`es acceptable. Cette technique est tr`es utilis´ee dans les jeux vid´eos en 3D. Dans ce projet, sont pr´esents des fonds, par exemple des murs, auxquels sera appliqu´ee cette technique, ce qui permet d’avoir des r´eflections dynamiques et en temps r´eel de lumi`ere. En effet, le normal mapping se base sur la mani`ere dont les r´eflections de lumi`eres sont d´ecrites pour donner une telle illusion. Et c’est bien cette caract´eristique de l’effet que l’on va utiliser, ainsi il y aura des r´eflections dynamiques et en temps r´eel lorsqu’une lumi`ere qui passera devant un quelconque objet ou fond. Figure 11 – Technique du normal mapping Mushroom Compiler 22
  • 23. chip-ninja() Page 23 sur 78 6.1.2 Principe Pour cet effet, il faudra cr´eer une image appel´ee normal map, telle que pour un texel (Texture ´el´ement, ´equivalent d’un pixel, mais pour une texture), les composantes R, G et B encoderont un vecteur de composante X, Y et Z, avec X vers la droite et Y vers le haut. Figure 12 – Une texture et sa Normal map Les composantes R, G et B sont comprises entre 0 et 1 et X,Y et Z entre -1 et 1. Avec ce vecteur, il faut pouvoir retrouver une normale, une tangente et une bitangente. Ceux-ci, vont nous permettre de cr´eer une matrice d´efinissant un espace. On peut facilement avoir la normale, en faisant : ComposanteNormale = (2 ∗ composanteCouleur) − 1 Nous avons d´ej`a la normale, laquelle nous permet de trouver une tangente. En th´eorie, pour choisir une tangente, il est possible de prendre n’importe laquelle, vu qu’il y en a une infinit´e, et pourtant, pour ´eviter des probl`emes qui d´et´erioreraient la qualit´e de certains cˆot´es, il faut prendre la tangente (voir annexe- Normale et Tangente) allant dans la mˆeme direction que les coordonn´ees de notre texture. (Voir Annexe - Cˆot´es). Et puisque qu’il nous faut un troisi`eme vecteur pour d´efinir un espace, il faut cherche une bitangente (voir annexe - Bitangente), qui sera perpendiculaire `a la tangente, pour faciliter les calculs. Il faut, maintenant, exprimer nos deux vecteurs. Sachant que notre texture est plaqu´ee sur des triangles, on peut poser DeltaPosition1 et DeltaPosition2, deux cˆot´es de l’un de nos triangle et deltaUV1 et Mushroom Compiler 23
  • 24. chip-ninja() Page 24 sur 78 deltaUV2, les diff´erences respectives des coordonn´ees UVs. Et ainsi, poser : DeltaPosition1 = (AbscissededeltaUV1) ∗ Tangente + (Ordonn´eedeDeltaUV1) ∗ Bitangente et DeltaPosition2 = (AbscissededeltaUV2) ∗ Tangente + (Ordonn´eedeDeltaUV2) ∗ Bitangente Il suffit de r´esoudre ces equations et, nous avons la tangente et la bitangente. Ce qui nous permet d’avoir notre matrice qui d´ecrit le changement d’espace entre l’espace bas´e sur les tangentes et l’espace du mod`ele sur lequel est appliqu´e l’effet.      Tx Bx Nx Ty By Ny Tz Bz Nz      Il faut noter qu’il y a 3 dimensions, mˆeme en 2D, puisque l’effet d’´eclairage donnera un effet de relief 3D. Cette matrice permet donc de faire des transformations sur des normales pour les adapter `a l’espace du mod`ele. Mais, nous voulons faire l’inverse, il faut donc inverser la matrice. Sachant que c’est une matrice qui repr´esente un rep`ere orthogonal, c’est-`a-dire que chaque vecteur est perpendiculaire `a un autre, et que nous sommes en 2D et qu’on n’applique pas de matrice de projection, on a simplement :      Tx Ty Tz Bx By Bz Nx Ny Nz      Avec tout ceci, il est possible d’impl´ementer deux shaders, qui, employ´es avec une certaine m´ethode de rendu, permettra d’avoir l’effet d´esir´e. 6.1.3 Le rendu Le rendu d’un environnement qui doit exploiter un tel effet de lumi`ere dynamique et en temps r´eel, n´ecessite une m´ethode de rendu qui n’est pas habituelle en 2D. Mushroom Compiler 24
  • 25. chip-ninja() Page 25 sur 78 En effet, il va falloir traiter quatre versions de l’image `a laquelle on veut appliquer l’effet. Il y aura donc : une Color map qui est la texture ´eclair´ee de mani`ere parfaite, puis la normal Map associ´ee. Apr`es traitement de ces deux l`a, il y aura la shadow map et finalement, la technique du blending sera utilis´ee, qui nous permet de m´elanger plusieurs rendus, avec laquelle on m´elangera la shadow map et la color map, pour obtenir l’image finale `a rendre `a l’´ecran. 6.1.3.a Valse des RenderTargets Pour faire tout ces rendus, il va nous falloir plusieurs RenderTar- gets, ceux-ci sont les ´el´ements sur lesquels le rendu sera fait. De mˆeme, il faut des listes de textures, une liste de color maps et une autre de normal maps. Finalement, une liste de coordonn´ees qui contient les d´ecalages de positions entre chaque textures. Cette derni`ere sera utilis´ee de la mˆeme fac¸on pour la liste de color map et de normal maps. Remarque : Dans ce qui suit, il y aura beaucoup de changements de RenderTargets. Il ne sera pas pr´ecis´e qu’`a chaque changement, il fau- dra passer par le RanderTarget principal, dont l’identifiant est null . Remarque 2 : Tous les RenderTargets ont les dimensions de l’´ecran. Ce n’est pas forc´ement le cas des textures. Premi`erement, toutes les couleurs du RenderTarget principal seront mises en Noir, ce qui est utile pour nettoyer la zone de rendu. La couleur noire est utilis´ee pour l’effet d’obscurit´e. Apr`es, on passe au RenderTarget de color maps qui est nettoy´e en noir, pour pouvoir dessiner toutes les color maps contenues dans la liste qui leur est propre en tenant compte des d´ecalages de coordonn´ees pr´ecis´es dans une liste. Ensuite, on prend le RenderTarget de normal maps dans lequel on dessine nos normal maps aux mˆeme coordonn´ees que nos color maps. Mushroom Compiler 25
  • 26. chip-ninja() Page 26 sur 78 Tout cela fini, on passe au RenderTarget de la shadow map o`u l’on pourra rendre celle-ci. Cette ´etape est la plus complexe dans ce rendu et n´ecessite un shader. 6.1.3.b Rendu de la shadow map Pour cette ´etape, nous avons d´efini au pr´ealable une liste des lumi`eres, contenant leur puissance, l’intensit´e de r´eflexion sp´eculaire, la dur´ee de chaque rayon ´emis, leur position et couleur, ainsi qu’un ´el´ement d´efinissant la couleur et la puissance de la lumi`ere ambiante. Ainsi, on effectue le traitement qui suit de la mˆeme mani`ere pour chaque lumi`ere, en tenant compte des diff´erentes valeurs entre cha- cune. Tout d’abord, on met en place un vertex buffer, qui est un tableau de coordonn´ees de sommets, contenant en plus, une couleur pour chaque sommet (qui n’est pas utile ici, car la couleur finale est r´ealis´e par interpolation lin´eaire, ce que l’on ne veut pas) et des coordonn´ees UV de textures. Cette ´etape est tr`es importante, car on ne dessine plus avec de simples SpriteBatch. Apr`es cela, il faut utiliser notre shader. Notre shader va, `a chaque it´eration, prendre la couleur qui se trouve `a certaines coordonn´ees sur la color map donn´ee au shader. Apr`es cela, il extrait une normal de la normal map, avec la formule donn´ee ci-dessus : Normale.X = (2 ∗ Couleur.R) − 1.0 Normale.Y = (2 ∗ Couleur.G) − 1.0 Normale.Z = (2 ∗ Couleur.B) − 1.0 Ensuite, on convertit les coordonn´ees actuelles, utilis´ees pour par- courir la color map et la normal map, en coordonn´ees sur l’espace ´ecran : Mushroom Compiler 26
  • 27. chip-ninja() Page 27 sur 78 PositionPixel.X = LongueurEcran ∗ AbscisseActuelle PositionPixel.Y = HauteurEcran ∗ Ordonn´eeActuelle PositionPixel.Z = 0, car nous sommes en 3D. Avec c¸a, on peut connaˆıtre la direction de la lumi`ere avec une soustraction de vecteurs : DirectionLumi`ere = PositionLumi`ere − PositionPixel On doit pouvoir normaliser ce vecteur : DirectionLumi`ereNormlis´e.X = DirectionLumi`ereNormalis´e.X longueur(DirectionLumi`ere) DirectionLumi`ereNormlis´e.Y = DirectionLumi`ereNormalis´e.Y longueur(DirectionLumi`ere) DirectionLumi`ereNormalis´e.Z = 0 Il faut ´egalement calculer la quantit´e de lumi`ere projet´ee, avec un produit scalaire : Quantit´eLumi`ere = Maximum(Normale·Dir´ectionLumi`ereNormalis´e, 0) Grˆace `a cela, le calcul de l’att´enuation conique nous permet de donner une projection de la lumi`ere dans le noir en forme de cˆone en 3D et donc de cercle en 2D : Att´enuationConique = saturate(1.0 − longueur(DirectionLumi`ere) Dur´eeDesRayonsDeLumi`ere ) Remarque : La fonction saturate permet de mettre le r´esultat dans l’intervalle [0, 1]. Ensuite, il faut obtenir le vecteur d´ecrivant la r´eflexion en 3D, par : R´eflexion = Normaliser(2 ∗ Quantit´eLumi`ere∗ (normale − DirectionLumi`ereNormalis´e)) Mushroom Compiler 27
  • 28. chip-ninja() Page 28 sur 78 Il reste une derni`ere ´etape avant de pouvoir exprimer la compo- sante sp´eculaire de notre ´eclairage. Il faut d´efinir ce qu’est, un half vector : Dans le fragment shader, les coordonn´ees de sommets qui sont trait´ees peuvent ˆetre consid´er´ee comme un vecteur qui va de la cam´era (ou l’oeil du spectateur) jusqu’au fragment (´el´ement contenant toutes les donn´ees n´ecessaires afin de g´en´erer ou non un pixel). Ainsi, en inversant la direction de ce vecteur, c’est-`a-dire, en multipliant toutes ses composantes par -1, le vecteur donnant la direction du regard du spectateur est obtenu. Sachant que la sc`ene est en 2D, il suffit d’avoir une composante `a 1 : HalfVector =      0 0 1      On peut donc maintenant trouver la composante sp´eculaire de notre ´eclairage : Sp´eculaire = Minimum((saturate(R´eflexion·HalfVector))10, Quantit´eLumi`ere) Figure 13 – R´eflexion Et finalement trouver la couleur que le shader doit renvoyer, qui est : Mushroom Compiler 28
  • 29. chip-ninja() Page 29 sur 78 R´esultat = Att´enuationConique∗CouleurLumi`ere∗Intensit´eLumi`ere R´esultat = R´esultat + (Sp´eculaire ∗ Intensit´eSp´eculaire ∗ Att´enuationConique). Nous avons l`a, la shadow map rendue dans son propre RenderTar- get. Bien sˆur, ce n’est pas fini et il reste quelques ´etapes. 6.1.3.c Blending Apr`es cela, le RenderTarget de base est remit et un deuxi`eme sha- der est utilis´e pour combiner toutes les maps cr´e´ees pr´ec´edemment. Ce shader va avoir besoin de toutes les maps cr´e´ees, ainsi, il y aura besoin de la couleur `a une certaine coordonn´ee des color map et shadow map. Pour la normal map, il va falloir combiner les couleurs pour n’obtenir qu’une seule valeur. Il faudra, ´egalement, la couleur, l’intensit´e et la quantit´e de lumi`ere ambiante, qui seront des valeurs diff´erentes de pr´ec´edemment car, il y aura d´ej`a eu plusieurs rendus avec le shader. De ce fait, la couleur finale sera : - Si la combinaison des composantes de la couleur de la normal map aux coordonn´ees actuelles est sup´erieure `a 0.0 ) CouleurFinale = colorMap∗couleurAmbiente∗Intensit´eAmbiante. Et donc : CouleurFinale = CouleurFinale + shadowMap ∗ colorMap ∗ Quantit´eLumi`ereAmbiante. - Sinon : Mushroom Compiler 29
  • 30. chip-ninja() Page 30 sur 78 CouleurFinale =         0 0 0 0         = Noir Tout cela, permet de faire le blending de nos maps et ainsi, le rendu voulu est obtenu. 6.1.3.d Finalisation Pour finir et ajuster l’effet le plus proche possible de l’id´ee d’origine, un BlendState sera d´efini au niveau du GraphicDevice. Celui-ci, va nous permettre d’ajuster le niveau de noir sur les bords du cercle afin d’obtenir un effet de qualit´e plus professionnelle . Figure 14 – Plusieurs sortes de BlendState On cr´e´ee donc ce BlendState, tel que : La fonction de blend des couleurs ainsi que de l’alpha sera d’ad- ditionner les couleurs. La couleur de la destination et de la source, ainsi que l’alpha de la destination seront multipli´es par : Blend.One =         1 1 1 1         Et l’alpha de la source sera mis au carr´e et s’il d´epasse 255, il est ramen´e `a 255. On peut donc poser : Mushroom Compiler 30
  • 31. chip-ninja() Page 31 sur 78 CouleurFinale = ((CouleurSource + AlphaSource) ∗         1 1 1 1         ) Et ainsi : CouleurFinale = CouleurFinale + ((CouleurDestination ∗         1 1 1 1         ) + Saturate(Minimum(AlphaDestination2, 255))) Nous pouvons, enfin, avoir le rendu en temps r´eel que nous vou- lions : Figure 15 – Rendu Final 6.2 Rayons cr´epusculaires Le ciel est une partie trop souvent statique dans les jeux vid´eos. Il a donc fallu rajouter un ´el´ement comblant ce d´efaut. L’id´ee d’int´egrer un effet de rayons cr´epusculaire qui soit `a la fois dynamique et r´ealis´e en temps r´eel, rendrait le tout agr´eable `a regarder de par son niveau artistique et technique. Mushroom Compiler 31
  • 32. chip-ninja() Page 32 sur 78 6.2.1 Ph´enom`ene Les rayons cr´epusculaires apparaissent lorsque la propagation de la lumi`ere du soleil est bloqu´ee par un ´el´ement entre le soleil et le spectateur. Ceux-ci paraissent diverger directement du soleil. Mais, ils sont en fait parall`eles, c’est l’effet de perspective qui donne cet effet. Ils sont intensifi´es par la lumi`ere ambiante. Ces derniers sont surtout caus´es lorsque l’atmosph`ere contient des particules de poussi`eres, des mol´ecules de gaz ou autres particules sur lesquels sont projet´ees des ombres form´ees par ces rayons. 6.2.2 R´ealisation 6.2.2.a Rendu Afin d’obtenir cet effet, il faut effectuer un rendu en diff´erentes ´etapes. Premi`erement, on doit prendre une texture repr´esentant un facteur de flare positionn´ee d’une certaine mani`ere, qui sera rendue dans le Render Target de base. Un Render Target est un espace o`u le rendu s’effectue. Deuxi`emement, on dessine tous les ´el´ements de la sc`ene en noir dans un Render Target s´epar´e. Ceux-ci serviront de masque pour notre shader, et ainsi seront les objets bloquants le flux de lumi`ere. Il est `a not´e, qu’il faut des images ayant un format supportant le canal alpha, tel que le PNG. Ainsi, pour l’instant, le rendu donne ceci : Figure 16 – Rendu Interm´ediaire Mushroom Compiler 32
  • 33. chip-ninja() Page 33 sur 78 Par la suite, le Render Target r´esultant (image ci-dessus) sera donn´e au Post-Processing Manager qui va traiter le Render Target pour qu’il soit utilisable par le shader du soleil. 6.2.2.b Le Shader Pour calculer les rayons cr´epusculaires, il faut se baser sur un mod`ele physique. Le mod`ele utilis´e est celui de Hoffman and Mitchell (2002), appuy´e par celui de Hoffman and Preetham (2003). Le premier mod`ele (2003) est celui-ci : , avec D(φ) : la proportion d’´echantillons qui se placent devant la r´egion ´emettant de la lumi`ere, par rapport `a ceux qui intersectent les rayons ´emis, nous donne le pourcentage d’occlusion. Avec s, la distance parcoure sur l’´ecran. θ, l’angle entre le rayon et le soleil. Esun, l’illumination du soleil. βex, la constante d’extinction du rayon, compos´ee des propri´et´e d’absorption de la lumi`ere et de sa dispersion vers un environnement ext´erieur. βsc, la propri´et´e angulaire du rayon. Le premier terme de cette ´equation calcule la quantit´e de lumi`ere absorb´ee depuis le point d’´emission jusqu’au point o`u il est vu. Le second terme calcule la somme des quantit´es de lumi`eres qui intersectent avec nos rayons de soleil. Mushroom Compiler 33
  • 34. chip-ninja() Page 34 sur 78 Apr`es, on simplifie en divisant l’illumination des ´echantillons par le nombre d’´echantillons et ainsi, on a plus simplement : Ensuite, on introduit des coefficients pour contrˆoler notre ´equation : O`u exposure contrˆole l’exposition de l’effet. Ainsi que weight, contrˆolant l’intensit´e lumineuse de chaque ´echantillon. Puis, decay dans l’inter- valle [0, 1] r´eduisant l’apport en lumi`ere de chaque rayon, plus leur distance est grande par rapport `a la source de lumi`ere. Ensuite, un sous´echantillonnage est effectu´e, c’est-`a-dire que l’on r´eduit la taille de l’image trait´ee, pour am´eliorer les performances, sachant qu’un tel effet en temps r´eel est coˆuteux. Apr`es ceci, il faut rendre la sc`ene actuelle en couleur dans un autre Render Target, puis utiliser la technique du blending permettant de m´elanger deux Render Target, pour obtenir le r´esultat voulu. Pourtant, une artefact en forme de cercle apparaˆıt au centre du soleil, ce qui est gˆenant. Une m´ethode a ´et´e impl´ement´ee, permettant de faire disparaˆıtre le probl`eme, tout en am´eliorant l’effet. Cette m´ethode se base sur un autre mod`ele physique qui va permettre de d´ecrire la dispersion du rayonnement lumineux dans l’atmosph`ere. On se base sur le mod`ele de Henyey et Greenstein adapt´ee par Nishita. On a donc la fonction de phase , telle que : Mushroom Compiler 34
  • 35. chip-ninja() Page 35 sur 78 Avec θ l’angle entre le spectateur (la cam´era) et le rayon de lumi`ere π et g une constante qui affecte la sym´etrie de la diffusion des rayons. Cette constante g est pr´ed´efinie `a l’avance, en valant 0 on peut ap- proximer l’effet de diffusion de Rayleigh et entre 0,75 et 0,999 pour approximer l’effet de la diffusion de Mie . La couleur r´esultante est donc multipli´ee par F(θ,0) et on ajoute F(θ, 0,85). Pour trouver la valeur de cos θ, un produit scalaire entre la position du soleil sur l’´ecran et la direction vers laquelle la cam´era regarde suffit. Le tout sera divis´e par la norme de la direction. Pour la cam´era, puisque le jeu est en 2D, le vecteur   0 45   fourni au shader donnait de bon r´esultat. Avec tout ce qui pr´ec`ede, on a un soleil en temps r´eel, simulant le rayonnement dans l’atmosph`ere, qui est, ici, le fond. Pour finir, il est possible de rajouter quelques ´el´ements pour finaliser l’effet. 6.2.2.c High Dynamic Range Le High Dynamic Range ou Grande Gamme Dynamique est un effet qui simule la r´etine afin d’obtenir un effet d’´eblouissement. On applique donc cette formule `a la couleur : 1.0−exp (Exposure ∗ LDR), avec Exposure valant un nombre sup´erieur ou ´egal `a 0.15 + 0.3 et LDR valant la couleur r´esultante juste avant le calcul du mod`ele physique de Henyey et Greenstein adapt´e par Nishita appell´ee Color, on a donc : LDR = Color ∗ F(θ, 0.85) + F(θ, 0.76) ∗ 0.3 ∗      0.713 0.494 0.356      Mushroom Compiler 35
  • 36. chip-ninja() Page 36 sur 78 Avec      0.713 0.494 0.356      , ´etant la couleur d’un soleil vers 12h et plus. 6.2.2.d Tone mapping Cet effet permet de reproduire la gamme de couleurs pr´esentes dans la nature. On applique cette formule `a l’HDR : HDR/(HDR + 0.5) Ainsi, grˆace `a tout ce qui pr´ec`ede, nous avons l’effet voulu : Effet final 6.3 Moteur `a particules Le moteur `a particules est un autre type d’effet, bien qu’il soit assez sobre, il est utilisable dans un bon nombre de situations. C’est pour cela, que nous avons d´ecid´e d’impl´ementer cette sorte d’effet. 6.3.1 M´ethode Tout d’abord, il faut connaˆıtre les caract´eristiques que doit avoir le moteur. Il doit avoir un nombre initial de particule et un nombre de particules par secondes. Celui-ci doit donner un angle minimal et maximal vers lesquels les particules pourront se diriger. La vitesse Mushroom Compiler 36
  • 37. chip-ninja() Page 37 sur 78 minimale et maximale de chacune des particules doit ˆetre connue, ainsi que leur temps de vie, leur taille, leur coordonn´ees en 2D et leur texture. 6.4 Arri`ere-plan Pour varier les environnements, changer l’atmosph`ere du jeu et avoir un jeu artistique, il faut s’occuper des Arri`ere-plans et autres ´el´ements dans le fond avec lesquels le joueur n’interagit pas directe- ment. Les arri`ere-plans auront chacun une profondeur qui nous permettra de simuler un effet de parallaxe lors du d´eplacement du joueur. 6.4.1 M´ethode Pour arriver `a cet effet, une liste d’arri`ere-plans va devoir ˆetre cr´e´ee, contenant, pour chaque arri`ere-plan, une texture et une profondeur. Grˆace `a ces informations, une vitesse de d´efilement va en ˆetre calcul´ee et ainsi, l’effet de parallaxe va pouvoir ˆetre simul´e. Pour chaque fond de la liste, il y aura un autre fond correspondant dans une autre liste qui sera d´ecal´e, pour donner un effet de d´efilement sans interruption. ´Egalement, lors du mouvement du personnage et donc de la texture, on aurait les fonds plus en arri`ere bougeant plus lentement que ceux de devant. 6.5 Animation Pour donner l’impression au joueur que les diff´erents personnages se d´eplacent, le principe de persistence r´etinienne est utilis´e. Fonda- mentalement, le principe de persistence r´etinienne se base sur une des propri´et´es de la r´etine selon laquelle une image reste un certain temps ”imprim´ee” sur la r´etine pour une dur´ee se rapprochant `a 1/25e de seconde sur la r´etine. Ainsi, en enchaˆınant plusieurs images assez rapidement, une illusion de mouvement est cr´e´ee. Concr`etement, Mushroom Compiler 37
  • 38. chip-ninja() Page 38 sur 78 Figure 17 – D´emonstration des arri`eres-plans en parallaxe l’image contenant l’ensemble d’images composant une animation est commun´ement appel´e une ”Sprite Sheet”. Il s’agit d’un ensemble de sprites, d’images, qui peuvent aussi ˆetre appel´es lutins. Pour en faire une animation, il suffit de consid´erer la sprite sheet comme un ensemble de rectangles, chaque image ayant sa propre coordonn´ee. Ensuite, il suffit de faire d´efiler les images `a une vitesse donn´ee, qui est ici de 50 millisecondes par image. Notre projet comporte plusieurs sprite sheets pour le personnage, qui correspondent `a ses diff´erents ´etats (Arrˆet, Marche, Course, Saut...). Mushroom Compiler 38
  • 39. chip-ninja() Page 39 sur 78 7 Gameplay 7.1 Le coeur du gameplay Peu importe les diff´erentes strates rajout´ees, le jeu reste un jeu de plate-forme, avec ses propri´et´es intrins`eques. Ainsi, le personnage se verra attribuer des vies et l’objectif est d’arriver `a la fin des niveaux. Ceci permet au jeu d’avoir des courbes de progression et d’interˆet satisfaisantes. 7.2 Ajouts Un certain nombre de m´ecaniques `a ´egalement ´et´e ajout´e. 7.2.1 Le combat Dans l’univers du jeu, le personnage est un ninja. Ainsi, le per- sonnage est ´equip´e d’un sabre et de shurikens, qu’il peut lancer. Le personnage peut ainsi blesser des ennemis et progresser dans le ni- veau. Ces armes, qui donnent plus de puissance au joueur, permettent ´egalement un rythme de jeu plus rapide. 7.2.2 La technique Sp´eciale Le personnage poss`ede ´egalement une technique sp´eciale, appel´ee , qui permet de d´ecouper un adversaire en plusieurs morceaux. Elle se d´eclenche lorsque le personnage a vaincu assez d’ennemis et poss`ede plusieurs b´en´efices. Premi`erement, elle cr´ee pour le joueur un senti- ment de puissance et de m´erite. Dans un second temps, cela permet de briser la routine du jeu et de pr´esenter une exp´erience plus vari´ee. 7.2.3 Manipulation de la gravit´e Le personnage `a ´egalement, en fonction des r`egles du niveau, le droit d’inverser la gravit´e. Cela permet, une fois de plus, de diversifier le gameplay et le rythme du jeu. Mushroom Compiler 39
  • 40. chip-ninja() Page 40 sur 78 7.2.4 Contrˆoles 7.2.4.a Clavier Il a ´et´e d´ecid´e que le jeu se jouerait `a la paire clavier-souris. Le joueur se d´eplacerait `a l’aide des touches Z-Q-D, sauterait `a l’aide du clic-gauche de la souris, et attaquerait `a l’aide du droit. 7.2.4.b Manette Quant `a la manette, le joueur se d´eplacerait `a l’aide du stick analo- gique gauche, sauterait `a l’aide du bouton A, et attaquerait `a l’aide du bouton X. Mushroom Compiler 40
  • 41. chip-ninja() Page 41 sur 78 8 Contenu 8.1 Graphismes 8.1.1 Personnage Les diff´erents sprites pour le personnage proviennent du jeu Su- per House Of Dead Ninjas . C’est un design efficace, qui correspond au personnage du projet. Pour pouvoir r´ecup´erer les sprites, il a fallu d´ecompiler l’ex´ecutable du jeu, et en assembler les diff´erents morceaux. 8.1.2 Tileset Les diff´erents tilesets ont des origines diff´erentes. En effet, la plu- part sont de composition personnelle, mais certains ont ´et´e r´ecup´er´es d’Internet. 8.1.3 Arri`ere-plans Les arri`ere-plans ont tous ´et´e r´ealis´es par les membres du projet, `a l’exception de l’arri`ere-plan du menu, qui provient du jeu Sword & Sworcery . 8.1.4 Facteurs de flare Les images repr´esentants le facteur de flare ont toutes ´et´e r´ecup´er´ees d’Internet. 8.2 Niveaux Artisanaux Le jeu, en tant que projet de sup, pr´esente trois niveaux fondamen- talement diff´erents, en plus de la g´en´eration proc´edurale. 8.2.1 Under The Pin Le premier niveau, d´enomm´e Under The Pin de par la ressem- blance des arches en arri`ere-plan avec des broches de processeur. C’est un niveau simple, qui introduira le joueur au jeu. Mushroom Compiler 41
  • 42. chip-ninja() Page 42 sur 78 Figure 18 – Niveau : Under The Pin 8.2.2 Ram Jam Ram Jam est le second niveau de chip-ninja(). Le niveau se d´eroule dans la RAM (Random Access Memory) d’un ordinateur, o`u se passe des choses ´etranges. Son nom est un hommage au groupe de Rock Ram Jam qui a notamment compos´e la chanson Black Betty. Figure 19 – Niveau : Ram Jam 8.2.3 Ohm My God Ohm My God est le troisi`eme niveau de chip-ninja(). Son nom est une r´ef´erence `a l’unit´e de mesure de la r´esistance d’un dipˆole. Figure 20 – Niveau : Ohm My God 8.2.4 Transisterrific Transisterrific est le nom donn´e `a tous les niveaux g´en´er´es proc´eduralement. Mushroom Compiler 42
  • 43. chip-ninja() Page 43 sur 78 Figure 21 – Niveau : Under The Pin 8.3 Generation Proc´edurale Pour permettre au joueur de faire l’exp´erience d’une infinit´e de niveaux, il a fallu impl´ementer de la g´en´eration proc´edurale. La g´en´eration proc´edurale de niveaux est le processus consistant `a cr´eer des niveaux `a l’aide d’un algorithme aux r`egles pr´ecises. Il faut g´en´erer un niveau ressemblant `a l’int´erieur d’un transistor, c’est `a dire dans un espace ferm´e. En effet, sans cela, nous ne pourrions jouer sur la verticalit´e des niveaux sans rendre le joueur confus. 8.3.1 Agencement La premi`ere ´etape est de cr´eer une succession de salles qui for- meront le parcours du joueur. On essaie d’obtenir quelque chose ressemblant `a ceci : Figure 22 – Agencement d’un niveau Mushroom Compiler 43
  • 44. chip-ninja() Page 44 sur 78 Concr`etement, ceci est repr´esent´e en m´emoire en utilisant un ta- bleau `a deux dimensions d’objets salles . L’algorithme se d´eroule comme suit : R1. Prendre des coordonn´ees al´eatoires parmi les limites (20x20). R2. Prendre al´eatoirement une salle adjacente. R3. Si elle est occup´ee, revenir `a R2. Sinon, l’ajouter au tableau. R4. Recommencer R3 tant que le nombre de salles minimum n’est pas atteint. Lorsque cet algorithme est fini, on se retrouve avec un agencement de salles parfaitement exploitable. 8.3.2 Solution Il faut maintenant g´en´erer un sch´ema de solution. C’est l`a la partie la plus difficile de la g´en´eration proc´edurale. En effet, il est tr`es simple de produire des niveaux impossibles. Il faut donc donner au joueur le moyen de naviguer `a travers toutes ces salles, jusqu’`a la derni`ere. Comme le mouvement du joueur est d´efini par la physique du jeu, il convient de s’assurer que les parties verticales (soit deux salles ou plus connect´ees verticalement) soient toujours accessibles. Apr`es diverses consid´erations, il a ´et´e d´ecid´e de cr´eer un parcours de solution, c’est-`a-dire un ensemble de plateformes et d’´echelles qui conduisent directement le joueur `a la sortie. Cela permet quelques avantages : En effet, cela permet souvent plusieurs chemins alternatifs, et garantit qu’au moins une solution existe. Cela paraˆıt peut-ˆetre trop ´evident pour le joueur, mais le chemin parfait est ensuite camoufl´e. Nous utilisons la m´ethode suivante : G´en´erer une position al´eatoire dans chaque salle, et connecter chacune d’elle en utilisant une ´echelle et une plateforme. Mushroom Compiler 44
  • 45. chip-ninja() Page 45 sur 78 On obtient alors ce r´esultat : Figure 23 – Le chemin de solution 8.3.3 Peupler Ensuite, il nous faut g´en´erer des plateformes. Pour cela, un algo- rithme est utilis´e qui produit les r´esultats suivants : Pour chaque tuile vide, il y a une chance que celle-ci cr´ee une plateforme d’une longueur al´eatoire. Il faut ´egalement faire attention `a ce qu’une plateforme nouvellement g´en´er´ee ne bloque pas le chemin du joueur. 8.3.4 Faire pousser des ´echelles Finalement, il nous faut g´en´erer des ´echelles. En ce but, une ´echelle est plac´ee `a une position al´eatoire de chaque plateforme g´en´er´ee. On les fait ensuite pousser vers le bas, jusqu’`a ce qu’elles touchent le sol, ou une autre plateforme. 8.4 Musique En r´ef´erence `a l’`ere des consoles de troisi`eme et quatri`eme g´en´eration, sur lesquelles le genre plate-forme s’est d´emocratis´e, mais ´egalement pour rester fid`ele au th`eme de notre jeu, nous avons choisi d’utiliser de la chiptune. Mushroom Compiler 45
  • 46. chip-ninja() Page 46 sur 78 8.4.1 Menu Le titre du menu, d´enomm´e Sad Robot, compos´e par le groupe Allemand Pornophonique, qui diffuse de la musique libre de droit. Nous avons trouv´e ce morceau particuli`erement adapt´e, car son utilisation d’une guitare en plus de sons electroniques transmet une impression de solitude, mais aussi une certaine chaleur, ce qui laisse une grande impression sur le joueur lors de son premier contact avec le jeu, l’´ecran- titre. 8.4.2 Under The Pin La musique s´electionn´ee pour le niveau Under The Pin , dont le titre est The Trials of MAN est une piste de Big Giant Circles sur son album The Glory Days. Cette chiptune va `a merveille avec le d´ecor du niveau, et donne un r´eel plaisir au joueur. 8.4.3 Ram Jam La musique du niveau Ram Jam est nomm´ee Hybrid Funky Stars qui est un morceau de Dubmood, un compositeur su´edois faisant partie d’un des plus grand groupe pr´esent sur la sc`ene warez, Razor1911. 8.4.4 Transisterrific ! Pour les niveaux Transisterrific ! , plusieurs musiques sont pr´esentes. 8.5 Menu Dans nos versions pr´ec´edentes, nous avions un menu, mais qui ne proposait que de jouer ou d’acc´eder au multijoueur. Bien sˆur, il y avait les sous-menus pour le multijoueur et une gestion du texte, pour entrer une adresse IP et le num´ero du joueur, mais ce n’´etait pas suffisant. Ainsi, nous avons rajout´e un menu d’options. Mushroom Compiler 46
  • 47. chip-ninja() Page 47 sur 78 8.5.1 Options Dans ce menu, il y a la possibilit´e de modifier certains param`etres du jeu. Menu des Options On peut, de cette mani`ere, r´eduire la qualit´e graphique du jeu, pour les machines peu performantes, ou alors exploiter les effets `a leur maxi- mum sur les machines qui en sont capables. Le nombre de d´ecoupes des ennemis peut ˆetre r´eduit pour ´economiser les performances puis- qu’un grand nombre de d´ecoupes implique beaucoup de calculs, sur- tout pour la physique, de ce fait, le nombre de d´ecoupes sera limit´e `a 50, sinon il sera virtuellement infini. Le joueur peut ´egalement mettre en Pause et Reprendre la musique en cours, ainsi que changer la langue du jeu dans les menus et ailleurs. Il y a aussi, une description de chaque ´el´ement des options au dessus des choix, pour permettre au joueur de comprendre ce qu’il va modifier. Mushroom Compiler 47
  • 48. chip-ninja() Page 48 sur 78 9 Outils de developpement 9.1 ´Editeur de niveau Pour pouvoir r´ealiser facilement des niveaux, il a fallu coder un ´editeur. 9.1.1 Interface L’interface est compos´ee de plusieurs ´el´ements. Pour visualiser le niveau, il a fallu cr´eer un contexte XNA dans le Windows Forms. Ainsi, par simple clic, nous pouvons ajouter une ou plusieurs tuiles. Sur le bord gauche est pr´esent la liste des tuiles disponibles. Les diff´erentes tuiles sont repr´esent´ees individuellement et par l’image qui leur correspond. 9.1.2 Fonctionnement Concr`etement, l’´editeur r´ecup`ere le fichier de la map, et le stocke dans un tableau `a deux dimensions. Apr`es les modifications faites, la tilemap est r´e´ecrite dans le fichier. Mushroom Compiler 48
  • 49. chip-ninja() Page 49 sur 78 10 Intelligence Artificielle Pour ce projet, il a fallu cr´eer des ennemis, avec chachun leur intelligence propre. Ceux-ci sont au nombre de trois. 10.1 Mettoru Mettoru est l’ennemi basique, repris de la s´erie classique Megaman. Il ne se d´eplace qu’en marchant. Cependant, il se d´eplace constamment en direction du joueur, `a condition qu’il ne rencontre aucun pr´ecipice. En ce cas l`a, il s’arrˆete et fixe le joueur. Ainsi, il faut veiller `a ce qu’il ne tombe pas du pr´ecipice. Pour cela, un mettoru consid`ere toujours la tuile devant lui, d’une mani`ere similaire `a celle des collisions. Si elle est vide, sa v´elocit´e devient nulle. 10.2 Sniper Mettoru Sniper Mettoru est le nom du second ennemi. Lui aussi repris de Megaman, c’est une version ´evolu´ee du Mettoru. En effet, il remarque lorsque le joueur se trouve proche de lui, et tire sur l’ennemi lorsque celui-ci est `a port´ee. Son projectile ne part qu’en ligne droite, mais peut ˆetre renvoy´e par le joueur. 10.3 Bat Le dernier ennemi est une chauve souris. Lorsque le joueur se trouve assez proche – lorsque le joueur peut voir la chauve souris – elle se lance `a petite vitesse dans sa direction. Si elle se trouve bloqu´ee par le terrain, elle prendra un autre itin´eraire, de fac¸on `a toujours suivre le joueur de fac¸on efficace. Mushroom Compiler 49
  • 50. chip-ninja() Page 50 sur 78 11 R´eseau 11.1 Multijoueur Nous savons tous que les jeux vid´eos sont amusants `a jouer, mais ils le sont encore plus `a plusieurs. C’est ainsi, qu’un mode multijoueur a ´et´e int´egr´e au jeu. Le jeu, ayant une architecture pens´ee comme ´etant polyvalente depuis le d´ebut, a permit la mise en place d’un multijoueur en r´eseau avec une grande simplicit´e sans avoir `a changer quoi que ce soit. Pour cela, nous prenons avantage du syst`eme d’´ecrans appel´es GameS- creens . Il suffit de cr´eer un ´ecran pour le multijoueur. Il ne reste plus qu’`a construire le syst`eme client-serveur utilis´e ici. Il a ´et´e d´ecid´e d’utiliser l’UDP (User Datagram Protocol) pour les communications sur le r´eseau. Les raisons de ce choix sont que l’UDP est rapide, assez simple `a mettre en place et est performant dans le cas o`u il y a de nombreuses connections sur un mˆeme port. 11.2 Pr´esentation du mode de jeu Pour ce mode multijoueur, nous avons opt´e pour un jeu `a plusieurs, diff´erent de celui du mode `a un joueur. Ce mode de jeu oppose plu- sieurs joueurs les uns contre les autres dans un combat `a mort. Prenons 2 joueurs, chacun sera compos´e d’une couleur unie comme le blanc ou le noir. Le fonds sera constitu´e d’´el´ements de mˆeme couleur que les personnages et changera `a des intervalles irr´eguliers. Dans ce mode, les joueurs auront la possibilit´e d’utiliser le d´ecors en tant que camouflage pour parvenir `a leur fin. Bien-sˆur, le tout est rendu dynamique par le fond qui change, rendant (ou pas) les person- nages visibles aux yeux des autres. Ce gameplay permet de jouer de mani`ere amusante, tout en am´eliorant ses comp´etences au combat et ses r´eflexes dans le jeu. Mushroom Compiler 50
  • 51. chip-ninja() Page 51 sur 78 Figure 24 – L’arri`ere-plan dynamique 11.3 R´ealisation Comme dit plus haut, le mode exploite l’architecture client-serveur achev´ee `a l’aide de l’UDP. Lors du lancement du jeu, le joueur a le choix entre plusieurs modes, dont le multijoueur. Apr`es avoir choisi ce mode, on prend la charge du serveur ou d’un client. 11.3.1 Cˆot´e Client On cr´ee un client, que le mode choisi soit client ou serveur. Le client prend un nom et une IP. Ce que va faire le client lors de sa cr´eation, est de cr´eer un UdpClient puis de cr´eer un Thread dans lequel on ´ecoutera sur le port 80 les donn´ees `a recevoir du serveur. Ce Thread ayant la plus haute priorit´e par rapport aux autres. Le client envoi ensuite un paquet contenant la chaˆıne de caract`ere connect ainsi que le nom du joueur et en fonction de la r´eponse, on continue. Remarque : la mani`ere dont sont organis´ees les donn´ees envoy´es et rec¸ues sera expliqu´ee plus bas. Lors de la r´eception, le client va lire le flux entrant de donn´ees qui sont un tableau de bytes, puis va les convertir en un format ad´equat pour le client. On lis ces donn´ees en regardant d’abord le nom. Le client ayant une liste de tous les clients connect´es, il va v´erifier si le nom existe : Mushroom Compiler 51
  • 52. chip-ninja() Page 52 sur 78 -S’il existe, on met `a jour les donn´ees. -Sinon, on rajoute le nouveau client ainsi que ses donn´ees. Lors de l’envoi des donn´ees, qui s’effectue dans la fonction Update() du client, on envoi les donn´ees du client actuel qui sont : -Le nom -L’´etat, c’est-`a-dire que l’on apprend si le joueur attaque ou autre. -La position -L’indice de background, cette donn´ee va permettre de connaˆıtre quel background devra ˆetre sur chaque clients Celles-ci sont envoy´ees au serveur pour ˆetre trait´ees. 11.3.2 Formatage des donn´ees Les donn´ees envoy´es et rec¸ues sont format´ees de mani`ere pr´ecise. Cette partie est trait´ee en annexe, partie D.1. 11.3.3 Cˆot´e Serveur Au d´ebut, chez le client, il y a le choix entre ˆetre client ou serveur. Si le serveur est choisi, il est lanc´e en tant que processus externe et donc la personne qui lance le serveur est cliente de son propre serveur. Lors de sa cr´eation, le serveur affiche son adresse IPv4 puis cr´e´ee un UdpClient sur le port 80 et deux Thread, l’un pour la r´eception et l’acceptation de nouveaux clients et l’autre pour recevoir des informa- tions depuis les clients et pour renvoyer les informations de chaque clients aux autres. Lorsque le serveur lit le flux entrant et trouve la chaˆıne connect , il va v´erifier si ce nouveau client n’a pas un pseudo existant d´ej`a, ou Mushroom Compiler 52
  • 53. chip-ninja() Page 53 sur 78 que le nombre de joueurs pr´esents est d´epass´es et si les donn´ees sont correctement format´ees et en fonction de cela, il sera accept´e ou refus´e. Figure 25 – Le serveur En mˆeme temps, il traite les donn´ees rec¸ues des autres clients. Ces donn´ees rec¸ues sont ensuite renvoy´ees, lorsque leur formatage est bon, `a tous les clients sauf la source. Le serveur ne sert que de relais, c’est un interm´ediaire entre les clients. Il ne fait aucune v´erification sur ce qui pourrait ˆetre de la triche ou autre. Le serveur va ´egalement g´erer le changement de l’image de fond. Il va, en fonction de formules bas´ees sur un facteur de temps, ´emettre un indice de background `a tous les clients qui vont, ainsi, avoir tous la mˆeme image de fond. Remarque : Chaque client v´erifie lui-mˆeme les collisions et autres et envoi ces informations, il n’y a donc aucun traitement externe, si ce n’est une derni`ere v´erification, par le client distant, des collisions pour plus de sˆuret´e. 11.3.4 Probl`emes Plusieurs probl`emes se sont pos´es lors de la cr´eation de ce mode. Le plus notable est celui o`u les adversaires des clients, pr´esentaient du flickering . Ceux-ci gardaient la position de leur d´epart et alter- Mushroom Compiler 53
  • 54. chip-ninja() Page 54 sur 78 naient entre cette derni`ere et la leur position actuelle. Le fait que la position de d´epart soit gard´ee ´etait dˆu au fait qu’une liste et un dictionnaire d’´el´ements ´etaient utilis´es en mˆeme temps. Pour r´egler ceci, il fallait garder la derni`ere position qui n’´etait pas celle de d´epart temporairement et la comparer avec les coordonn´ees de la position de d´epart. Cette position temporaire devenait donc, la position actuelle de l’adversaire si elle ne valait pas celle de d´epart. Remarque : la probabilit´e d’avoir exactement la mˆeme position que celle de d´epart est faible. Et pourtant le cas est g´er´e `a l’aide de la fr´equence de la mˆeme position sur une p´eriode donn´ee. Mushroom Compiler 54
  • 55. chip-ninja() Page 55 sur 78 12 Site Internet Nous avons donc tout recommenc´e avons voulu reprendre les qua- lit´es d’autres sites tout en allant `a l’essentiel. Nous sommes donc arriv´es `a ce r´esultat : Figure 26 – Le Site Web Avec ce nouveau design, il suffit de d´efiler vers le bas pour avoir toutes les informations souhait´ees. Le site est moderne et respecte les standards actuels en terme d’esth´etique. Le site dispose de boutons permettant guider le visiteur en se d´eplac¸ant d’un point `a un autre de mani`ere fluide. Le site ayant un design moderne, il va `a l’essentiel. On a du texte descriptif de notre jeu `a cˆot´e d’une image qui doit ˆetre assez repr´esentative du texte. 12.1 Responsive Design Le site adopte ´egalement le responsive design permettant au site de s’adapter `a tous les ´ecrans possibles, que ce soit sur smart- phones, tablettes ou ordinateurs, en mode paysage ou portrait. Mushroom Compiler 55
  • 56. chip-ninja() Page 56 sur 78 Ainsi, nous avons une vision agr´eable du site sur n’importe quel appareil, quel que soit le format de l’´ecran. 12.2 Communication Dans le soucis de connaˆıtre les attentes et r´eactions des visiteurs de notre site, nous voulions un moyens qui permettrait une interaction. Ainsi, nous avons rajout´e un syst`eme de message, dans lequel le visiteur laisse son nom ou pseudo, son adresse e-mail et son message qu’il nous envoie. Au bas du site, se trouvent des liens vers les r´eseaux sociaux Twitter et Facebook. Ceux-ci servent `a faire connaˆıtre le jeu aupr`es du monde, puisque ces r´eseaux sont tr`es connus et utilis´es. Mushroom Compiler 56
  • 57. chip-ninja() Page 57 sur 78 13 Conclusions personnelles 13.1 Alexandre Doussot ´Etant atir´e par la cr´eation de jeux vid´eos depuis un certain temps, trouver ce projet `a ´et´e un grand soulagement ainsi qu’une grande joie. J’avais en effet, depuis un certain nombre d’ann´ees, l’envie de cr´eer moi aussi un jeu vid´eo, et de mieux connaˆıtre les tenants et aboutis- sants de la cr´eation d’une partie d’un medium qui prend toujours plus d’ampleur. Ce projet, en me permettant de me placer de l’autre cˆot´e de l’´ecran, m’a permis d’enrichir drastiquement mes connaissances sur le sujet, qu’il s’agisse de connaissances purement techniques, ou au contraire, th´eoriques. J’ai ainsi pu d´ecouvrir et mettre en pratique plusieurs ´el´ements de la discipline du Game Design, ou Conception de Jeu. De plus, en tant que chef de projet, j’ai d´ecouvert un certain nombre de facettes de la r´ealisation d’un projet qui m’´etaient ´etrang`eres. En effet, nous avons ´et´e confront´es `a des attentes similaires `a celle d’un milieu entrepreneurial. J’ai ´egalement appris que travailler en groupe n’´etait pas si facile qu’il semblait au premier abord, et garder les diff´erents membres motiv´es a ´et´e un vrai challenge. Se confronter `a des d´efis tels que ceux qui nous ont ´et´e present´es m’ont sans aucun doute fait mˆurir, et m’ont permis d’am´eliorer ma maˆıtrise du langage C#, math´ematique et humain. Mushroom Compiler 57
  • 58. chip-ninja() Page 58 sur 78 13.2 Chady Dimachkie Mon int´erˆet pour le rendu a ´et´e ´enorm´ement suscit´e lors de ce projet. En effet, j’ai pu exploiter le langage de shaders HLSL et la s´erie d’outil d’XNA `a leur maximum, pour arriver `a des rendus d’une telle qualit´e sans pour autant r´eduire nettement les performances. Lors de ce projet, j’ai appris `a me questionner sur ce qui pouvait am´eliorer le jeu, tout en restant coh´erent. Ce projet m’a donn´e l’occasion de travailler en ´equipe, et donc d’avoir plusieurs mani`eres de penser dans un mˆeme projet. Cela m’a permit de concevoir des solutions s’adaptant `a une architecture com- prise et adopt´ee par tous les membres du groupe et ainsi, j’ai pu am´eliorer mes m´ethodes de d´eveloppement J’ai du apprendre `a fournir des produits, cr´e´es avec des m´ethodes efficaces et ceci rapidement, pour les remettre en temps et en heure. Tous ces changements, m’ont permet d’´evoluer, en tant que pro- grammeur et en tant que personne. De ce fait, pour de futurs projets en ´equipe, je pourrais m’adapter plus facilement aux besoins d’une ´equipe et prendre des d´ecisions relatives `a ceux-ci. Mushroom Compiler 58
  • 59. chip-ninja() Page 59 sur 78 13.3 Benjamin R´echou N’ayant jamais cod´e, ce projet me semblait irr´ealisable au d´ebut de l’ann´ee. Je n’avais `a l’´epoque pas les outils n´ecessaire pour r´ealiser un tel projet. Ayant pourtant beaucoup jou´e, je pensais avoir une id´ee de comment un jeu est fait, grande a ´et´e ma surprise lorsque mon groupe et moi mˆeme avons du r´ealiser par nous mˆeme tout les ´el´ements qui composent un jeu vid´eo. J’avais en effet l’id´ee g´en´eral du fonctionnement des ´el´ements d’un jeu mais j’´etais loin d’en imaginer la complexit´e. Ce projet a donc ´et´e une longue succession de blocage et de casse-tˆete mais toute la d´emarche de recherche et de r´eflexion que nous avons du fournir nous `a ´et´e b´en´efique. Apr`es nous ˆetre r´epartit les taches afin de travailler plus effica- cement, nous nous sommes chacun attel´e `a la tache. Chose qui n’a pas ´et´e simple au d´ebut car il est dur de se lancer dans un projet si imposant sans avoir les outils n´ecessaire. Je pense que la partie la plus dur fˆut d’acqu´erir les bons outils et d’apprendre `a les utiliser. Je ne me serais jamais cru capable de pouvoir participer a la cr´eation d’un site WEB ou encore r´ealiser un moteur a particules fonctionnel. La lecture des cartes du jeux est ce qui m’a demand´e le plus grand temps de r´eflexion, il me fallait trouver un moyen simple mais effi- cace de lire et g´en´erer des cartes jouable. Apr`es m’ˆetre entretenu avec Alexandre et Chady une solution fˆut rapidement trouv´ee. Il en est all´e de mˆeme pour quasiment l’ensemble du projet, nous avons rencontr´e des probl`emes mais ensemble nous avons su les surmonter. Je fˆut surprit du peu de tension qu’il y a eu au sein du groupe, nous partageons tout trois la mˆeme passion du jeu vid´eo et de ce fait nous n’avions pas tant de divergence de points de vue, ce qui `a grandement particip´e a la bonne r´ealisation de ce projet. Tout le temps que nous ne perdions pas `a essayer de trouver un commun accord nous le passions a travailler le projet pour finalement arriver `a un r´esultat final dont nous pouvons ˆetre fiers. Mushroom Compiler 59
  • 60. chip-ninja() Page 60 sur 78 14 Conclusion Ce projet s’est r´ev´el´e tr`es enrichissant pour chacun d’entre nous dans la mesure o`u nous avons pu d´ecouvrir et r´ealiser les diff´erentes facettes qui composent le divertissement que nous utilisons tous. Ce fut enrichissant d’un point de vue culturel, mais aussi immens´ement d’un point de vue technique, car nous avons dˆu mettre en pratique tout ce qui nous a ´et´e enseign´e durant l’ann´ee, et mˆeme plus. En effet, ce projet incite ´enorm´ement `a l’autonomie. Nous avons dˆu r´ealiser un certain nombre de recherches par nous-mˆeme, sans l’aide de nos professeurs, et avons dˆu apprendre `a nous arranger par nous mˆeme, sans avoir quelqu’un sur qui forc´ement compter, si ce n’est sur nous-mˆeme, membres de ce groupe. Effectivement, la gestion de groupe a ´et´e une facette tr`es importante de ce projet. Nous devions nous aider, et ne pas lˆacher lors des temps durs. Il y a bien eu quelques altercations, mais nous n’en sommes que ressortis grandis et plus soud´es. De plus, ce projet nous a mis face aux contraintes du milieu en- trepreneurial, comme le fait que nous ayons un cahier des charges `a respecter, tout en travaillant dans une entente cordiale. Ce fut d´efinitivement un projet tr`es int´eressant qui nous a permis de mˆurir en tant qu’´etudiants, mais ´egalement en tant que personnes. Mushroom Compiler 60
  • 61. chip-ninja() Page 61 sur 78 Annexes A Comment lire ce rapport ? Ce rapport se pr´esente sous la forme requise, `a savoir qu’il d´ebute par un sommaire, suivi de l’introduction ainsi que l’explication du travail r´ealis´e, enchaˆınant ensuite sur les Annexes, compos´ees de la bibliographie, des ressources, ainsi qu’une table des mati`eres. Le corps de ce document est divis´e en diff´erentes parties pr´ec´ed´ees d’une barre de couleur. Cette couleur correspond `a l’´etudiant qui a r´ealis´e le travail dont il est question dans la partie correspondante. Voici les couleurs correspondantes `a chaque ´etudiant. Alexandre Doussot Chady Dimachkie Benjamin R´echou Mushroom Compiler 61
  • 62. chip-ninja() Page 62 sur 78 B R´ef´erences -Tomoyuki Nishita, Yasuhiro Miyawaki et Eihachiro Nakamae, Com- puter Graphics (A SHADING MODEL FOR ATMOSPHERIC SCATTE- RING CONSIDERING LUMINOUS INTENSITY DISTRIBUTION OF LIGHT SOURCES), Assn for Computing Machinery, Volume 21, Num- ber 4, Juillet 1997 - Mitchell, Light Shafts : Rendering Shadows in Participating Media. , Presentation at Game Developers Conference 2004. -Y.Dobashi, T. Yamamoto , T.Nishita, Interactive Rendering Method for Displaying Shafts of Light, Proc.Pacific Graphics 2000, 2000p. -Sean O’Neil, GPU Gems 2 ,Chapitre 16, 2005. -Kenny Mitchell, Electronic Arts, GPU Gems 3 Chapitre 13, 2006. -NVIDIA Corp, The Cg Tutorial, Chapter 8. Bump Mapping,. -Tomas Akenine-M¨oller, Eric Haines, Naty Hoffman, Real-Time Rendering, Third Edition, Chapitre 6.7 Bump Mapping, 10.7 Particle Systems, 10.10 Color Correction, 10.11 Tone Mapping, 25 Juillet 2008, 1045p -Christer Ericson, Real-Time Collision Detection (The Morgan Kauf- mann Series in Interactive 3-D Technology), Chapitres 8.3.4 Splitting Poly- gons Against a Plane, 7.4.2 Uniform Grid Intersection Test, 22 D´ecembre 2004, 632p, - XNA GPA. [EN LIGNE]. 10 F´evrier 2012. [Consult´e le 8 Avril 2014]. Disponible sur : http ://xnagpa.net/about.php -Game Programming Patterns. [EN LIGNE]. Bob Nystrom. [Consult´e le 4 Mars 2014]. Disponible sur : http ://gameprogrammingpatterns.com -Schell Jesse, The Art of Game Design - A Book of Lenses., CRC Press, 2008, 464p. Mushroom Compiler 62
  • 63. chip-ninja() Page 63 sur 78 C Moteur Physique C.1 Attaque sp´eciale C.1.1 D´etection de collisions Pour avoir une bonne physique apr`es d´ecoupe, il nous faut des collisions. Nous allons, pour l’instant, utiliser des AABB.(Axis Ali- gned Bounding Boxes) qui nous serviront `a r´ealiser des formes plus complexes et ainsi avoir de la d´etection de collisions entre polygones complexes. Une AABB est un rectangle dont les cˆot´es sont align´es avec les axes de son syst`eme de coordonn´ee. Pour repr´esenter une AABB, son sommet est marqu´e ayant la plus petite abscisse et ordonn´ee et son sommet ayant la plus grande abscisse et ordonn´ee, c’est-`a-dire, le som- met en haut `a gauche et son sommet en bas `a droite Pour une AABB, le SAT (Separating Axis Theorem ou encore Sup- porting Hyperplane Theorem) est utilis´e. Il est appel´e Th´eor`eme de s´eparation des convexes par hyperplan, en franc¸ais. Concr`etement, le th´eor`eme implique qu’il n’y a pas collision lors- qu’on peut tracer un axe entre deux polygones, si ce n’est pas le cas, alors il y a collision. Figure 27 – Separatin Axis Theorem Mushroom Compiler 63
  • 64. chip-ninja() Page 64 sur 78 C.1.2 Apr`es collision On suppose que l’on a deux donn´ees apr`es le moment o`u la col- lision est d´etect´ee :la normale du point de collision et la profondeur de p´en´etration. Elles sont utilis´ees pour pouvoir appliquer une force `a chacun des polygones afin de les projeter apr`es collision. On note VAB la v´elocit´e entre les points A et B, donc pour connaˆıtre la v´elocit´e entre A et B sur la normale de collision, un produit scalaire suffit : VAB.n = (VB − VA).n. Ensuite, il nous faut le coefficient de restitution (ou encore le coefficient de Newton) not´e e. La restitution est l’´energie cin´etique g´en´er´ee apr`es collision. Elle est calcul´ee en prenant le minimum de l’attribut restitution des deux objets entr´es en collision. On a donc, d’apr`es la loi de restitution de Newton : V = e ∗ V, et dans notre cas : VAB.n = −e ∗ (VB − VA).n. Le signe est n´egatif car la projection des objets se fait dans le sens oppos´e. On doit, ensuite, pouvoir exprimer ces v´elocit´es avec l’aide d’un scalaire j repr´esentant un moment. Ce qui donne : V = V + j ∗ n, j = masse ∗ V ´elocit´e et V ´elocit´e = Impulse masse , de ce fait : V = V + j∗n masse. Apr`es, pour A et B : VA = VA + j∗n masseA et VB = VB − j∗n masseB . On peut d´evelopper le produit scalaire en : (VA − VB + j∗n masseA + j∗n masseB ) ∗ n = −e ∗ (VB − VA) · n, qui est ´equivalent `a (VA − VB + j∗n masseA + j∗n masseB ) ∗ n + e ∗ (VB − VA) · n = 0. Apr`es d´eveloppement : (VB − VA) · n + j ∗ ( j∗n masseA + j∗n masseB ) ∗ n + e ∗ (VB − VA) · n = 0, (1 + e)((VB − VA) · n) + j ∗ ( j∗n masseA + j∗n masseB ) ∗ n = 0, Donc, j = −(1+e)((VB−VA)·n) 1 masseA + 1 masseB . On a le moment j exprim´e en fonction de param`etres connus, ce qui nous permet d’avoir une collision d’objets et une projection de ces objets dans des directions en fonction de leur sens d’arriv´ee. Mushroom Compiler 64
  • 65. chip-ninja() Page 65 sur 78 Grˆace `a tout ce qui pr´ec`ede, il est possible de d´efinir une gravit´e qui permettra de faire tomber un objet de mani`ere cr´edible. Une gravit´e 4 fois sup´erieure `a celle trouv´ee sur Terre permet d’avoir une vitesse de chute appr´eciable. Cette gravit´e d´ependra ´egalement de ce qui a ´et´e calcul´e pr´ec´edemment. Si l’on prend une AABB quelconque, cette gravit´e sera appliqu´ee `a chacun de ses som- mets, ainsi, lors d’une collision ou autre, simuler des rotations sera ais´e, ce qui rend le concept de AABB obsol`ete en gagnant un degr´e de libert´e, en plus des translations sur les axes X et Y, et donc nous fourni un mod`ele physique plus ´elabor´e. Mushroom Compiler 65
  • 66. chip-ninja() Page 66 sur 78 D R´eseau D.1 Formatage des donn´ees Les donn´ees sont une structure appel´ee Data. Elle contient tous les ´el´ements n´ecessaires au bon d´eroulement du jeu. Comme dit dans la partie 11.3.1 du rapport, le nom, l’´etat et les coordonn´ees enti`eres x et y du client sont envoy´es. Sur cette structure, on force un formatage sp´ecial. En C#, fournir un objet dit ma- nag´e `a une structure non manag´ee force la structure `a avoir une repr´esentation non manag´ee de cet objet. C’est-`a-dire que ces objets peuvent avoir une repr´esentation en m´emoire, inattendue, ce qui est mauvais pour notre architecture. Pour cela, on ajoute en en-tˆete de la structure (juste au dessus de public struct Data ) : [StructLayout(LayoutKind.Sequential, Pack = 1)] Illustration : Figure 28 – Structure de types de donn´ee Mushroom Compiler 66
  • 67. chip-ninja() Page 67 sur 78 Et on force nos chaˆınes se cataractes, que sont l’´etat et le nom, `a une taille fix´ee de par exemple 10 caract`eres avec : [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 10)] Ainsi, lors de la conversion `a la r´eception et `a l’envoi, il n’y aura aucun probl`eme. Sachant que le tableau de bytes rec¸u est convertit en une donn´ee de type Data et inversement pour les donn´ees envoy´ees. Mushroom Compiler 67
  • 68. chip-ninja() Page 68 sur 78 E Images E.1 Normal Mapping E.1.1 Cˆot´es Figure 29 – Ce que l’on ne veut pas Figure 30 – Ce que l’on veut Mushroom Compiler 68
  • 69. chip-ninja() Page 69 sur 78 E.1.2 Tangente Figure 31 – Normale en bleu, tangente en rouge E.1.3 Bitangente Figure 32 – Bitangente en vert E.2 Ennemis Figure 33 – Mettoru Mushroom Compiler 69
  • 70. chip-ninja() Page 70 sur 78 Figure 34 – Sniper Mettoru E.3 Personnage Figure 35 – Tilesheet du personnage Mushroom Compiler 70
  • 71. chip-ninja() Page 71 sur 78 F Glossaire -XNA : Une s´erie d’outil permettant de simplifier l’utilisation de DirectX et donc de permettre un d´eveloppent de jeux vid´eos plus simplifi´e. - H´eritage : Notion de programmation orient´ee objet, qui permet `a une classe dite fille de b´en´eficier de toutes les attributs et m´ethodes de sa classe m`ere . - Design Pattern ou Patron de conception : Technique de pro- grammation qui permet une optimisation du code, qu’il s’agisse de performances ou de practicit´e. - Polymorphisme : Notion de programmation orient´ee objet qui permet entre autres de consid´erer une classe fille comme sa classe m`ere. -Render Target : Un espace dans lequel le processeur graphique fait un rendu -Buffer : Une zone m´emoire contenant des donn´ees -Vertex Buffer : Un buffer contenant des sommets de polygones. -SpriteBatch : Un objet fournit par XNA qui permet de d´essiner, tr`es simplement, des textures `a l’´ecran. -Shader : Un programme qui sera trait´e dans les unit´es de calcul du processeur graphique. -Blending : Une technique permettant de m´elanger deux rendus. -Color Map : Une texture ´eclair´ee de mani`ere parfaite depuis tous les angles possibles. -Normal Map : Une texture d´ecrivant les r´eflexions de la lumi`ere d’une Color Map. -Shadow Map : Le r´esultat du rendu effectu´e lors de l’utilisation de la technique de Normal Mapping. Mushroom Compiler 71
  • 72. chip-ninja() Page 72 sur 78 Table des figures 1 H´eritage des entit´es . . . . . . . . . . . . . . . . . . . . . . 9 2 Clipping d’un cube par un plan . . . . . . . . . . . . . . . 16 3 Clipping d’un rectangle par une droite . . . . . . . . . . 16 4 Distance d’un point par rapport `a un plan . . . . . . . . 16 5 D´ecoupe d’un triangle . . . . . . . . . . . . . . . . . . . . 18 6 D´ecoupe d’un rectangle par une ligne . . . . . . . . . . . 19 7 Assemblage de triangle . . . . . . . . . . . . . . . . . . . 19 8 Coordonn´ees UV . . . . . . . . . . . . . . . . . . . . . . . 20 9 Bonne et mauvaise d´ecoupe . . . . . . . . . . . . . . . . . 20 10 Rendu non final . . . . . . . . . . . . . . . . . . . . . . . . 21 11 Technique du normal mapping . . . . . . . . . . . . . . . 22 12 Une texture et sa Normal map . . . . . . . . . . . . . . . 23 13 R´eflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14 Plusieurs sortes de BlendState . . . . . . . . . . . . . . . . 30 15 Rendu Final . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16 Rendu Interm´ediaire . . . . . . . . . . . . . . . . . . . . . 32 17 D´emonstration des arri`eres-plans en parallaxe . . . . . . 38 18 Niveau : Under The Pin . . . . . . . . . . . . . . . . . . . 42 19 Niveau : Ram Jam . . . . . . . . . . . . . . . . . . . . . . . 42 20 Niveau : Ohm My God . . . . . . . . . . . . . . . . . . . . 42 21 Niveau : Under The Pin . . . . . . . . . . . . . . . . . . . 43 22 Agencement d’un niveau . . . . . . . . . . . . . . . . . . 43 23 Le chemin de solution . . . . . . . . . . . . . . . . . . . . 45 24 L’arri`ere-plan dynamique . . . . . . . . . . . . . . . . . . 51 25 Le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 26 Le Site Web . . . . . . . . . . . . . . . . . . . . . . . . . . 55 27 Separatin Axis Theorem . . . . . . . . . . . . . . . . . . . 63 28 Structure de types de donn´ee . . . . . . . . . . . . . . . . 66 29 Ce que l’on ne veut pas . . . . . . . . . . . . . . . . . . . 68 30 Ce que l’on veut . . . . . . . . . . . . . . . . . . . . . . . . 68 Mushroom Compiler 72
  • 73. chip-ninja() Page 73 sur 78 31 Normale en bleu, tangente en rouge . . . . . . . . . . . . 69 32 Bitangente en vert . . . . . . . . . . . . . . . . . . . . . . . 69 33 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 34 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . 70 35 Tilesheet du personnage . . . . . . . . . . . . . . . . . . . 70 Mushroom Compiler 73
  • 74. chip-ninja() Page 74 sur 78 Table des mati`eres 1 Introduction 5 2 Le groupe 6 2.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . 8 3 Architecture du code 9 3.1 H´eritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Composants . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 Gestionnaire d’entr´ees . . . . . . . . . . . . . . . . 10 3.2.2 Gestionnaire d’´etats . . . . . . . . . . . . . . . . . 11 3.2.3 Gestionnaire d’arri`ere-plans . . . . . . . . . . . . . 11 3.3 ´Etats du personnage . . . . . . . . . . . . . . . . . . . . . 12 4 Moteur de Tuiles 13 4.1 Impl´ementions . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1 M´eta-donn´ees . . . . . . . . . . . . . . . . . . . . . 13 4.2 Fonctionnalit´es . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Moteur Physique 14 5.1 Physique des personnages . . . . . . . . . . . . . . . . . . 14 5.1.1 D´eplacement . . . . . . . . . . . . . . . . . . . . . 14 5.1.2 Gravit´e . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1 Sutherland-Hodgman . . . . . . . . . . . . . . . . 15 5.3.2 Ajout de physique . . . . . . . . . . . . . . . . . . 21 6 Moteur Graphique 22 6.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . 22 6.1.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . 22 Mushroom Compiler 74
  • 75. chip-ninja() Page 75 sur 78 6.1.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.3 Le rendu . . . . . . . . . . . . . . . . . . . . . . . . 24 6.1.3.a Valse des RenderTargets . . . . . 25 6.1.3.b Rendu de la shadow map . . . . 26 6.1.3.c Blending . . . . . . . . . . . . . . 29 6.1.3.d Finalisation . . . . . . . . . . . . . 30 6.2 Rayons cr´epusculaires . . . . . . . . . . . . . . . . . . . . 31 6.2.1 Ph´enom`ene . . . . . . . . . . . . . . . . . . . . . . 32 6.2.2 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.2.a Rendu . . . . . . . . . . . . . . . . 32 6.2.2.b Le Shader . . . . . . . . . . . . . . 33 6.2.2.c High Dynamic Range . . . . . . . 35 6.2.2.d Tone mapping . . . . . . . . . . . 36 6.3 Moteur `a particules . . . . . . . . . . . . . . . . . . . . . . 36 6.3.1 M´ethode . . . . . . . . . . . . . . . . . . . . . . . . 36 6.4 Arri`ere-plan . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.4.1 M´ethode . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7 Gameplay 39 7.1 Le coeur du gameplay . . . . . . . . . . . . . . . . . . . . 39 7.2 Ajouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2.1 Le combat . . . . . . . . . . . . . . . . . . . . . . . 39 7.2.2 La technique Sp´eciale . . . . . . . . . . . . . . . . 39 7.2.3 Manipulation de la gravit´e . . . . . . . . . . . . . 39 7.2.4 Contrˆoles . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.4.a Clavier . . . . . . . . . . . . . . . 40 7.2.4.b Manette . . . . . . . . . . . . . . . 40 8 Contenu 41 8.1 Graphismes . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1.1 Personnage . . . . . . . . . . . . . . . . . . . . . . 41 8.1.2 Tileset . . . . . . . . . . . . . . . . . . . . . . . . . 41 Mushroom Compiler 75
  • 76. chip-ninja() Page 76 sur 78 8.1.3 Arri`ere-plans . . . . . . . . . . . . . . . . . . . . . 41 8.1.4 Facteurs de flare . . . . . . . . . . . . . . . . . . . 41 8.2 Niveaux Artisanaux . . . . . . . . . . . . . . . . . . . . . . 41 8.2.1 Under The Pin . . . . . . . . . . . . . . . . . . . . 41 8.2.2 Ram Jam . . . . . . . . . . . . . . . . . . . . . . . . 42 8.2.3 Ohm My God . . . . . . . . . . . . . . . . . . . . . 42 8.2.4 Transisterrific . . . . . . . . . . . . . . . . . . . . . 42 8.3 Generation Proc´edurale . . . . . . . . . . . . . . . . . . . 43 8.3.1 Agencement . . . . . . . . . . . . . . . . . . . . . . 43 8.3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . 44 8.3.3 Peupler . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3.4 Faire pousser des ´echelles . . . . . . . . . . . . . . 45 8.4 Musique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.4.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.4.2 Under The Pin . . . . . . . . . . . . . . . . . . . . 46 8.4.3 Ram Jam . . . . . . . . . . . . . . . . . . . . . . . . 46 8.4.4 Transisterrific ! . . . . . . . . . . . . . . . . . . . . 46 8.5 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.5.1 Options . . . . . . . . . . . . . . . . . . . . . . . . 47 9 Outils de developpement 48 9.1 ´Editeur de niveau . . . . . . . . . . . . . . . . . . . . . . . 48 9.1.1 Interface . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . 48 10 Intelligence Artificielle 49 10.1 Mettoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10.2 Sniper Mettoru . . . . . . . . . . . . . . . . . . . . . . . . 49 10.3 Bat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 11 R´eseau 50 11.1 Multijoueur . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.2 Pr´esentation du mode de jeu . . . . . . . . . . . . . . . . 50 11.3 R´ealisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Mushroom Compiler 76
  • 77. chip-ninja() Page 77 sur 78 11.3.1 Cˆot´e Client . . . . . . . . . . . . . . . . . . . . . . 51 11.3.2 Formatage des donn´ees . . . . . . . . . . . . . . . 52 11.3.3 Cˆot´e Serveur . . . . . . . . . . . . . . . . . . . . . 52 11.3.4 Probl`emes . . . . . . . . . . . . . . . . . . . . . . . 53 12 Site Internet 55 12.1 Responsive Design . . . . . . . . . . . . . . . . . . . . . . 55 12.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . 56 13 Conclusions personnelles 57 13.1 Alexandre Doussot . . . . . . . . . . . . . . . . . . . . . . 57 13.2 Chady Dimachkie . . . . . . . . . . . . . . . . . . . . . . 58 13.3 Benjamin R´echou . . . . . . . . . . . . . . . . . . . . . . . 59 14 Conclusion 60 Annexes 61 A Comment lire ce rapport ? 61 B R´ef´erences 62 C Moteur Physique 63 C.1 Attaque sp´eciale . . . . . . . . . . . . . . . . . . . . . . . . 63 C.1.1 D´etection de collisions . . . . . . . . . . . . . . . . 63 C.1.2 Apr`es collision . . . . . . . . . . . . . . . . . . . . 64 D R´eseau 66 D.1 Formatage des donn´ees . . . . . . . . . . . . . . . . . . . 66 E Images 68 E.1 Normal Mapping . . . . . . . . . . . . . . . . . . . . . . . 68 E.1.1 Cˆot´es . . . . . . . . . . . . . . . . . . . . . . . . . . 68 E.1.2 Tangente . . . . . . . . . . . . . . . . . . . . . . . . 69 E.1.3 Bitangente . . . . . . . . . . . . . . . . . . . . . . . 69 E.2 Ennemis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Mushroom Compiler 77
  • 78. chip-ninja() Page 78 sur 78 E.3 Personnage . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 F Glossaire 71 Mushroom Compiler 78