feat: interface de combat dynamique (#57) #67

Merged

Reliodas merged 1 commit from feature/57-dynamic-combat-ui into develop

2026-06-22 07:05:54 +00:00

Reliodas commented

2026-06-22 07:04:32 +00:00

Owner

Closes #57.

Adapte l'interface de combat au membre actif au lieu d'une barre codée pour le Guerrier initial. Neuvième pierre du jalon 0.16.0 (dépend de #49 et #54). Le menu, les panneaux et le prompt suivent désormais l'acteur dont c'est le tour, et la barre d'actions est construite à partir des capacités réellement disponibles.

Changements

Descripteur CombatAction (scripts/combat_action.gd) : id, label, kind (ATTACK/DODGE/SECOND_WIND/MOVE/END_TURN/FLEE), enabled, requires_target.
CombatController.available_actions() fournit la liste pour l'acteur actif, avec les drapeaux enabled calculés depuis l'état courant. Second Wind n'apparaît que si l'acteur actif possède la feature → deux classes exposent des menus différents. execute_action(id, target) exécute l'action par identifiant (attaque/esquive/Second Wind/fin de tour).
CombatOverlay construit sa barre d'actions à partir de ces descripteurs (visibilité + état dérivés des capacités disponibles) au lieu d'encoder des règles de classe : plus d'appel direct à has_second_wind()/can_player_attack() dans l'overlay. Les boutons sont inertes hors tour joueur (donc pendant les tours automatiques). Le panneau « joueur » et le prompt (PV, déplacement) suivent l'acteur actif contrôlable. Les actions passent par execute_action(id).

Critères d'acceptation

changer d'acteur actif met à jour portrait, PV, déplacement et actions ;
deux classes différentes exposent des menus différents (Guerrier→Second Wind, Prêtre→non) ;
les boutons sont inertes pendant les tours automatiques (descripteurs enabled = false hors tour joueur) ;
un membre à terre ou absent n'est pas présenté comme contrôlable (panneau/menu liés à l'acteur actif contrôlable) ;
l'interface reste utilisable en solo ;
tests couvrent au moins deux acteurs, deux ensembles de capacités et un tour ennemi.

Tests

Suite GUT complète verte : 270 tests / ~880 assertions (depuis 264), stable sur 4 exécutions.

tests/unit/test_combat_actions.gd : le Guerrier expose Second Wind, le Prêtre non (menus différents) ; requires_target réservé à l'attaque ; toutes les actions inertes hors tour joueur ; Attaquer actif au contact ; exécution par id (execute_action), id inconnu sans effet.
tests/unit/test_combat_overlay.gd : tests existants mis à jour sur _action_buttons (Second Wind visible pour le Guerrier, absent pour le Magicien ; resynchro après un tour ennemi).

Validation manuelle (différée au #58)

Le rendu visuel (portrait/PV qui basculent quand le tour passe à un allié PLAYER, panneaux multiples) sera vérifié dans Godot au #58. Le portrait reste pour l'instant le panneau de PV de l'acteur actif (pas d'illustration dédiée au stade prototype).

Closes #57. Adapte l'interface de combat au membre actif au lieu d'une barre codée pour le Guerrier initial. Neuvième pierre du jalon 0.16.0 (dépend de #49 et #54). Le menu, les panneaux et le prompt suivent désormais l'acteur dont c'est le tour, et la barre d'actions est construite à partir des capacités réellement disponibles. ## Changements - **Descripteur `CombatAction`** (`scripts/combat_action.gd`) : `id`, `label`, `kind` (ATTACK/DODGE/SECOND_WIND/MOVE/END_TURN/FLEE), `enabled`, `requires_target`. - **`CombatController.available_actions()`** fournit la liste pour l'**acteur actif**, avec les drapeaux `enabled` calculés depuis l'état courant. **Second Wind n'apparaît que si l'acteur actif possède la feature** → deux classes exposent des menus différents. **`execute_action(id, target)`** exécute l'action par identifiant (attaque/esquive/Second Wind/fin de tour). - **`CombatOverlay`** construit sa barre d'actions à partir de ces descripteurs (visibilité + état dérivés des capacités disponibles) au lieu d'encoder des règles de classe : plus d'appel direct à `has_second_wind()`/`can_player_attack()` dans l'overlay. Les boutons sont inertes hors tour joueur (donc pendant les tours automatiques). Le panneau « joueur » et le prompt (PV, déplacement) **suivent l'acteur actif contrôlable**. Les actions passent par `execute_action(id)`. ## Critères d'acceptation - [x] changer d'acteur actif met à jour portrait, PV, déplacement et actions ; - [x] deux classes différentes exposent des menus différents (Guerrier→Second Wind, Prêtre→non) ; - [x] les boutons sont inertes pendant les tours automatiques (descripteurs `enabled = false` hors tour joueur) ; - [x] un membre à terre ou absent n'est pas présenté comme contrôlable (panneau/menu liés à l'acteur actif contrôlable) ; - [x] l'interface reste utilisable en solo ; - [x] tests couvrent au moins deux acteurs, deux ensembles de capacités et un tour ennemi. ## Tests Suite GUT complète verte : **270 tests / ~880 assertions** (depuis 264), stable sur 4 exécutions. - `tests/unit/test_combat_actions.gd` : le Guerrier expose Second Wind, le Prêtre non (menus différents) ; `requires_target` réservé à l'attaque ; toutes les actions inertes hors tour joueur ; Attaquer actif au contact ; exécution par id (`execute_action`), id inconnu sans effet. - `tests/unit/test_combat_overlay.gd` : tests existants mis à jour sur `_action_buttons` (Second Wind visible pour le Guerrier, absent pour le Magicien ; resynchro après un tour ennemi). ### Validation manuelle (différée au #58) Le rendu visuel (portrait/PV qui basculent quand le tour passe à un allié PLAYER, panneaux multiples) sera vérifié dans Godot au #58. Le portrait reste pour l'instant le panneau de PV de l'acteur actif (pas d'illustration dédiée au stade prototype).

Reliodas added 1 commit

2026-06-22 07:04:33 +00:00

feat: interface de combat dynamique liée à l'acteur actif (#57 )

ci/woodpecker/push/woodpecker Pipeline was successful

Details

ci/woodpecker/pr/woodpecker Pipeline was successful

Details

ci/woodpecker/pull_request_closed/woodpecker Pipeline was successful

Details

556eab43d9

Nouveau descripteur CombatAction (id, label, kind, enabled, requires_target).
CombatController.available_actions() fournit le menu de l'acteur actif et
execute_action(id, target) l'exécute par identifiant. Le menu n'expose
Second Wind que si l'acteur actif possède la feature — deux classes
affichent donc des menus différents, sans règle de classe codée dans
l'overlay.

CombatOverlay construit sa barre d'actions à partir de ces descripteurs
(visibilité/état dérivés des capacités réellement disponibles, boutons
inertes hors tour joueur) et lie son panneau « joueur » à l'acteur actif
contrôlable (PV et déplacement suivent le changement d'acteur).

Tests : test_combat_actions.gd (Guerrier expose Second Wind, Prêtre non —
menus différents ; requires_target ; inerte hors tour joueur ; exécution
par id) ; tests d'overlay existants mis à jour sur _action_buttons. Cas
solo inchangé. Suite 270 tests, stable sur 4 exécutions.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>