GameEvent refactor

[MostCromulent]

@tool4ever here is the GameEvent refactor.

This has been done based on the refactor plan which has been updated to reflect implementation. See implementation notes section for deviations from original plan.

I have not had a chance to test in depth yet - but unit test is succesful and local network testing indicates client is at least playing sounds now.

In relation to subgame events Claude ran into an issue, summarised below:

Subgame Event Reclassification — Options

The Problem

The event refactor (Step 5) added blanket forwarding of all GameEvents to remote clients via handleGameEvent(). The two subgame events (GameEventSubgameStart, GameEventSubgameEnd) contain Game references — not serializable, and their handlers do host-only GUI wiring (subscribing to EventBus, switching GameView, iterating PlayerControllerHuman). Forwarding these to a remote client would fail at serialization and is conceptually wrong — they're local lifecycle signals.

Per your earlier feedback, these should be reclassified as UiEvent to create a clean dividing line: GameEvent = networked game state, UiEvent = local GUI concerns.

The Constraint

SubgameEffect (in forge-game) creates and fires both events. UiEvent is defined in forge-gui. forge-game cannot depend on forge-gui — the dependency goes the other way. There is no existing precedent for forge-game code firing UiEvents; all 3 current UiEvent types are created exclusively in forge-gui input handlers.

Option A: Filter in Forwarding Code

Skip subgame events in the HostedMatch.receiveGameEvent() forwarding loop with an instanceof check.

• Pros: 2-line change, zero architectural disruption
• Cons: No type-system enforcement — the dividing line is a runtime check, not a compile-time guarantee. Future GameEvent types that shouldn't be forwarded would need additional filters.

Option B: LocalGameEvent Marker Interface in forge-game

Create a new interface LocalGameEvent extends GameEvent in forge-game. Subgame events implement LocalGameEvent instead of GameEvent directly.
Forwarding code skips any LocalGameEvent instance.

• Pros: Type-system enforced dividing line within forge-game. Any future host-only events can implement LocalGameEvent. No module boundary issues.
• Cons: Requires removing subgame visit methods from IGameEventVisitor and updating all 5 visitor implementations. A new concept (LocalGameEvent) that's effectively a subset of GameEvent — not as clean as GameEvent vs UiEvent.

Option C: Replace Events with Callback Hooks

Remove the subgame events entirely. SubgameEffect calls hooks on Game or Match (like the existing startGameHook/endGameHook pattern in
HostedMatch). HostedMatch registers the hooks during game setup.

• Pros: Cleanest separation — subgame lifecycle exits the event system entirely. No forwarding concern. Follows existing precedent (startGameHook, endGameHook).
• Cons: Most invasive. Requires refactoring SubgameEffect to use callbacks, and moving the GUI wiring logic from event visitors into hook implementations. Changes the execution model (hooks are synchronous callbacks vs EventBus dispatch).