Le rapport - Julien Canovas

Réalisation d'un jeu de
simulation de vie d'un
petit animal
(Tamagotchi)
Modélisation Objet
Projet disponible sur SourceForge
Plagnard jean mathieu
Kajjoua Khalid
Lafage Laury
Canovas Julien
Mohamadou Niang
Haouas Adil
SOMMAIRE
Equipe projet..................................................................................................... 4
Cahier des Charges ..........................................................................................4
contexte et objectifs........................................................................................................ 4
Choix d'implementation............................................................................................... 4
Ressources et outils........................................................................................................5
Fonctionnalités du Tamagotchi....................................................................................6
Méthode de développement........................................................................... 7
Style de programmation............................................................................................... 7
Règles de documentation..............................................................................................7
Gestion des versions...................................................................................................... 7
Compilation.................................................................................................................... 7
Protocoles de Tests.........................................................................................................8
Organisation de l'équipe projet...................................................................... 9
Spécifications techniques...............................................................................10
Diagramme UML (diagramme de classe)................................................................ 10
Le Jeu..............................................................................................................................12
Temps.............................................................................................................................12
Le Tamagotchi.............................................................................................................. 13
L'environnement.......................................................................................................... 13
Gestion des sauvegardes.............................................................................................15
Interface graphique......................................................................................................15
2
Interface Generique (Classe abstraite).............................................................................................................................15
Interface GTK...................................................................................................................................................................... 16
Gestionnaire de nourritures....................................................................................... 17
Compilation / Makefile............................................................................................... 17
Rapport des tests.............................................................................................18
3
EQUIPE PROJET
➢
Plagnard jean mathieu
➢
Kajjoua Khalid
➢
Lafage Laury
➢
Canovas Julien
➢
Mohamadou Niang
➢
Haouas Adil
=> Chef de projet
CAHIER DES CHARGES
CONTEXTE ET OBJECTIFS
Le projet consiste au développement d’un jeu qui simule la vie d'un petit animal virtuel
(Tamagotchi). L'utilsateur devra s'occuper régulierement de lui pour qu'il survive dans de
bonnes conditions. Il pourra communiquer avec lui et intervenir sur son environnement.
Notre projet sera autant que possible orienté objet afin de rendre son adaptation et évolution la
plus efficace possible.
Dans le cadre d'un projet universitaire le projet sera open source, et tous les outils de
développements utilisés seront également libres.
CHOIX D'IMPLEMENTATION
Le projet sera implémenté en C++, utilisant ses capacités orientés objets et l'héritage.
L'interface Graphique utilisera la bibliothèques GTK+.
4
RESSOURCES ET OUTILS
Les outils necessaire pour le développement du projet seront :
-
Editeur de texte (ou IDE)
-
Compilateur c++
-
Editeur de lien
-
Serveur de gestion de versions partagé
-
Générateur de documentation
Outils proposés à l'équipe projet :
●
CodeBlocks IDE
●
Compilateur g++
●
Doxygene
Ressources de l'équipe projet,
- Plateforme Sourceforge intégrant (https://sourceforge.net/projects/calculette/)
●
Serveur CVS
●
Partage de fichiers
●
Forum de discussion
- Plateforme de type PhpCollab afin de compléter les besoins non fournis par sourceforge :
●
Suivi de l'avancement du projet
●
Gestion / Répartition des taches
●
Plannifcation des taches
Le projet etant développé en C++, cela permet une très grande interaction possible du fait qu’il
soit très répandu et que la plupart des systèmes existant disposent d’un compilateur C++. Le
choix pourra donc etre laissé à l'equipe projet de ses outils complémentaires notament les choix
de son environnement de développement.
5
FONCTIONNALITÉS DU TAMAGOTCHI
●
Interface Graphique de type « fenetre graphique »
○
●
Sauvegarde / Chargement d'une partie
●
Choix du Tamagotchi :
○
Nom
○
Espèce (chien, chat, monstre, ...)
●
Deplacement du Tamagotchi dans plusieurs environnements (ex: jardin, chambre)
●
Interaction avec l'utilisateur :
●
6
indépendante du reste du Jeu (ou au moins modulaire)
○
Manger
○
Soigner
○
Divertir
○
Récompenser
○
Punir
○
Faire Dormir
Gestion des nourritures disponibles
MÉTHODE DE DÉVELOPPEMENT
STYLE DE PROGRAMMATION
La charte de programmation choisie est celle de « Applied Informatics »
http://www.appinf.com/download/CppCodingStyleGuide.pdf, à laquelle nous avons apportés
des modifications. Afin de rester clair et de gagner du temps nous ne citerons que les
modifications par rapport à la charte d'origine :
Rule 4
Les noms de fichiers essayerons d'être aussi représentatifs du contenu que possible, ils seront
écris exclusivement en lettres minuscules non accentuées et en français.
Rule 13
Tous les commentaires seront écrits en Français.
La « Rule 19 » sera ignorée.
Les commentaires et documentations sur les fonctions et classes seront définis juste avant leurs
déclarations afin d'être identifiables par Doxygen.
Tous les fichiers sources sont au format UTF-8 pour le codage des caractères.
RÈGLES DE DOCUMENTATION
Doxygene sera et devra être utilisé pour la rédaction de la documentation technique, ainsi
chaque développeur aura à sa charge de rédiger les commentaires de chaucun de ses fichiers, de
chacune des ses classes, et de chacune de ses fonctions protected ou public afin de permettre la
génération de la documentation.
GESTION DES VERSIONS
Le serveur CVS devra être utilisé par chaque développeur ;
Au minimum chaque développeur devra synchroniser son travail chaque fois qu'il fini une
journée de développement.
COMPILATION
Toute compilation devra utilisé un fichier makefile.
Un makefile en accord avec le Modèle UML sera ecrit et disponible pour chacun dès le debut
7
Un autre makefile dédié aux tests en développement permettra à chacun de ne compiler que sa
partie avec un « main » et une interface simplifié (console) qui lui est spécifique.
PROTOCOLES DE TESTS
Chaque membre de l'équipe aura à sa charge un premier test de sa partie sur une application de
test utilisant une interface simplifiée et des interaction possible minimales definis au debut du
projet utilisant un makefile specifique.
Dans un deuxieme temps chaque membre du projet devra tester les cas limites de 2 autres
membres. Par conséquent chaque membre sera aussi tester par 2 membres différents. Les tests
seront limités aux fonctions publiques du « module » à tester en leur donnant des valeurs de
parametres limites.
Enfin le Chef de Projet aura pour rôle la compilation et l'intégration complète des différents
modules afin de pouvoir tester le Jeu en conditions réelles.
Pour être considéré conforme le Jeu devra :
–
Être compilable à partir du makefile sur Achille & Zenon
–
Se lancer sur les 2 systemes Unix d'Agroparc
–
8
–
Achille & Zenon
–
Ubuntu
Avoir un affichage coérant durant au moins 15 minutes.
ORGANISATION DE L'ÉQUIPE PROJET
Chaque membre aura à sa charge le développement d'un module correspondant à un ensemble
de classes en accord avec le diagramme UML.
●
Jean-Mathieu Plagnard (Chef de projet)
Développement du Jeu lui meme, c'est à dire la coordinations de ses différents modules,
Développement de l'Interface graphique générique (classe abstraite) et de ses
fonctionnalités.
●
Khalid Kajjoua
Développement du module Tamagotchi, incluant sont état, ses caractéristiques, ...
●
Laury Lafage
Développement du module Environnement, incluant la gestion de la méteo, des différent
endroit accessibles aux Tamagotchi, ...
●
Julien Canovas
Développement de l'interface graphique GTK.
●
Mohamadou Niang
Developpement du Gestionnaire de sauvegarde et de la gestion du temps.
●
Adil Haouas
Développement du gestionnaire de nourriture.
9
SPÉCIFICATIONS TECHNIQUES
DIAGRAMME UML
(DIAGRAMME DE CLASSE)
(Diagramme réalisé au début du projet afin d'avoir un plan de développement et de découper le
projet en différents module attribué à chaque acteurs du projet)
Afin de simplifier le diagramme seules quelques fonctions membres et attributs interressants
seront indiqués .
(Le diagramme de référence de l'équipe projet est en image externe à ce document au format
Gif)
10
11
LE JEU
But:
Coordonnées les différents modules du Jeu. Faire le lien avec l'interface graphique.
Le pricipal rôle est en fonctions des actions utilisateurs ou de la temporisation d'appeller les
bonnes fonctions des modules puis de mettre à jour l'interface. Donc un rôle de communication.
Pour le developpeur:
L'ajout d'un nouveau module devra donc faire l'objet d'une mise à jour de la classe Jeu.
TEMPS
Temporisation:
une temporisation de type « signal » est utilisé lors d'une session de Jeu.
Ayant pour but principal la mise à jour des caracteristiques du tamagotchi.
Le temps entre 2 tempos est parametrable.
But de la classe Temps:
(Different de la Temporisation)
Nous avons voulu une gestion du temps « asynchrone »
La classe temps à pour 1ere rôle de tranformer le temps réel en « temps Tamagotchi » par un
calcul de reduction mettant en jeu un coefficiant parametrable
(ainsi par defaut 1seconde de Jeu correspond à 1h de vie du Tamagotchi)
Son 2eme rôle est la gestion asynchrone du tamagotchi (lorsque que l'application est fermé) par
calcul encore une fois :
Le principe est de calculer le temps effectivement ecoulé entre 2 sessions ou 2 appels à la
fonction principale de la classe Temps afin de déterminer l'etat du Tamagotchi courant
(implique la sauvegarde de l'etat du Temps dans un fichier).
Ainsi le Jeu est capable de savoir combien de mise à jour il doit faire simulant ainsi le fait que le
Tamagotchi continu à vivre lorque le jeu est arrété. (Aucun « processus de fond » n'est
necessaire)
12
LE TAMAGOTCHI
But:
Cette partie a pour but de gérer les caractéristiques de l'animal, de les modifiers par rapport à
ses actions et de retourner des valeurs qui représentent ses états.
Actions, caractéristiques et Etats:
Un Tamagotchi possède des actions: manger, dormir, etc... Ces actions influent sur ses
caractéristiques, par exemple si le Tamagotchi mange, alors sa faim diminura, mais au fur et à
mesure du temps, elle augmentera et si le Tamagotchi a trop faim, son poids baissera, par
contre si on lui donne trop à manger, il grossira.
Un Tamagotchi possède aussi des états, un état psychologique et un état physique, chaqu'un de
ses états se basent sur ses caractéristiques, par exemple l'état physique dépend de sa faim et son
énergie, si les deux sont à leur maximum, alors le Tamagotchi est en pleine forme physique
sinon, par rapport à ses caractéristiques, d'autres états seront donné.
Intérêt pour le développeur (Polymorphisme):
Nous avons créé une classe T_monstre qui hérite de la classe Tamagotchi pour donner un
exemple d'animal. Un développeur peut créer de nouveaux animaux qui hériteront eux aussi de
la classe Tamagotchi et qui pourront définir leur propres actions et autres fonctions.
Par exemple on pourrait créer l'animal cheval qui hériterait des fonctions de la classe
Tamagotchi et qui devra implémenter les fonctions GetType() qui retournera le type de l'animal,
c'est à dire « cheval » et ainsi on pourra récupérer dans le dossier cheval, les images de l'animal
que l'on affichera sur l'interface. Il devra aussi implémenter la fonction Envie() qui devra
retourner vrai si le cheval est en vie par rapport à ses caractéristiques et faux sinon. Mais il
pourra aussi implémenter de nouvelles fonctions propre au cheval ou redéfinir les existantes.
Pour l'utilisateur, cela lui permettra au début du jeu de choisir son animal parmis tout ceux
proposés et implémentés. Ils auront donc chaqu'un, un comportement différent, un aspect
graphique différent et des actions différentes.
L'ENVIRONNEMENT
But:
Cette partie a pour but de géré l'environnement du jeu. L'environnement représente les lieux ou
l'animal peut se déplacer et l'aspect météorologique.
Aspect météorologique:
13
La météo, la température et la durée du luminosité dans la journée varie selon la saison.
-La météo varie entre SOLEIL, PLUIE, NUAGEUX, NIEGE et VENT. Elle change tous les jours
aléatoirement selon la saison.
exemple : En été il y aura plus de probabilité qu'il fasse SOLEIL qu'en hiver et il ne pourra pas
neiger en été.
-La température varie selon l'heure, c'est à dire le matin, l'après midi et le soir la température
sera différente. On aura une température maximum et minimum dans la journée selon la météo
et selon la saison.
-La luminosité dans la journée variera selon la saison.
Exemple : En été il fera jour plus longtemps qu'en hiver.
-La saison est donnée par la date.
Comment utiliser cette fonctionnalité :
-Le jeu demandera au module de mettre à jour les informations sur la météorologie (météo,
température, saison ect...) selon la date donnée en paramètre.
Exemple :
Date d;
//27 janvier à 2heure du matin
d.heure = 2;
d.mois = 1;
d.jour = 27;
GestionEnvironnement* E = new GestionEnvironnement(d);
d.heure = 12;
E->MiseAJour(d);
Les lieux :
L'animal pourra se déplacer dans différents lieu (jardin,salon,cuisine...). On ne pourra se
déplacer d'un lieux à un autre que si les deux lieux sont reliés.
Par exemple le jardin est relié au salon, l'animal, étant dans le jardin, ne pourra pas aller à la
cuisine. Il faudra d'abord qu'il passe par le salon.
14
Chaque lieux sera associé a des actions possible de faire avec l'animal.
Par exemple l'action manger sera activé que si l'animal est dans la cuisine.
Comment utiliser ces fonctionnalités :
-Le jeu demandera quelle action l'animal peut effectuer dans l'environnement où il est avec la
fonction int* ActionPossible(); cette fonction renvoie un tableau de int représentant les actions
possibles de l'animal
-Le jeu demandera quelles sont les lieux où l'animal peut effectuer un prochain déplacement.
Ceci se fera avec la fonction int* DeplacementPossible(); cette fonction renvoie un tableau de int
représentant les déplacement possibles de l'animal par rapport au lieux dans lequel il est.
GESTION DES SAUVEGARDES
Sauvegardes effectué dans un fichier, sauvegardant l'ensembles des attributs representant le jeu
(caracterisique du Tamagotchi, dernier temps connu, nom, ...)
INTERFACE GRAPHIQUE
INTERFACE GENERIQUE (CLASSE ABSTRAITE)
nous avons voulu une interface graphique le plus indépendante possible du reste du Jeu afin de
pouvoir etre adpaté à tout types de systemes.
Nous avons pour cela utilisé les capacités de l'héritage en créeant une classe generique
d'interface laissant au developpeur de l'interface graphique le choix du type d'interface.
Permettant aussi durant les phases de test d'utiliser une interface de type texte (mode console)
Ici nous avons toutes les fonctions abstaites qui doivent etre redefinis par les classes dérivées
void demarrer();
void arreter();
void aff_position(int);
void aff_humeur(int); //Modifie l’humeur courante du Tama.
void aff_meteo(int); //Modifie météo courante.
void aff_saison(int); //Modifie saison courante.
void aff_sexe(bool); //Modifie sexe courante.
15
void aff_phrase(char*); //Modifie la phrase que Tama dit.
/* Affichage des caracteristiques publiques du Tama*/
void aff_niv_vie(int);
void aff_niv_faim(int);
void aff_niv_sante(int);
void aff_niv_divert(int);
void aff_niv_prop(int);
void aff_niv_joie(int);
INTERFACE GTK
Cette interface graphique est codée en GTK2+/C++.Elle peut etre totalement remplacer pour une
autre sans que le programme principal en soit affecter. Du moment bien evidement que les
fonctions de la classe abstraite sont respectés.
Utilisation des objets GTK:
Interface_gtk.h
//Widget statiques
static GtkWidget *text_view;
static GtkWidget *_fenetre;
static GtkWidget *ptext_base;
static GtkWidget *pNom;
static GtkWidget *pSexe;
Les widget statiques permettent des crée des objets qui seront accesibles de toute les fonctions.
Ceci était nescessaire par exemple pour la fenetre « pop-up » que création d’un nouveau Tama.
_fenetre est l’objet qui deviens la fenetre principale.
pNom et pSexe sont respectivement les objets qui contiennent le nom et le sexe du Tama, pour
l’afficher plus tard.
16
Ici nous avons les fonction CALLBACK qui permette de rendre l’interface « réactive » a e que
fait l’utilisateur, ce sont les différentes fonction appeles en cas de clic sur un boutton.
/* Prototype des fonctions CallBack pour GTK */
void on_quit (GtkWidget *, gpointer);
Fonction qui permet de quitter le programme (manière « brute »)
void on_action_X (GtkWidget *, gpointer);
Fonctions qui permettent de gerer les differentes actions liées aux boutton
void saisie(GtkButton *);
void on_save(GtkWidget *, gpointer);
fonction qui permet de sauvergarder un Tama existant
GESTIONNAIRE DE NOURRITURES
But:
Cette partie a pour but de gérer la nourriture qui peut être mangé par l'animal.
Utilisation:
Le développeur peut implémenter différents gestionnaire de nourriture par rapport à chaque
lieu où se trouve l'animal. Par exemple, il peut y avoir un frigo dans la cuisine.
L'utilisateur peut choisir quelle nourriture l'animal doit manger, la nourriture étant une classe
abstraite dont croquettes, paté, etc... héritent. Après avoir choisi, l'élément est retiré du
gestionnaire. Au début de chaque mois, les gestionnaire de nourriture sont remplis à leur
maximum.
Le développeur peut créer de nouveaux gestionnaire de nourriture mais aussi de nouvelles
nourritures.
COMPILATION / MAKEFILE
La compilation utilisera exclusivement un makefile. Afin de rendre la compilation
simple pour les phases de developpement, test et finales.
Il permettra de compiler l'intégralité du Jeu.
17
Ou de compiler des modules indépendants réservé aux phases de tests
exemple :
>make test_env
>make test_tama
>make interface_simp
RAPPORT DES TESTS
Test ok sur :
✔
Achille
✔
Zenon
✔
Ubuntu
✔
Windows+cygwin (instable)
✗
Windows(98, Vista) (non testé)
reste à faire :
intégrer gestion nourriture au jeu et à l'interface graphique
intégrer l'ensemble des actions possibles sur l'interface graphique
ajouter des images differentes pour chaques « postures » et actions
ajuster les parametres et caracteristiques du tamagotchi afin d'avoir un comportement le plus
realiste possible
18