Changes outside of the package are mostly due to renaming WIN, LOSE, DRAW game results to _GAME to allow distinguishing from _ROUND in games which are played over multiple rounds where players may be eliminated before coming back for the next round.
Fixed a bunch of bugs in Love Letter
Simplified code
Introduced abstract class PlayCard that all Love Letter actions subclass (and offloading a bunch of the common code, variables and checks onto this class instead). Executes the "move card from player hand to their discard pile", then the card's effect, if any, and executable (not executable if everyone targettable is protected, for example).
Easier access to more game information for AI players / metrics system (and metrics updated too).
All actions return correct copies and toString methods for display in the GUI
GUI updated with a GUI listener for round change rather than the trickier check done previously
A thought on game result enums, currently often used to decide if a player should have actions generated for them or not. I see this more as a tree structure, i.e. 3 states are key, PLAYING (because game is ongoing, player is expected to make frequent decisions), PAUSE_PLAYING (if ROUND_WIN/LOSE, or just passed for the current round, but then coming back for more play later), and FINISHED_PLAYING (which can be due to WIN_GAME, LOSE_GAME, DRAW_GAME). I'm not sure if it's worth to rethink the structure of these a little for more clarity?
Changes outside of the package are mostly due to renaming WIN, LOSE, DRAW game results to _GAME to allow distinguishing from _ROUND in games which are played over multiple rounds where players may be eliminated before coming back for the next round.
A thought on game result enums, currently often used to decide if a player should have actions generated for them or not. I see this more as a tree structure, i.e. 3 states are key, PLAYING (because game is ongoing, player is expected to make frequent decisions), PAUSE_PLAYING (if ROUND_WIN/LOSE, or just passed for the current round, but then coming back for more play later), and FINISHED_PLAYING (which can be due to WIN_GAME, LOSE_GAME, DRAW_GAME). I'm not sure if it's worth to rethink the structure of these a little for more clarity?