Salut a tous,
 
J'essaye de réaliser une applet de jeu d'echecs java, pour cela ( et on peut dire que j ai commencer a l envers surement ) j ai plus ou moins realiser l interface graphique...
 
Je m attaque donc maintenant a la realistion du "moteur" qui est en fait la portion du code qui verifie si un coup est conforme ou non en ce basant sur les regles du jeu d echecs...
 
Ma question est donc , comment faire le lien entre le gui et le moteur de verification ?
C est a dire un joueur joue un coup et instantanement le prog verifie si le coup est valide et l autorise ou non...
 
En gros si le joueur joue un coup est ce que je peut recuperer la case de depart , la case d arriver , et le type de la piece , passer tout ces arguments au moteur qui verifie etc ...
 
Au niveau du GUI je gere le mouvements des pieces avec des transferHandler(du dnd), peut t on recupere les arguments citees avec cette classe?
 
 
J'ai ouie dire qu il fallait le moins possible lier l interface graphique et le code executant proprement dit,dans ce cas ma solution convient elle?
 
Qu en pensez vous?
 
merci

Salut je crois que oui effectivement ut t'y es pris completement a l'enver.  
Pour ta modelisation le mieu est a mon avis que ton interface graphique habille un moteur de règle. Je m'explique tu devrais commencer par considerer ce qu'est un jeu d'echec, c'est un plateau avec dessus des pieces.
tu as plusieurs choix soit tu modelise ton plateau comme étant une matrice contenant des pieces soit tu te contente de penser le plateau comme un ensemble de coordonées.
Un pièce d'une manière générale serait définie par ses coordonnées actuelles, de cette classe mère tu peut faire dérivé des classe pour chacun des types de pièces. Ces classes filles implémenteraient chacune une méthod is_valid abstraite hérité de la classe pièce prenant les futur coordonées en paramètre et vérifiant la validité du coup ....
bref quand ton joueur tente une action tu appelle la méthode is valid sur l'objet concerné ...
Bon ce sera un poil plus complexe que ca mais en gros ca te donne je l'espère un piste de reflexion

salut,
Si je modelise le plateau comme une etant une matrice , il faut qu a un moment ou un autre lorsque le joueur joue son coup les informations relatives aux cases de depart et d arrives remontent au moteur d analyse?
 
donc je doit recuperer ces infos a partir du GUI non ?
 
genre si l echiquier est un gridlayout de JPanel je recupere :
 
-le type objet Pieces(roi tour ...) qui est dessus
-la position du JPanel dans l echiquier( abs et coord)
-la postion du JPanel de la case d arrive(abs et coord)
 
et j envoie tout ca au moteur qui valide ou non le coup??
 
j ai bon

Ce qui est dans le GUI est dessiné à partir des info généré par le moteur de jeu, pas l'inverse.
Si tu as ta matrice qui représente le plateau (avec la position des pièces), il suffit de faire une methode Plateau::draw() qui affiche les bonnes pièces au bonne endroit.
 
Tu pourrais avoir une méthode abstraite Piece::draw(). Puisque chaque classe héritée l'implémente, la méthode Plateau::draw() appelerait juste Piece::draw() sur toutes les pièces du plateau.

Exact exo 7 la partie graphique n'est qu'un habillage, ton jeu doit être concut en logique avant tout, d'ailleur pour bien te faire comprendre l'utilité de proceder de la sorte il suffit de te demander ce qui se passera si plus tard tu souhaite changer completement ton moteur graphique, dans le cas ou tout en dépend, ce sera la crois et la banière. Si tout est séparé modifier le moteur d'affchage ne t'obligera pas a toucher a ton moteur de règle.
Bref il faut vraiment que ton affichage soit séparé du moteur de règle.
c'est le moteur de règle qui commande l'affichage pas l'inverse tu t'en sortira beaucoup mieu comme ca .

merci merci je pense avoir capté ...
++

D'ailleurs quasiment tous les jeux d'échecs actuels séparent complètement le moiteur d'échecs proprement dit de l'interface graphique. Il y a deux interfaces définies pour les faire communiquer, Winboard et UCI (je crois), de sorte qu'on peut choisir son interface graphique et le moteur que l'on veut.