Cross Plugin Communication

Cross-Plugin Communication

PGX separates compile-time dependency from runtime coordination.

Compile-time rule

Feature runtime plugins depend on PGXCore, not on sibling runtime plugins. This keeps the dependency graph inward-facing and prevents feature-to-feature cycles.

Runtime mechanisms

Typed messages

Core message channels are addressed by Gameplay Tags and carry typed payloads. They support listeners, broadcasts and diagnostic history. Bridge payloads allow one feature to publish state without importing another feature module.

Event handlers

The event-handler subsystem maps a Gameplay Tag to a handler class. Handler lifecycle can be ephemeral, cached or singleton. This is command/behavior resolution, not the same mechanism as message broadcast.

Interfaces and registries

Shared interfaces express stable capabilities such as saveable objects or tagged registry entries. Registries allow late discovery when a direct object reference would create unnecessary coupling.

Delegates

Domain delegates expose strongly typed local lifecycle notifications. Use a Core message when the receiver is optional or lives in a sibling plugin; use a direct delegate when the relationship is already within the same dependency boundary.

Example flow

sequenceDiagram
  participant Flow as PGXGameFlow
  participant Core as PGXCore Messages
  participant PSO as PGXPSO
  participant Loading as PGXLoading
  Flow->>Core: flow-state bridge payload
  Core->>PSO: matching state channel
  PSO->>Core: warm-up progress/completion
  Core->>Loading: loading presentation update
  Loading->>Core: temporary state request
  Core->>Flow: set or revert

Loading

No direct runtime Build.cs edge is required between these three feature plugins.