Weitere Àhnliche Inhalte
Ăhnlich wie Rapport de Soutenance 1 (20)
Rapport de Soutenance 1
- 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 ïŹchier 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 enïŹn 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 ProïŹle,
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 aïŹn 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. AïŹn 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 eïŹet 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 aïŹn 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 eïŹet Ă 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 eïŹet, considĂ©rons une pile dâĂ©crans dans laquelle seul lâĂ©cran au som-
met est aïŹchĂ© ; Ă 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 eïŹet, 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 ïŹni dâĂ©tats, de transitions entre ces Ă©tats, et dâactions : nous quittons un
Ă©tat particulier en eïŹectuant une action qui va valider une transition. Par la suite,
nous avons couplĂ© ces diïŹĂ©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 modiïŹer 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 diïŹĂ©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 ïŹchier 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 eïŹet 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 ïŹchiers 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. EnïŹn 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 ïŹchier 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 eïŹet 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 : EnïŹn, 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 ïŹĂš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 modiïŹe 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Ă©riïŹer les entrĂ©es du clavier. EnïŹn sâil est en mouvement,
nous actualiserons son mouvement de translation.
VĂ©riïŹcation 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
eïŹectuĂ©. Nous vĂ©riïŹons 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 diïŹĂ©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 ïŹchier texte en une matrice de sprite.
GrĂące Ă XNA, nous avons pu nous servir de Stream Reader qui permet de lire
un ïŹchier 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.
EnïŹn 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 eïŹet câest ce
qui dĂ©terminera si les objets sont aïŹchĂ©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
modiïŹons 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 modiïŹcations 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 modiïŹer le volume sonore directement dans le menu. Des sons complĂ©men-
taires seront aussi implĂ©mentĂ©s aïŹn 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 aïŹcher 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Ă©ïŹnir ci-dessous.
5.1.1 SVN
Suite aux diïŹĂ©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 conïŹit 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 diïŹĂ©rentiable des autres jeux et de
controler parfaitement ce qui est aïŹchĂ© 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
eïŹet 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 diïŹĂ©-
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 diïŹcile 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 enïŹn 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 ïŹnal.
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 eïŹet 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, aïŹn de prĂ©senter un travail
cohĂ©rent. Ceci est une partie diïŹcile, 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 diïŹĂ©rents (nous sommes de 3
classes diïŹĂ©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 conïŹant 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 ïŹxĂ©s dans le cahier des charges. Nous sommes capables
dâaïŹcher diïŹĂ©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 conïŹants 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