Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
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
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
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