main
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Kevin L'Hereec
|
fcad0f5d88 |
fix: le HUD mettait à jour les compteurs des joueurs trop tôt pendant la résolution du tour
Cause : le serveur émet 'round-result' (déclenche l'animation de révélation
des cartes/gains sur le plateau Phaser, ~3.5s avant le tour suivant) et
'game-state' en phase 'resolve' (déjà avec les jauges/scores post-résolution
via getPlayersInfo) au même instant. Le HUD Vue (alimenté directement par
gameStore.players) sautait donc à ses nouvelles valeurs INSTANTANÉMENT, en
même temps que l'animation de résolution démarrait tout juste sur le
plateau — les compteurs changeaient avant/pendant que le joueur voie
l'animation qui justifie ce changement, au lieu d'être synchronisés avec
elle.
Fix : le store Pinia (client/src/stores/game.js) gèle désormais
players/currentTurn pendant toute la phase 'resolve' — les valeurs reçues
sont stockées dans un buffer interne (_pendingPlayers/_pendingCurrentTurn)
au lieu d'être appliquées immédiatement, et ne sont propagées à l'affichage
qu'au game-state suivant dont la phase n'est PLUS 'resolve' (typiquement
'selecting' du tour suivant, ou 'end'). Le reste de l'état (phase, main,
objets/bâtiments/événements) continue de se mettre à jour normalement et
immédiatement — seul l'affichage des jauges/scores est différé.
6 nouveaux tests unitaires (game.store.test.js) couvrant le gel/dégel du
buffer, la rediffusion de plusieurs game-state en phase 'resolve'
successifs, la transition directe vers 'end', et le nettoyage du buffer
par reset().
Nouveau test E2E (hud-resolution-timing.spec.js) confirmé discriminant :
échoue de façon reproductible (2/2 tentatives) sans le fix ("0 pts" attendu
pendant resolve, "5 pts" déjà affiché), passe systématiquement avec le fix
(stable sur 3 répétitions). Attente active de la phase 'resolve' via
expect.poll plutôt qu'un délai fixe, pour éviter la fenêtre d'observation
manquée sous charge variable.
60 tests unitaires client + 166 tests unitaires serveur + suite
game-flow.spec.js (4 tests, non liée à ce fix) toujours au vert.
|
||
|
Kevin L'Hereec
|
33a3c20dcb |
fix: la carte détaillée d'un événement débordait sous le canvas au survol
ItemBoardToken._showExpanded() ancrait TOUJOURS la carte détaillée vers le
BAS du jeton compact, quel que soit son emplacement sur le plateau —
adapté aux boutiques d'objets/bâtiments (positionnées en haut du canvas),
mais pas à la main de cartes Événement (positionnée en BAS du canvas,
voir eventHandLayout.js) : la carte (jusqu'à 266px de haut avec le bouton
JOUER) débordait alors largement sous le bas de l'écran, la rendant
invisible et son bouton totalement injoignable au clic.
- Ajout du paramètre vAnchor ('bottom' par défaut, 'top' pour les jetons
proches du bas de l'écran) sur ItemBoardToken, symétrique au hAnchor déjà
existant pour l'axe horizontal. La main d'événements passe désormais
vAnchor='top' pour que la carte s'étende vers le HAUT au lieu du bas.
- Extraction du calcul de décalage (expandedCardOffset) et des constantes
de dimensionnement (EXPANDED_W/H, BUY_BTN_H) dans tokenLayout.js (module
pur, sans dépendance Phaser) pour pouvoir le couvrir par de vrais tests
unitaires Vitest.
- 11 nouveaux tests unitaires (tokenLayout.test.js) : orientation dx/dy
selon hAnchor/vAnchor, alignement exact du bord du jeton avec le bord de
la carte, et surtout la régression elle-même — un test vérifie que
vAnchor='top' maintient la carte dans les limites du canvas pour un
jeton en bas d'écran (1080p et 720p), et qu'un test symétrique confirme
que l'ancien comportement implicite (vAnchor='bottom') débordait bien
sous le canvas dans ce même scénario.
- 54 tests unitaires client au vert au total (43 précédents + 11 nouveaux),
vérification privilégiée par rapport à une nouvelle suite E2E (lente vu
la pioche aléatoire à stabiliser dans ce projet).
|
||
|
Kevin L'Hereec
|
1a91a0f876 |
fix: cartes Événement illisibles + objets/bâtiments adversaires au-dessus de leur carte
Deux problèmes de lisibilité/placement signalés : 1. Le texte des cartes Événement (nom + description) restait illisible malgré le passage précédent de l'échelle 0.55 à 0.8 — le composant dédié EventCardObject affichait une grande carte réduite, écrasant systématiquement le texte quelle que soit l'échelle choisie. Fix : suppression complète d'EventCardObject, remplacé par le même pattern que les objets/bâtiments (ItemBoardToken, nouveau kind='event') : un petit jeton compact (46x46) toujours visible sur le plateau, avec la carte détaillée affichée en TAILLE RÉELLE (police 13-16px, jamais réduite) au survol de la souris, et un bouton "JOUER" (au lieu d'"ACHETER") pour confirmer. ItemBoardToken généralisé pour supporter ce 3e kind (pas de badge de coût affiché — déjà payé à la pioche — mais badge "!" repris pour les événements à effet négatif type Épidémie). Extraction de client/src/game/objects/tokenLayout.js (ICON_SIZE) dans un module SANS dépendance à Phaser, pour que eventHandLayout.js (et ses tests Vitest) puisse l'importer sans jamais charger Phaser — qui échoue à l'import en environnement jsdom (canvas natif requis, absent de jsdom). 2. Les mini-cartes objets/bâtiments déjà achetés par un ADVERSAIRE étaient affichées SOUS son slot de jeu, visuellement en dessous/après sa carte jouée. Déplacées AU-DESSUS de son slot pour les mettre davantage en évidence, comme posées sur sa carte plutôt que cachées dessous. - 43 tests unitaires client mis à jour (eventHandLayout.test.js migré vers ICON_SIZE au lieu de CARD_W/CARD_H/scale, désormais indépendant de Phaser). - e2e/tests/helpers.js : playEventCard adapté au nouveau flux survol->bouton JOUER (au lieu d'un simple clic direct sur la carte) ; drawEventUntil corrigé pour ne jamais défausser une carte 'royal_accord' sans fournir ses 2 cibles de ciblage séquentiel obligatoire (le jeu sans cible bloquait silencieusement la séquence, sans jamais émettre 'play-event', rendant la boucle de pioche très peu fiable). - Vérification ciblée via un test E2E existant (pas de nouvelle suite E2E lourde, conformément à la demande de privilégier les tests unitaires) : le nouveau flux jeton->survol->JOUER->résolution fonctionne bout en bout (Récolte exceptionnelle +2 Nourriture confirmé après résolution). |
||
|
Kevin L'Hereec
|
45eb9be60d |
fix: repositionner les cartes Événement en bas-droite avec un texte lisible
Les cartes Événement (bouton de pioche + main) étaient positionnées trop près du bouton "CONFIRMER MA CARTE" — le bouton de pioche chevauchait même physiquement son bord droit de ~25px (x = width/2 + 210, même Y), au point de prêter à confusion entre "piocher un événement" et "jouer une carte". - Nouveau module pur client/src/game/objects/eventHandLayout.js (eventDrawButtonPosition, eventHandGeometry, eventCardPosition) : ancre toute la zone événement en bas-DROITE du canvas, clairement séparée du bouton de confirmation (centré) et de la main de personnages (centrée). - EVENT_CARD_SCALE remonté de 0.55 à 0.8 pour que le nom de l'événement (police de base augmentée 12px -> 15px) reste réellement lisible une fois réduit — ajout d'un bandeau semi-opaque derrière le texte (EventCardObject) pour garantir le contraste quel que soit le portrait en arrière-plan. - La légende des attributs occupait déjà le coin bas-droit : déplacée en bas-GAUCHE (setOrigin ajusté en conséquence) pour laisser la place à la nouvelle zone événement. - 16 nouveaux tests unitaires Vitest (eventHandLayout.test.js) couvrant la géométrie : positions dans les limites du canvas, absence de chevauchement avec le bouton de confirmation/la main/la légende, ancrage stable au bord droit avec 1 ou 2 cartes, robustesse sur petite résolution (1280x720) et cardCount=0. Choix explicite de tests UNITAIRES (rapides, ~600ms pour toute la suite client) plutôt que E2E pour cette correction de positionnement pur, les tests E2E de ce projet étant lents (plusieurs minutes par scénario à cause de la pioche aléatoire à stabiliser). |
||
|
Kevin L'Hereec
|
44d4eb7e96 |
fix: bugs critiques du système d'événements + stabilisation E2E
Trois bugs fonctionnels réels découverts et corrigés en stabilisant les tests E2E des cartes Événement : 1. client/src/stores/game.js — le store Pinia n'exposait JAMAIS les champs liés aux bâtiments (myBuildings, pendingBuyBuildingId, availableBuildings) ni aux événements (myEventHand, eventDeckSize, hasPendingEventDraw, pendingEventPlayId) : updateState() ne les lisait pas depuis le 'game-state' serveur. Conséquence concrète : GameScene._epidemicNeedsTarget() lisait this.store.myBuildings (toujours vide) pour décider si la variante Église d'Épidémie s'applique — le ciblage de la variante Trousse ne fonctionnait donc jamais correctement dès qu'un joueur possédait aussi le Château. Corrigé + 4 nouveaux tests unitaires Vitest. 2. client/src/game/scenes/GameScene.js — GameScene._onEventCardSelected envoyait encore les clés historiques gainTargetSocketId/ loseTargetSocketId/targetSocketId au serveur, alors que Room.js avait été migré vers gainTargetTeamIndex/loseTargetTeamIndex/targetTeamIndex (socketId n'est jamais exposé au client). Conséquence : le ciblage d'Accord royal et de la variante Trousse d'Épidémie était intégralement cassé en jeu réel — les clés ne correspondant à rien côté serveur, aucune cible n'était jamais appliquée, silencieusement. 3. e2e/tests/helpers.js — drawEventUntil abandonnait immédiatement dès que la main d'événements atteignait 2 cartes sans contenir l'id recherché, rendant les tests E2E d'événements extrêmement flaky (avec seulement 6 types d'événements et une main de 2, l'échec dès les 2 premières pioches est fréquent, pas rare). Corrigé : joue désormais une carte pour libérer un slot et continue à piocher jusqu'à maxDraws (20). Stabilisation supplémentaire : - Toutes les fonctions d'introspection Phaser dans helpers.js sécurisées (optional chaining) contre une scène pas encore initialisée après un changement de tour/navigation sous charge (plusieurs pages Playwright simultanées). - Timeouts des tests events.spec.js augmentés (150-240s) pour laisser le temps aux boucles d'accumulation de jauge + pioche aléatoire de converger. - playwright.config.js : retries=1 même en local, pour absorber la variance résiduelle des tests basés sur un tirage aléatoire, tout en gardant une détection fiable des vraies régressions (qui échoueraient de façon reproductible sur les deux tentatives). - events.spec.js : test 'Accord royal' fournit désormais les 2 cibles requises par le ciblage séquentiel (gain + perte) au lieu d'une seule, ce qui laissait la séquence de ciblage bloquée sans jamais émettre 'play-event'. Résultat : 166 tests unitaires serveur + 28 tests unitaires client toujours au vert ; suite events.spec.js (9 tests E2E) passe intégralement (certains via retry probabiliste documenté, comportement attendu vu la pioche aléatoire dans le deck partagé). |
||
|
Kevin L'Hereec
|
11cba0467b |
feat: écran de fin de partie + tests unitaires client et E2E Playwright
- Fix: UIScene n'était jamais lancée (active: false, jamais scene.launch)
donc l'event 'game-over' du serveur n'était jamais affiché — la partie
semblait ne pas avoir de fin. Remplacé par un panneau Vue dans GameView
(vainqueur, classement trié, bouton Quitter via vue-router). UIScene.js
supprimée (code mort).
- Extraction de client/src/utils/hudUtils.js (constantes ATTRS/couleurs et
gaugePercent) depuis GameView.vue pour les rendre testables isolément.
- Tests unitaires client (Vitest) : store Pinia (game.js) et hudUtils
(24 tests, client/test/unit/).
- Tests d'intégration E2E (Playwright, e2e/) avec de vrais clients
Socket.io et rendu Phaser réel dans Chromium :
* game-flow.spec.js : lobby → démarrage → main de 4 cartes → résolution
* item-shop.spec.js : boutique, bouton désactivé si jauge insuffisante,
achat retire l'objet pour tous + effet appliqué + affiché sur la table
* game-over.spec.js : partie complète (12 tours) → panneau de fin
webServer démarre automatiquement client+serveur ; ajout d'une route
GET /health côté Express pour permettre à Playwright de détecter un
serveur déjà démarré.
- README : documentation des 3 niveaux de tests (unitaires serveur,
unitaires client, intégration E2E) et de la nouvelle arborescence.
|