1. Rapport de soutenance
Cross Divinity
04/01/2012
lefebv_k dossan_j
do_o benoth_c

2. Table des matières
1 Présentation du jeu 3
2 Moral du groupe 3
2.1 Le menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Les cartes et les tuiles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Le site internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Moteur graphique, la cartographie par tuiles 6
3.1 Création de la classe Sprite . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Détermination de la position dessinée . . . . . . . . . . . . . . 7
3.1.2 La méthode Dessiner . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 La méthode Actualiser . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Conversion d’un fichier texte en une matrice de sprite. . . . . . . . . 10
3.2.1 La fonction statique Associer . . . . . . . . . . . . . . . . . . 10
3.2.2 La fonction RemplirMatrice . . . . . . . . . . . . . . . . . . . 10
3.3 Utilisation de la matrice dans la Carte . . . . . . . . . . . . . . . . . 11
3.3.1 Charger les contenus . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Dessiner la carte . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.3 Actualiser la carte . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Moteur son 12
5 Les logiciels que nous avons utilisés 13
5.1 Visual Studio et XNA . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2 Gimp et Paint . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Conclusions 14
6.0.3 Chemsi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.0.4 Olivier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.0.5 Stéphane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.0.6 Johan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.0.7 Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . 15

3. Le projet Sup du groupe Jamps de la promotion 2016 de l’Epita est lancé. Notre
création avance avec enthousiasme et nous allons présenter l’état d’avancement de
notre travail. Ce compte-rendu détaillera ce qui était prévu dans le cahier des
charges : Le RPG « Cross Divinity », qui correspondra aux critères que nous
avions énoncés ainsi que quelques "bonus".
commencerons par une présentation du jeu, puis nous montrerons les rouages
internes. Et enfin nous dévoilerons ce que nous avons utilisé comme outils pour
arriver à ce résultat.

4. EPITA 2016 2 MORAL DU GROUPE
1 Présentation du jeu
Pour ce projet nous avons décidé de réaliser un RPG au tour par tour s’inspirant
essentiellement des RPG japonais comme Final Fantasy, Persona, Valkyrie Profile,
et autres « japonaiseries » mais aussi de jeux occidentaux comme Fallout et Morro-
wind.
Le système de combat sera semblable aux premiers Final Fantasy, c’est-à-dire un
système de combat au tour par tour où l’on contrôle quatre personnages que l’on
fait agir les uns après les autres avant (ou après) nos opposants. Ce système implique
que les combats et les phases d’exploration soient des phases distinctes pendant le
jeu.
Les phases d’explorations seront faites en 2D isométriques (Fallout 2, Age of Em-
pire I , II). Durant ces phases, des énigmes seront proposées au joueur. La résolution
de ces énigmes sera nécessaire afin de pouvoir continuer la progression dans le jeu.
Les monstres ou autres ennemis seront visibles à l’écran et un contact avec ceux-
ci entrainera le lancement du combat. Ce système permettra au joueur de pouvoir
choisir ou non de lancer un combat.
Et l’histoire ? Pour le moment aucun scénario précis n’a été décidé par le groupe.
Beaucoup d’idées ont été proposées par tous les membres du groupe mais aucune
ne nous satisfait tous. Seul le monde dans lequel l’histoire se déroulera a été décidé.
L’histoire se passera donc sur une île.
2 Moral du groupe
Avant l’entrée dans l’Epita, seuls deux des membres du groupe se connaissaient,
le groupe s’est principalement formé en pré-rentrée de mathématiques. Mais ce n’est
que lorsque la création de groupe devenait nécessaire que le groupe a commencé à
fonctionner réellement. Ce projet nous a donc permis de faire de nouvelles connais-
sances. Le courant entre nous passe plutôt bien, même très bien. Tous les membres
sont très motivés pour coder le jeu : De longues journées (pendant les vacances) de
codage intensif se sont déroulées dans la joie et la bonne humeur. Afin de renforcer
nos liens et permettre une meilleure cohésion au sein du groupe, il fut décidé de faire
une activité extrascolaire, car nous ne nous connaissions que dans l’Epita et nos rap-
ports n’étaient que sur le plan du travail. Une sortie dans un bar ou se déroulait un
concert fut organisée, les membres ont donc assisté à un concert de rock, une bière à
la main. Cependant la communication interne au groupe a nécessité quelques amé-
nagements. En effet l’un des membres n’ayant pas de téléphone portable en début
d’année, il fut conclu un rendez-vous bihebdomadaire afin que tout le groupe soit
mis au courant des dernières avancées.
3 Jamps

5. EPITA 2016 2 MORAL DU GROUPE
2.1 Le menu
L’interface globale est un élément indispensable au bon fonctionnement du logi-
ciel. Elle permettra en effet à l’utilisateur de manipuler plus facilement et rapidement
celui-ci. Il faut donc qu’elle soit complète mais également simple d’accès. Elle s’or-
ganise autour du concept de l’écran : chaque partie du logiciel (comme le menu
principal, le menu des options, le jeu lui-même) est gérée de manière graphique par
un écran, une surface qui prend toute la fenêtre et qui capte toutes les interactions
de l’utilisateur.
Le fonctionnement des successions de ces écrans est alors facilité par l’utilisation
d’une pile. En effet, considérons une pile d’écrans dans laquelle seul l’écran au som-
met est affiché ; à l’instant où nous lançons le programme, cette pile est vide. Nous
empilons alors le menu principal qui donne ensuite l’ordre, selon le choix de l’utili-
sateur, d’empiler un autre écran (celui de jeu ou des options), ou de dépiler, ce qui
terminerait alors l’exécution.
La conception du menu fut relativement simple à imaginer mais sa réalisation s’avéra
complexe. En effet, nous avons commencé par penser à toutes les classes d’une ma-
chine à état. Une machine à états est un modèle de comportement composé d’un
nombre fini d’états, de transitions entre ces états, et d’actions : nous quittons un
état particulier en effectuant une action qui va valider une transition. Par la suite,
nous avons couplé ces différents états à l’adoption du langage C. Cela était parfait
pour le menu, qui avait besoin de simplicité, et de rapidité et cela rejoignait donc
l’idée que nous nous étions faits sur l’interface globale. Il est simple à utiliser pour
l’utilisateur, permet une utilisation intuitive et agréable même s’il reste pas mal de
choses à améliorer car pour le moment il est loin d’être totalement fonctionnel.
Pour ce qui est du menu à proprement parler, nous avons décidé de placer en fond
une image que nous avons réalisée par nos soins pour le rendre plus original et pour
être en cohérence avec l’univers qui réside dans notre jeu.
Les bases du jeu sont posées, il faut maintenant les consolider. Au sein de la partie
interface, pas mal de choses restent à ajouter. Nous nous sommes juste occupés du
menu pour le moment, l’interface utilisateur en jeu est en cours de construction et
le menu lui-même est en phase d’amélioration. Nous rajouterons de nouvelles fonc-
tionnalités au menu, notamment dans la partie Options et Jouer de celui-ci. Dans
la partie « Options », des outils permettant de régler le volume correctement et
de modifier la taille de l’écran seront ajoutés ; dans la partie « Jouer », un sous
menu avec de nouveaux icônes seraient envisageables pour permettre à l’utilisateur
de créer une nouvelle partie ou alors d’en charger une déjà commencée. Pour ce qui
est de l’interface utilisateur, nous devrons réaliser un inventaire, et d’autres outils
facilitant la manipulation de notre jeu.
4 Jamps

6. EPITA 2016 2 MORAL DU GROUPE
2.2 Les cartes et les tuiles
Le jeu se déroulera sur plusieurs emplacements, qui peuvent être structurés en
trois ensembles distincts :
-La carte intégrant la ville et les donjons, qui sera en 2D isométrique, et composée
de tuiles assemblées les unes aux autres, dans laquelle l’équipe du héros, représenté
par le personnage principal, se déplace et rencontre des personnages non joueurs.
-"La carte de combat", qui sera en 2D vue de côté, où le joueur combat les différents
monstres qu’il rencontre. On y voit représentée l’équipe du joueur, les uns à côté des
autres, face aux monstres. Dans cet emplacement le jeu se déroule au tour par tour.
-"La carte du monde", qui sera un simple dessin sur lequel les villes, les donjons et
les lieux visitables de l’ile seront placés et où le joueur sera représenté par un point
qui se déplace entre les lieux.
Lors de la phase de visite de la ville ou de donjons, la carte est générée à partir
d’un fichier texte et de tuiles. Les tuiles sont créées avec gimp et paint. Leur taille
étant choisie arbitrairement, nous avons d’abord opté pour une puissance de 2, la
128x64, étant plus facilement calculable par la carte graphique. Malheureusement
cette façon de procéder donnait des tuiles trop grandes ce qui nous mena à créer des
tuiles en 52x28.
2.3 Le site internet
Les changement successifs de dessins ralentirent la création de la base de gra-
phismes. Les héros étant créés en pixel art, le changement tardif de norme de base a
remis à zéro les sprites des héros préexistants et la façon de les créer a été changée :
Les héros sont maintenant dessinés à la main sur papier, puis scannés et pixélisés à la
bonne taille. Une contrepartie inattendue s’en est dégagée, dessins sont en effet aussi
utilisés pour maintenir le site web actif, en fournissant des artworks régulièrement a
la communauté potentielle.// Le site web, qui est notre vitrine à travers le monde,
a été conçu mais n’est pas encore disponible sur le web. Il est codé en XHtml et en
CSS, le but étant à terme d’y ajouter une base SQL et le rendre plus interactif à
l’aide du PHP. Nous avons rencontré des problèmes dans la conception du site et
notamment dans la tentative d’instaurer une police personnalisée.//
5 Jamps

7. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
3 Moteur graphique, la cartographie par tuiles
Pourquoi avoir choisi cette méthode ? Parce qu’elle permet, une fois que l’algo-
rithme est conçu, de créer rapidement et simplement des cartes. Ainsi à partir d’un
ou plusieurs fichiers textes (selon le nombre de couches) composés d’une suite de
lettres, nous obtenons une matrice de sprite disposant pour chacun d’entre eux de
toutes les informations nécessaires pour créer un environnement cohérent. Enfin les
méthodes pour dessiner et actualiser les attributs des tuiles seront faciles à réaliser
depuis la matrice.
Décomposons ce procédé en grandes étapes :
1. Création de la classe sprite.
2. Conversion d’un fichier texte en une matrice de sprite.
3. Utilisation de cette matrice créer une carte.
3.1 Création de la classe Sprite
Un sprite étant tout ce que l’on va dessiner à l’écran, c’est donc ce qui servira de
base à tous les éléments graphiques, d’une part les tuiles, et d’autre part les décors
et les personnages. Il devra disposer d’un certain nombre d’attributs dont ceux pour
déterminer la position où elle sera dessinée et de méthodes telles que celles permet-
tant de le dessiner à l’écran à la position enregistrée.
6 Jamps

8. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
3.1.1 Détermination de la position dessinée
Pour déterminer la position où le sprite sera dessiné, nous avons besoin d’un
certain nombre d’attributs intermédiaires. En effet nous ne disposons, au début, que
d’un seul paramètre : la position matricielle qui demandera pour commencer d’être
convertie en position isométrique, ou position réelle.
PositionIsometrique : Dépend uniquement des dimensions par défaut des tuiles
et de la position matricielle, l étant la ligne et c la colonne.
Soit H, la hauteur par défaut d’une tuile et L la largeur par défaut d’une tuile.
BaseRectangle : Nous aurons nécessairement besoin de dessiner des sprites
plus larges et/ou plus profonds qu’une case, tels qu’une maison. Nous devons donc
calculer à partir de la position isométrique, la position de la base, ainsi que ses di-
mensions.
Soit h, la hauteur en nombre de cases et l la largeur en nombre de cases.
7 Jamps

9. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
Position de dessin : Enfin, intéressons nous aux objets de décors ou même des
personnages qui dépasseraient en hauteur et/ou en largeur. Par exemple un arbre
en position (1,1) dans la matrice, doit évidement avoir sa base confondue à la tuile
en position (1,1). Or, si nous dessinons la texture à la position de la base, nous
observerons un décalage. Ainsi nous devons calculer la position D, en fonction du
décalage en hauteur (decH) et en largeur (decL).
baseX − decH
D(B, decH, decL) =
baseY − decL
Variations en fonction de la caméra : La caméra dispose principalement
d’une position en X ainsi que d’une position en Y. La caméra a deux modes de
déplacement : le déplacement libre avec les flèches directionnelles, et un deuxième
qui permet de verrouiller la caméra sur le personnage principal. On peut passer d’un
mode à l’autre grâce à la touche « L ».
Le premier modifie simplement la position de la caméra en fonction de la touche
pressée. Le deuxième fait varier la position en fonction de la position de la cible, sa
hauteur et la taille de l’écran (nécessaire pour centrer correctement).
Quelque soit la méthode choisie, la position de dessin de chaque sprite est actualisée
en fonction de la position de la caméra.
8 Jamps

10. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
3.1.2 La méthode Dessiner
Nous pouvons dessiner à l’écran à l’aide de SpriteBatch, la texture (si non nulle)
à la position de dessin enregistrée.
3.1.3 La méthode Actualiser
Si le sprite n’est pas en mouvement, nous n’aurons qu’à actualiser la position
dessinée en fonction de la caméra. Autrement, s’il est le personnage principal, mais
ne bouge pas, il faudra vérifier les entrées du clavier. Enfin s’il est en mouvement,
nous actualiserons son mouvement de translation.
Vérification des entrées :En fonction de l’une des 8 directions entrée par le joueur,
le vecteur vitesse changera de valeur selon le sens de la translation qui pourra être
effectué. Nous vérifions ensuite si le mouvement dans ce sens est réalisable à partir
de la position du personnage dans la matrice, et d’une matrice de booléen (plus de
détail dans la partie Création de la Carte). S’il n’y a pas d’obstacle, nous calculons
sa destination.
Calcul de la destination :En fonction de la direction, nous trouvons la destination
matricielle que nous pouvons convertir en destination isométrique.
Mouvement du personnage :Tant que la position est différente de la destination,
la vitesse s’ajoute à la position. Une fois que la translation est réalisée, la position
matricielle prend la valeur de la destination matricielle.
9 Jamps

11. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
3.2 Conversion d’un fichier texte en une matrice de sprite.
Grâce à XNA, nous avons pu nous servir de Stream Reader qui permet de lire
un fichier texte externe.
3.2.1 La fonction statique Associer
Cette fonction crée une nouvelle instance d’un sprite en fonction du caractère
fourni en paramètre. Par exemple la lettre W créera un sprite de type Eau.
3.2.2 La fonction RemplirMatrice
L’algorithme marche ainsi :
1. Il crée une matrice de taille (le nombre de lignes, le nombre de caractères par
ligne).
2. Ajoute à la même position dans la matrice le type de sprite associé à la lettre.
10 Jamps

12. EPITA 2016 3 MOTEUR GRAPHIQUE, LA CARTOGRAPHIE PAR TUILES
3.3 Utilisation de la matrice dans la Carte
Nous disposons désormais de toutes les méthodes nécessaires pour créer des ma-
trices de sprite. Nous pouvons donc nous en servir pour créer une carte disposant
de trois matrices, une pour les tuiles une autre pour la seconde couche (Décors et
personnages), la troisième est une simple matrice de booléen que l’on nommera Obs-
tacles.
3.3.1 Charger les contenus
Pour chacune des matrices de sprite, nous commençons par charger les textures
adaptées en fonction du type de sprite rencontré dans la matrice. Ainsi, si le sprite
est de type , la texture de ce sprite chargera l’image de la tuile Eau. Nous chargeons
dans le même temps certains attributs tels que le booléen estPassable qui indique
si l’on peut traverser ou non cet élément, ou encore ceux déjà expliqués précédem-
ment : la longueur (l) et la profondeur (h) du sprite, et les décalages en hauteur et
en largeur.
Nous utilisons ensuite la fonction ChargerPositions, qui à partir de la position ma-
tricielle et des calculs précédents, permet de déterminer la position dessinée.
Enfin nous remplissons Obstacles en fonction de la valeur d’EstPassable des sprites
de chacune des matrices. Si la position est franchissable, alors vrai sinon faux.
3.3.2 Dessiner la carte
Dessiner la carte revient à appeler la fonction Dessiner pour chacun des sprites
des deux matrices. Cependant l’ordre du parcours est important. En effet c’est ce
qui déterminera si les objets sont affichés devant ou derrière les autres.
De cette manière, les objets se superposeront de manière cohérente, y compris lors
des déplacements.
11 Jamps

13. EPITA 2016 4 MOTEUR SON
3.3.3 Actualiser la carte
Nous distinguons deux cas pour actualiser un élément d’une matrice de sprite :
S’il est en mouvement ou non. S’il ne bouge pas, nous appellerons la méthode d’ac-
tualisation en fonction de la caméra. Ce sera le cas pour toutes les tuiles, mais
pas pour la seconde couche contenant également les personnages. S’il bouge, nous
modifions sa position dans la matrice puis nous actualisons sa translation.
4 Moteur son
Le son est une des caractéristiques primordiales dans un RPG. Il permet de créer
une ambiance en fonction de la situation et une meilleure immersion du joueur dans
le jeu.
Le moteur son a donc été commencé pour la première soutenance. Pour l’instant ce
moteur gère uniquement des musiques, qui seront jouées pendant la phase de jeu.
Deux musiques sont disponibles dans le jeu. Il est possible de changer de musique
directement pendant le jeu en appuyant sur les touches "P" ou "M".
Il est aussi possible d’augmenter le son grâce à la touche "Numa 1" ou de le baisser
grâce à la touche "Numa 2". On peut aussi couper le son grâce à la touche "O".
Ces modifications sonores ne sont pas pour l’instant possibles dans le menu.
Il faudra désormais implémenter plusieurs musiques qui se lanceront automatique-
ment en fonction de la situation et du lieu où le joueur se trouvera. Il faudra que l’on
puisse modifier le volume sonore directement dans le menu. Des sons complémen-
taires seront aussi implémentés afin de rendre le jeu plus réaliste (bruits de coups
lors des combats, son d’ambiance etc..)
12 Jamps

14. EPITA 2016 5 LES LOGICIELS QUE NOUS AVONS UTILISÉS
5 Les logiciels que nous avons utilisés
5.1 Visual Studio et XNA
Microsoft Visual Studio est une suite de logiciels de développement pour Win-
dows conçue par Microsoft. La dernière version en date s’appelle Visual Studio 2010,
celle que nous utilisons pour la réalisation du projet.
Visual Studio est un ensemble complet d’outils de développement permettant de gé-
nérer de nombreuses fonctionnalités notamment des applications Web, des Services
Web XML et des applications mobiles. Visual C, l’outil de programmation que nous
avons pu découvrir grâce à notre projet, utilise le même environnement de dévelop-
pement intégré (IDE, Integrated Development Environment) que les autres langages
fonctionnant sous Visual Studio. Cela leur permet de partager des outils et facilite
la création de solutions faisant appel à plusieurs langages.
XNA désigne une série d’outils fournis gratuitement par Microsoft qui facilite les dé-
veloppements de jeux pour les plates-formes Windows, Windows Phone 7, et Xbox
360 en réunissant un maximum d’outils en provenance de Microsoft et de ses parte-
naires (DirectX, Visual Studio).
Par conséquent, le logiciel Microsoft XNA nous a principalement permis de repré-
senter notre jeu vidéo sous Windows. Grâce à ce dernier, nous pouvons afficher tout
le contenu de nos travaux réalisés en C à l’écran.
L’environnement de développement intégré utilisé est Visual Studio, un programme
que nous allons définir ci-dessous.
5.1.1 SVN
Suite aux différentes conférences faites par les promotions précédentes, nous
avons décidé de choisir SVN comme logiciel de gestion de versions. Jusque là, aucun
de nous n’avait entendu parler de ce type de logiciel, nous étions encore à l’époque
des clés de stockage. Il nous a pas mal facilité la vie, nous n’avons plus à nous soucier
des problèmes de pertes des clés. En plus de cela, SVN nous permet de travailler à
plusieurs simultanément sur le même projet sans qu’il n’y ait aucun conflit entre les
uns et les autres. Suite à cet avantage là, nous avons pu consacrer le temps gagné à
approfondir d’autres tâches du projet qui nous paraissaient plus complexes.
5.1.2 Gimp et Paint
Bien que photoshop est à la disposition des élèves, le groupe utilise le logiciel
Gimp pour créer l’univers graphique, et paint vient faciliter la démarche de créa-
tion, le but étant de se créer un style graphique différentiable des autres jeux et de
controler parfaitement ce qui est affiché a l’écran
13 Jamps

15. EPITA 2016 6 CONCLUSIONS
6 Conclusions
6.0.3 Chemsi
Avant de commencer à coder notre projet, j’appréhendais un peu cette étape. En
effet c’était la première fois de ma vie que j’allais coder un projet concret et je n’y
connaissais rien du tout je ne connaissais rien au C et à XNA. J’ai donc commencé
par apprendre tout seul les bases du C grâce a à des tutoriels sur internet. Cette
étape n’était vraiment pas motivante. Mais le fait de coder en même temps que
les autres membres du groupe et de voir que ce que j’avais appris se concrétisait
m’a grandement motivé. Ce n’est que le début du projet mais je pense que celui-
ci va beaucoup m’apporter au niveau intellectuel et aussi me donner une véritable
expérience dans la programmation.
6.0.4 Olivier
Depuis la rédaction du cahier des charges, nous nous sommes réparti les diffé-
rentes tâches pour le projet. Personnellement je me suis chargé de la partie « Menu
» de notre jeu. Dans cette partie là, le début était fort difficile d’autant plus que je
ne comprenais pas grand-chose au C et en plus de cela il fallait apprendre les bases
d’XNA. Savoir par quoi et où commencer le codage du menu n’a pas été simple pour
ma part. J’ai parcouru pas mal de chemin avant de trouver un assez bon tutoriel
qui m’aura pas mal aidé. A l’aide de ce dernier, j’ai pu réaliser des choses que je ne
concevais même pas de faire avant un certain temps. Le fait d’avoir enfin réussi à
apporter quelque chose de concret au groupe et au projet m’a complètement boosté.
Cela me réjouissait à l’idée de devoir continuer sur cette voie là et faire progresser
le projet jusqu’à son terme final.
6.0.5 Stéphane
Ce projet est pour moi l’occasion d’une double expérience : la création d’un jeu
et la gestion d’un groupe pour le mener vers la réussite. L’ensemble n’est pas une
chose facile, car ce sont deux domaines dans lesquels je n’ai pas ou peu d’expérience :
Je n’ai en effet jamais participé à la création d’un jeu en groupe et bien qu’ayant
déjà acquis quelques compétences en code au collège et au lycée, la programmation
orientée objet ainsi que la maitrise C ne m’étaient pas connues. Je me suis chargé de
la partie du graphisme du jeu, car j’aime également dessiner, et du site web. C’est
également la première fois que je dois gérer l’organisation du travail d’un groupe, et
c’est peut-être la partie qui me paraît la plus compliquée. Mes camarades sont très
motivés, mais il s’agit d’essayer de structurer l’ensemble, afin de présenter un travail
cohérent. Ceci est une partie difficile, qui ne m’est pas familière.
14 Jamps

16. EPITA 2016 6 CONCLUSIONS
6.0.6 Johan
La première partie de ce projet a été très plaisant pour moi. Ayant déjà un peu
d’expérience en algorithmique, je n’ai pas eu peur de me jeter à l’eau le premier.
Ainsi, j’ai appris les bases du C directement sur le terrain, puisque j’ai commencé
par notre moteur jeu (que nous commencerons à exploiter qu’à partir de la 2ème
soutenance). Cela m’a permis d’apprendre beaucoup sur la programmation orien-
tée objet. Mais ceci m’a également fait prendre de l’avance sur le reste du groupe,
qui n’avançait pas au même rythme que moi. Pour que ces acquis nous soient fa-
vorables à tous, nous avons décidé de nous réunir pour coder ensemble, ce qui ne
fût pas chose aisée à cause de nos horaires de cours différents (nous sommes de 3
classes différentes). Nous avons alors pu partager nos connaissances et ainsi réajuster
les inégalités. A partir de ce moment, j’ai senti un intérêt croissant chez les autres
membres du groupe. C’est ce qui me rend confiant pour le reste de l’aventure.
6.0.7 Conclusion générale
Pour cette première soutenance nous sommes parvenus à accomplir tous les ob-
jectifs que nous nous étions fixés dans le cahier des charges. Nous sommes capables
d’afficher différents types de "texture au sol" (eau, sable, herbe) et des décors comme
des arbres. Notre moteur physique gère les collisions avec les éléments du décor
(arbres pour l’instant), et il est impossible pour le personnage de passer sur des tex-
tures qui sont inaccessibles, comme l’eau. De plus, étant en 2D isométriques, notre
personnage est positionné derrière le décor quand il doit l’être (si le personnage passe
derrière un arbre il n’est plus visible). Nous disposons aussi d’un scrolling qui permet
à la caméra de suivre notre personnage au fur et à mesure qu’il se déplace sur la
carte. Nous sommes donc confiants quant à l’avenir de notre projet et la motivation
grandit d’autant que ce dernier progresse.
15 Jamps

17. EPITA 2016 6 CONCLUSIONS
L’image d’introduction et de menu, fait sous Gimp
Une image de notre jeu
16 Jamps

18. EPITA 2016 6 CONCLUSIONS
Des fois les choses ne se passent pas aussi simplement que voulu
Une image de l’ébauche du site
17 Jamps

19. EPITA 2016 6 CONCLUSIONS
Toute l’équipe espère que cette présentation vous aura plu
18 Jamps