Projet 2025-2026

1. Introduction

L’objectif de ce mini-projet est de réaliser une application Web écrite en TypeScript du jeu de stratégie Pions et barrières à peu près jouable (et observable) en multijoueur réseau, en utilisant toutes les compétences acquises lors des TP et TD précédents.

🗓️ La date limite de rendu est fixée au dimanche 12 avril 2026 à 23h59.

Ce projet est à réaliser obligatoirement par groupe de deux (provenant du même demi-groupe de TP). Les groupes de trois ne sont autorisés que dans le cas d’un nombre d’étudiants impair, avec au plus un groupe de trois par groupe de TP.

2. Règles du jeu Pions et barrières

2.1. 🎯 Objectif du jeu

Pions et barrières (P&B) est un jeu de stratégie où l’objectif principal est d’amener son pion à la ligne opposée du plateau avant ses adversaires. La première personne à atteindre sa ligne opposée remporte la partie.

Une partie de Pions et barrières se joue généralement avec 2 à 4 adversaires ou PJ (personnes joueuses). Il existe 20 barrières qui sont distribuées de manière équitable entre les PJ avant le début de la partie.

2.2. ♟️ Déplacements des pions

Les PJ peuvent déplacer leur pion d’une case à la fois dans les directions suivantes :

  • ⬆️ Vers le haut

  • ⬇️ Vers le bas

  • ⬅️ Vers la gauche

  • ➡️ Vers la droite

Les pions ne peuvent pas se déplacer en diagonale. ↗️↘️↙️↖️

2.3. 🚧 Obstacles : les barrières

Pour compliquer les déplacements, les PJ peuvent placer des barrières sur le plateau. Une barrière est constituée de deux segments et peut être placée horizontalement ou verticalement entre deux cases adjacentes. Les barrières bloquent le passage des pions.

2.3.1. Description

Dans le jeu Pions et barrières, une barrière est représentée par une structure de données appelée Fence. Chaque Fence est définie par les deux positions adjacentes nécessaires pour placer la barrière.

2.3.2. Représentation des barrières dans le jeu Pions et barrières

  • Une barrière horizontale est définie par les positions adjacentes qui se trouvent en haut de la barrière. Elle ne peut pas être placée le long des limites supérieure et inférieure du plateau.

  • Une barrière verticale est définie par les positions adjacentes qui se trouvent à gauche de la barrière. Elle ne peut pas être placée le long des limites gauche et droite du plateau.

La structure Fence comprend les champs suivants :

  • startPosition: position de début de la barrière.

  • endPosition: Position de fin de la barrière.

  • isHorizontal: booléen indiquant si la barrière est horizontale (true) ou verticale (false).

Dans la représentation d’une barrière, l’ordre dans lequel les positions sont fournies n’a pas d’incidence sur son orientation. En d’autres termes, il n’y a pas de notion d’orientation associée à la représentation d’une barrière.

image
Figure 1. Représentation graphique des barrières horizontales et verticales dans le système.

2.4. 🔀 Règles de déplacement

  • Une PJ peut déplacer son pion d’une case adjacente horizontalement ou verticalement, à condition que la case de destination ne soit pas bloquée par une barrière.

  • Les pions ne peuvent pas traverser les barrières. Si une barrière bloque le chemin, le pion doit contourner celle-ci (en plusieurs coups).

  • Un pion peut sauter par-dessus un pion adverse si la case juste derrière le pion est libre.

  • Les pions ne peuvent pas sortir du plateau.

  • Chaque PJ ne peut placer qu’une barrière par tour.

3. Préparation

3.1. Création de votre bifurcation

Une seule fois par binôme, avant de commencer à travailler sur le projet, suivre rigoureusement les étapes suivantes :

  1. Créer une bifurcation (en anglais, fork) du Projet Pions et barrières en cliquant sur « Créer une bifurcation ».

  2. Dans la fenêtre de création « Bifurquer un projet » :

    1. Dans « Niveau de visibilité », choisir « 🔒️ Privé ». Ainsi, vous devenez la seule personne autorisée à accéder à votre code source.

    2. Dans « Description du projet (facultative) », saisir rigoureusement la description de projet suivante, différente pour chaque groupe de TP — consulter le tableau ci-après.

      Cette étape est très importante car elle nous permet de retrouver vos projets sur le GitLab.

    3. Puis cliquer sur « Bifurquer un projet »

    4. Une fois le projet bifurqué, dans Gestion  Membres, cliquer sur « Inviter des membres » puis donner accès à votre projet à votre binôme de projet, avec le rôle « Propriétaire » ; ainsi, les deux membres du projet ont le maximum d’autorisations sur le projet.

    5. Toujours dans Gestion  Membres, ajouter votre enseignant⋅e de TP, avec le rôle « Rapporteur ». Pour savoir quel compte ajouter, consulter le tableau ci-après.

Groupe de TP 2025-2026 Description Compte à ajouter en rôle « Rapporteur »

281Q

projet-dl-2025-281Q

Vincent KOWALSKI (@E164695R)

281R

projet-dl-2025-281R

Ginwa FAKIH (@E20d463S)

284I

projet-dl-2025-284I

Denis BÉCHET (@bechet-d)

284J

projet-dl-2025-284J

Vincent KOWALSKI (@E164695R)

285K

projet-dl-2025-285K

Henri COSSAIS (@E235881S)

285L

projet-dl-2025-285L

Vincent KOWALSKI (@E164695R)

286M

projet-dl-2025-286M

Étienne ANDRÉ (@andre-e-2)

286N

projet-dl-2025-286N

Vincent KOWALSKI (@E164695R)

287P

projet-dl-2025-287P

David JULIEN (@djulien)

287Q

projet-dl-2025-287Q

Vincent KOWALSKI (@E164695R)

289S

projet-dl-2025-289S

Étienne ANDRÉ (@andre-e-2)

289T

projet-dl-2025-289T

David JULIEN (@djulien)

Terminer ensuite de préparer votre répertoire de travail :

  1. Ouvrir le terminal et effectuer une commande git clone appropriée pour récupérer votre bifurcation sur votre poste de travail.

    Il vous est fortement recommandé d’utiliser l’adresse SSH de votre bifurcation pour faire le clone ; vous devriez avoir au préalable configuré votre accès SSH comme expliqué dans le TP GitLab. Si ce n’est pas le cas, il convient de le faire maintenant.

  2. Utiliser la commande cd pour vous rendre dans le répertoire créé par votre git clone puis faire la commande npm install pour télécharger les dépendances nécessaires.

3.2. Analyse de la structure du projet

Regardez la structure du projet. Le projet est organisé en différents dossiers :

.
├── README.adoc
├── client
│   ├── script.js
│   └── style.css
├── package-lock.json
├── package.json
├── src
│   ├── main
│   │   └── ts
│   │       ├── fence-placement-validation.ts
│   │       ├── fence-placement.ts
│   │       ├── fence.ts
│   │       ├── game-board.ts
│   │       ├── game.ts
│   │       ├── main.ts
│   │       ├── movement-validation.ts
│   │       ├── pawn-movement.ts
│   │       ├── pawn.ts
│   │       ├── position.ts
│   │       ├── server.ts
│   │       ├── square.ts
│   │       └── util.ts
│   └── test
│       └── ts
│           ├── move-validation-test.spec.ts
│           └── position-test.spec.ts
├── tsconfig.json
└── views
    └── index.ejs

  • Le répertoire client contient le code JavaScript qui sera exécuté sur le navigateur, ainsi que le style de la page. Vous ne devez pas modifier le contenu de ce dossier.

  • Le répertoire views contient le fichier index.ejs qui définit la page principale de l’application Web. Vous n’avez pas besoin de le modifier.

  • Le répertoire src/main/ts contient le code source du serveur.

    • Dans ce dossier, 📝 vous allez modifier les fichiers move-validation.ts et fence-placement-validation.ts.

      En aucun cas vous ne devez modifier le contenu des fichiers fence-placement.ts, fence.ts, game-board.ts, game.ts, main.ts, pawn-movements.ts, pawn.ts, position.ts, server.ts, square.ts et util.ts.

  • Le fichier main.ts est le programme principal de création et gestion de la ligne de commandes. Vous ne devez pas modifier le contenu de ce fichier.

  • Le fichier server.ts est le programme principal de création et gestion du serveur Web. Vous ne devez pas modifier le contenu de ce fichier.

  • Le répertoire src/test/ts contient les tests unitaires du serveur. 📝 Vous allez modifier le contenu de ce dossier.

  • Le répertoire node_modules contient les modules Node.js téléchargés par npm install. Vous ne devez pas modifier le contenu de ce dossier.

  • Le fichier package.json est le fichier de configuration de npm, qui décrit les dépendances ainsi que les commandes exécutables. Vous n’avez pas besoin de le modifier.

  • Le fichier tsconfig.json est le fichier de configuration du compilateur TypeScript. Il est similaire à celui que vous avez utilisé en TP. Vous n’avez pas besoin de le modifier.

3.3. Mise à jour du projet (seulement si demandé)

Il est possible que l’équipe pédagogique ait laissé quelques coquilles dans le projet et que ces coquilles soient corrigées alors que vous aurez déjà commencé à travailler sur le code.

Seulement si l’équipe pédagogique vous le demande, vous pourrez récupérer les corrections des coquilles à l’aide des commandes suivantes :

Une seule personne parmi votre binôme doit effectuer cette commande ; l’autre récupérera ensuite la version actualisée avec un git pull. 
# ajoute à votre référentiel local un lien vers le dépôt originel et le nomme `upstream`.
# (pas besoin si déjà fait une première fois sur votre machine)
git remote add upstream git@gitlab.univ-nantes.fr:gl/developpement/projet-pions-barrieres.git

# fusion par défaut
git config --global pull.rebase false

# récupère les changements de l'équipe pédagogique et les fusionne avec votre bifurcation.
git pull upstream main

# envoie les changements ainsi récupérés sur votre référentiel distant.
git push

  • La première ligne ajoute à votre référentiel local un lien vers le dépôt originel et le nomme upstream.

  • La deuxième ligne récupère les changements et les fusionne avec votre bifurcation.

  • La troisième ligne s’assure que les changements ainsi récupérés sont bien envoyés sur votre référentiel distant.

4. Description du fonctionnement du projet fourni

4.1. Exécution des tests unitaires, exécution de l’application

Le projet utilise l’outil de construction et de gestion de modules npm. Deux principales commandes vous sont fournies, exécutables avec npm :

  • Pour lancer tous les tests unitaires du projet avec Alsatian, exécutez : npm run test.

  • Pour lancer le jeu en ligne de commande, exécutez : npm run command-line.

  • Pour lancer le serveur en mode développement, exécutez : npm run start-server. Puis, une fois le serveur lancé :

Comme vu en TP, il ne faut pas hésiter à lancer ces deux commandes en mode Debug, afin de pouvoir profiter du débogueur. Pour rappel, nécessite de passer par l’encart NPM Scripts que vous pouvez afficher tout en bas à gauche de VSCode (si besoin, retournez voir les instructions fournies dans le TP sur le test).

Deux commandes optionnelles vous sont également fournies :

  • Pour supprimer le code compilé, exécutez : npm run clean.

  • Pour supprimer les dépendances téléchargées, exécutez : npm run clean-deps.

4.2. Manuel d’utilisation de l’application

Une fois votre application lancée et ouverte dans une ligne de commande, répondez aux questions de l’interface pour déplacer les pions et placer des murs.

4.3. Fonctionnement interne de l’application (contenu avancé, optionnel)

4.3.1. Serveur Web

Le programme principal du serveur (server.ts) est chargé de démarrer un mini-serveur Web capable de recevoir les différentes requêtes provenant des navigateurs connectés à l’application :

  • GET "/" : distribue le fichier views/index.ejs ;

  • GET "/status.js" : génère et distribue le plateau en cours au format JSON ;

  • POST "/" : reçoit et traite un coup à jouer.

Ces trois traitements correspondent aux différents appels à app.get() et app.post() du programme principal.

4.3.2. Chronologie d’une partie

  1. Lorsqu’une personne se connecte à l’application (adresse "/"), le serveur distribue alors la page HTML principale composée d’un plateau vierge et d’une zone de saisie permettant à cette personne de remplir le coup à jouer.

  2. Le navigateur Web récupère immédiatement les informations de la partie en cours présentes à l’adresse /status.js et remplit le plateau à l’aide d’un script situé dans le fichier script.js. Ces deux scripts se trouvent dans le répertoire client/.

  3. Un clic sur le bouton « Envoyer » effectue une requête de type POST à l’adresse "/" du serveur, contenant les informations du champ de texte associé. Le serveur traite alors la requête afin de jouer le coup demandé.

  4. La page Web est alors rechargée automatiquement, affichant ainsi le nouvel état de la partie.

5. Travail à réaliser

5.1. Code à écrire

5.1.1. Validation des mouvements et des placements de mur

La version actuelle permet le déplacement libre des pions, sans respecter les règles du jeu. Il est donc possible de déplacer les pions et placer des murs sur n’importe quelle case, ce qui n’est pas correct !

🎯 L’objectif principal de votre travail est d’écrire le code nécessaire pour vérifier qu’un mouvement est bien valide (du point de vue des règles du jeu) avant d’être exécuté.

Dans le projet que vous avez récupéré, ce travail a été commencé mais, pour le moment, aucun déplacement n’est vérifié. Vous devez mettre en œuvre la validation des déplacements des pions et le placement des murs.

En interne, le traitement des déplacements se fait de la façon suivante :

  1. Lorsqu’une requête POST arrive, le serveur extrait la valeur du champ envoyé et appelle la fonction processMove() du module movement-validation.

  2. La fonction processMove() appelle une autre fonction, parseMoveString(), qui transforme une chaîne de caractères en un déplacement (type Move) entre deux positions (type Position).

  3. La fonction processMove() appelle ensuite la fonction isMovePossible(), qui fait appel à différentes fonctions de validation spécifiques aux pièces du plateau de jeu (une par type de pièce). Le module move-validation contient toutes les fonctions de validation de déplacements.

  4. Si le mouvement est possible, c’est-à-dire si la fonction isMovePossible() retourne true, la fonction processMove() appelle la fonction performMove(), qui effectue le déplacement.

Vous devez donc parcourir le module move-validation et implémenter les fonctions de validation contenant un commentaire de la forme :

// #TODO: Implement this function
Votre projet sera évalué sur le bon fonctionnement de vos fonctions de validation.

5.1.2. Tests unitaires

Pour vérifier que les fonctions du module move-validation fonctionnent correctement, vous devez écrire des tests unitaires, qui vont vérifier que les fonctions acceptent les mouvements possibles et n’acceptent pas les mouvements impossibles.

Comme les règles du jeu sont complexes, vous devrez écrire plusieurs tests unitaires pour vérifier les mouvements possibles et impossibles d’un pion ainsi que les placements des murs.

Les tests unitaires du module position ont déjà été implémentés ; vous les trouverez dans le fichier ./src/test/ts/position-test.spec.ts.

Votre projet sera évalué sur le bon fonctionnement de vos tests.

5.1.3. Comment procéder ?

Vous devez procéder par itérations successives ; n’essayez pas d’implémenter les fonctions d’un seul trait. Observez le cycle de développement suivant :

  1. Implémentez une fonctionnalité simple.

  2. Écrivez le ou les tests unitaires qui vérifient cette fonctionnalité.

  3. Exécutez les tests pour vérifier que la fonctionnalité marche correctement et la non-régression.

  4. Recommencez avec la fonctionnalité suivante.

5.2. Qualité du code exigée

Il est demandé que votre travail respecte tous les principes de qualité de code étudiés en cours et en TP, ce qui inclut :

  • Nommage approprié de vos fonctions et variables,

  • Usage de commentaire lorsque c’est nécessaire et approprié,

  • Simplification du code lorsque c’est possible.

Votre projet sera évalué sur la qualité du code que vous aurez produit.

5.3. Utilisation de GitLab et git

Il est demandé que votre développement soit entièrement versionné à l’aide de GitLab et git. Vous devez enregistrer tous les changements que vous réalisez à l’aide de commit et de push sur votre référentiel distant, en choisissant à chaque fois des messages de commit appropriés. Vous devez également utiliser git pour collaborer à plusieurs sur votre projet, en partageant le même référentiel distant auprès des deux membres du binôme.

Effectuez des commit et des push régulièrement ! Cela vous permet d’éviter de perdre votre travail, et de mieux collaborer en équipe.
Votre projet sera évalué sur votre usage de git, que ce soit la qualité des messages de commit, la fréquence des commit, et l’équilibre de la répartition des commit entre les membres du binôme. Il est notamment absolument requis que chaque membre du binôme ait fait au moins un commit.

5.4. Derniers conseils

  • Rappelez-vous que « Une fonction sans test unitaire ne fonctionne pas » !

  • Rappelez-vous aussi que « N’importe qui peut écrire du code compréhensible par les ordinateurs, mais seulement les bon développeurs parviennent à écrire du code intelligible par les humains » !

  • Écrivez les tests unitaires en même temps que (ou, encore mieux, avant) les fonctions. Ne les laissez pas pour la fin : les test unitaires sont très utiles pendant le développement et vous feront gagner du temps global.

6. Rendu de votre travail

🗓️ La date de rendu est fixée au dimanche 12 avril 2026 à 23h59.

Pour rendre votre projet, il vous suffit de vous assurer d’avoir parfaitement bien suivi ce qui est demandé dans la partie « Préparation » au début de ce document, et d’avoir bien validé (commit) et publié (push) tous vos changements et fichiers de travail avant la date limite. Nous vous encourageons à vérifier plusieurs fois que tout a bien été fait exactement comme demandé ; autrement, nous ne pourrons pas avoir accès à vos projets pour les corriger.

Éditer le fichier README.md à la racine du projet, et y indiquer en haut du fichier vos nom, prénom, groupe, numéro d’étudiant⋅e, pour vous et votre binôme. Sans cela, il y a un risque que nous oublions votre binôme lors de la notation, et que ce soit compté comme 0.

Si vous le souhaitez, vous pouvez également éditer le fichier README.md à la racine du projet, afin de décrire les spécificités de votre projet (choix techniques, parties non traitées, extensions non demandées, etc.).

Votre projet doit compiler et s’exécuter correctement ! Si ça n’est pas le cas, un nombre de points significatif sera retranché.

Pour vous assurer que tout compile bien et s’exécute bien et que vous n’avez rien oublié, essayez vous-même les commandes suivantes sur une machine sur laquelle vous n’avez pas travaillé, ou sinon dans un répertoire différent :

git clone <votre projet>
cd <votre répertoire cloné>
npm install
npm run test
npm run start-server

C’est peu ou prou les commandes que nous testerons lors de l’évaluation.

Vous pouvez tout à fait demander, pendant un TP, à votre enseignant⋅e de vérifier s’il a bien accès à votre git, et de tester la version préliminaire de votre projet sur sa machine. Ça réduira déjà les probabilités de problèmes lors de l’évaluation.

Votre projet doit compiler et s’exécuter correctement (on le redit).

On rend jamais un code qui ne compile pas, ou ne se lance pas. (Il peut y avoir d’éventuelles erreurs à l’exécution dans une version préliminaire d’un code, mais le programme doit se lancer correctement.)

VOTRE PROJET DOIT COMPILER ET S’EXÉCUTER CORRECTEMENT.

VOTRE. PROJET. DOIT. COMPILER. ET. S’EXÉCUTER. CORRECTEMENT.

⚠️🔴 VOTRE. 👏 PROJET. 👏 DOIT. 👏 COMPILER. 👏 ET. 👏 S’EXÉCUTER. 👏 CORRECTEMENT.

Sur ce… bon développement ! 👩‍💻👨‍💻