main
8
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
|
29cc728f09 |
feat: distinction visuelle "achat en attente" avant résolution du tour
Après avoir cliqué sur ACHETER, aucune indication ne montrait que l'achat était pris en compte avant que la mini-carte définitive n'apparaisse à côté de la main (à la résolution du tour, plusieurs secondes plus tard). Le serveur exposait déjà pendingBuyItemId/pendingBuyBuildingId via getStateFor(), mais rien côté client ne les utilisait. - ItemBoardToken.js : nouveau paramètre `pending`. Quand actif, le jeton compact affiche un halo doré pulsant (tween alpha 1<->0.25 en boucle) et un texte "En attente..." sous l'icône, tant que l'achat n'est pas résolu. Le bouton ACHETER de la carte détaillée passe alors sur un libellé distinct "EN ATTENTE..." (au lieu de "INSUFFISANT", qui suggérerait à tort un problème de jauge) et devient non-cliquable, cohérent avec le refus déjà appliqué côté serveur pour une seconde tentative le même tour. Le tween est proprement arrêté dans destroy() (les jetons sont détruits/ recréés à chaque game-state). - GameScene.js : _buildItemTokens()/_buildBuildingTokens() déterminent `pending` à partir de state.pendingBuyItemId/pendingBuyBuildingId (déjà reçus du serveur, jamais consommés auparavant) et le passent au jeton correspondant, désactivant aussi son affordabilité pendant l'attente. shopChanged/buildingShopChanged comparent désormais aussi ces deux champs pour déclencher la reconstruction dès le clic sur ACHETER (avant, seul un changement de myItems/availableItems/jauges provoquait un rebuild). - Nouveau test E2E (item-shop.spec.js) : après achat, vérifie que le jeton correspondant a pending=true, affordable=false et un tween actif chez l'acheteur, que l'ADVERSAIRE ne voit PAS cet état "pending" (propre au joueur), et qu'après résolution du tour le jeton disparaît normalement de la boutique (comportement de stock unique déjà existant, inchangé). 54 tests unitaires client + 166 tests unitaires serveur + suite item-shop.spec.js (4 tests) au vert. |
||
|
Kevin L'Hereec
|
a5ecc23498 |
fix: bouton de confirmation désactivé après avoir sélectionné une carte, si une autre action réseau survient entretemps
Cause : le listener 'game-state' de GameScene se déclenche à CHAQUE action de N'IMPORTE QUEL joueur dans la salle (jouer une carte, acheter un objet ou un bâtiment, piocher/jouer un événement) — pas seulement au vrai changement de tour. À chaque déclenchement, dès que phase==='selecting', _deactivateBtn() était appelé INCONDITIONNELLEMENT, même si le joueur avait déjà sélectionné une carte de sa main (this.selectedCard non-null) sans encore l'avoir confirmée. Conséquence concrète : sélectionner une carte, PUIS effectuer n'importe quelle autre action (typiquement piocher une carte Événement) désactivait visuellement le bouton "CONFIRMER MA CARTE" (fond terne, texte grisé) alors que la carte restait réellement sélectionnée en mémoire ET visuellement surélevée sur le plateau (CardObject._selected reste true, jamais désélectionnée par ce chemin). Un premier clic sur la carte la DÉSÉLECTIONNAIT alors (CardObject._onDown bascule select/deselect selon _selected, déjà à true), obligeant à cliquer une seconde fois pour la vraiment resélectionner — exactement le symptôme rapporté. Fix : ne réinitialiser visuellement le bouton (_deactivateBtn()) que si aucune carte n'est actuellement sélectionnée (), respectant l'état réel de sélection au lieu de le réinitialiser à chaque game-state reçu. Nouveau test E2E de régression (e2e/tests/card-selection-persistence.spec.js) reproduisant précisément le scénario : sélectionner une carte, piocher un événement, vérifier que selectedCard ET le pulse-tween du bouton restent actifs, puis confirmer directement sans recliquer sur la carte. Confirmé discriminant : échoue de façon reproductible (2/2 tentatives) quand le fix est retiré isolément, passe systématiquement avec le fix en place. Ajout des helpers e2e/tests/helpers.js: selectHandCard() et confirmSelectedCard() (extraits de playCard(), qui reste inchangée en façade — les 5 usages existants de playCard() dans la suite E2E restent compatibles sans modification). 54 tests unitaires client + 166 tests unitaires serveur + suite game-flow.spec.js (4 tests, non liés à ce fix) toujours au vert. |
||
|
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
|
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
|
1726f8f96b |
feat: cartes Événement (pioche partagée de 18 cartes, 6 effets, synergies, ciblage)
- Nouveau server/src/game/events.js : 6 événements (Récolte exceptionnelle, Épidémie, Levée des troupes, Accord royal, Complot découvert, Grande fête au château), deck PARTAGÉ de 18 cartes (3 exemplaires de chacun) mélangé au démarrage de la partie. - Room.js : buyEventDraw() (coût fixe 1 point dans chacune des 4 jauges, effet immédiat contrairement aux objets/bâtiments — pas de conflit de stock possible), playEventCard() (choix de jouer une carte de sa main, max 1 par tour, avec ciblage optionnel), _resolvePendingEventPlays() (résolution de TOUS les événements du tour AVANT le calcul des gains de cartes personnage, défausse systématique, protection "Complot découvert" pour soi-même uniquement). Les 6 effets incluent leurs synergies avec les objets/bâtiments existants (Charrue, Trousse+Église pour Épidémie, Trébuchet, Sceau Royal, Château Royal → pioche bonus). - IMPORTANT : le ciblage de joueur (Accord royal, variante Trousse d'Épidémie) transite par teamIndex (identifiant public) et non socketId (jamais exposé au client via getPlayersInfo/getStateFor) — le serveur résout teamIndex -> joueur réel au moment de la résolution. - Nouvel event socket 'buy-event-draw' (effet immédiat) et 'play-event' (résolution différée), eventResults inclus dans round-result. - Client : events.js (miroir), EventCardObject.js (carte épurée façon CardObject, badge rouge "!" pour les événements à effet négatif). BootScene génère les textures plein cadre (méthode _generateClippedTexture généralisée, réutilisée avec les personnages). - GameScene : bouton de pioche à droite du bouton de confirmation (état grisé selon jauges/main pleine/pioche déjà tentée), seconde main de cartes événement (max 2) au-dessus de ce bouton, sélection d'une carte pour la jouer avec séquence de ciblage interactive (surbrillance des slots adversaires cliquables) pour Accord royal et la variante Trousse d'Épidémie. - 61 nouveaux tests unitaires serveur (events.js + Room.js : pioche, choix de jouer, résolution des 6 effets avec/sans synergie, Complot découvert, ordre événements-avant-personnages, deck partagé). - Nouveaux helpers et tests d'intégration E2E Playwright (e2e/tests/events.spec.js) pour la pioche, la limite de main à 2, et les 6 effets — certains scénarios restent probabilistes (pioche aléatoire dans le deck partagé) et peuvent nécessiter une stabilisation supplémentaire du timing. |
||
|
Kevin L'Hereec
|
9139989fa7 |
feat: bâtiments achetables (Église, Château Royal) avec synergie objets
- Nouveau server/src/game/buildings.js : 2 bâtiments, chacun couvrant 2 attributs, coût réparti sur les deux jauges, garantit +1 par tour sur chaque attribut, avec bonus de synergie +1 si l'objet correspondant est aussi possédé (Église+Trousse/Sceau, Château+Charrue/Trébuchet). - Room.js : buyBuilding() (validation coût multi-jauges), résolution des achats en attente avec la même priorité/stock unique que les objets, _applyBuildingEffects() (garantie de base + synergie, jamais de recul par rapport aux gains déjà boostés par un objet). getStateFor/getPlayersInfo exposent buildings/myBuildings/availableBuildings/pendingBuyBuildingId. - Nouvel event socket 'buy-building', boughtBuildings inclus dans round-result. - Client : buildings.js (miroir), BootScene génère les textures portrait des bâtiments (méthode _generatePortraitTexture généralisée, réutilisée avec les objets). ItemBoardToken généralisé (kind='item'|'building', hAnchor 'left'|'right') pour afficher indifféremment un objet ou un bâtiment, avec coût détaillé par jauge affiché sur la carte agrandie pour les bâtiments. - GameScene : boutique de bâtiments en colonne à DROITE du plateau (symétrique à la boutique d'objets à gauche), mes bâtiments possédés affichés à GAUCHE de ma main (symétrique à mes objets à droite), bâtiments des adversaires affichés sous leurs objets au niveau de leur slot. - Fix : la carte détaillée héritait par défaut d'un ancrage "s'étend vers la droite" adapté à la boutique d'objets (bord gauche du canvas) mais cassait la boutique de bâtiments (bord droit) — le bouton ACHETER se retrouvait hors du canvas et donc injoignable au clic. Ajout du paramètre hAnchor. - 26 nouveaux tests unitaires serveur (buildings.js + Room.js : validations d'achat multi-jauges, priorité/stock unique, effets de base et synergie). - 6 nouveaux tests E2E Playwright (boutique bâtiments : affichage, position, carte détaillée dans les limites du canvas, coût affiché, achat complet). - Fix flakiness des tests E2E d'achat (item-shop + building-shop) : le mode 'min' de playCard garantit désormais que l'adversaire joue sa carte la plus faible sur l'attribut ciblé, au lieu de simplement jouer un autre attribut (insuffisant, le gain dépend de la comparaison au voisin gauche). |
||
|
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.
|