View Categories

Event Manager

16 min read

Event Manager #

Table of Contents #

  • Overview
  • Core Concepts
    • What is the Event Manager?
    • Use Cases
    • Event-Driven Architecture
  • Components
    • Event Manager Component
    • Event Registration
    • Event Triggering
  • Setting Up Event Manager
    • On Player Controller (Player-Specific Events)
    • On Game State (Global Events)
    • Event Naming Convention
  • Registering to Events
    • Register Event Function
    • Unregister Event Function
    • Common Registration Patterns
  • Triggering Events
    • Trigger Event Function
    • Event Return Values
    • Event Parameters
  • Integration with Other Systems
    • Inventory System (Add/Remove Item)
    • Quest System (Quest Rewards)
    • Attribute Manager (Add XP/Reputation)
    • Custom System Integration
  • Example Implementations
    • Quest Reward System
    • Global World Events
    • Multi-System Coordination
  • How To Guides
    • Setting Up Inventory Event Integration
    • Creating Custom Events
    • Setting Up Global World Events
  • OVERVIEW

The Event Manager is a lightweight, powerful event system that enables loosely-coupled communication between game systems. It allows components to register to events and trigger them without direct actor references.

Core Features:

  • Register components to specific events
  • Trigger events with parameters and return values
  • Player-specific events (Player Controller)
  • Global world events (Game State)
  • Loosely-coupled architecture (no direct references needed)
  • Return success/failure values from events
  • Simple to implement, highly extensible

Common Applications:

  • Quest reward distribution (add items, XP, reputation)
  • Inventory system integration (add/remove/check items)
  • Achievement tracking
  • Global world state changes
  • Multi-system coordination
  • Save/load triggers
  • UI refresh events

The Power of Loose Coupling:

Instead of having your quest system directly reference the inventory system to add items, the quest system simply triggers an “Add Item” event. The inventory system listens for this event and handles it. This means:

  • Systems don't need to know about each other
  • Easy to add new systems that respond to existing events
  • Modular, maintainable architecture
  • Systems can be enabled/disabled independently
See Also: Quest System documentation, Inventory System documentation for integration examples.

Core concepts #

What is the Event Manager? #

The Event Manager is a component-based system that facilitates event-driven communication between game systems.

Two Core Functions:

  • Register to Events: Components subscribe to specific events they want to listen for
  • Trigger Events: Systems broadcast events that registered listeners will receive

Event Flow:

System A (Quest System):

  • Trigger Event: “Add Item”
  • Parameters: Item ID, Quantity

Event Manager:

  • Receives “Add Item” event
  • Finds all registered listeners
  • Calls each listener's bound function

System B (Inventory System):

  • Registered to “Add Item” event
  • Receives parameters
  • Adds item to inventory
  • Returns success/failure

No Direct References:

The quest system doesn't need a reference to the inventory system. It just triggers an event. This makes systems:

  • Modular: Add/remove systems independently
  • Reusable: Events can be used by multiple systems
  • Maintainable: Changes to one system don't break others
  • Testable: Systems can be tested in isolation

Event Types:

  • Player Events: Specific to individual players (on Player Controller)
  • Global Events: Affect the entire world (on Game State)

Use Cases #

Quest Reward Distribution:

Quest completes → Trigger “Add Item” event → Inventory system adds reward items automatically.

This is implemented in the quest system integration. Quest data tables specify rewards, and events handle distribution.

Inventory Management:

  • Add Item Event: Triggered when items need to be added (quest rewards, pickups, crafting)
  • Remove Item Event: Triggered when items are consumed (crafting, usage)
  • Has Item Event: Check if player has specific items (quest requirements, vendor purchases)

This is implemented with return values. Has Item returns true/false, Add Item returns success/failure.

Attribute System Integration:

  • Add XP Event: Triggered when player gains experience
  • Add Reputation Event: Triggered when faction reputation changes
  • Level Up Event: Triggered when player levels up

These are examples of how you can integrate with our Attribute Manager or other progression systems (sold separately).

Global World Events:

  • Boss Defeated Event: Global event when world boss dies
  • Area Captured Event: Territory control changes
  • Time of Day Event: Triggered at dawn/dusk
  • Weather Change Event: Global weather state changes

These are examples of global events you can implement using Event Manager on Game State.

Achievement Tracking:

  • Any achievement-relevant action triggers an event
  • Achievement system listens and tracks progress
  • Loosely coupled from gameplay systems

UI Refresh:

  • Inventory changes → Trigger “Inventory Updated” event → UI refreshes
  • Attribute changes → Trigger “Stats Updated” event → HUD updates
  • No need for UI to constantly poll data

Event-Driven Architecture #

The Event Manager implements an event-driven architecture pattern.

Traditional Approach (Tightly Coupled):

Quest System:

  • Get reference to Inventory Component
  • Call Add Item function directly
  • Get reference to Attribute Manager
  • Call Add XP function directly
  • Get reference to UI Widget
  • Call Update Display function directly

Problems:

  • Quest system needs to know about all other systems
  • Hard to add new systems
  • Changes cascade through dependencies
  • Difficult to test in isolation

Event-Driven Approach (Loosely Coupled):

Quest System:

  • Trigger “Add Item” event (Item ID, Quantity)
  • Trigger “Add XP” event (XP Amount)
  • Trigger “Quest Completed” event (Quest ID)

Other Systems:

  • Inventory listens to “Add Item” and adds items
  • Attribute Manager listens to “Add XP” and adds XP
  • UI listens to “Quest Completed” and updates display
  • Achievement system listens to “Quest Completed” and tracks progress
Benefits:
  • Quest system only knows about Event Manager
  • Easy to add new listeners (achievements, analytics, etc.)
  • Systems are modular and independent
  • Easy to test each system separately

Key Advantages:

  • Decoupling: Systems don't reference each other
  • Extensibility: Add new listeners without changing event triggers
  • Maintainability: Changes to one system don't affect others
  • Reusability: Same events can be used by multiple systems
  • Testing: Each system can be tested independently

This architecture makes your codebase more maintainable and scalable as your project grows.

Components #

Event Manager Component #

The Event Manager Component handles event registration and triggering.

Component Locations:

On Player Controller (Player-Specific Events):

  • Add Event Manager Component to BP_PlayerController
  • Handles events specific to individual players
  • Examples: Add item to player's inventory, add XP to player, player-specific achievements

On Game State (Global Events):

  • Add Event Manager Component to BP_GameState
  • Handles events that affect the entire world
  • Examples: Boss defeated, area captured, global weather change, server-wide announcements

When to Use Which:

  • Player Controller: Events that affect individual players (inventory, stats, quests)
  • Game State: Events that affect the world or all players (global state changes, world events)

Multiple Event Managers:

You can have both simultaneously:

Player Controller Event Manager:

  • Add Item (player-specific)
  • Complete Quest (player-specific)
  • Gain XP (player-specific)

Game State Event Manager:

  • Boss Defeated (global)
  • Server Shutdown Warning (global)
  • Time of Day Change (global)

This separation keeps player events isolated while allowing global coordination.

Event Registration #

Registering to an event means subscribing a function to be called when that event is triggered.

Parameters:

  • Event Name: String or gameplay tag identifying the event (e.g., “Add Item”, “Quest Completed”)
  • Callback Function: Custom event or function to call when event is triggered

How It Works:

  • Component calls Register Event with event name and function reference
  • Event Manager stores this registration
  • When event is triggered, Event Manager calls all registered functions
  • Each registered function receives event parameters
Example – Inventory Registering to Add Item:

Inventory Component – Begin Play:

  1. Get Event Manager from Player Controller
  2. Register Event(“Add Item”, Handle Add Item)
  3. Now when “Add Item” is triggered, Handle Add Item function is called

Multiple Registrations:

Multiple systems can register to the same event:

“Add Item” event can be registered by:

  • Inventory System (adds item to inventory)
  • Achievement System (tracks items collected)
  • Quest System (checks for quest item updates)
  • UI System (updates inventory display)

All will be called when “Add Item” is triggered.

Important – Cleanup:

Unregister events when component is destroyed to prevent errors:

On Component Destroyed:

  • Unregister Event(“Add Item”)

Event Triggering #

Triggering an event broadcasts it to all registered listeners.

Trigger Function:

Trigger Event(Event Name, Parameters)

Returns: Success/Failure (optional)

Parameters:

  • Event Name: String or gameplay tag identifying the event
  • Parameters: Data to pass to listeners (item ID, quantity, etc.)

How It Works:

  • System calls Trigger Event with event name and parameters
  • Event Manager finds all registered listeners for that event
  • Event Manager calls each listener's function with parameters
  • Listeners process event and optionally return success/failure
  • Event Manager returns combined result to caller
Example – Quest Triggering Add Item:

Quest Completed:

  1. Get reward items from quest data table
 - Reward 1: Item ID "Sword_Iron", Quantity 1
 - Reward 2: Item ID "Gold_Coin", Quantity 50
  1. Trigger Event(“Add Item”, Item ID: “Sword_Iron”, Quantity: 1)
  2. Trigger Event(“Add Item”, Item ID: “Gold_Coin”, Quantity: 50)
  3. Inventory System receives events and adds items

Return Values:

Events can return success/failure:

Has Item Event:

  • Trigger Event(“Has Item”, Item ID: “Key_Red”)
  • Inventory checks if key exists
  • Returns true (has key) or false (doesn't have key)
  • Caller uses return value for logic (unlock door, show message)

This allows events to be used for queries, not just commands.

Setting up event manager #

On Player Controller (Player-Specific Events) #

Set up Event Manager on Player Controller for player-specific events.

Setup Steps:

  • Open BP_PlayerController
  • Add Event Manager Component
  • Component is now ready to register/trigger player events

Common Player Events:

  • Add Item (player inventory)
  • Remove Item (player inventory)
  • Has Item (player inventory check)
  • Add XP (player progression)
  • Add Reputation (player faction standing)
  • Quest Completed (player quest state)
  • Achievement Unlocked (player achievements)

Event Manager Reference:

Other components get reference to Event Manager from Player Controller:

Get Player Controller → Get Event Manager Component → Register/Trigger Events

Multiplayer Considerations:

Each player has their own Player Controller and Event Manager. Events are isolated per player:

Player 1 triggers “Add Item”:

  • Only Player 1's inventory receives event
  • Player 2's inventory is unaffected

Each player's Event Manager is independent.

On Game State (Global Events) #

Set up Event Manager on Game State for global world events.

Setup Steps:

  • Open BP_GameState
  • Add Event Manager Component
  • Component is now ready to register/trigger global events

Common Global Events:

  • Boss Defeated (world boss killed)
  • Area Captured (territory control change)
  • Time of Day Changed (day/night cycle)
  • Weather Changed (global weather state)
  • Server Announcement (server-wide message)
  • World State Changed (any global state)

Event Manager Reference:

World actors get reference to Event Manager from Game State:

Get Game State → Get Event Manager Component → Register/Trigger Events

Example – Boss Defeated Event:

Boss Dies:

  1. Get Game State Event Manager
  2. Trigger Event(“Boss Defeated”, Boss ID: “Dragon_Fire”)
  3. All registered listeners receive event:
 - Quest system checks if quest requires this boss
 - Achievement system unlocks "Dragon Slayer"
 - World manager spawns new content
 - UI shows global announcement

When to Use Global Events:

  • Events that affect all players
  • World state changes
  • Events that multiple world actors need to know about
  • Server-wide announcements or state changes

Event Naming Convention #

Consistent event naming makes the system easier to use and maintain.

Recommended Naming:

  • Use descriptive action names
  • Use consistent verb tense (Add Item, not Adding Item or Item Added)
  • Consider using gameplay tags instead of strings for type safety

Common Event Names:

  • Add Item: Add item to inventory
  • Remove Item: Remove item from inventory
  • Has Item: Check if item exists in inventory
  • Add XP: Add experience points
  • Add Reputation: Modify faction reputation
  • Quest Completed: Quest finished successfully
  • Boss Defeated: Global boss killed
  • Area Captured: Territory control changed

Using Gameplay Tags for Events (Optional):

You can use gameplay tags instead of strings:

Event

├─ Event.Inventory.AddItem
├─ Event.Inventory.RemoveItem
├─ Event.Inventory.HasItem
├─ Event.Quest.Completed
├─ Event.World.BossDefeated
└─ Event.World.AreaCaptured
Benefits:
  • Type safety (no typos)
  • Autocomplete in editor
  • Hierarchical organization
  • Easier to refactor

Consistency is Key:

Document your event names and parameters so all systems use them consistently.

Registering to events #

Register Event Function #

Components register to events to receive notifications when those events are triggered.

Parameters:

  • Event Name: The name of the event to listen for (string or gameplay tag)
  • Callback Function: Your custom event/function to call when event triggers

When to Register:

Typically register in Begin Play or when component is initialized:

Inventory Component – Begin Play:

  1. Get Player Controller
  2. Get Event Manager Component
  3. Register Event(“Add Item”, On Add Item)
  4. Register Event(“Remove Item”, On Remove Item)
  5. Register Event(“Has Item”, On Has Item)

Creating Callback Functions:

Create custom events or functions to handle the event:

On Add Item (Custom Event):

Parameters:

  • Item ID (String)
  • Quantity (Integer)

Logic:

  1. Receive parameters from Event Manager
  2. Add item to inventory array
  3. Return success or failure
Example – Full Registration:

Inventory Component:

Begin Play:

  1. Get Event Manager from Player Controller
  2. Register Event(“Add Item”, On Add Item Event)

On Add Item Event (Custom Event):

Parameters: Item ID, Quantity

  1. Find item in inventory
  2. If found, increase quantity
  3. If not found, add new item
  4. Return true (success)

Common Registration Patterns #

Pattern 1: Single System Registration:

Inventory Component:

  • Registers to: Add Item, Remove Item, Has Item
  • Purpose: Manage player inventory based on events

Pattern 2: Multi-System Registration:

Same event, multiple listeners:

“Add Item” event registered by:

  1. Inventory System (adds item)
  2. Achievement System (tracks collection)
  3. Quest System (checks quest progress)
  4. UI System (updates display)

All receive the same event and handle it independently.

Pattern 3: Conditional Registration:

Achievement System:

Begin Play:

  1. For each achievement:
 - If achievement tracks item collection:
 - Register Event("Add Item", Check Achievement Progress)
 - If achievement tracks boss kills:
 - Register Event("Boss Defeated", Check Achievement Progress)
  1. Dynamically register based on achievement requirements

Pattern 4: Temporary Registration:

Mini-Game Component:

On Mini-Game Start:

  • Register Event(“Item Collected”, Award Mini-Game Points)

On Mini-Game End:

  • Unregister Event(“Item Collected”)

Only listen to events during specific gameplay moments.

Triggering events #

Trigger Event Function #

Trigger events to notify all registered listeners.

Function Signature:

Trigger Event(Event Name, Parameters…)

Returns: Boolean (Success/Failure)

Parameters:

  • Event Name: The event to trigger (string or gameplay tag)
  • Parameters: Data to pass to listeners (varies by event)

Basic Triggering:

Quest System – On Quest Completed:

  1. Get reward from quest data table
 - Item ID: "Sword_Iron"
 - Quantity: 1
  1. Get Event Manager from Player Controller
  2. Trigger Event(“Add Item”, Item ID: “Sword_Iron”, Quantity: 1)
  3. Event Manager calls all registered listeners
  4. Inventory System receives event and adds item

Where to Trigger From:

  • Quest System: Trigger Add Item for quest rewards
  • Pickup Actors: Trigger Add Item when player collects item
  • Crafting System: Trigger Add/Remove Item for crafting
  • Combat System: Trigger Add XP when enemy defeated
  • World Events: Trigger Boss Defeated when boss dies
  • Any System: Trigger custom events for your gameplay

Getting Event Manager Reference:

For Player Events:

  • Get Player Controller → Get Event Manager Component

For Global Events:

  • Get Game State → Get Event Manager Component

Event Return Values #

Events can return success/failure values, making them useful for queries.

Return Value Types:

  • Boolean: True (success) / False (failure)
  • Custom: Could be extended to return other data types
Example – Has Item Event:

Door Requires Key:

  1. Trigger Event(“Has Item”, Item ID: “Key_Red”)
  2. Inventory System checks if key exists
  3. Returns true or false
  4. Door uses return value:
 - If true: Open door
 - If false: Show "Locked" message
Example – Add Item Event:

Pickup Item:

  1. Trigger Event(“Add Item”, Item ID: “Potion_Health”, Quantity: 1)
  2. Inventory System tries to add item
  3. Returns success or failure:
 - Success: Inventory had space, item added
 - Failure: Inventory full, cannot add
  1. Pickup actor uses return value:
 - If success: Destroy pickup actor
 - If failure: Show "Inventory Full" message, don't destroy pickup

Multiple Listeners with Return Values:

If multiple systems are registered to same event, Event Manager combines return values:

“Add Item” registered by:

  1. Inventory System (returns true if added)
  2. Achievement System (returns true if tracked)

Event Manager returns true only if ALL listeners return true.

This ensures all systems successfully handled the event.

Event Parameters #

Events can pass any data needed by listeners.

Common Parameter Patterns:

Add Item Event:

Parameters:

  • Item ID (String): Which item to add
  • Quantity (Integer): How many to add
Example:

Trigger Event(“Add Item”, “Sword_Iron”, 1)

Remove Item Event:

Parameters:

  • Item ID (String): Which item to remove
  • Quantity (Integer): How many to remove
Example:

Trigger Event(“Remove Item”, “Potion_Health”, 5)

Has Item Event:

Parameters:

  • Item ID (String): Which item to check
Example:

Trigger Event(“Has Item”, “Key_Red”)

Add XP Event:

Parameters:

  • XP Amount (Integer): How much XP to add
Example:

Trigger Event(“Add XP”, 100)

Quest Completed Event:

Parameters:

  • Quest ID (String): Which quest was completed
Example:

Trigger Event(“Quest Completed”, “MainQuest_001”)

Boss Defeated Event:

Parameters:

  • Boss ID (String): Which boss was defeated
  • Player Who Killed (Actor): Player who got killing blow
Example:

Trigger Event(“Boss Defeated”, “Dragon_Fire”, Player Reference)

Custom Parameters:

You can create events with any parameters your systems need:

Custom Event – “Weather Changed”:

Parameters:

  • Old Weather (Enum)
  • New Weather (Enum)
  • Transition Duration (Float)

All listeners receive these parameters and can respond accordingly.

Parameter Best Practices:

  • Keep parameters simple and consistent
  • Document expected parameters for each event
  • Use meaningful names
  • Consider using structs for complex parameter sets

How to guides #

Creating Custom Events #

Step-by-step guide to create your own custom events.

Step 1: Define Your Event #

Decide:

  • Event Name: What will you call the event?
  • Parameters: What data does the event pass?
  • Return Value: Does it return success/failure or other data?
Example: “Player Damaged” event
  • Parameters: Damage Amount, Damage Type, Attacker Reference
  • Return Value: Boolean (Was damage applied?)

Step 2: Create Event Listener #

  • Open component that should listen to event (e.g., Health Component)
  • In Begin Play:
    • Get Event Manager (from Player Controller or Game State)
    • Register Event(“Player Damaged”, On Player Damaged)

Step 3: Create Event Handler Function #

Create Custom Event: On Player Damaged

Parameters:

  • Damage Amount (Float)
  • Damage Type (Enum or String)
  • Attacker (Actor Reference)

Return Value: Boolean (Success)

Implementation:

  1. Receive parameters
  2. Apply damage to health
  3. Check for death
  4. Return true if damage applied

Step 4: Trigger Your Event #

In damage dealing code (e.g., Weapon Blueprint):

  1. Get Event Manager from target's Player Controller
  2. Trigger Event(“Player Damaged”, Damage: 50, Type: “Fire”, Attacker: Self)
  3. Event Manager calls all registered listeners
  4. Health Component receives event and applies damage

Step 5: Add More Listeners (Optional) #

Other systems can listen to same event:

UI System:

  • Register Event(“Player Damaged”, Update Health Bar)
  • When event triggers, update health display

Achievement System:

  • Register Event(“Player Damaged”, Track Damage Taken)
  • Track damage taken for achievements

Analytics System:

  • Register Event(“Player Damaged”, Log Damage Event)
  • Log for telemetry

Step 6: Document Your Event #

Document in your project:

Event: “Player Damaged”

Parameters:

  • Damage Amount (Float): Amount of damage dealt
  • Damage Type (String): Type of damage (“Physical”, “Fire”, “Ice”, etc.)
  • Attacker (Actor Reference): Who dealt the damage

Return Value: Boolean – true if damage was applied, false if blocked/immune

Triggers: When player takes damage from any source

Listeners: Health Component, UI System, Achievement System

This ensures all team members use the event consistently.

Setting Up Global World Events #

Step-by-step guide to set up global events using Game State Event Manager.

Step 1: Add Event Manager to Game State #

  • Open BP_GameState
  • Add Event Manager Component (if not already present)
  • Component is ready for global events

Step 2: Create Global Event Trigger #

Example: Boss Defeated Event
  • Open BP_Boss_Dragon (or your boss blueprint)
  • On death:
    • Get Game State
    • Get Event Manager Component from Game State
    • Trigger Event(“Boss Defeated”, Boss ID: “Dragon_Fire”, Killer: Player Reference)

Step 3: Register Listeners on Player Controllers #

For player-specific responses:

Quest Component (on Player Controller):

Begin Play:

  1. Get Game State
  2. Get Event Manager Component from Game State
  3. Register Event(“Boss Defeated”, On Boss Defeated)

On Boss Defeated Handler:

Parameters: Boss ID, Killer

  1. Check if active quests require this boss
  2. If yes, mark objective complete

Step 4: Register Listeners on World Actors #

For world-level responses:

World Manager (on Game State or Level Blueprint):

Begin Play:

  1. Get Game State
  2. Get Event Manager Component from Game State
  3. Register Event(“Boss Defeated”, On Boss Defeated)

On Boss Defeated Handler:

Parameters: Boss ID, Killer

  1. Update world state
  2. Save boss defeat status
  3. Start boss respawn timer
  4. Spawn new world content

Step 5: Test Global Event #

  1. Place boss in level
  2. Start game with multiple players (if multiplayer)
  3. Kill boss
  4. Verify event triggers
  5. Verify all players receive event
  6. Verify world state updates
  7. Check that all registered listeners responded

Step 6: Create More Global Events #

Common global events to add:

“Time Of Day Changed”:

  • Parameters: Old Time, New Time
  • Triggered by: Day/Night cycle system
  • Listeners: AI (behavior changes), Lighting, World events

“Weather Changed”:

  • Parameters: Old Weather, New Weather
  • Triggered by: Weather system
  • Listeners: AI, Effects, World actors

“Area Captured”:

  • Parameters: Area ID, Capturing Team
  • Triggered by: Territory control system
  • Listeners: Spawn points, UI, Quest system

Best Practices for Global Events:

  • Use Game State Event Manager for events affecting all players
  • Use Player Controller Event Manager for player-specific events
  • Document which Event Manager to use for each event type
  • Ensure event names are unique and descriptive
  • Always unregister listeners to prevent errors
  • —

END OF DOCUMENTATION

See Also:
  • Quest System Documentation
  • Inventory System Documentation
  • Attribute Manager Documentation
  • Gameplay Tag Component Documentation
What are your Feelings