Steamforge Communication System Design: Messaging and Event Flow - wwestlake/Steamforge GitHub Wiki

Steamforge Communication System Design: Messaging and Event Flow

🧠 Communication System Design Goals

  • Systems (e.g., weather, time) act as publishers of events/state.
  • Listeners (e.g., pawns, crops, UI) subscribe or filter relevant messages.
  • Support scoped communication, avoiding global broadcast when unnecessary.
  • Messages are structured, interpretable, and extensible.
  • Senders emit state; listeners decide how to respond (decoupled behavior).

☁️ Example Use Case: Weather Communication

Actors and Roles

Actor Role
WeatherManager Publishes weather state changes
PlayerPawn Listens for nearby rain, spawns FX
CropActor Listens for rain, tracks water intake
UIController Optionally updates HUD with ambient state

Message Flow

  1. WeatherManager registers its CommunicationComponent as "WeatherSystem"
  2. Creates channel (e.g., "WeatherZone-001")
  3. Sends message:
    • MessageType = WeatherUpdate
    • Payload = { WeatherType: Rain, Intensity: 0.6, Region: Bounds }
  4. Listeners respond:
    • PlayerPawn spawns rain FX locally
    • CropActor begins hydration process
    • UIController may ignore or update display

🌄 Example Use Case: TimeKeeper Actor

Message Flow

  1. Registers as "TimeKeeper"
  2. Creates channel: "GlobalTimeEvents"
  3. Sends:
    • MessageType = TimeChange, Payload: "Sunrise"
    • MessageType = SeasonChange, Payload: "Spring"

Listener Reactions

  • Creatures shift behavior on "Sunrise"
  • Crops start growth cycle on "Spring"
  • Lighting system adjusts environment visuals

📊 System Mechanics Needed

1. Structured Messages

  • Move beyond simple FString Payload
  • Use structured data:
    • TMap<FString, FString>
    • FStruct or union-type data

2. Scoped Routing & Filtering

  • Messages delivered only if:
    • Subscribed to the channel
    • Explicitly addressed by ID
    • Metadata matches (e.g., region, tags)

3. Temporal / Stateful Messaging

  • Some messages represent ongoing state:
    • e.g., Rain continues until a stop/update message is sent
  • Support message lifecycle types:
    • BeginEvent, UpdateEvent, EndEvent

🧠 Listener Responsibilities

  • Interpret message type and payload
  • Decide local behavior
  • Remain decoupled from sender logic or identity

Next Steps

  • Define FCommMessage payload structure to support structured data
  • Specify channel access and filtering logic
  • Build sender/receiver usage patterns into test actors