Chip_Ninja____Rapport_soutenance_finale

134 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
134
Sur SlideShare
0
Issues des intégrations
0
Intégrations
17
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Chip_Ninja____Rapport_soutenance_finale

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 70. chip-ninja() Page 70 sur 78 Figure 34 – Sniper Mettoru E.3 Personnage Figure 35 – Tilesheet du personnage Mushroom Compiler 70
  71. 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. 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. 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. 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. 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. 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. 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. 78. chip-ninja() Page 78 sur 78 E.3 Personnage . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 F Glossaire 71 Mushroom Compiler 78

×