Modifications des diagrammes UML

BERTHO David
RIGAU Jean-Louis
LO02 - Java
Java
Jeu de la vie avec des trolls
Université de Technologie de Troyes
1
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Introduction
Ce rapport présente la deuxième partie du projet de création d’un jeu de la vie qui met en
scène différents personnages qui interagissent. Il fait suite à la modélisation UML de ce
projet, et présente la partie de programmation Java, les modifications faites aux diagrammes
UML, ainsi que les difficultés et les points que nous n’avons pas pu terminer.
Modifications des diagrammes UML
Les diagrammes n’ont pas été fondamentalement modifiés, mais il y a eu de nombreuses
modifications, principalement des ajouts d’accesseurs. Nous avons aussi ajouté des variables
en rapport avec la gestion de la mort. Au début nous pensions balayer toutes les cases et
supprimer les morts mais lors des essais nous nous sommes rendus compte qu’il était possible
de se reproduire avec les morts, de les manger, et de faire n’importe quelle action avec eux.
Cela posait un léger problème de logique et d’éthique, que nous avons dû résoudre.
Classe case :
Méthodes ajoutées :
getGibierMort
ajouterGibierMort : incrémente le nombre de gibiers morts d’une case
getNaissances
ajouterNaissance : ajoute une naissance dans la liste des naissances de la case.
viderNaissances : vide la liste des naissances de la case.
toString : cette méthode permet de retourner la liste des « habitants » d’une case sous forme
de chaîne de caractères.
Classe JeuDeLaVie
Attributs ajoutés :
Longueur / largeur : taille du tableau
Nb_tours : nombre de tours de la partie, dans le cas où les tours passent tout seuls
Université de Technologie de Troyes
2
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Méthodes ajoutées :
getPlateau
tableauPlein : permet de savoir si le tableau est plein. Cela permet par exemple d’éviter
d’ajouter des gibiers quand aucune case n’est libre
determineSexe : cette méthode compte le nombre de mâles et de femelles et détermine le sexe
des futures naissances, dans le but d’équilibrer la population.
Classe Personnage
Attributs ajoutés :
type
mort : contient l’état d’un personnage
Méthodes ajoutées :
getType
setMort / getMort
getcaseCourante
Classe Reproducteur
Attributs ajoutés :
ageMax
ageReproduction
mortDeFaim
nbTourAvtRepas
nbTourAvtReproduction
Méthodes ajoutées :
getSexe
getAge
getAgeReproduction
setDerniereRelation
setDernierRepas
setRepas
Université de Technologie de Troyes
3
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Classe Humain
Méthodes ajoutées :
getPouvoir
toString
Classe Troll
Méthodes ajoutées
tuerTroll
toString
Classes Gibier et Sorcier
Méthode ajoutée :
toString
Université de Technologie de Troyes
4
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Ajout de classes
Nous n’avions pas modélisé certaines fonctions du programme dans le diagramme initial.
Nous avons créé 2 nouvelles classes : InterfaceBD qui gère la base de données, et
FenetreJeuDeLaVie qui est l’interface graphique.
Interface graphique :
L’interface montre le tableau de jeu avec le contenu de chaque case. Chaque case est un
bouton sur lequel il est possible de cliquer pour avoir des informations détaillées dans le cadre
en haut à droite. La zone de texte affiche les événements de chaque tour. Il faut cliquer sur
Tour suivant pour faire passer les tours. Enfin les options de sauvegarde et de chargement de
partie sont dans le menu Fichier.
Université de Technologie de Troyes
5
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Base de données :
--- Structure de la table `case`
-CREATE TABLE `case` (
`id_case` int(25) NOT NULL auto_increment,
`id_partie` int(25) NOT NULL default '0',
`arbre` int(1) NOT NULL default '0',
`x` int(2) NOT NULL default '0',
`y` int(2) NOT NULL default '0',
PRIMARY KEY (`id_case`)
) TYPE=MyISAM;
-- ---------------------------------------------------------- Structure de la table `partie`
-CREATE TABLE `partie` (
`id_partie` int(25) NOT NULL auto_increment,
`nom_partie` varchar(30) NOT NULL default '',
`nb_humain` int(5) NOT NULL default '0',
`nb_troll` int(5) NOT NULL default '0',
`nb_tour` int(5) NOT NULL default '0',
PRIMARY KEY (`id_partie`)
) TYPE=MyISAM;
-- ---------------------------------------------------------- Structure de la table `personnage`
-CREATE TABLE `personnage` (
`id_personnage` int(25) NOT NULL auto_increment,
`id_case` int(25) NOT NULL default '0',
`type` varchar(30) NOT NULL default '',
`sexe` int(1) default NULL,
`age` int(5) default NULL,
`derniere_relation` int(5) default NULL,
`dernier_repas` int(5) default NULL,
`repas` varchar(30) default NULL,
`pouvoir` int(2) default NULL,
`enchante` int(1) default NULL,
PRIMARY KEY (`id_personnage`)
) TYPE=MyISAM;
Université de Technologie de Troyes
6
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Actions des personnages
Nous avons défini les priorités suivantes pour les actions des personnages.
Un troll va d’abord essayer de se reproduire (cette priorité a la reproduction a pour but de
permettre aux trolls de résister plus longtemps à la domination humaine). Ensuite il va essayer
de manger un fruit, puis un gibier. Puis, si il n’a pas faim, si le troll est enchanté, il va tuer un
troll voisin, sinon il va tuer un humain voisin. Enfin si aucun autre choix n’est possible, il se
déplacera.
Un humain n’a pas la même philosophie de la vie, il ne tentera de se reproduire que si les
conditions sont favorables. L’humain ne veut pas être dérangé !
Il va donc d’abord manger si il a faim, pour reprendre des forces (en essayant d’abord de
cueillir des fruits, car c’est moins fatiguant que chasser). Puis il assurera sa sécurité en
enchantant ou en tuant un troll. Enfin, une fois les environs sécurisés, il pourra se reproduire
tranquillement.
Déroulement d’un tour
Nous avons tout d’abord tenté de créer une liste des personnages du jeu, et de parcourir cette
liste pour faire passer le tour. Cette technique a posé un problème puisque la liste était triée
par type de personnage. Tous les humains faisaient leurs actions, puis les trolls, … Je jeu
n’était donc pas équilibré puisque les humains pouvaient tuer tous les trolls qu’ils pouvaient
en premier.
Nous avons donc programmé le déroulement d’un tour de la façon suivante.
Chaque case est contenue dans une liste, et contient une liste de la population. Le jeu fait un
balayage de toutes les cases et de toutes les populations.
Université de Technologie de Troyes
7
BERTHO David
RIGAU Jean-Louis
LO02 - Java
Problèmes rencontrés
Le principal problème a été la gestion du temps. Nous ne pouvions pas vraiment commencer
le rapport final sans avoir fini le programme. Et pendant la programmation (qui s’est avérée
plutôt longue), chaque résolution de problème apportait de nouvelles erreurs. Il a donc fallu
décider de s’arrêter même si toutes les fonctions n’étaient pas implémentées et qu’il restait
des bugs.
Un premier problème non résolu est l’équilibre des forces en présence. Les humains sont bien
plus forts que les trolls, qui se font systématiquement exterminer. Nous avons essayé de
résoudre ce problème en permettant aux trolls de se reproduire plus souvent, de jeûner plus
longtemps, mais cela ne faisait que repousser leur extinction. Nous avons alors accepté le fait
que les humains soient les plus forts.
Un autre problème est apparu lorsque nous avons fait des essais sur de nombreux tours (+ de
500 tours). Après avoir exterminé les trolls, les humains étant en paix, ils décident de se
reproduire à outrance. Mais malgré l’aspect aléatoire de la reproduction, les humains du haut
du tableau se reproduisaient exponentiellement. On avait alors un attroupement sur les 3 ou 4
rangées du haut, avec plusieurs dizaines d’humains par case au bout de 1000 tours. Nous
avons alors décidé de faire naître les personnages dans une case aléatoire au lieu de la case
des parents. Cette méthode n’est pas vraiment logique mais nous a permis d’avoir un tableau
équilibré.
Il y a aussi eu un problème dans le remplacement des gibiers morts. Si les personnages sont
en période de forte reproduction, la population totale peut augmenter sensiblement. Toutes les
cases sont alors occupées. Dans nos premières versions, ce cas de figure faisait planter le jeu
car il fallait ajouter les gibiers mais il n’y avait plus de case libre. Nous avons alors ajouté un
test qui vérifie ne place des gibiers que si il reste de la place pour eux. Cela permet aussi de
réguler la population : sans assez de nourriture, les personnages meurent de faim, et des places
se créent.
Nous avons également eu des problèmes lors de la programmation de l’interface avec la base
de données. Nous l’avons programmée pour qu’elle récupère les paramètres de connexions,
mais ça n’a pas marché. Nous n’avons pas réécrit cette classe en codant les paramètres en dur
car nous n’avions plus le temps de réfléchir aux requêtes, à la façon de récupérer les données
à sauvegarder, …
Université de Technologie de Troyes
8
BERTHO David
RIGAU Jean-Louis
LO02 - Java
De nombreux problèmes ont ensuite suivi lors de la programmation de l’interface graphique.
Tout d’abord le bouton lancement fait « planter » le programme. Nous avons pensé qu’il
aurait fallu utiliser des processus pour afficher le résultat et faire passer les tours en même
temps, mais nous n’avons pas pu trouver de solution par manque de temps. Nous avons donc
supprimé ce bouton.
Seule le mode manuel est donc accessible en graphique, le mode automatique étant accessible
en console en précisant le nombre de tours à effectuer.
Conclusion
Ce projet nous a permis de nous plonger plus en profondeur dans Java et la programmation
objet. Nous nous somme aperçu que Java est un langage qui offre de nombreuse possibilités,
et que des fonctions avancées comme la gestion des bases de données ou des interfaces
graphique sont relativement accessibles (après un léger effort de documentation).
Il a également mis en évidence l’intérêt de la modélisation UML. Touts les problèmes
auxquels nous avons pensé ne sont pas apparus pendant la programmation, et cela nous a fait
gagner un temps énorme. Faire face à certains problèmes que nous avons réglé plus tôt grâce à
la modélisation aurait impliqué de modifier en profondeur le code. Et il faut avouer qu’il est
plus simple de modifier le code en profondeur quand le code en question se limite à des
schémas.
Université de Technologie de Troyes
9