MODULE INFORMATIqUE 3

PROJET C++

SNOOPY’S REVENGE

Professeurs :
Florent DIEDLER Auteurs :
Jean-Pierre SEGADO Maxime REMY
Pierre MOREAU

Equipe : 709

29 Novembre 2015
Table des matières

0 Introduction 4

1 Organisation 5
1.1 Planning.....................................................................................................5
1.2 Répartition des tâches................................................................................5

2 Conception 7
2.1 Les classes.......................................................................................................8
Vecteur2D........................................................................................................8
Dessinable........................................................................................................8
Snoopy.............................................................................................................9
Case..................................................................................................................9
Balle.................................................................................................................9
Plateau...................................................................................................9
Jeu..............................................................................................................9
Partie.....................................................................................................9
Menu................................................................................................................9
Timer..........................................................................................................9
2.2 Graphe d’appel................................................................................................9
2.3 Analyse Chronologique et Descendante..................................................11
2.4 Documentation.........................................................................................12

3 Scénarios 14
Structures, defines et conception modulaire...........................................14
Menus et paramètres................................................................................14
Charger Partie/Code...........................................................................15
High Score.....................................................................................................16
Game Over...............................................................................................16
Musiques et effets sonores en stéréo............................................................17
Temps.............................................................................................................17
Moteur de jeu...........................................................................................17
Balle...............................................................................................................18
Case................................................................................................................18
Interface.........................................................................................................19
Save................................................................................................................19
1
Projet C++ 2015-2016 Equipe 709 : Remy & Moreau

Debug.............................................................................................................20

4 Problèmes rencontrés 21
Tests.........................................................................................................21
Accessibilité et Navigabilité entre objets................................................21
Mono-existence des ressources graphiques..................................................21
Collisions.......................................................................................................23

5 Conclusion 24

Références 25
TABLE DES MATIÈRES 2
Table des images

1.1 Diagramme d’organisation..............................................................................6

2.1 Diagramme des classes....................................................................................8

2.2 Graphe d’appel de menu..........................................................................10
2.3 snoopy.photeine.com : documentation exhaustive du projet..................13

3.1 menu graphisme.......................................................................................14

3.2 Menus.............................................................................................................15
3.3 écran de Meilleur Scores...............................................................................16
3.4 écran de GAME OVER...........................................................................17
3.5 Interfaces de jeu.......................................................................................19

3
Partie 0

Introduction

Le projet

Snoopy’s Revenge est un puzzle game. Le principe très répandu à l’époque

des jeux 2D est de récupérer quatre oiseaux dans un plateau de 9x8 cases en moins
d’une minute sous peine de perdre une vie. Toutefois pour éviter que cela soit trop
simple de nombreux blocs aux effets variés vous bloquent le chemin, à cela
s’ajoute des balles qui parcourent le niveaux et retire une vie si le joueur les
touchent. Pour finir le jeux composé de trois niveaux, le joueur doit tous les
compléter les uns à la suite des autres.
Le projet est réalisés en code C++ par les étudiants ingénieurs en seconde
année du cycle préparatoire à l’ECE (École Centrale d’Électronique) de Paris,
dans le cadre du cours de programmation. Il a pour but d’initier les étudiants au
code C++ tout en leur faisant découvrir la Programmation Orientée Objet (POO).

L’équipe

Notre équipe était constituée de 2 élèves dont l’un avait déjà une bonne
expérience en C++ :
— Pierre Moreau (CP)
— Maxime Remy
Cela nous a permis de créer le squelette du projet rapidement et exhaustive-
ment avec pour ambition de programmer un jeu jouable répondant au cahier des
charges (CDC) aussi bien sur console que sur allegro.

4
Partie 1

Organisation

1.1 Planning
Le projet s’est déroulé du 02/11/15 au 01/12/15. Pierre connaissant déjà la
structure du C++ il a pu aider l’équipe en expliquant rapidement les différences
avec le code C, ce qui a considérablement avancé le début de la phase de pro-
grammation. Vous pouvez trouvez ci-dessous un diagramme de Gant pour plus de
détails.

1.2 Répartition des tâches

Le code C++ étant langage orienté objet. Il nous a été aisé de développer
un code modulaire ce qui, couplé avec les outils de versionning SourceTree et
Bitbucket, nous a permis de facilement s’organiser et de se répartir les tâches.
Pierre, qui fort de son expérience du projet précédent a pu mettre en place
rapidement les classes, le polymorphisme, et les timers. C’est donc lui qui s’est
chargé de la boucle de jeu des affichages, et des interactions avec les différents
éléments d’un jeu.
Tandis que Maxime s’est penché vers la transition de niveaux, la sauvegarde
de la progression d’un joueur dans un niveau et de tout ce qui touche au score.
Le menu a été fait ensemble avec Pierre qui s’est concentré sur l’aspect gra-
phique de celui-ci, tandis que Maxime en a implémenté les fonctions.
Pour la rédaction du rapport, nous avons utilisés un éditeur LATEX en
ligne. Cela nous permet de rédiger tous les deux en même temps, et de voir les
modifi- cations de l’autre en temps réel. Le rapport est aussi séparé en plusieurs
fichiers
de code afin d’avoir une conception modulaire offrant meilleure ergonomie.

5
Projet C++ 2015-2016 Equipe 709 : Remy & Moreau

Image 1.1 – Diagramme d’organisation

PARTIE 1. ORGANISATION 6
Partie 2

Conception

La conception que nous avons mis en place, pour le code et l’organisation

des fichiers, utilisait au maximum le principe de la DTI (Données, Traitements,
Interface). Nous avons séparé en trois parties chaque fonctionnalités. La première
partie est l’allocation, la création et la suppression des données ; puis la seconde
est la modification de ces données ; pour terminer avec l’affichage. Le langage C++
que nous avons utilisé permet vraiment de pousser cette implémentation très loin
avec des classes, l’héritage et le polymorphisme.
Nous voulions que le jeu fonctionne aussi bien en mode console qu’en mode
graphique, sans avoir à dupliquer du code. Nous nous sommes naturellement
tournés vers le polymorphisme : tous les objets affichables héritent d’une classe
DESSINABLE qui fournit une méthode virtuelle pure dessine(). C’est cette mé-
thode publique qui gère l’affichage conditionnel des éléments de la classe. Tout le
traitement des données dans la classe est conçu pour être compatible sans être
spécifique.

7
Projet C++ 2015- Equipe 709 : Remy &

2.1 Les classes

Image 2.1 – Diagramme des classes

Vecteur2D Contient des coordonnées cartésiennes entières. Elle permet d’effec-

tuer de nombreux calculs et affichages en surchargeant les opérateurs
arithmétiques et externes.

Dessinable Classe abstraite, qui ne contient que la méthode virtuelle pure

dessine(). Nous avions prévu au début l’utiliser aussi pour mettre en commun
les bibliotheques d’images et de sons pour allegro via un pointeur sur structure,
mais nous nous sommes rendus compte que cette structure serait constemment
dupliquée pour ne pas être supprimée, ce qui prendrait trop de place mémoire.
Nous

PARTIE 2. 8
Projet C++ 2015- Equipe 709 : Remy &

avions ensuite envisagé les pointeurs intelligents boost::shared_ptr mais après

de nombreuses recherches et tentatives, leur implémentation était trop complexe.

Snoopy Personnage principal du jeu, snoopy doit avoir des méthodes spéci-
fiques à ses actions.

Case Représente une case du plateau de jeu. Cette case a donc des coordonnées,
un type (les différents types sont défini par des macros dans config.h), et des
méthodes qui permettent de la déplacer, de la modifier, et de l’afficher.

Balle Afin que la balle puisse se déplacer lentement en fonction des timers, sa
position et sa vitesse sont des réels.

Plateau Encapsule les éléments du jeu : Snoopy, un tableau de case, et un ta-

bleau de balles. Cette classe coordine leur interactions. Sa fonction dessine appelle
les fonctions dessine des éléments qui la compose ; elle n’a même pas besoin de
savoir si le jeu est en graphisme ou console.

Jeu Gère la boucle de jeu. Elle encapsule donc tous les autres éléments présentés
ci-dessus, et répond des commandes de l’utilisateur.

Partie Coordonne la transition entre les niveaux, le chargement, et la sauve-

garde des parties.

Menu Cette classe morcelle le fonctionnement d’un menu selon le principe de

la DTI. Cela permet une grande liberté de fonctionnement et une implémentation
facile dans tous les contextes. Elle contient un tableau avec tous les choix
possibles, et la position du choix actuel. Il suffit d’appeler le constructeur
surchargé de menu avec le type voulu (défini en macro dans config.h) pour que le
menu se lance automatiquement.

Timer Élément principal pour le moteur de jeu. Les timers permettent de

mesurer une durée de manière unique et stable. Ils sont utilisés dans les boucles
de jeu pour mesurer le temps, ainsi que pour le moteur de jeu afin que le jeu se
déroule toujours à la même vitesse.

2.2 Graphe d’appel

Voici le graphe d’appel du constructeur de la classe menu qui est appelé dans
le main. C’est ce constructeur qui gère ensuite l’appel des autres fonctions.
Seules les fonctions globales et méthodes publiques des classes sont représen-
tées.

PARTIE 2. 9
Projet C++ 2015- Equipe 709 : Remy &

Image 2.2 – Graphe d’appel de menu

PARTIE 2. 1
Projet C++ 2015- Equipe 709 : Remy &

2.3 Analyse Chronologique et Descendante

ACD du menu

1. Initialisation des choix possibles

1. Détection du mode graphique
a. Si console affiche menu console
b. Si allegro affiche menu allegro
2. Tant que quit!=1
2. Affiche les choix
3. Affiche le curseur du choix actuellement sélectionné
4. Si appuie de la touche enter
a. Regarde choix sélectionné
i. Si nouvelle partie lancer une partie
ii. Si charger partie
1. Demande du pseudo
2. Lancement de la partie avec l’adresse du fichier déduite du pseudo
iii. Si mot de passe
1. Demande du mot de passe
2. Comparaison avec les codes du jeux
3. Si concordance lance le niveau choisit
4. Sinon revient au menu
iv. Si quittez quit=1
5. Quitte niveau

ACD de la gestion de transition des niveaux

1. Chargement du niveaux avec l’adresse du fichier passer en paramètre

a. Vérification que le fichier existe sinon renvoi message d’erreur
b. Si le fichier existe lance lance la boucle de jeu
i. la boucle se déroule
ii. Renvoi un char selon la façon du joueur pour quittez le jeux (escape,
2. Analyse le char
a. Si perdu propose de sauvegarder le score
i. Si jouer veut sauvegarder demande de saisie du pseudo
b. Si win et si il y a un niveau après lance le niveau suivant sinon propose d
3. Revient au menu

PARTIE 2. 1
Projet C++ 2015- Equipe 709 : Remy &

ACD de niveau

1. Si allegro on lance la musique

2. Initialisation des variables
3. Tant que quit!=’W’ ou ’E’ ou ’X’
a. Tant que game_time>0
i. Recuperation des touches et action selon la touche
ii. Blindage position Snoopy
iii. Déplacement balles
iv. Si la vie du joueur est en dessous de 0
1. quit=’X’
2. On affiche l’écran de game over
viii. on décrémente game_time
b. Si on change de secondes, on met à jour les compteurs et les FPS
c. On gère les collisions
d. On affiche tout
5. Si le temps est écoulé
a. On enleve une vie au joueur
6. Si tout les oiseaux sont récupérés
a. Si on est au dernier niveau
i. On affiche l’écran de victoire
b. Sinon on affiche l’écran de victoire et on passe au niveau suivant
7. Si le nombre de vie du joueur est à 0 on le remet au niveau 1
8. On s’occupe des scores
9. On arrete la musique
10. On free les variables
11. On quitte

2.4 Documentation
Nous avons généré une documentation que nous avons mis sur un serveur de
Pierre, accessible en ligne via son domaine : http : ://snoopy.photeine.com .
Il est possible de naviguer de manière interactive à travers tous les éléments
composants le projet. Pour chaque classe et fonctions, un descriptif détaillé ainsi
que des diagrammes de relations et d’appel permettent de comprendre les imbri-
cations les plus compliquées.
Nous vous encourageons vivement à aller la visiter.

PARTIE 2. 1
Projet C++ 2015- Equipe 709 : Remy &

Image 2.3 – snoopy.photeine.com : documentation exhaustive du projet

PARTIE 2. 1
Partie 3

Scénarios

Structures, defines et conception modulaire

Une conception modulaire permet de travailler efficacement en équipe sur
des fichiers différents. De plus, cela donne une meilleure clarté au code, car les
fichiers sont allégés en lignes de code.
La définition de constantes permettent d’éviter d’avoir à redéfinir le code si
l’on change des choses tel que la taille du plateaux ou le nombre de niveaux. De
plus code C++ de par son orientation objet rend aisé la création de modules avec
tout les sous-programmes nécessaire rendant ainsi le code compacte et simple à
comprendre.

Menus et paramètres
Lorsque le jeu se lance, un menu proposant au joueur d’activer le mode
graphique (allegro) ou le mode console.

Image 3.1 – menu graphisme

14
Projet C++ 2015- Equipe 709 : Remy &

Suite à cela il se retrouve sur le menu principal où il reviendra à chaque fin

de partie.

(a) menu principal allegro (b) menu principal console

Image 3.2 – Menus

C’est d’ici qu’il peux commencer une nouvelle partie, charger une partie
sauvegardé précédemment, commencer à partir d’un niveau précis, consulter les
meilleurs scores et quitter le jeu. Nous avons bien sur fait en sorte que le menu
s’adapte à la position du joueur dans la partie. Nous avons une pause qui fige le
jeu jusqu’à l’annulation de celle-ci. De plus si le joueur veut quitter la partie, il
doit simplement appuyer sur la touche escape. Il choisira à ce moment là s’il veut
sauvegarder sa partie ou non.

Charger Partie/Code
Un joueur, en sélectionnant ces options, va se voir demander soit un code
pour charger le niveau correspondant où un pseudo pour retrouver une partie
précédemment sauvegardée.
Toutefois si le code ou le pseudo ne marche pas le jeu envoi un message
d’erreur

PARTIE 3. 1
Projet C++ 2015- Equipe 709 : Remy &

High Score
L’option meilleurs score du menu permet au joueur d’afficher les 5
meilleurs score enregistrés par ordre décroissant.
Pour cela le jeu charge un fichier où tout les scores sont enregistrés avec le
pseudo associé puis les tris selon le score et enfin les affiche.

Image 3.3 – écran de Meilleur Scores

Cette fonction se met à jour dés qu’on l’appelle et de ce fait prend en compte
même les scores enregistrés pendant l’exécution du programme.

Game Over
Lorsque les vies du joueur tombent à 0, la partie se termine sur un écran de
game over : la musique ralentit rapidement en même temps que l’écran se remplit
de noir qui se renferme sur le vaisseau. Le jeu affiche à ce moment là le score du
joueur et lui demande s’il veut sauvegarder.

PARTIE 3. 1
Projet C++ 2015- Equipe 709 : Remy &

Image 3.4 – écran de GAME OVER

Musiques et effets sonores

La musique est malheureusement présente que sur la version allegro du
projet, un clip musical se joue à chaque début niveaux et se répète tant que le
joueur ne finit pas le niveaux ou meurt. L’écran de victoire dispose de son propre
clip qu’il ne joue qu’une fois.
La musique est activable ou désactivable en plein jeu avec la touche ’L’.
De plus chaque action de Snoopy à part ses déplacements est accompagnée
d’un petit effet sonore correspondant à l’action effectuée.

Temps
Le joueur doit finir le niveaux en moins de 60 secondes sous peine de perdre
une vie.
Le temps restant au joueur est indiqué dans les modes à droite du plateau.
Toutefois dans le cas d’allegro nous avons ajouté une barre de progression en
dessous qui avance au fur et à mesure que le temps passe.
Afin que le jeu se déroule toujours à la même vitesse et que le temps soit
mesuré précisément, nous avons implémenté des timers pour créer un moteur de
jeu pour allegro et pour la console.

Moteur de jeu
L’utilisation de timers permet d’avoir une vitesse d’exécution constante,
peux importe le nombre de calculs qu’il y a à faire, et sur toutes les machines.
Le fonctionnement est axé autour de cet exemple, dans lequel game_time est
une variable globale, gérée en temps que timer, qui compte le temps réel en ms
(remis à zéro chaque seconde).

PARTIE 3. 1
 Projet C++ 2015- Equipe 709 : Remy &

1 game_time=0;
2 while(!key[KEY_ESC])
3 {
4 while(game_time>0)
5 {
6 // Calculs...
7 game_time--;
8 }
9 // Affichage...
10 }

Pour cela : au début de chaque boucle le programme calcule le temps que prends
les instructions, et effectue autant de fois qu’il faut les affichages afin que le
nombre d’instructions reste constant dans une seconde. Le nombre d’affichage par
seconde n’est donc lui pas constant.
J’ai suivi pour cela le tutoriel d’Emeric POUPON, qui nous a été retransmit
par notre professeur.

Balle
Les balles sont les "ennemis" du joueur. Elles se déplacent diagonalement
dans le niveau en rebondissant sur les éléments du décor. A chaque fois qu’elles
touchent Snoopy le joueur perd une vie. De façon surprenante c’est ce qui nous a
donné le plus de mal a implémenter. Toutefois nous avons réussi la programmer
pour qu’elle fonctionnent aussi bien sur allegro que sur console.

Case
Une case représente une case du plateau de jeu. Elle peux être soit vide, soit
un bloc, soit un oiseau, soit un bonus.
Pour la gestion des cases nous avons créé une classe, et le polymorphisme.
En effet une case se traite et se comporte de la même manière sous allegro ou
sous console. Ce n’est que lors de l’affichage avec la méthode virtuelle dessine()
héritée de DESSINABLE que le traitement prendra en compte le mode de graphisme.
En effet celles-ci pouvant changer selon si le joueur les a touchées ou pas
nous devions faire pouvoir établir un programme qui peut changer leur types dy-
namiquement. La classe encapsule donc un caractère pour définir son type, et les
différents types sont définie en macros.

PARTIE 3. 1
 Projet C++ 2015- Equipe 709 : Remy &

image type fonction

bloc H bloc fixe
bloc P bloc poussable qu’une seule fois
Explose si snoopy s’y deplace. Snoopy perds alors une
bloc T
v
Snoopy peux casser ce bloc. Des bonus peuvent appa-
bloc raître
Des blocs flèches existent dans les 4 directions. Ils télé-
bloc portent snoopy vers la case pointée
peux apparaître lorsqu’un bloc est cassé. Redonne une
bonus vie à snoopy (max 5)
bonus peux apparaître lorsqu’un bloc est cassé. Ajoute 10s au
temps timer.

Tableau 3.1 – types de cases

Interface
Une procédure est spécialement dédiée à l’affichage des informations elle
détecte automatiquement si elle est en allegro (comme toutes nos fonctions d’affi-
chage) pour adapter son affichage.
Durant une partie, plusieurs informations sont affichées :

(a) interface de jeu allegro (b) interface de jeu console

Image 3.5 – Interfaces de jeu

1. titre
2. commandes principales
3. vies restantes
4. temps restant
5. points
6. variables activées (pause, invincibilité,...)
7. Courte description des objectifs (allegro uniquement)

PARTIE 3. 1
Projet C++ 2015- Equipe 709 : Remy &

Sav
e
Comme dit précédemment le joueur peut sauvegarder en cours de partie et
revenir au menu grâce à la touche S.
Quand il choisit de faire cela un menu apparaît lui demandant si il veut
vraiment sauvegarder, puis sous quelle pseudo le faire. Il faut savoir que si le jeu
n’arrive pas à sauvegarder un message d’erreur le signalant s’affiche.

Debug
Afin de pouvoir tester le jeu, il est possible de commencer directement à un
niveau,et l’on peut passer en mode invincible grâce à la touche G.

PARTIE 3. 2
Partie 4

Problèmes rencontrés

Tests Comme mentionné dans le graphique d’organisation, nous avions prévu de

finir le projet 2 semaines en avances afin de garder une semaine pour les tests.
Nous commençons en effet a avoir l’habitude, et savons qu’il y a toujours de
nombreuses corrections a faire pour des cas n’ayant pas étés prévus. Nous avons
donc fait appel aux membres de notre entourage pour tester notre programme. Il y
avait différentes catégories de tests :
— Les tests omniscients : la personne qui testait connaissait le jeu et son
fonctionnement. Ce n’étaient pas les tests les plus fructifs.
— les tests en découverte : le jeu est donné tel quel, sans explications à une
personne qui doit comprendre comment s’en servir. Cela nous a permis
d’ajouter beaucoup d’éléments dans l’interface de jeu afin de rendre plus
compréhensible son utilisation. Nous avions envoyé notre jeu à des amis
en suisse, et nous avons remarqué que allegro ne pouvait pas prendre en
compte leur clavier.
— les tests de sécurité : nous mettions notre jeu entre les mains d’une
per- sonne ayant pour but de planter le jeu. Cela nous a permis de
déceler des failles que nous n’aurions pas pu prévoir. Par exemple, si
un joueur réécrit sur les fichiers texte enregistrant les niveaux pour se
placer à des niveaux supérieur, le dernier niveau sera
automatiquement généré.

Accessibilité et Navigabilité entre objet

Le premier problème que nous avons rencontré dans le projet était d’établir
quelle méthodes appartenaient à quel objet. Par exemple le déplacement de la
balle a du être déplacé car nous nous sommes rendu compte que pour le faire
correctement la méthode devait avoir accès à la matrice pour vérifier ses
alentours.
Toutefois le problème à été vite résolu grâce à une conception faite en amont
du projet qui nous a permis de développer une ACD solide ainsi qu’un graphe de
classes. Ces deux éléments on alors permit de voir où implémenter les méthodes.

Mono-existence des ressources graphiques

Le deuxième problème venait de l’implémentation sous allegro du projet.

21
 Projet C++ 2015- Equipe 709 : Remy &

Nous voulions pouvoir avoir accès aux ressources graphiques dans chaque objet
dessinable, sans avoir à dupliquer ces ressources.
En effet, si l’on partage un pointeur vers la ressource allouée en mémoire, il
faut la dupliquer pour chaque objet afin qu’elle ne soit pas détruite en sortie de
bloc. Étant donné qu’une bibliothèque d’images et de musiques est volumineuse,
nous voulions à tout prix éviter cela.
Nous nous sommes intéressés aux pointeurs intelligents boost::shared_ptr
qui permettent de partager une ressource entre plusieurs pointeurs, et de ne la
supprimer que lorsque le dernier pointeur est supprimé. Mais implémenter cela
c’est avéré très compliqué, et nous nous sommes tournés vers la solution actuelle :
un namespace.
Le namespace BIB englobe et protège la gestion des bibliothèques. Une va-
riable externe est source d’erreurs et d’attaques de sécurité, mais ici, elle n’est
utilisable qu’en connaissant le nom du namespace. Cela a garanti une fiabilité
dans l’implémentation du code. De plus, le namespace BIB englobe les fonctions
nécessaires à la gestion mémoire des ressources graphiques.

1 /***************************************************************************//**
2 * \namespace BIB
3 * \brief Gestion des bibliotheques de sons et d’images
4 *
5 * BIB donne acces aux bibliotheques d’images et de sons,ainsi qu’a leur
6 * construction et destruction.
7 ******************************************************************************/
8 namespace BIB
9 {
10 extern bool alleg; ///< Booleen pour connaitre le mode graphique
11 extern SOUND_GALLERY* sons; ///< gallerie globale de sons
12 extern BITMAP_GALLERY* images; ///< gallerie globale d’images
13

14 /**\brief Charger tous les sons en memoire

15 * \return une structure SOUND_GALLERY chargee */
16 SOUND_GALLERY init_soundGallery();
17

18 /** \brief Charger tous les images en memoire

19 * \return une structure BITMAP_GALLERY chargee */
20 BITMAP_GALLERY init_imageGallery();
21

22 void load(BITMAP**, std::string);

23

24 /** \brief Charge en memoire toutes les ressources graphiques et sonores */

25 void initGallery();
26 /** \brief libere la memoire de toutes les ressources graphiques et sonores */
27 void freeGallery();
28 }

PARTIE 4. PROBLÈMES 2
Projet C++ 2015- Equipe 709 : Remy &

Collisions
Enfin, nous avons rencontrés rapidement un problème au niveau du système
de collision. En effet les balles doivent rebondir sur les faces et les arêtes des
blocs du plateau.
Nous avions initialement prévu un algorithme fonctionnant parfaitement
sous console, mais lorsque la balle devait être représentée par une image plus
petite qu’un bloc sous allegro, les rebonds ne s’effectuaient pas comme prévu. Il a
fallu prendre en compte la largeur de la balle, ainsi que la taille des cases dans le
calcul du déplacement afin que cela fonctionne correctement. De plus, ces
considérations ont dues être implantées intelligemment dans les calculs afin de ne
pas gêner le déplacement sous console, et que les traitements soient les mêmes.

PARTIE 4. PROBLÈMES 2
Partie 5

Conclusion

Ce projet d’informatique nous as permis de nous familiariser principalement

avec la notion d’objet en POO. Grâce aux objets, nous avons pu concevoir un code
modulaire pouvant mettre à profit un même traitement pour plusieurs rendus. Les
principes d’encapsulation et d’héritage nous ont donnés cette marge de manœuvre.
De plus, cela nous a permis de concrétiser une multitude de cours jusqu’à présent.
Ce projet nous a permis de mener à bout un vrai programme Allegro construit,
réfléchi et utile, en réutilisant nos notions de C.
Il nous a aussi permit de développer nos compétences de travail en binôme.
Nous n’avons pas rencontrés de problèmes réellement bloquants mais nous avons
du réfléchir ensemble à des solutions envisageables et pouvant être mis en œuvre
facilement. En plus, le projet étant plutôt libre, nous avons pu exercer notre créa-
tivité pour rajouter des fonctionnalités ou des éléments de gameplay.

Bilan de Maxime
C’est dans le cadre de ce projet que j’ai pu vraiment comprendre l’intérêt
d’un langage de programmation orienté objet. Il m’a aussi permis de me
familiariser avec la syntaxe et la conception du C++ qui est un langage très
nouveau pour moi. Enfin Pierre m’a introduit à la magnificence de LATEX qui
deviendra proba-
blement mon support de rapport principale.

Bilan de Pierre
J’ai poussé encore plus loin la programmation modulaire avec l’utilisation
de structures, de #define, et bien sûr d’objets, afin de coder un programme
concis, modulaire et dynamique. Avec une bonne conception, l’ajout d’une
fonctionnalité ou d’un objet se fait sans redondance de code. Même si le
programme doit pouvoir se dérouler de plusieurs manières.
J’avais appris à coder en LATEX durant mes vacances, j’ai donc pu
enfin rédiger un rapport complet avec ce langage. J’ai donc appris pleins de
nouvelles commandes et je me sens beaucoup plus à l’aise avec le LATEX
maintenant. Par exemple, je me suis rendu compte que même en LATEX, la
compilation modulaire

2
s’avère très utile.

2
Références

[1] Jean-Cédric Chappelier, Cours d’introduction à l’informatique et a la

program- mation. EPFL, 2002-2012.
[2] Documentation en C++ :
http ://www.cplusplus.com/reference/
http ://en.cppreference.com/
http ://stackoverflow.com/
[3] Documentation Allegro :
http ://liballeg.org//
[4] Sprites : http ://cdn.supersoluce.com/
http ://www.dghs.ptc.edu.tw/Picture/
[5] Outils GIT :
https ://bitbucket.org
SourceTree Atlassian
[6] Documentation Doxygen :
http ://www.stack.nl/ dimitri/doxygen
http ://franckh.developpez.com/tutoriels/outils/doxygen
[7] Documentation LATEX : http ://tex.stackexchange.com/
[8] Forum d’aide pour LATEX : http ://tex.stackexchange.com/
[9] Code source LATEX de notre rapport : https ://www.overleaf.com/read/zdxkznhnfdtf
[10] Documentation de notre projet en ligne : http ://snoopy.photeine.com/