Troisième défi Qt : les résultats du jeu d'échecs

Les règles permettent de jouer une partie sérieuse aboutissant à un mat. Plusieurs points restent à revoir :

• la triple répétition n'est pas entièrement fonctionnelle : si un seul joueur (et non les deux) fait trois fois le même coup, un pat est détecté. Cela donne à chaque camp la possibilité de faire de l'anti-jeu en cas de mauvaise posture ;
• le pat n'est pas correctement géré dans le cas où un camp ne pourrait plus se déplacer ;
• prise en passant : le pion ayant effectuant la prise peut bel et bien effectuer le mouvement mais le pion qu'il doit prendre reste sur le plateau ;
• gestion du roque : on a moyen de roquer sans la tour si on replace le roi à sa position d'origine et également de roquer à l'envers pour replacer le roi au centre ;
• la règle des cinquante coups est implémentée mais non fonctionnelle.

Par rapport à la syntaxe elle-même du code, des coding rules sont respectées et le code est aéré comme il se doit. De ce fait, il n'est pas difficile de lire et de comprendre le code. Néanmoins, il serait judicieux de faire bien attention à ne pas oublier de placer les mentions « const » sur les paramètres et variables locales non modifiées.

Du point du vue C++, une classe ChessEngine est utilisée pour la gestion core de la totalité de la partie. Pour la réalisation de l'algorithme principal de l'application, il aurait pu être intéressant de faire quelques petites modifications. Tout d'abord, il aurait été possible de sous-classer Piece afin de reproduire un schéma similaire à celui utilisé dans la partie QML (des classes Pawn, King, etc. hériteraient de Piece). De plus, on peut ajouter que cette architecture permettrait à chaque type de pièce de gérer les comportements propres à eux-mêmes. Autrement dit, cela aurait permis à ChessEngine de se libérer de fonctions telles que les fonctions de déplacement des pièces selon leur type, de la promotion des pions, etc.

Mis à part cela, l'approche Model/View avec une partie core en C++ et une partie graphique en QML/JS est tout à fait correcte.

Du côté de QML, deux détails. Le premier : on remarque sous Linux au lancement que les cases de l'échiquier sont trop grosses, tout comme les indicateurs de déplacement et de menace, ce qui crée des problèmes à voir sur quelle case de l'échiquier est chaque pièce. Ce problème provient de la valeur de BoardCellSpacing de DrawingConstants.js. Une proposition de correction :

--- DrawingConstants_old.js	2012-07-28 21:03:03.265542825 +0200
+++ DrawingConstants_new.js	2012-07-28 21:03:02.645529458 +0200
@@ -4,15 +4,15 @@
 var BoardHeight = 8
 var BoardCenterOffset_X = -BoardWidth / 2.0
 var BoardCenterOffset_Z = BoardWidth / 2.0
-var BoardCellSpacing = BoardWidth / 8.0
+var BoardCellSpacing = BoardWidth / 16.0
 var BoardTopSurfaceOffset = BoardHeight / 2.0
 var MovesDuration = 400

 function cellCenter_X(column) {
-    return BoardCenterOffset_X + BoardCellSpacing * (column + 0.5)
+    return BoardCenterOffset_X + BoardCellSpacing * 2 * (column + 0.5)
 }

 function cellCenter_Z(row) {
-    return BoardCenterOffset_Z - BoardCellSpacing * (row + 0.5)
+    return BoardCenterOffset_Z - BoardCellSpacing * 2 * (row + 0.5)
 }

Une capture d'écran du rendu :

Le second détail touchant la partie QML : les messages « Échec aux blancs », « Échec et mat », etc. sont coupés et de taille bien trop grande selon le système. Il s'agit d'un problème lié aux polices ; il est préférable d'utiliser dans la mesure du possible la propriété pixelSize à la place de pointSize pour garantir un résultat identique.

À part cela, on constate que le code QML, combiné à un peu de JavaScript, est aussi bien découpé qu'architecturé. Dans la partie C++, le framework Qt est exploité à bon escient, rien à dire.

• lors de la sélection, la pièce élue se met à se scaler/déscaler, tout comme les indicateurs de déplacement et de menace ;
• le déplacement des pièces est progressif et suit un chemin particulier, aucune pièce ne se percute ;
• le fou avance en zigzags, le roi/piont en ligne droite, le cavalier décolle et retombe, la tour s'incline, s'avance et se remet droite et la reine tourne sur elle-même ;
• le plateau pivote lors d'un changement de tour (blancs/noirs).

Le code suit des règles de codage, le rendant aussi facile à comprendre qu'agréable à lire. Des commentaires en anglais sont présents dans les parties où des explications peuvent être nécessaires pour expliquer telle ou telle partie de l'algorithme.

Du point de vue de la syntaxe elle-même du code, les mentions « const » sont souvent présentes. Toutefois, attention à ne pas en négliger les emplois devant les variables d'énumérations, les variables locales et les pointeurs (voir http://duramecho.com/ComputerInformation/WhyHowCppConst.html). Trois illustrations où les mentions sont à ajouter:

Piece * Board::addPiece(Piece::Type type, Piece::Color color, const QString &squareName) 
    /* Avec la mention const et l'emploi de références : 
        Piece * Board::addPiece(const Piece::Type &type, const Piece::Color &color, const QString &squareName) */
bool isWhitePiece = piece.getColor() == Piece::White; 
    /* Avec la mention : const bool isWhitePiece = piece.getColor() == Piece::White; */
Board::Board(QWidget *parent) : QDeclarativeView(QUrl("qrc:/board.qml"), parent), 
    /* Avec la mention : Board::Board(QWidget* const parent) */

Certaines conditions ternaires ne sont pas exploitées pour une affectation ou bien leur un retour n'est pas utilisé. Préférer dans ces cas l'emploi d'une simple paire if/else pour éviter des conversions implicites de type possibles dans le cas où les fonctions ne retourneraient pas void. Par exemple :

isWhiteMoving?emit whiteMoveStarted():emit blackMoveStarted();

Au niveau de l'architecture du code, une classe Board joue le rôle du gestionnaire global de l'application. Il gère la partie humain contre humain, le déplacement des pièces, le nombre de coups effectués, etc. Il est aussi marqué en TODO qu'il aurait également pu gérer la promotion des pions. Au final, on a une classe qui s'écarte du principe de responsabilité unique. Il serait préférable de réaliser une arborescence de classes plus ample afin d'attribuer à chacune un rôle bien précis et donc d'obtenir des apports conséquents par rapport à la complexité et la lisibilité du code.

Les déplacements élémentaires des pièces sont présents. Cependant, de nombreux points sont à reprendre/mettre en place :

• le mat et le pat ne fonctionnent pas, on peut prendre le roi et continuer de jouer ;
• l'échec est détecté mais n'empêche pas le joueur d'effectuer des mouvements non autorisés (un cavalier peut se déplacer et mettre en échec son roi, ce dernier pouvant entrer dans le champ d'action d'une tour et se mettre lui-même en position d'échec, etc.) ;
• la prise en passant et la promotion d'un pion ne sont pas implémentées ;
• le petit roque chez les blancs n'est pas fonctionnel, on ne peut pas effectuer le mouvement à moins de déplacer le roi de la position initiale (E1) à la position F1 puis de déclencher le roque en le déplaçant en G1.
• il est possible de roquer plusieurs fois : les conditions de roque ne sont pas respectées.
• la règle des cinquante coups n'est pas implémentée (tout comme d'autres règles de pat) : si 50 coups sont effectués depuis la dernière prise ou déplacement d'un pion, un match nul peut être proposé.