 |
Cockatrice 2026-09-01-Development-3.1.0-beta.10
A virtual tabletop for multiplayer card games
|
|
Cockatrice 2026-09-01-Development-3.1.0-beta.10
A virtual tabletop for multiplayer card games
|
PlayerEventHandler is responsible for applying player-scoped game events to a single Player instance. These events modify the player’s board state, zones, cards, counters, arrows, and associated UI and logging output.
Each PlayerEventHandler instance is bound 1:1 to a Player and is invoked exclusively by GameEventHandler after basic routing and validation of incoming server events.
This class represents the lowest-level authoritative application of game state changes on the client.
PlayerEventHandler operates under the following guarantees:
As a result, the handler does not perform rule validation or permission checks. Its responsibility is to apply state, not decide legality.
The primary responsibility of PlayerEventHandler is to mutate player-owned state, including:
Many handlers update both logical state and visual/UI state in tandem.
Some events—most notably card movement—require coordinated updates across multiple systems. For example, eventMoveCard():
This makes PlayerEventHandler intentionally stateful and tightly coupled to the board implementation.
Rather than writing directly to logs or widgets, PlayerEventHandler emits structured Qt signals describing what happened, including:
These signals are consumed by logging systems and UI components, keeping presentation concerns out of the handler.
Logging signals may be emitted before or after mutation, depending on whether later changes would invalidate log data (e.g. card identity).
Although bound to a single player, some events necessarily affect other players’ state, including:
In these cases, PlayerEventHandler performs the minimal required mutation while respecting ownership boundaries enforced elsewhere.
PlayerEventHandler exposes a single public entry point:
This method:
This keeps the event routing centralized and makes it easy to audit coverage when new game events are introduced.
Unhandled events are logged as warnings.
For clarity, event handlers are grouped conceptually into:
This grouping mirrors the structure of the header file and reflects the conceptual responsibilities of the class.
PlayerEventHandler is never instantiated or invoked directly by UI code. Instead:
This separation keeps game-wide logic decoupled from player board state and makes reconnection and replay handling simpler.
PlayerEventHandler is designed to be:
PlayerEventHandler is responsible for applying player-scoped game events to a single Player instance. These events modify the player’s board state, zones, cards, counters, arrows, and associated UI and logging output.
Each PlayerEventHandler instance is bound 1:1 to a Player and is invoked exclusively by GameEventHandler after basic routing and validation of incoming server events.
This class represents the lowest-level authoritative application of game state changes on the client.
PlayerEventHandler operates under the following guarantees:
As a result, the handler does not perform rule validation or permission checks. Its responsibility is to apply state, not decide legality.
The primary responsibility of PlayerEventHandler is to mutate player-owned state, including:
Many handlers update both logical state and visual/UI state in tandem.
Some events—most notably card movement—require coordinated updates across multiple systems. For example, eventMoveCard():
This makes PlayerEventHandler intentionally stateful and tightly coupled to the board implementation.
Rather than writing directly to logs or widgets, PlayerEventHandler emits structured Qt signals describing what happened, including:
These signals are consumed by logging systems and UI components, keeping presentation concerns out of the handler.
Logging signals may be emitted before or after mutation, depending on whether later changes would invalidate log data (e.g. card identity).
Although bound to a single player, some events necessarily affect other players’ state, including:
In these cases, PlayerEventHandler performs the minimal required mutation while respecting ownership boundaries enforced elsewhere.
PlayerEventHandler exposes a single public entry point:
This method:
This keeps the event routing centralized and makes it easy to audit coverage when new game events are introduced.
Unhandled events are logged as warnings.
For clarity, event handlers are grouped conceptually into:
This grouping mirrors the structure of the header file and reflects the conceptual responsibilities of the class.
PlayerEventHandler is never instantiated or invoked directly by UI code. Instead:
This separation keeps game-wide logic decoupled from player board state and makes reconnection and replay handling simpler.
PlayerEventHandler is designed to be:
1.16.1