Discussion :

[Malikemal]

Bonjour à tous,

Je participe donc à ce troisième défi Qt ! Je suis un jeune lycéen en 1E SSI, et je n'ai pas beaucoup de temps consacrer à ce projet mais j'espère que je pourrais au moins présenter le minimum. Niveau code pour le moment je suis parti sur une structure ressemblant à du MVC : je gère d'un côte les données (ou se trouve les pièces, le "calcul" des déplacements possibles, y'a t-il un échec ?...) et d'un autre côté j'ai la vu, qui se contente d'afficher "bêtement" e qui e trouve dans la classe qui représente l'échiquier. Pour celle-ci je compte utiliser un QGraphicsScene, et pour le placement des pièces je pense utiliser un QGraphicsAnchorLayout (vous avez une autre idée ?).
Je vais je pense commencer par faire le minimum, puis si j'ai encore le temps j'ajouterai de nouvelles fonctionnalités (3D, minuteur, "feuille" de coups, ...). De plus ce n'est pas un projet que j'ai prévu d'arrêter après la fin du défi.
Je posterai des screens, un "calendrier prévisionnel" dès que j'aurai le temps et que ce sera prêt.

Merci et bonne chance aux participants !

PS : Si vous avez des questions sr les échecs, vous pouvez me les poser ! J'y joue depuis que j'ai 6 ans (soit presque 10 ans !).

[Amnell]

Bonjour,

Selon moi, La classe QGraphicsAnchorLayout peut être une solution, mais à ce que je lis, malgré le fait qu'elle donne la possibilité de lier un item au layout lui-même, elle est plutôt utilisée pour sa capacité à lier les éléments graphiques entre eux. De ce fait, j'aurais plutôt considéré la classe QGraphicsGridLayout qui semble plus adaptée à un jeu d'échecs.

Bon courage pour le défi !
Amnell.

[Malikemal]

Merci pour ta réponse.

Je m'étais effectivement demandé si QGraphicsGridLayout n'étais pas approprié mais je me suis confronté à quelques "problèmes" (plus des questions en fait, mais je n'ai vraiment pas le temps de faire des tests ...). Nottament la superposition des layouts ou le déplacement d'une pièce. Si ça ne te gêne pas, on peut en parler par MP ?

Merci

[dourouc05]

Si ça ne te gêne pas, on peut en parler par MP ?

Et pourquoi donc ? Tout le monde peut être intéressé (sans oublier les autres arguments présentés dans les règles).

[Malikemal]

OK je m'incline

Bref je tiens à préciser que ce que je vais dire maintenant est purement théorique, je n'ai VRAIMENT pas l'occasion de faire des tests. Quand je peux taper du code je vais tot de suite à ce dont je suis sûr pour ne pas perdre de temps (chez moi, je peux seulement aller sur l'ordi 4h par WE grand max et rien la semaine ... Je suis au lycée en ce moment).
Donc, déjà est-ce que le gridLayout gère la superposition des éléments ? Autrement dit est-ce que ce code fonctionnera correctement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
layout->addItem(item1, 0, 0);
layout->addItem(item2, 0, 0);

Est-ce que item2 sera au-dessus de item1, ou alors est-ce que item2 effacera item1 ? Je me pose la même question avec l'AnchorLayout, si deux objets se trouvent superposés, que se passera-t-il ?

Selon la réponse à ma précédente question, je pouvais soit utiliser le même GridLayout (si la superposition ne pose pas de problèmes) ou alors créer un nouveau GridLayout. Ce dernier se trouvera donc au même emplacement que le précédent, pour que les pièces puissent se trouver sur les cases ... Est-ce possible ? (J'entends par là de superposer deux layouts)

Enfin, pour que je puisse placer une image dans n'importe lequel des layouts, celui-ci doit dériver de QGraphicsGridLayoutItem ou QGraphicsAnchorLayoutItem. Or, j'ai besoin de placer une image. Ma queston est donc : l'héritage multiple est-il ici mal placé ? Je compte aussi ajouter quelques attributs à la représentation graphique de la pièce.

Si vous avez besoin de compléments, n'hésitez pas

Merci encore,

[johnlamericain]

Je doute que QGraphicsGridLayout te permette d'avoir plusieurs items à la même position. Ce qui me fait dire ça c'est surtout que itemAt(row, column) retourne que un élément et non une liste. J'ai cependant jamais utilisé cette classe.

Par contre si tu fais le layout toi même (position des cases + piéces, tailles constantes évidemment), tu peux utiliser le Z-Order disponible sur un QGraphicsItem (setZValue).

Bon courage.

[Malikemal]

Merci pour ta réponse.

C'est ce que je me suis en effet dit, mais une confirmation est toujours utile. Pour créer mon propre layout je dois hériter de QGraphicsLayout c'est ça ? Mais comment pourrais-je gérer la superposition (à moins que ça ne soit automatique ?) ?

[johnlamericain]

Merci pour ta réponse.

C'est ce que je me suis en effet dit, mais une confirmation est toujours utile. Pour créer mon propre layout je dois hériter de QGraphicsLayout c'est ça ? Mais comment pourrais-je gérer la superposition (à moins que ça ne soit automatique ?) ?

Tu n'as pas besoin d'utiliser une classe de layout fournit par Qt. Tu peux simplement ajouter des éléments (items) à une position. J'imagine que tes cases d’échiquier vont pas bouger, ni leur taille (cadrillage d'item 8x8), puis tes piéces ont surement la même taille et vont bouger à des position définis (les cases). Tu fais un mapping de chaque case avec la position sur ta Graphics View (coordinées en haut à gauche) et le tour est jouer.

[Malikemal]

Bon, un petit point. J'ai fini de programmer les déplacements "principaux" (comprendre tout sauf roque, prise en passant, ...), voici une petite explication de comment je vais me débrouiller.
J'ai une classe pour chaque pièce (tour, cavalier, fou, roi, reine et pion) qui est basée sur une interface commune. Pourquoi ? Parce que chaque déplacement est différent et que surtout pour le roi il faut faire un certain nombre de vérifications avant de le déplacer. En effet, je vais avoir deux "parties", l'affichage et les données. L'affichage, ben c'est la vue. Les données sont divisés en trois : le jeu qui vérifie par exemple quand on veut déplacer une pièce qu'elle le peut (quand un roi est en échec par exemple, il faut arrêter l'échec) avec l'aide d'une classe Echiquier. C'est un tableau de pointeurs de pièces qui représentent le plateau ([8][8]). Et donc les pièces.
Pour l'instant seules la classe Échiquier et les différentes pièces sont codées.

Si vous avez des questions, n'hésiter pas je sais que je ne suis pas très clair.

Tu n'as pas besoin d'utiliser une classe de layout fournit par Qt. Tu peux simplement ajouter des éléments (items) à une position. J'imagine que tes cases d’échiquier vont pas bouger, ni leur taille (cadrillage d'item 8x8), puis tes piéces ont surement la même taille et vont bouger à des position définis (les cases). Tu fais un mapping de chaque case avec la position sur ta Graphics View (coordinées en haut à gauche) et le tour est jouer.

Bonne idée en effet Je pense que c'est ce que je ferais, mais pas tout de suite !

[johnlamericain]

Question : Comment tu vas gérer tes règles de déplacement ? Quelle classe va être en charge de la validation (piéce, échequier, gestionnaire de règle, etc.) ?
De plus, tu as raison concernant le roi et ces déplacement limité mais c'est loin d'être tout. Tout déplacement de pièce (même un simple pion) peut mettre le roi en échec ce qui est interdit (impossible de s'auto mettre en échec), il y a donc une validation à faire sur tous les déplacements.

[Malikemal]

C'est principalement pour cette raison que j'ai créé une classe pour chaque pièce. Chaque classe redéfinit une méthode interaction (déclarée dans l'interface) qui renvoie un tableau multidimensionnels. Chaque case peut avoir 4 valeur (une énumération) : rien, protect (ce qui signifie que la pièce protège une pièce de son "équipe"), eat (ce qui signifie que la pièce peut manger une pièce adverse) et go (ce qui signifie que la pièce peut aller sur cette case. Puis je n'ai plus qu'à vérifier que l'emplacement où veut aller la pièce le peut. C'est pour cela que la classe Échiquier contient un tableau de [8][8] de pointeurs de pièces, pour pouvoir toujours accéder à ces éléments.
Vous vous demandez peut être pourquoi il y a une option protect et eat ? La valeur protect est utile quand le roi peut manger une pièce adverse. Comme tu l'a dis il ne peut pas se mettre en échec seul donc je vérifie que la pièce qu'il veut manger n'est pas protégée. Et eat sert justement à définir quelle pièce adverse une pièce peut manger.
Le cas que tu évoque sera gérée dans la classe "Jeu", on vérifie d'abord que le déplacement est possible (via la méthode précedente"), puis on "simule" son déplacement pour vérifier que le roi n'est pas échec, pour ça j'ai une fonction isChess, qui vérifie que pour une position donnée, le roi n'est pas mis en échec par aucune pièce adverse.

N'hésite pas à reposer des questions, ça me permet aussi de vérifier que j'ai bien pensé à tout .

[johnlamericain]

Ma deuxième question est donc, pense tu que ta classe pièce respecte le principe d'une seule responsabilité par classe ?

http://en.wikipedia.org/wiki/Single_...lity_principle (pas de version française apparement).

[Malikemal]

La version anglaise est généralement la plus complète de toute façon. Je ne regarde que très rarement seulement la version française.

Je dirais que oui, celle de gérer les "interactions" avec le reste de l'échiquier. Mais puisque tu poses cette question ça ne doit pas être le cas, pourquoi ? C'est l'inconvenient de l'auto-didactisme, il y a un certain nombre de théories que je ne possède pas

Merci,

[LittleWhite]

En français, expliqué par un GURU : http://blog.emmanueldeloget.com/inde...abilite-unique
(Pensez à voir le reste du site )

[Malikemal]

Je comprends mieux cette notion, et j'ai peut être cerné ce que vous vouliez dire. Si mon interface change, je vais devoir modifier aussi les classes qui en héritent. I'm right ?

[LittleWhite]

Oui, mais ça, c'est dans le cas où l'on utilise un héritage. Chose que l'on est pas toujours obligé
Le principe de la responsabilité unique permet aussi de faire en sorte que si l'on change un bloc, le reste n'est pas affecté (ou peut affecté (bon, c'est lié avec le principe d'encapsulation)).

[Malikemal]

Tant que le résultat est le même (un tableau de [8][8] contenant les valeurs énumérées), même si je change la classe Piece, il n'y aura pas de problèmes puisque ce que l'on veut avoir on l'a. D'une façon peut être différente mais on l'a. Le principe est donc respecté non ? Si changement il y a, ça n'affecte pas le reste du code.

[johnlamericain]

Mon point était le suivant, tu peux avoir une classe d'une pièce qui fait les choses suivantes.

Class du Roi par exemple :

1. Stockage des données (couleur, position, etc.) ;
2. Affichage graphique (pixmap, etc.) ;
3. Gestion des règles de la pièce à partir de ces données.

Ou avoir 3 classes différentes

• Structure de données (éventuellement héritage) ;
• Graphics item contenant un pointeur vers ta structure de données, une fonction de mise à jour quand les données changes, etc. ;
• Manager qui gére les règles basé sur les données globales de l'échiquier.

L'avantage de cette deuxième méthode est que si tu décide de changer ton interface graphique pour un affichage console ou OpenGL, ton gestionnaire de régles et ta sutrcture de données ne change pas. Si tout est encapsulé dans la même classe, tu auras un gros travail de refactoring.

C'est juste des pistes de réfléxion.

[Malikemal]

J'avais tout faux en fait ...

Plus sérieusement, je n'allais de toute façon pas encapsuler les données et la gestion des règles de la pièce avec l'affichage. Ça aurait vraiment été pas malin, même pour moi . Mais la gestion des règles et les données sont liés, l'un ne pouvant se faire sans l'autre, c'est pour cela que j'ai mis les deux dans une même classe. De plus gérer toutes les règles dans une seule classe en aurait fait un mastodonte à peine lisible.

[johnlamericain]

J'avais tout faux en fait ...

Plus sérieusement, je n'allais de toute façon pas encapsuler les données et la gestion des règles de la pièce avec l'affichage. Ça aurait vraiment été pas malin, même pour moi . Mais la gestion des règles et les données sont liés, l'un ne pouvant se faire sans l'autre, c'est pour cela que j'ai mis les deux dans une même classe. De plus gérer toutes les règles dans une seule classe en aurait fait un mastodonte à peine lisible.

Donc si tu as une même régle qui s'applique à plusieurs piéces, la logique est dupliquée dans l'ensemble des pièces qui doivent respecter cette règle ?