Modes actuels : deux joueurs locaux ou 1v1 à distance. Les descriptions d’annulation immédiate, de confirmation locale et de stockage dans le composant ci-dessous concernent le mode local. Le mode distant utilise un serveur et l’accord de l’adversaire ; voir la section dédiée en fin de fiche et le guide de déploiement (../DEPLOIEMENT_JEUX.md).
Fiche comparée aux sources, à l’interface et au catalogue le 26 octobre 2026. Voir l’audit commun des neuf activités (../JEUX.md#validation-documentaire). Les comptes de tests et recettes navigateur datés plus bas sont des vérifications historiques, pas un état de validation global actuel.
État et accès
Mode deux joueurs sur le même appareil, route /rubriques/jeux-hex. Le composant src/components/HexGame.svelte est chargé dans la rubrique existante après le contrôle de niveau habituel (public actuellement). Identifiant jeux-hex conservé, aucun nouveau lien ni accès indépendant. Bloc d’attente retiré, description actualisée, mention Jeux de stratégie, absence de séparation sous le titre comme pour le L Game. Bleu #2365a0 et rouge #ae4433.
Règles et interface
11 × 11 par défaut ; choix 7, 9, 11 ou 13 après les règles. Un clic sur une case vide pose immédiatement le pion, sans confirmation. Le pion reste en place. Bleu relie première et dernière lignes ; rouge première et dernière colonnes. Six voisins par côtés, diagonales axiales incluses. Un chemin gagnant est détecté après chaque pose et souligné en jaune. Pas de nul ni de limite de tours.
Règle d’échange activée par défaut, désactivable avant le premier coup : après la première pose, le joueur 2 peut prendre les bleus au lieu de poser. Le pion initial ne bouge pas et ne change pas de couleur ; les joueurs échangent la propriété des couleurs ET des bords, puis le joueur 1 joue rouge. Ce choix consomme un tour et ne peut être répété. Poser un second pion renonce à l’échange.
Annuler le dernier coup revient avant la dernière pose / le dernier échange, y compris après victoire. Ce bouton prend la couleur du joueur qui vient de jouer (sa couleur après échange le cas échéant). Nouvelle partie demande confirmation ; ses réglages deviennent modifiables. Les règles sont toujours visibles, les réglages en dessous. Aucun bouton de pose ni de sélection. Cadre coloré fermé en parallélogramme à l’extérieur, contour hexagonal à l’intérieur. Bandes affinées : marge de 7 unités SVG au-delà des pointes, contre 14 pour les anciennes bandes bleues. Les bords rouges suivent exactement la pente de la grille (dx/dy = 1/√3), à distance constante, sans élargissement en bout de côté. Le chemin gagnant porte un liseré et une ligne centrale dorés ; les autres cases sont atténuées. Aucun numéro ni coordonnée visible sur les cases ; labels accessibles par case, navigation fléchée et activation Entrée/Espace. Le conteneur défilant est lui-même un arrêt Tab, suivi du seul hexagone actif dans l’ordre Tab. Le plateau a un défilement horizontal sous 540 px pour garder des cases utilisables au toucher.
Moteur et données
src/lib/hex.mjs : moteur pur, sans DOM. BOARD_SIZES=[7,9,11,13]. initialHex(size=11, swapEnabled=true), neighbors(cell,size), winningPath(board,size,color), placeStone(state,cell), canSwap(state), swapSides(state). Le moteur accepte de 2 à 19 cases par côté ; l’interface propose quatre tailles. État : size, board (tableau par ligne : -1 vide, 0 bleu, 1 rouge), player (identité 0/1), colors (couleur possédée par chaque identité), moves (poses et échanges), swapEnabled, swapped, winner (identité ou null), path (cases du chemin gagnant).
Attention : après échange, identité du joueur et couleur sont différentes. winner est une identité, les valeurs de board sont des couleurs. winningPath utilise une recherche en largeur, rend un chemin continu ou []. Les transitions ne modifient pas l’entrée ; ne pas modifier les tableaux partagés en place. L’historique est dans le composant. En mode local, état uniquement en mémoire du composant : recharger perd la partie ; aucun stockage, appel serveur ou dépendance nouvelle.
Futur adversaire informatique (non implémenté)
Le moteur est déjà indépendant de Svelte et du DOM. Aucun Worker, algorithme de décision, adversaire automatique ni niveau de difficulté n’est implémenté. Les points ci-dessous décrivent les précautions pour une future intervention, pas des fonctionnalités disponibles.
Contrat à réutiliser
| Fonction | Utilisation pour un adversaire automatique |
|---|---|
| initialHex(size, swapEnabled) | Créer un état indépendant avec les mêmes réglages que la partie. |
| neighbors(cell, size) | Utiliser les six voisins axiaux du moteur ; ne pas remplacer par les huit voisins d’une grille carrée. |
| winningPath(board, size, color) | Détecter une connexion pour une couleur et obtenir un chemin ; renvoie [] sinon. |
| placeStone(state, cell) | Simuler une pose et vérifier immédiatement la victoire ; refuse une case occupée, hors plateau, ou une partie terminée. |
| canSwap(state) / swapSides(state) | Ajouter l’échange aux actions candidates uniquement lorsqu’il est autorisé ; simuler l’échange avec le moteur. |
Il n’existe pas de générateur d’actions complet : énumérer les cases vides ET l’action d’échange si canSwap(state). Arrêter la recherche si winner !== null. Ne pas interpréter moves comme le nombre de pions : l’échange compte également pour un tour. Après une pose gagnante, player reste le vainqueur ; sinon il passe à l’adversaire. Les états fournis doivent provenir du moteur : celui-ci ne valide pas intégralement des états arbitraires importés.
Couleurs, objectifs et échange
L’ordinateur doit être attaché à une identité de joueur (0 ou 1), et non définitivement au bleu ou au rouge. Sa couleur est colors[computerPlayer], ses bords dépendent de cette couleur. Après échange, le premier pion reste bleu à la même case : ce sont les propriétaires des couleurs et des bords qui changent. Ne pas appliquer en plus une transposition ou un recoloriage du premier pion.
Évaluer les positions du point de vue de l’identité choisie, en utilisant colors ; winner est une identité, tandis que board contient des couleurs. Une clé de cache doit inclure la taille, le plateau, le joueur au trait, les couleurs attribuées et le droit d’échange. Aucune limite de tours ni règle de nul du L Game ne doit être transférée à Hex.
Interface et calcul à prévoir
- Conserver le mode deux joueurs existant et la pose immédiate au clic ou au clavier. Pendant le tour de l’ordinateur, bloquer les poses humaines aussi bien à la souris qu’au clavier.
- Appliquer le résultat avec placeStone ou swapSides, puis réutiliser path pour le chemin doré et winner pour l’annonce. Ne pas écrire directement dans board ni introduire un second moteur de règles.
- Pour une recherche coûteuse, utiliser un Web Worker avec budget de calcul, annulation et identifiant de partie/requête. Ignorer une réponse périmée après annulation, nouvelle partie, changement de taille, changement de mode ou démontage du composant. Ne pas muter les tableaux partagés entre états.
- L’historique est actuellement un tableau d’états précédant chaque pose ou échange dans HexGame.svelte. Définir le comportement solo avec le propriétaire : annuler un seul tour ou revenir au dernier choix humain, notamment si un calcul est en cours.
- Définir aussi le choix du premier joueur, les difficultés et le temps de réflexion. Aucun algorithme ni niveau de force n’est arrêté ; ne pas promettre un jeu optimal ou une réactivité mobile sans mesure.
- Préserver le calcul local et l’absence d’envoi des coups au serveur, sauf demande explicite contraire. La géométrie du cadre SVG et le focus clavier restent des responsabilités de l’interface.
Tests à ajouter
Vérifier chaque action produite avec le moteur, les deux identités et couleurs, la victoire immédiate, une défense obligatoire, l’échange choisi ou refusé, et les différentes tailles. Contrôler le chemin et le vainqueur après échange. Tester les résultats périmés, l’annulation pendant la réflexion, la reprise après victoire, le verrouillage des entrées et la réactivité sur appareil mobile. Les tests existants couvrent les règles locales ; ils ne prouvent aucune qualité de décision de l’ordinateur.
Validation
node –test tests/hex.test.mjs : voisinage réciproque et bords, immutabilité, coups invalides, victoires des deux couleurs, connexions obliques, faux chemins, échange et propriété du vainqueur, absence de nul sur les 512 plateaux 3 × 3 remplis. Tester aussi dans le navigateur : pose, victoire, échange, annulation, nouvelle partie, réglages et clavier. Vérifier la disposition sur appareil tactile avant de la déclarer validée sur téléphone.
Règles consultées : https://exeterabstractgames.org.uk/sites/exeterabstractgames.org.uk/files/Hex%20Rules.pdf et https://en.wikipedia.org/wiki/Hex_(board_game).
Vérifications effectuées le 26 octobre 2026
- 5 tests Hex réussis ; suite complète : 95 tests réussis. Compilation du site réussie.
- Navigateur : présentation et plateau 11 × 11 inspectés ; passage à 7 × 7, pose, échange, annulation de cet échange, victoire complète du joueur 2 devenu bleu, chaîne gagnante, reprise après fin de partie, annulation des changements de réglages et navigation au clavier vérifiés lors de l’intégration initiale.
- Contrôle visuel dans une fenêtre de 790 px environ. Le défilement horizontal est prévu pour les petits écrans ; gestes tactiles et affichage sur téléphone réel non vérifiés.
- Catalogue actualisé après vérification de l’absence de fichiers non déclarés. Serveur 4321 conservé sans redémarrage.
Pose directe et cadre : vérifiés dans le navigateur sur 7 × 7 et 11 × 11. Une partie complète confirme le chemin doré, les autres cases atténuées, la victoire du joueur 1 et son bouton Annuler bleu. Annulation du premier coup vérifiée. Le moteur de règles reste inchangé.
Mode distant — 27 octobre 2026
L’hôte choisit la taille 7/9/11/13 et la règle d’échange avant le lancement ou une nouvelle partie acceptée. L’échange change les couleurs et les bords, jamais l’identité des joueurs ni les droits de l’hôte. Annuler restaure la dernière pose ou le dernier échange, couleurs et chemin compris.
OnlineLobby.svelte gère création, invitation, présence et consentement ; OnlineSettings.svelte gère les options de l’hôte. L’invité ne peut pas les changer. Les API contrôlent la rubrique de ce jeu et réutilisent son moteur pur. Plateaux/historiques en mémoire serveur, clé de place dans sessionStorage (hex-online-seat-v1). Recharger le même onglet retrouve le salon tant qu’il existe ; redémarrer le serveur le perd. Sélections préparatoires non envoyées non sauvegardées.
Annulation et nouvelle partie nécessitent l’accord adverse ; délai de demande d’une minute. Une coupure suspend le jeu et réserve la place cinq minutes par défaut. Ces délais et le plafond global sont décrits dans le contrat commun. La validation distante (tests de service, parties complètes, HTTP/SSE et scénario navigateur propre à ce jeu) est consignée dans cette fiche commune ; le tactile et l’hébergement public restent à valider. Les anciennes recettes datées ci-dessus restent un historique du mode local.
Revanche distante : le salon reste ouvert après victoire ou nul, jusqu’au départ ou à son expiration. Chaque nouvelle partie acceptée alterne le premier joueur (hôte, invité, hôte…), qui reçoit le joueur 1 et le bleu au départ. Les droits de l’hôte restent inchangés. Refus, retrait, expiration de demande, annulation de coup et reconnexion ne changent pas cet ordre. Voir les champs starterRole/playerIndex, délais et vérifications dans le contrat commun.