Fichier PDF

Partagez, hébergez et archivez facilement vos documents au format PDF

Partager un fichier Mes fichiers Boite à outils PDF Recherche Aide Contact



Rapport Tour Infernale .pdf



Nom original: Rapport_Tour_Infernale.pdf

Ce document au format PDF 1.5 a été généré par TeX / MiKTeX pdfTeX-1.40.14, et a été envoyé sur fichier-pdf.fr le 30/12/2016 à 14:31, depuis l'adresse IP 2.11.x.x. La présente page de téléchargement du fichier a été vue 209 fois.
Taille du document: 436 Ko (15 pages).
Confidentialité: fichier public




Télécharger le fichier (PDF)









Aperçu du document


Ensta Bretagne
2, rue François Verny
29806 Brest cedex
France
Tel +33 (0)2 98 34 88 00
www.ensta-bretagne.fr

16 mars 2015

Groupe 3 Projet Java : Jeu de
La Tour Infernale

Arnaud DRAPIER

Marc MULLER

Sommaire
Analyse du problème et but
Règles du jeu . . . . . . . .
Analyse du problème . . . .
But du projet . . . . . . . .
Compilation du code . . . .

du projet
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .

Analyse des classes
suivie
Classe Case . . . .
Classe Damier . . .
Classe Joueur . . .
Classe Simulation .
Classe IA . . . . .
Interface graphique
Classe Case .
Classe Damier
Classe Fenetre

.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

2
2
2
3
3

pas à pas et explication de la démarche
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

Conclusion, Résultat obtenus

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

4
4
4
5
5
6
7
7
7
7
9

1

Analyse du problème et but du
projet
Règles du jeu
Règle du jeu de la tour infernale :
Le jeu oppose deux joueurs et se déroule sur une grille. Chaque joueur
dispose d’une tour. Il peut exister deux modes ; un mode solo (humain plus intelligence artificielle) et un mode multi-joueurs (plusieurs humains). À chaque
tour de jeu, le joueur choisit une case à interdire sur le Damier, puis déplace
sa tour d’une case selon l’une des quatre directions principales (haut, bas,
droite, gauche). Lorsqu’une tour ne peut plus bouger, le joueur à qui appartient la tour bloquée a perdu la partie.

Analyse du problème
Les principale difficulté du projet vont être d’une part de mettre en place
les différents objets du jeu et les liens qui permettent à ces objets dinteragir
entre eux, d’autre part de réaliser une intelligence artificielle. L’étape de la
mise en place de l’intelligence artificielle sera la plus difficile. Elle se basera
sur la construction de deux arbres : un pour le choix du coup offensif (blocage
d’une des cases du Damier), et un pour le choix du coup défensif (déplacement
de la Tour IA sur le Damier). Une autre difficulté est de créer une interaction
judicieuse entre l’humain et la machine (instructions claires, exécution des
instructions, résultats souhaité). Nous souhaitons une réponse pas à pas du
programme sur l’évolution du jeu. Dans la deuxième partie du projet, nous
mettrons en place une interface graphique avec Swing.
Cette seconde partie est également délicate car il faut insérer de manière
judicieuse les éléments de l’interface graphique et les éléments du programme
déjà constitué.

2

But du projet
Le but du projet est de mettre en oeuvre ce que nous avons appris lors du
module JAVA dispensé à L’ENSTA Bretagne au cours des deux semestres.
Plusieurs notions doivent être incorporées telles l’utilisation de l’héritage (la
classe IA héritera de la classe Joueur dans notre projet), l’utilisation de listes
(utilisation d’arbres dans notre cas), polymorphisme etc. De plus, ce projet
permet et demande un certain travail d’équipe nécessaire à l’aboutissement
de ce dernier. Ce projet, ludique, est particulièrement intéressant dans le
sens où il demande une très bonne organisation et une réflexion simple et
structurée pour son élaboration.

Compilation du code
Le code fourni avec ce rapport est divisé en deux parties ; le code relatif
au code du jeu-lui-même est situé dans le fichier TourInfernale. c’est le code
dépourvu de l’interface graphique. Le code relatif à l’IHM est situé dans le
dossier Jeu_IHM. Ce code reprend les classes de TourInfernale nécessaires
au fonctionnement de l’interface graphique, et inclut la classe Fenetre de
l’interface graphique 1 .

1. Il y de grandes chances que le jeu via l’interface graphique ne fonctionne pas...

3

Analyse des classes pas à pas et
explication de la démarche
suivie
Classe Case
L’idée est de créer un Damier de cases qui posséderont différentes caractéristiques : 0 si la case est vide, 1 si la case est grisée (bloquée), 3 si la
case est occupée par une Tour (joueur ou IA). Les cases bonus auront la
caractéristique 2. Nous avons voulu que la case obtienne sa caractéristique
de manière aléatoire et que des cases grisées et bonus soient installées dès le
début de partie. Toutefois nous souhaitons une prépondérance de cases vides
par rapport au nombre de cases grisées ou encore bonus.

Classe Damier
Le Damier va représenter le plateau de jeu sur lequel vont évoluer les
deux Tours. C’est en fait un tableau double d’objet de la classe Case. Les
dimensions du damier seront demandées au joueur en début de la partie. A la
fin de la classe Damier, la méthode getCaractCase() nous permet d’obtenir
la caractéristique d’une des cases du tableau, ce qui nous sera fort utile par
la suite notamment pour la réalisation de l’intelligence artificielle.
Nous avons introduit une subtilité dans la taille du damier. Pour plus de
facilité dans la manipulation du damier ainsi que pour simplifier l’écriture de
l’intelligence artificielle nous avons préférer griser (bloquer) toutes les « cases
bordures »de ce celui-ci. En conséquence, il a fallu augmenter la taille de 4
et la caractéristique des cases contours est donc égale à 1. Nous avons par la
suite enlevé les bordures du damier. Le size+4 nous permet ainsi de garder la
taille demandée par le joueur en début de partie. La méthode getCaractCase()
permet d’obtenir la carcatéristique de n’importe quelle case du damier.
4

p u b l i c Damier ( i n t s i z e ){ // c o n s t r u c t e u r du damier
t h i s . s i z e= s i z e ;
tab = new Case [ s i z e + 4 ] [ s i z e + 4 ] ;
// on c r é e un damier de c a s e s i z e +4
pour g a r d e r l a bonne t a i l l e
f o r ( i n t i =0; i <s i z e +4; i ++){
f o r ( i n t j =0; j <s i z e +4; j ++){
Case o b j=new Case ( i , j ) ;
tab [ i ] [ j ]= o b j ;
// on donne à chaque c a s e une abs
e t une ord en r e l a t i o n avec l e t a b l e a u
}

Classe Joueur
Cette classe permet de définir différentes méthodes telles que le déplacement des joueurs, la méthode qui permet de bloquer une case. On y trouve
aussi une fonction qui vérifie la capacité des joueurs à se déplacer verifMouv()
(si la tour du joueur n’est pas encerclé le jeu continue) ce qui permet la fin
de partie dans le cas contraire. La classe IA va hériter de cette classe Joueur.
Le joueur est repéré sur le damier par son abscisse et son ordonnée. La méthode placerDebut() permet de placer de manière aléatoire le joueur (humain
et IA) sur le damier en début de partie. Chaque case occupée par une tour
prend comme caractéristique 3. Cette classe contient également les méthodes
dinteraction entre le joueur et la machine. Le joueur humain répondra aux
questions : « Quelle case du damier souhaitez vous grisée ? « Dans quelle direction voulez-vous vous déplacez ? »Les demandes du joueur humain seront
exécutées par cette classe.

Classe Simulation
C’est la classe qu’il faut compiler pour obtenir le fonctionnement du jeu.
C’est dans cette classe que se trouve le squelette du Jeu. Un jeu de boucles
While permet son fonctionnement en regardant notamment le résultat de
variables booléennes misent en place dans la classe Damier et Joueur.
5

La classe Scanner de l’API Java nous permet d’établir un lien entre l’humain et la machine. Ce dernier rentre une valeur au clavier qui est récupérée
par le Scanner et exploitée. Les différentes classe y sont mises en relation. Le
plus important est de bien structurer les étapes pour ne pas avoir de souci
dans la compilation des boucles.
Afin que le joueur suive au mieux ce qui se passe dans le jeu, la classe
Simulation fait apparaître plusieurs fois le Damier au cour d’un « round ».
La classe vérifie à chaque tours les possibilités de mouvement L’IA ainsi que
du joueur et permet ou non la poursuite du jeu.

Classe IA
C’est la classe la plus intéressante de notre projet. L’idée principale est de
donner à chaque case un « potentiel ». C’est une valeur attribuée en fonction
du nombre de cases bloquées encadrant la case à qui ont veut affecter un
potentiel suivant les directions nord, sud, est et ouest. Exemple : Une case à
ses voisines Nord et Est grisées, elle a donc un potentiel de 2.
Pour griser une case, l’IA regardera le potentiel des cases entourant la
Tour humain et grisera celle qui aura le plus faible potentiel. Si plusieurs
cases ont le même potentiel la case à griser sera choisit au hasard.
Pour le déplacement de la Tour IA il en sera de même, la case « idéale »pour
un déplacement sera celle ayant le potentiel le plus faible parmi les cases voisines de la Tour IA.
On peut également ajouter la notion de « niveau »au potentiel, c’est à
dire que l’on pourra regarder un peu plus loin que les cases jouxtant la Tour.
L’idée au départ était de créer deux arbres. Un pour le blocage de la case,
un autre pour le déplacement. Toutefois nous un seul arbre est finalement nécessaire à pour la réalisation de l’IA, c’est à dire pour réaliser le déplacement
de l’ia et pour griser une case.
Dans un noeud est stocké l’abscisse et l’ordonnée d’une case ainsi que la
valeur de son potentiel. Dans ces arbres chaque noeud aura 4 descendants (fils
Nord, Sud, Est, Ouest) ainsi que leurs caractéristiques respectives servant de
base au calcul du potentiel.
Le choix de griser deux niveaux de cases au niveau des bords du Damier
s’est révélé nécessaire au moment de la construction de la classe Simulation. En effet le calcul du potentiel sur « les bords »du Damier nécessite la
caractéristique des cases voisines jusqu’au deuxième rang.

6

Interface graphique
Pour l’interface graphique, nous avons fait le choix de créer une IHM
indépendante, dans un premier temps, du code de jeu (classe Simulation).
Cependant, à ce jour, le lien avec le code de jeu n’est pas encore complet, et
il reste ainsi des bugs lors du lancement du jeu complet.
Les classes Case et Damier ont été modifiées. Seule une nouvelle classe
Fenetre a été crée, qui intègre tous les détails de l’IHM. L’interface graphique
affiche le damier de jeu entouré des boutons nécessaires au déplacement et
au choix des cases à griser.
Si le main Jeu() dans la classe Jeu ne fonctionne pas correctement, lancer
le main de la classe Fenêtre pour avoir un aperçu du résultat escompté.

Classe Case
La classe Case hérite désormais de JButton. Elle inclut ainsi les caractéristiques des bouttons de Java tout en conservant celles qui définissent les
cases (leurs caractère associé entre autres). C’est également dans cette classe
que l’apparence des cases a été définie. Les cases grisées sont de couleur bleu
foncé, la case Joueur de couleur rouge, la case IA de couleur orange, et le
reste des cases vides de couleur bleu clair.

Classe Damier
La classe Damier, nommée Panel dans le code joint, hérite, comme son
nom l’indique, de JPanel. C’est le damier de jeu. Elle est donc sensiblement
différente de la classe Damier initiale, car elle construit un damier de bouttons
Case. Elle a également la particularité de créer un damier de taille voulue,
ce qui est utile dans le cas où le joueur souhaite agrandir damier de jeu, et
ainsi augmenter la durée du jeu. Comme décrit précédemment, le damier crée
inclut un contour de cases grisées, qu’il n’a pas été possible de cacher dans
l’interface graphique.

Classe Fenetre
La classe Fenetre est le coeur de l’interface graphique. Elle hérite d’un
JFrame, lui-même divisé, grâce à un BorderLayout, en 5 JPanels différents.
Le Panel central est le damier. Sa taille par défaut 2 est 10 x 10. Le bordereau supérieur, qui n’est autre que le JPanel supérieur, inclut un JSpinner,
2. La taille du damier est modifiable jusqu’à une taille de 20 x 20.

7

permettant de modifier la taille du damier, ainsi qu’un bouton Jouer, qui
initialise le Jeu en plaçant le joueur et l’IA aléatoirement sur le damier.
La fenêtre inclut également les boutons de déplacement et de choix de
case à griser. Nous avons en effet fait le choix de ne pas se servir des clics de
souris dans notre interface 3 . Les boutons de déplacement, qui se présentent
comme une croix (haut, bas, droite, gauche), sont placés sur le JPanel de
droite. Le choix des cases à griser s’effectue en choisissant les abscisses et les
ordonnées de ces dernières par l’intermédiaire de deux JSpinner.
Le JPanel du bas contient un JLabel qui affiche les instructions ainsi qu’un
bouton de fin de partie, qui quitte simplement le jeu et ferme la fenêtre.

3. Et cela à regret, car il aurait certainement été plus simple d’exploiter les JButton...

8

Conclusion, Résultat obtenus
La compilation fonctionne et ne plante pas mais nous obtenons un résultat
assez capricieux concernant l’IA. L’IA se déplace comme attendu mais réalise
parfois des « sauts »sur le damier quand elle est entourée de cases grisées. Ce
qui rend le jeu plus difficile. Le grisement de case fonctionne également mais
la case à l’Est du joueur qui est grisée de manière récurrente.
La partie est décomposée en Rounds. On obtient bien un retour « partie
terminée »lorsque que la tour du joueur est complètement bloquée. Le jeu
s’arrête toutefois au bon moment, c’est à dire quand l’une des tours est
encerclée.
Il faut faire attention à la lecture de l’abscisse sur le Damier (ordonnée
usuelle descendante ) et de l’ordonnée ( abscisse usuelle ascendante). C’est
en fait une lecture matricielle
NB : il arrive qu’une première compilation donne en résultat où l’une des
deux Tours est dès le départ bloquée par des cases grisées car la répartition
se fait de manière aléatoire.
Concernant l’interface graphique, le fait que nous n’ayons pas réussi à
lier parfaitement l’interface graphique au code est décevant ; cependant, l’interface graphique proposée est potentiellement exploitable sous la condition
que la classe Jeu arrive correctement à faire le lien avec la classe Fenetre. Ce
point nécessite une amélioration.

9

Figure 1 – Résultats obtenu 1

10

Figure 2 – Résultats obtenu 2

11

Figure 3 – Résultats obtenu 3

12

Figure 4 – Diagramme de classe

13

Figure 5 – Interface graphique

Figure 6 – Interface graphique après lancement

14


Documents similaires


Fichier PDF rapport tour infernale
Fichier PDF posterdemerde
Fichier PDF formulaire tzr02 2016 avec texte
Fichier PDF dossier partie specialite julien baumann
Fichier PDF awt jpg
Fichier PDF coursword2010


Sur le même sujet..