🔗 Blueprint Communication and Variables

Why Blueprint Communication Matters

Imagine building a game where:

• A pressure plate needs to tell a door to open
• An enemy needs to know the player's location to chase them
• A UI widget needs to display the player's current health
• A collectible needs to notify the score manager when picked up
• Multiple lights need to turn on when the player flips a switch

Every one of these scenarios requires Blueprint communication—Blueprints sending messages, sharing data, or triggering actions in other Blueprints.

The Communication Challenge

Consider this scenario: You have a pressure plate Blueprint and a door Blueprint. The plate needs to tell the door "Player stepped on me—open up!" But how?

flowchart LR
    A[BP_PressurePlate] -->|How to communicate?| B[BP_Door]
    C[Player Character] -->|Steps on| A
    B -->|Opens| D[Door Opens]
    
    style A fill:#ff9800,stroke:#e65100,color:#fff
    style B fill:#2196F3,stroke:#1565c0,color:#fff
    style C fill:#4CAF50,stroke:#2e7d32,color:#fff
    style D fill:#9c27b0,stroke:#6a1b9a,color:#fff

Figure: Blueprints need mechanisms to communicate actions and data between each other.

The pressure plate can't just say "open the door" into thin air. It needs:

1. A reference: "Which door am I talking to?"
2. A communication method: "How do I tell it to open?"
3. Data sharing: "Does it need any information from me?"

This lesson teaches you all the ways Blueprints can communicate, from simple direct references to advanced event dispatching systems.

Communication Methods Overview

We'll cover each method in depth, starting with the foundation: variables.

Variables: Fundamentals

Before Blueprints can communicate effectively, you need to understand variables—the containers that store data.

Why Variables Matter

Variables are how Blueprints remember information:

• 💚 Player health: An integer variable (e.g., Health = 100)
• 🚪 Door state: A boolean variable (e.g., bIsOpen = false)
• 🎯 Enemy position: A vector variable (e.g., TargetLocation = (500, 200, 100))
• 📝 Player name: A string variable (e.g., PlayerName = "Hero")
• 🔗 Door reference: An object reference variable (e.g., DoorToOpen = BP_Door_Instance)

Without variables, Blueprints would have amnesia—unable to remember anything from one frame to the next.

Creating a Variable

1. Open a Blueprint
2. In My Blueprint panel, click + Variable
3. Name the variable (e.g., Health)
4. In Details panel, set the Variable Type (e.g., Integer)
5. Set Default Value (e.g., 100)
6. Click Compile to save

Using Variables in Blueprints

Once created, variables can be accessed in the Event Graph:

flowchart LR
    A[Get Variable] -->|Reads current value| B[Use in Logic]
    C[Set Variable] -->|Writes new value| D[Variable Updated]
    
    style A fill:#4CAF50,stroke:#2e7d32,color:#fff
    style B fill:#2196F3,stroke:#1565c0,color:#fff
    style C fill:#ff9800,stroke:#e65100,color:#fff
    style D fill:#9c27b0,stroke:#6a1b9a,color:#fff

Figure: Variables have two primary operations—Get (read) and Set (write).

Get Variable:

• Drag variable from My Blueprint panel into Event Graph
• Choose "Get"
• Creates a getter node that outputs the variable's current value
• Getters are "pure" (no execution pins)—they just return data

Set Variable:

• Drag variable from My Blueprint panel into Event Graph
• Choose "Set"
• Creates a setter node with execution pins
• Connect a new value to the input pin
• When executed, updates the variable

Figure: Get node reads variable value (pure function), Set node writes new value (requires execution).

Variable Properties

When you select a variable in My Blueprint, the Details panel shows configuration options:

Blueprint Data Types

Blueprint variables can hold many different types of data. Understanding data types is crucial for effective communication and data management.

Primitive Data Types

The basic building blocks—simple values:

Structural Data Types

Complex types that hold multiple related values:

Figure: Structural data types combine multiple values into cohesive units.

Reference Types

Variables that point to objects in the world:

Container Types (Collections)

Types that hold multiple values:

Array example: An array of Actor references to store all enemies in a level.

EnemyArray[0] = Enemy_1
EnemyArray[1] = Enemy_2
EnemyArray[2] = Enemy_3

Access by index: EnemyArray[0] gets first enemy.

Choosing the Right Data Type

flowchart TD
    A{What data do you need?} --> B{True/False state?}
    B -->|Yes| C[Boolean]
    B -->|No| D{Whole number?}
    D -->|Yes| E[Integer]
    D -->|No| F{Decimal number?}
    F -->|Yes| G[Float]
    F -->|No| H{Text?}
    H -->|Yes| I[String/Name/Text]
    H -->|No| J{3D position/direction?}
    J -->|Yes| K[Vector]
    J -->|No| L{Rotation?}
    L -->|Yes| M[Rotator]
    L -->|No| N{Reference to object?}
    N -->|Yes| O[Actor/Object Reference]
    N -->|No| P{Multiple items?}
    P -->|Yes| Q[Array/Set/Map]
    
    style C fill:#4CAF50,stroke:#2e7d32,color:#fff
    style E fill:#2196F3,stroke:#1565c0,color:#fff
    style G fill:#ff9800,stroke:#e65100,color:#fff
    style I fill:#9c27b0,stroke:#6a1b9a,color:#fff
    style K fill:#00bcd4,stroke:#006064,color:#fff
    style M fill:#f44336,stroke:#c62828,color:#fff
    style O fill:#ff5722,stroke:#d84315,color:#fff
    style Q fill:#795548,stroke:#4e342e,color:#fff

Figure: Decision tree for selecting the appropriate data type.

Variable Scope and Access

Not all variables are created equal—where and how they can be accessed depends on their scope.

The Three Levels of Scope

graph TD
    A[Variable Scopes] --> B[Local Variables]
    A --> C[Instance Variables]
    A --> D[Class Variables Static]
    
    B --> B1[Function/Macro only]
    B --> B2[Temporary data]
    B --> B3[Can't be accessed outside]
    
    C --> C1[Entire Blueprint]
    C --> C2[Each instance unique]
    C --> C3[Can expose to other BPs]
    
    D --> D1[Shared across all instances]
    D --> D2[Class-wide data]
    D --> D3[Rarely used in BP]
    
    style A fill:#667eea,stroke:#4527a0,color:#fff
    style B fill:#4CAF50,stroke:#2e7d32,color:#fff
    style C fill:#2196F3,stroke:#1565c0,color:#fff
    style D fill:#ff9800,stroke:#e65100,color:#fff
    style B1 fill:#e8f5e9,stroke:#4CAF50
    style B2 fill:#e8f5e9,stroke:#4CAF50
    style B3 fill:#e8f5e9,stroke:#4CAF50
    style C1 fill:#e3f2fd,stroke:#2196F3
    style C2 fill:#e3f2fd,stroke:#2196F3
    style C3 fill:#e3f2fd,stroke:#2196F3
    style D1 fill:#fff3e0,stroke:#ff9800
    style D2 fill:#fff3e0,stroke:#ff9800
    style D3 fill:#fff3e0,stroke:#ff9800

Figure: The hierarchy of variable scope from local (narrowest) to class (widest).

1. Local Variables

Local variables exist only within a single function or macro. They're created when the function starts and destroyed when it ends.

Creating local variables:

1. Inside a function, add a node that creates a variable (like "Make Vector")
2. Or: Right-click → "Promote to Variable" → Choose "Local Variable"
3. Local variables appear in the function's local variable list

Use cases:

• ✅ Temporary calculations within a function
• ✅ Loop counters
• ✅ Intermediate values you don't need to keep
• ✅ Prevents cluttering the Blueprint with unnecessary variables

2. Instance Variables (Most Common)

Instance variables are what you typically create—they're accessible throughout the entire Blueprint and unique to each instance.

Example: You place 3 doors in your level from BP_Door. Each door has its own bIsOpen variable—one door opening doesn't affect the others.

Use cases:

• ✅ Actor state (health, speed, isOpen)
• ✅ Configuration values (damage, range, color)
• ✅ References to other Actors
• ✅ Data that persists across function calls

3. Class Variables (Static)

Class variables are shared across ALL instances of a Blueprint. Changing one instance's class variable changes it for all.

Use cases:

• ⚠️ Rarely used in Blueprints (more common in C++)
• ✅ Global counters (e.g., total enemies spawned)
• ✅ Shared configuration data

Note: In Blueprints, you typically use a Game Instance or Game Mode for truly global data instead of class variables.

Access Levels

Variables also have access levels that control who can see and modify them:

Best Practices for Variable Scope

Example: Variable Scope in Action

Consider a CalculateDamage function in a weapon Blueprint:

Instance Variables (accessible everywhere in Blueprint):
  - BaseDamage (Float) = 50.0
  - DamageMultiplier (Float) = 1.5
  - LastDamageDealt (Float)

Function: CalculateDamage
  Local Variables (only exist in this function):
    - RandomBonus (Float) = Random between 0 and 10
    - FinalDamage (Float) = BaseDamage * DamageMultiplier + RandomBonus
  
  Set LastDamageDealt = FinalDamage
  Return FinalDamage

Why this structure?

• BaseDamage and DamageMultiplier are instance variables—they persist and can be configured per weapon
• RandomBonus and FinalDamage are local—temporary calculations, no need to store
• LastDamageDealt is instance—we want to remember it for debugging or UI display

Blueprint References

To make one Blueprint control another, you need a reference—a variable that points to the specific Blueprint instance you want to affect.

Why References Are Necessary

You can't just say "open the door" into the void. You need to specify which door. References solve this:

sequenceDiagram
    participant Lever as BP_Lever
    participant Door as BP_Door
    
    Note over Lever: Needs reference to Door
    
    Lever->>Lever: Get DoorReference variable
    Lever->>Door: Call "Open" function
    Door->>Door: Execute open logic
    Door-->>Lever: Done
    
    Note over Lever,Door: Communication succeeded because Lever had Door reference

Figure: References enable direct communication between Blueprint instances.

Creating References

There are several ways to establish references between Blueprints:

Method 1: Manual Assignment (Instance Editable)

1. In BP_Lever, create a variable: DoorToControl
2. Set type to Actor → BP_Door (object reference)
3. Check "Instance Editable"
4. Place both lever and door in your level
5. Select the lever instance
6. In Details panel, you'll see "Door To Control"
7. Click the eyedropper, then click the door in viewport to assign

Now the lever has a reference to that specific door!

Method 2: Search and Store (BeginPlay)

1. Create variable: PlayerReference (Actor → Character)
2. In Event BeginPlay:
   • Use "Get Player Character" node
   • Store result in PlayerReference variable
3. Now you can access player from anywhere in the Blueprint

Method 3: Collision/Overlap Detection

1. OnBeginOverlap event provides "Other Actor" pin
2. This is a reference to whatever touched you
3. You can store it or use it immediately

Method 4: Spawning

1. When you spawn an Actor, the Spawn node returns a reference to it
2. Store this reference to control the spawned Actor later

Get DoorReference → IsValid? → If valid, use it
                                    → If invalid, handle error

Casting: Type-Safe Communication

Having a reference is step one. But what if you have a generic "Actor" reference and need to access specific Blueprint functionality? That's where casting comes in.

Why Casting Is Necessary

When you get a reference from events like OnBeginOverlap, you often get a generic "Actor" reference. This could be anything—a player, a rock, a light, anything. To access specific functionality, you need to cast:

flowchart LR
    A[Generic Actor Reference] --> B{Cast to Specific Type}
    B -->|Success| C[Access Specific Functions/Variables]
    B -->|Failure| D[Not that type - handle accordingly]
    
    style A fill:#9e9e9e,stroke:#616161,color:#fff
    style B fill:#ff9800,stroke:#e65100,color:#fff
    style C fill:#4CAF50,stroke:#2e7d32,color:#fff
    style D fill:#e74c3c,stroke:#c0392b,color:#fff

Figure: Casting converts generic references to specific types, enabling type-specific access.

How to Cast

1. Have a reference (e.g., from OnBeginOverlap's "Other Actor" pin)
2. Right-click in graph → search "Cast to [BlueprintName]"
3. Example: "Cast to BP_Player"
4. Connect the reference to the cast node's Object input
5. The cast has two execution outputs:
   • Cast Succeeded: It was that type—proceed
   • Cast Failed: It wasn't that type—handle error
6. From "Cast Succeeded" output pin, you get a typed reference

Casting Example: Pressure Plate

Scenario: A pressure plate should only activate when the player steps on it, not enemies or props.

flowchart TD
    A[OnBeginOverlap Event] --> B[Get Other Actor]
    B --> C{Cast to BP_Player}
    C -->|Success| D[It's the player!]
    C -->|Failed| E[Not the player - ignore]
    D --> F[Open Door]
    E --> G[Do Nothing]
    
    style A fill:#e74c3c,stroke:#c0392b,color:#fff
    style B fill:#9e9e9e,stroke:#616161,color:#fff
    style C fill:#ff9800,stroke:#e65100,color:#fff
    style D fill:#4CAF50,stroke:#2e7d32,color:#fff
    style E fill:#9e9e9e,stroke:#616161,color:#fff
    style F fill:#2196F3,stroke:#1565c0,color:#fff
    style G fill:#757575,stroke:#424242,color:#fff

Figure: Casting filters overlaps to only respond to specific Actor types.

Blueprint nodes:

1. OnBeginOverlap (CollisionComponent) → Other Actor pin
2. Cast to BP_Player → Object = Other Actor
3. If cast succeeds → Player stepped on plate → Trigger door
4. If cast fails → Something else → Ignore

Casting Best Practices

Performance Note

Casting has a small performance cost. If you're casting every frame (Event Tick), consider caching the result:

❌ Bad:
Event Tick
  Get Other Actor → Cast to Player → Use Player

✅ Good:
Event BeginPlay
  Get Player → Cast to Player → Store in PlayerRef

Event Tick
  Use PlayerRef (no casting needed)

Direct Blueprint Communication

Once you have a reference and optionally cast it, you can directly communicate—call functions, access variables, trigger events.

Calling Functions

If BP_Door has a function called OpenDoor(), and you have a reference to it:

1. Drag the DoorReference variable into the graph (Get)
2. Drag from its output pin → search "OpenDoor"
3. Unreal shows all functions available on that Blueprint
4. Connect execution flow to call it

The function executes on that specific door instance.

Getting and Setting Variables

If a variable is public or instance editable, you can access it:

• Get variable: Drag from reference → search "Get [VariableName]"
• Set variable: Drag from reference → search "Set [VariableName]"

Example: Check if door is open:

Get DoorReference → Get bIsOpen → Branch (if true, do something)

Common Communication Pattern

sequenceDiagram
    participant A as BP_Button
    participant B as BP_Door
    
    Note over A: Player presses button
    A->>A: OnInteract Event fires
    A->>A: Get DoorReference
    A->>B: Call OpenDoor()
    B->>B: Set bIsOpen = true
    B->>B: Play animation
    B->>B: Play sound
    B-->>A: Function complete
    
    Note over A,B: Direct communication via reference + function call

Figure: Complete direct communication sequence from button press to door opening.

Blueprint Interfaces

What if you want to send the same message to many different Blueprint types without casting to each one? Use Blueprint Interfaces.

The Interface Problem

Imagine a game where explosions should damage nearby objects. But different objects respond differently:

• Player: Reduce health, play hurt animation
• Enemy: Reduce health, ragdoll if dead
• Crate: Break apart, spawn loot
• Door: Take damage, open when health reaches 0

Without interfaces, you'd need to cast to each type and call different functions. With interfaces, you create one "TakeDamage" message that all implement.

flowchart TD
    A[Explosion Blueprint] --> B[Send TakeDamage message]
    B --> C[Interface: I_Damageable]
    C --> D[BP_Player implements]
    C --> E[BP_Enemy implements]
    C --> F[BP_Crate implements]
    C --> G[BP_Door implements]
    
    D --> D1[Reduce health]
    E --> E1[Reduce health + ragdoll]
    F --> F1[Break apart]
    G --> G1[Damage door]
    
    style A fill:#ff9800,stroke:#e65100,color:#fff
    style B fill:#2196F3,stroke:#1565c0,color:#fff
    style C fill:#9c27b0,stroke:#6a1b9a,color:#fff
    style D fill:#4CAF50,stroke:#2e7d32,color:#fff
    style E fill:#4CAF50,stroke:#2e7d32,color:#fff
    style F fill:#4CAF50,stroke:#2e7d32,color:#fff
    style G fill:#4CAF50,stroke:#2e7d32,color:#fff

Figure: Interfaces allow one message to reach multiple Blueprint types, each responding uniquely.

Creating a Blueprint Interface

1. Content Browser → Right-click → Blueprint Interface
2. Name it (e.g., BPI_Damageable)
3. Open it
4. Add functions (e.g., "TakeDamage")
   • Define inputs (DamageAmount, DamageType)
   • Define outputs (if needed)
   • No implementation—just signatures
5. Save and close

Implementing an Interface

1. Open a Blueprint (e.g., BP_Player)
2. Class Settings → Interfaces → Add → Choose your interface
3. In Event Graph or Functions, you'll see interface functions listed
4. Right-click → Implement event "TakeDamage"
5. Add your custom logic (for player: reduce health, play sound, etc.)

Calling Interface Functions

Instead of casting, you call the interface directly:

1. Have a reference to an Actor (any Actor)
2. Drag from it → search "TakeDamage" (the interface message)
3. Choose the interface version (blue icon)
4. Connect inputs (DamageAmount, etc.)
5. If the Actor implements the interface, it receives and handles the message
6. If it doesn't implement it, nothing happens (no error)

Interface vs. Casting

Event Dispatchers

Event Dispatchers are Unreal's publish-subscribe system—one Blueprint broadcasts an event, multiple others can listen and respond.

When to Use Event Dispatchers

Perfect for one-to-many communication where the sender doesn't know (or care) who's listening:

• ✅ Player collects a coin → Update UI, play sound, trigger achievement check
• ✅ Boss dies → Close doors, spawn loot, start victory sequence, update quest
• ✅ Button pressed → Open multiple doors, activate lights, trigger cutscene
• ✅ Wave completed → Update score, spawn next wave, display message

flowchart TD
    A[Event Dispatcher: OnBossDeath] --> B[Broadcast]
    B --> C[Listener 1: UI Widget]
    B --> D[Listener 2: Level Door]
    B --> E[Listener 3: Quest Manager]
    B --> F[Listener 4: Music Controller]
    
    C --> C1[Show Victory Screen]
    D --> D1[Open Exit Door]
    E --> E1[Complete Quest]
    F --> F1[Play Victory Music]
    
    style A fill:#ff9800,stroke:#e65100,color:#fff
    style B fill:#e74c3c,stroke:#c0392b,color:#fff
    style C fill:#2196F3,stroke:#1565c0,color:#fff
    style D fill:#2196F3,stroke:#1565c0,color:#fff
    style E fill:#2196F3,stroke:#1565c0,color:#fff
    style F fill:#2196F3,stroke:#1565c0,color:#fff
    style C1 fill:#4CAF50,stroke:#2e7d32,color:#fff
    style D1 fill:#4CAF50,stroke:#2e7d32,color:#fff
    style E1 fill:#4CAF50,stroke:#2e7d32,color:#fff
    style F1 fill:#4CAF50,stroke:#2e7d32,color:#fff

Figure: Event Dispatchers broadcast to multiple listeners simultaneously.

Creating an Event Dispatcher

1. Open the broadcasting Blueprint (e.g., BP_Boss)
2. My Blueprint panel → Event Dispatchers → + Event Dispatcher
3. Name it (e.g., OnBossDeath)
4. In Details, add inputs if needed (e.g., DeathLocation, LootToSpawn)
5. Compile

Broadcasting (Calling) the Dispatcher

1. In the broadcaster's Event Graph, when the event occurs:
2. Drag the Event Dispatcher into the graph
3. Choose "Call [DispatcherName]"
4. Connect execution flow
5. Provide any input values

Example: Boss death logic:

Health <= 0 → Call OnBossDeath → Pass (DeathLocation, LootType)

Binding to (Listening to) the Dispatcher

In the listening Blueprint (e.g., Level Blueprint, UI Widget):

1. Get a reference to the broadcasting Actor (Boss)
2. Drag from that reference → search for the dispatcher name
3. Choose "Bind Event to [DispatcherName]"
4. This creates a custom event node
5. Wire your response logic to that custom event

When the broadcaster calls the dispatcher, all bound custom events fire.

Event Dispatcher Example: Collectible System

Scenario: When player collects a coin, multiple systems need to know.

BP_Coin (Broadcaster):

1. Create Event Dispatcher: OnCoinCollected (inputs: CoinValue)
2. OnBeginOverlap (player touches coin):
   → Call OnCoinCollected (Value = 10)
   → Destroy Actor

BP_ScoreManager (Listener 1):

BeginPlay:
  Get All Actors of Class (BP_Coin)
  For each coin:
    → Bind to OnCoinCollected
    → When fired: Add CoinValue to TotalScore

WBP_HUD (Listener 2 - UI Widget):

Construct:
  Get All Actors of Class (BP_Coin)
  For each coin:
    → Bind to OnCoinCollected
    → When fired: Update score text display

Result: One coin collection triggers multiple responses—score increases, UI updates, sound plays—without the coin knowing about any of them!

Choosing the Right Communication Method

With multiple communication options, how do you choose? Here's a decision guide:

flowchart TD
    A{Communication Scenario} --> B{One sender, one receiver?}
    B -->|Yes| C{Do you have direct reference?}
    C -->|Yes| D[Direct Communication: Call functions/set variables]
    C -->|No| E{Can you get reference easily?}
    E -->|Yes| F[Get reference + Direct Communication]
    E -->|No| G{Same message to different types?}
    
    B -->|No| H{One sender, many receivers?}
    H -->|Yes| I[Event Dispatcher]
    
    G -->|Yes| J[Blueprint Interface]
    G -->|No| K{Need specific Blueprint functionality?}
    K -->|Yes| L[Casting + Direct Communication]
    K -->|No| M[Consider redesigning architecture]
    
    style D fill:#4CAF50,stroke:#2e7d32,color:#fff
    style F fill:#4CAF50,stroke:#2e7d32,color:#fff
    style I fill:#ff9800,stroke:#e65100,color:#fff
    style J fill:#9c27b0,stroke:#6a1b9a,color:#fff
    style L fill:#2196F3,stroke:#1565c0,color:#fff

Figure: Decision tree for selecting the appropriate Blueprint communication method.

Method Comparison

Real-World Examples

Summary

Blueprint communication and variables are the glue that connects individual Blueprints into cohesive gameplay systems. Master these concepts and you can build anything from simple door mechanics to complex multiplayer games.

Key Takeaways

• 📦 Variables store data—from simple booleans to complex object references—with three scope levels (local, instance, class)
• 🔢 Data Types include primitives (Boolean, Integer, Float, String), structures (Vector, Rotator, Transform), references (Actor, Object), and containers (Array, Set, Map)
• 🔗 References are pointers to specific Actors—without them, Blueprints can't communicate
• 🎯 Casting converts generic references to specific types, enabling type-safe access to unique functionality
• 📞 Direct Communication via references allows calling functions and accessing variables on other Blueprints
• 🔌 Blueprint Interfaces define contracts that multiple types implement, enabling flexible messaging without tight coupling
• 📡 Event Dispatchers broadcast events to multiple listeners without the broadcaster needing references—perfect for one-to-many communication
• 🧭 Choosing Methods: Direct reference for 1-to-1, interfaces for same-message-different-types, dispatchers for broadcasting
• ✅ Best Practices: Validate references, cache frequently-used references, use appropriate scope, minimize casting in Tick

What's Next?

Now that you understand how Blueprints communicate, the next lesson explores Lesson 3.3: Blueprint Flow Control and Logic. You'll learn conditionals (Branch, Switch), loops (For, While), sequences, gates, and how to build complex decision-making systems that bring your gameplay to life.