Client RPC — call a function on a specific client from the server

Custom Event → Replicates = 'Run On Owning Client'. Only executes on the client that owns this actor. Use for player-specific UI updates, messages, sounds.

Multiplayer: Server RPC for damage, Multicast RPC for effects

Pattern for shooting in multiplayer: ON CLIENT: InputAction Shoot → ServerRPC_Shoot (Custom Event, Run On Server, Reliable). ServerRPC_Shoot (runs on SERVER): LineTraceByChannel → Branch(hit) → ApplyDamage → MulticastRPC_PlayEffect(ImpactPoint). MulticastRPC_PlayEffect (Custom Event, Multicast, Unreliable): SpawnNiagaraSystemAtLocation(NS_BulletImpact, ImpactPoint). Key rules: - Server RPC: Custom Event → Replicates='Run On Server', Reliable=true. - Multicast: Custom Event → Replicates='Multicast', Reliable=false (VFX can be dropped). - Client RPC: Custom Event → Replicates='Run On Owning Client'. - Never directly modify replicated vars on clients — always go through Server RPC.

GameState

Replicated state shared across all clients (e.g. match time, team scores). Read-only from clients.

Multicast RPC — call a function on server AND all clients

Custom Event → Replicates = 'Multicast'. When called on server, executes on server and all connected clients. Use for visual effects, sounds, animations that all players should see.

Server RPC — call a function on the server from a client

Create a Custom Event → check 'Replicates' in Details → set to 'Run On Server', 'Reliable'. Call from client → executes on server. Reliable = guaranteed delivery (use for important events). Unreliable = may drop (use for frequent updates like position).

Multicast

An RPC the server calls that runs on every connected client. Use for one-shot effects (explosions, sounds).

MultiGate — distribute execution across multiple outputs

Blueprint communication: 4 methods ranked by coupling

1. DIRECT REFERENCE (tightest coupling): Get reference → CastTo<BP_Other> → call function. Use when: actor A always knows about actor B (e.g. Player → HUD). 2. CAST via GetAllActorsOfClass (loose): find → cast → call. Use when: you need to find actors dynamically. 3. EVENT DISPATCHER (loose): Owner calls dispatcher → listeners receive event. Use when: one actor notifies many others (e.g. death notification). 4. BLUEPRINT INTERFACE (loosest): Call interface message → any implementing actor responds. Use when: multiple different actor types should respond to same action (e.g. 'Interact'). 5. GAME INSTANCE (persistent): Store shared data in GameInstance → GetGameInstance → Cast. Use when: data must survive level loads.

Performance optimization checklist for Blueprints

1. TICK MANAGEMENT: - Disable tick on static actors (SetActorTickEnabled=false). - Use SetActorTickInterval(0.1-0.5) for AI, non-critical systems. - Prefer event-driven over tick polling where possible. 2. AVOID EVERY-TICK EXPENSIVE CALLS: - GetAllActorsOfClass: cache in BeginPlay, refresh only when needed. - CastTo: cache result in variable after first cast. - GetComponentByClass: call once and store reference. 3. VISIBILITY: - SetActorHiddenInGame + SetActorTickEnabled=false for off-screen actors. - Use LOD (Level of Detail) on meshes. 4. SPAWNING: - Use object pooling for frequently spawned/destroyed actors (bullets, effects). 5. EVENTS OVER POLLING: - Use overlap events instead of periodic distance checks. - Use delegates/dispatchers instead of checking conditions each frame.

Variable names in connections must match exactly (case-sensitive)

When connecting GetVariable or SetVariable nodes, the pin name must exactly match the variable_name field. E.g. variable 'MyHealth' → pin name 'MyHealth'. SetVariable exec input pin is always 'execute', not 'Execute' or 'in'. GetVariable has no exec pins — it is a pure data node.