Objectif : programmer un prototype d’interface adaptée au jeu \”En garde !\”.
Ce jeu de Reiner Knizia, aux règles simples qui peuvent sembler simplistes, permet de simuler à moindre coût un duel entre deux protagonistes.
Règles du jeu (tirées du site trictrac.fr) :
Les escrimeurs, représentés par des dés, se tiennent chacun à un bout du plateau. Les joueurs possèdent 5 cartes en mains. Les cartes possèdent des valeurs allant de 1 à 5. Chaque carte apparaît 5 fois dans le paquet.
Chacun son tour, on joue une carte et on déplace son personnage d’autant de cases, généralement vers l’avant, mais on peut aussi reculer.
Quand les personnages sont assez près l’un de l’autre, le joueur dont c’est le tour peut jouer une carte de la valeur exacte qui sépare les deux personnages. C’est une attaque. Pour parer, le joueur qui défend peut jouer à son tour une carte de la même valeur. C’est la parade.
Si un joueur peut jouer plusieurs cartes d’attaque de la même valeur, c’est une attaque renforcée. Le défenseur devra joueur le même nombre de cartes de même valeur pour parer, ce qui est plus difficile.
Mieux encore, on peut charger. Le joueur qui charge joue d’abord une carte pour bouger, puis une autre pour toucher. Le défenseur aura alors la possibilité de reculer s’il ne possède pas de carte adéquate pour parer. Mais, déséquilibré, il ne pourra pas jouer au prochain tour, laissant la main au joueur offensif.
Si à la fin de la pioche, aucune touche n’a été faite, le joueur le plus avancé sur le plateau remporte le point.
Chaque attaque non parée ou défendue est une touche. La manche prend fin immédiatement et le vainqueur marque 1 point. Le premier qui remporte 5 touches gagne la partie.
Vous trouverez une description complète des règles dans ce fichier PDF : engarde-regles.pdf.
Cahier des charges
Ce projet s’inscrivant dans une mise en pratique des notions vu dans le module IHM, il est bien entendu hors de question d’établir un cahier des charges dépassant cet objectif. On s’attachera donc à proposer une interface simple, intuitive et conviviale permettant à deux joueurs de s’affronter sur la base de ces règles (en s’abstenant d’implanter un adversaire électronique et une liaison réseau notamment). Une réflexion préalable doit être menée pour décider quelle représentation donnée au plateau de jeu, aux protagonistes et aux cartes ainsi que de leur agencement réciproques. Ces deux aspects, représentation et agencement, doivent pouvoir être personnalisés par les utilisateurs. Le fait que cette interface soit employée par deux utilisateurs ne doit pas être négligé. Le système doit ensuite permettre le bon déroulement d’une partie dans le respect des règles du jeu, ce qui suppose un traitement des erreurs approprié et adapté à tout public ainsi que de tenir à jour le nombre de manches remportées. Enfin l’utilisateur doit pouvoir retrouver son interface telle qu’il l’a personnalisée entre deux sessions de jeu. Par contre, aucune sauvegarde d’une partie en cours n’est demandée.
Programmation
L’ensemble du projet devra être écrit en TclTk exclusivement, mais avec l’aide de la bibliothèque tkpng qui permet d’afficher des images au format PNG, et dont le principal intérêt dans le cadre de ce projet est de pouvoir gérer le canal alpha des couleurs, et de la bibliothèque tcllib qui permet l’utilisation de structures de données plus élaborées que les listes notamment (cf. struct). L’utilisation des namespace est recommandée. De même, il est indispensable de construire ce projet modulairement, seule approche succeptible de garantir au minimum les principes d’encapsulation, de protection et de réutilisabilité. Vous pouvez utiliser tout module disponible sur le net (écrit en TclTk) augmentant l’ergonomie et/ou la présentation de votre application (attention cependant à la surenchère, rarement synonyme de qualité).
Notation
La notation de ce projet prendra en compte le respect du cahier des charges, la qualité de la programmation (robustesse, lisibilité et modularité de votre code) ainsi que les aspects propres à une IHM que sont : cohérence, concision (limitation du nombre d’intervention de l’utilisateur), structuration des activités (décomposition d’une tâche complexe), flexibilité (application personnalisable), retour d’informations et gestion des erreurs, toutes choses qui garantissent une interface ergonomique et intuitive et qui n’apparaissent pas explicitement dans cette présentation.