"We'll add multiplayer later."

Those five words have torpedoed more game projects than scope creep and feature bloat combined. Not because multiplayer is impossible to add late, but because retrofitting replication into systems that were never designed for it touches everything. Health, inventory, abilities, quest state, save data, UI — every system needs to understand the difference between server truth and client prediction.

This guide covers how to think about multiplayer architecture in Unreal Engine 5, how replication works under the hood, and how to design gameplay systems that work in both single-player and multiplayer contexts without doubling your codebase.

Why Think About Multiplayer Early

There's a practical argument for designing with replication in mind, even if your first release is single-player.

The Retrofit Tax

Adding multiplayer to an existing single-player game typically requires:

• Refactoring authority — every gameplay system needs to know who owns the truth. Health can't just decrement on whatever machine runs the code. It needs to decrement on the server and replicate to clients.
• Splitting execution — functions that currently run once now need to run in different contexts (server, owning client, all clients). A single "take damage" function becomes three or four.
• Redesigning state flow — UI that reads directly from a component now needs to read from replicated state. Inventory that modifies arrays locally now needs server validation.
• Testing everything twice — every feature needs testing as both host and client. Edge cases multiply.

Teams that retrofit multiplayer typically estimate 2-3 months and spend 6-9. The systems you build first are the hardest to change.

The Architecture-First Approach

The alternative isn't building full multiplayer support from day one. It's designing your systems so that the concept of authority and state ownership is baked in. A health system that always modifies health through a server-authoritative function costs almost nothing extra in a single-player context (the "server" is just the local machine). But when you add a second player, the same function works without modification.

This approach means:

• No duplicate code — the same system works for both modes
• No state synchronization bugs — authority is clear from the start
• Gradual multiplayer support — you can enable replication system by system
• Cleaner architecture overall — the discipline of thinking about authority produces better single-player code too

Replication 101

Before diving into gameplay systems, let's establish how UE5 replication actually works.

What Is Replication?

Replication is the process of synchronizing game state between a server and one or more connected clients. In UE5's networking model:

• The server is the authoritative source of truth for game state
• Clients receive replicated state from the server and display it
• Some actions happen on clients first (prediction) and are validated by the server

This is a server-authoritative model. The server always has the final say on what's real.

What Gets Replicated?

UE5 can replicate:

• Actors — spawning, destroying, and state changes for any actor marked as replicated
• Properties — individual variables marked with the Replicated or ReplicatedUsing specifier
• RPCs (Remote Procedure Calls) — function calls that execute on a specific machine (server, owning client, or all clients)

What doesn't replicate automatically:

• Components (unless explicitly set to replicate)
• Local variables — only UPROPERTY members can replicate
• Blueprint local variables — these exist only on the machine that runs the Blueprint
• Assets — textures, meshes, and sounds are assumed to exist on all machines

The Relevancy System

Not everything replicates to every client. UE5 uses a relevancy system to determine which actors need to replicate to which clients. An actor on the far side of the map isn't relevant to a player who can't see it. This saves bandwidth and reduces the number of properties being synchronized.

Relevancy is controlled by:

• Net cull distance — actors beyond this distance aren't replicated
• bAlwaysRelevant — forces an actor to replicate to all clients regardless of distance
• bOnlyRelevantToOwner — only replicates to the client that owns this actor (useful for inventory, personal UI state)
• Custom relevancy — override IsNetRelevantFor() for custom logic

Replication Rate

Properties don't replicate every frame. The server evaluates which properties have changed (are "dirty") and batches updates at the net update frequency. Default is typically 100Hz for the server tick, but actual replication to clients happens at a lower rate depending on bandwidth and relevancy priority.

This means replicated properties have latency. A health value that changes on the server might take 20-50ms to appear on a client. For gameplay-critical feedback (hit reactions, ability activations), this latency needs to be masked with prediction or cosmetic effects.

Authority and Ownership

Understanding authority and ownership is the single most important networking concept for gameplay programmers.

Authority

Authority means "this machine is the source of truth for this actor." In a dedicated server model, the server has authority over all actors. In a listen server model, the host machine has authority.

In Blueprints, you check authority with Has Authority (returns true on the server, false on clients). Every gameplay decision that affects game state should check authority:

• Dealing damage? Check authority. Only the server should modify health.
• Picking up an item? Check authority. Only the server should modify inventory.
• Completing a quest? Check authority. Only the server should update quest state.

Ownership

Ownership determines which client "owns" an actor. A player's character is owned by the client controlling it. Ownership matters for:

• RPCs — "Run on Owning Client" only works if the actor has an owner
• Relevancy — bOnlyRelevantToOwner uses ownership
• Input — only the owning client can send input for a character

Ownership flows through the possession chain: PlayerController owns the Pawn it possesses. Components on the Pawn inherit ownership from the Pawn. Actors spawned by the Pawn don't automatically inherit ownership — you need to set it explicitly.

The Authority Pattern

Here's the pattern that makes single-player and multiplayer work with the same code:

1. Client detects intent — player presses a button, triggers an interaction
2. Client sends request to server — via RPC or by calling a function that checks authority
3. Server validates and executes — checks if the action is legal, modifies authoritative state
4. Server replicates result — changed properties automatically sync to all relevant clients
5. Clients update visuals — UI, animations, and effects respond to the replicated state

In single-player, steps 2 and 4 are effectively instant (the "server" is local). The same code path runs, but with no network latency.

RPCs: When and How

Remote Procedure Calls are functions that execute on a specific machine. UE5 provides three types:

Server RPCs

Marked as Run on Server (or Server in C++). Called by a client, executed on the server.

Use for: Player actions that need server validation. "I want to use this ability." "I want to pick up this item." "I want to deal damage to this target."

Rules:

• Must be called on an actor owned by the calling client (ownership chain must lead to the client's PlayerController)
• Can be unreliable (no guarantee of delivery, lower bandwidth) or reliable (guaranteed delivery, higher bandwidth)
• Use unreliable for frequent, non-critical calls (movement input). Use reliable for important, infrequent calls (ability activation, item pickup)

Client RPCs

Marked as Run on Owning Client (or Client in C++). Called by the server, executed on the owning client.

Use for: Client-specific feedback that shouldn't replicate to everyone. "Show this error message." "Play this camera shake." "Open this UI panel."

Rules:

• Only works if the actor has an owning client
• The server initiates the call, so it always executes on the correct client
• Useful for feedback that's private to one player

Multicast RPCs

Marked as Multicast (or NetMulticast in C++). Called by the server, executed on the server and all connected clients.

Use for: Effects that everyone should see. "Play this explosion." "Show this hit effect." "Play this animation montage."

Rules:

• Runs on the server AND all clients (including the host in listen server)
• Use sparingly — this is the most bandwidth-expensive RPC type
• Subject to relevancy — only clients for whom the actor is relevant will execute it
• Multicast RPCs are fire-and-forget. If a client joins after the multicast, they won't see it

Common RPC Mistakes

Using RPCs for state synchronization. RPCs are events, not state. If a client misses an RPC (relevancy change, packet loss on unreliable calls), the state is lost. Use replicated properties for persistent state and RPCs for transient events.

Server RPCs without validation. Never trust client RPCs. A Server RPC that says "deal 1000 damage to this enemy" should validate that the client's character is in range, has the ability, and the damage value is legal. Trusting client data is how cheating happens.

Reliable RPCs in tight loops. Reliable RPCs queue up if the network is congested. Calling a reliable RPC every frame can flood the reliable buffer and disconnect the client. Use unreliable for anything frequent.

Multicast for private information. Don't multicast a player's inventory contents. Other clients don't need it and shouldn't have it. Use bOnlyRelevantToOwner or Client RPCs.

Replicating Gameplay Systems

Now let's look at how specific gameplay systems should handle replication. These patterns apply whether you're building systems from scratch or extending existing ones like those in the Blueprint Template Library.

Health and Combat

Health is the canonical replication example because it's simple, visible, and critical.

Server-authoritative health:

• Health value lives on the server. It's a replicated property with RepNotify.
• When health changes on the server, OnRep_Health fires on all clients.
• Clients use OnRep_Health to update health bars, play damage effects, trigger death animations.
• Damage is applied only on the server. Client code never directly modifies health.

The damage flow:

1. Client fires weapon, detects hit locally (for responsive feel)
2. Client sends Server RPC: "I hit this target at this location"
3. Server validates: Is the target in range? Is the weapon equipped? Is the damage value legal?
4. Server applies damage, modifying the authoritative health value
5. Health property replicates to all relevant clients via RepNotify
6. Each client's OnRep_Health triggers visual feedback

Damage prediction: For immediate feel, the attacking client can play hit effects (blood splash, hit marker) before the server confirms. If the server rejects the hit (target moved, out of range), the effect already played but the health didn't change. This feels better than waiting 50-100ms for confirmation.

Death: Death is a server decision. When health reaches zero on the server, the server sets a replicated bIsDead flag. Clients respond to this flag with death animations, ragdoll, and UI updates. Never let clients decide they're dead based on local health prediction.

Inventory

Inventory replication is tricky because inventory data can be large and changes need to be atomic.

Design principles:

• Inventory state is server-authoritative. Clients cannot add or remove items without server approval.
• Use bOnlyRelevantToOwner. A player's inventory should only replicate to their client, not to all clients. This saves bandwidth and prevents information leaking (you don't want opponents knowing your loadout in a PvP game).
• Replicate the minimum. Instead of replicating the entire inventory array on every change, use RepNotify on individual slots or send delta updates via Client RPCs.

The item pickup flow:

1. Client interacts with a world item (walks over it, presses a button)
2. Client sends Server RPC: "I want to pick up this item"
3. Server validates: Does the item still exist? Is the client close enough? Is there inventory space?
4. Server adds item to inventory, destroys the world item actor
5. Inventory change replicates to the owning client
6. World item destruction replicates to all clients (everyone sees it disappear)

Inventory operations that need server authority:

• Adding items (pickup, quest reward, crafting output)
• Removing items (dropping, consuming, crafting input)
• Moving items between slots (reordering, equipping)
• Splitting and merging stacks

Every one of these operations should validate on the server before modifying state.

Abilities and Buffs

Ability systems combine the challenges of health (state replication) and inventory (per-player relevancy) with the additional complexity of timing and prediction.

Ability activation flow:

1. Client presses ability key
2. Client optionally plays prediction animation/VFX (immediate feel)
3. Client sends Server RPC: "Activate ability X"
4. Server validates: Is the ability available? Is it off cooldown? Does the player have enough resources (mana, stamina)?
5. Server activates ability, applies effects, starts cooldown
6. Ability state replicates to relevant clients
7. Multicast RPC triggers visual effects (particles, animations) on all nearby clients

Cooldowns: Cooldowns should be server-authoritative. The server tracks when an ability was last used and rejects premature activation requests. The client displays a cooldown timer based on replicated cooldown start time and duration, but the server has the final say.

Buffs and debuffs: These are replicated properties on the target actor. When the server applies a buff, it replicates to relevant clients. Buff effects (stat modifications) are calculated server-side. Visual indicators (particle effects, UI icons) are triggered by RepNotify on clients.

Stacking and interaction: If buffs can stack or interact (a fire debuff does double damage when the target is wet), all stack logic runs on the server. Clients see the result through replicated stack counts and modified stats.

Quest and Objectives

Quest state is simpler to replicate because it changes infrequently and is per-player.

Design principles:

• Quest state is bOnlyRelevantToOwner — each player has their own quest progress
• Quest state changes on the server only (completing objectives, accepting quests, turning in quests)
• Use RepNotify to trigger client-side quest UI updates
• In co-op games, shared quests need a decision: does everyone share progress, or does each player track independently?

Shared quest progress (co-op):

The server maintains a shared quest state actor that replicates to all party members. When any player completes an objective, the server updates the shared state, and all party members see the update via RepNotify. This requires a "party" or "group" system to determine who shares quest progress.

Stats and Attributes

Character stats (strength, agility, intelligence) are server-authoritative and replicated.

The pattern:

• Base stats are set on the server when a character is created or levels up
• Stat modifiers from equipment, buffs, and abilities are calculated on the server
• Final stat values replicate to the owning client for UI display
• Other clients may or may not need to see your stats (depends on the game — an inspect system would need them, a co-op game might not)

Stat modification flow:

1. Something changes a stat (level up, equip item, apply buff)
2. Server recalculates the final stat value (base + modifiers)
3. Final value replicates to the owning client
4. Client UI updates via RepNotify

Never let clients calculate their own stat values. If the client calculates "base strength + equipment bonus + buff bonus," a cheat can modify any of those values. The server should be the only machine that computes final stats.

Common Networking Mistakes

These are the patterns we see most often in projects that struggle with multiplayer.

Trusting the Client

The number one mistake. If the client sends "I dealt 9999 damage," and the server applies it without validation, cheating is trivial. Every Server RPC should validate:

• Is the action possible? (ability available, item in inventory, target in range)
• Are the values legal? (damage within expected range, resource costs correct)
• Is the timing valid? (cooldown elapsed, not already performing another action)

Running Game Logic on Clients

If game logic runs on a client and the result is sent to the server, the server is trusting the client's logic. Instead, clients should send intent ("I want to attack"), and the server should execute the logic ("calculate damage, apply to target, replicate result").

Over-Replicating

Replicating every property on every actor to every client wastes bandwidth. Common over-replication patterns:

• Replicating derived values. If max health is calculated from level and constitution, replicate level and constitution. Let clients calculate max health locally. Only replicate values that the client can't derive.
• Replicating private data to everyone. Inventory, quest state, and ability cooldowns should use bOnlyRelevantToOwner.
• Replicating at high frequency. Properties that change slowly (experience points, quest progress) don't need high replication priority. Reserve bandwidth for properties that change rapidly (position, rotation, health).

Ignoring Latency

On a local machine, RPC round-trip time is effectively zero. On a real network, it's 20-200ms. Systems that feel responsive in local testing feel sluggish online because every action waits for server confirmation.

The fix: Client-side prediction. Play effects immediately on the client, then correct if the server disagrees. For most games, the server agrees 99% of the time, so the prediction is almost always correct. The 1% correction (a hit that didn't register, an ability that was rejected) is less noticeable than 100% of actions having visible latency.

Not Testing with Latency

UE5's Play-In-Editor multiplayer testing runs on localhost with zero latency. This hides every latency-related bug. Always test with simulated network conditions:

• Editor settings: Under Editor Preferences > Level Editor > Play > Multiplayer Options, set Network Emulation Profile to simulate packet loss, latency, and jitter
• Minimum test latency: 50ms each way (100ms round trip). This represents a good connection. Test at 150ms for a realistic worldwide connection.
• Packet loss: Test at 1-2% loss. This is common on consumer internet and exposes bugs in reliable RPC ordering and state recovery.

The Single-Player First Approach

Here's the practical strategy: build for single-player, but with multiplayer-ready architecture.

What "Multiplayer-Ready" Means in Practice

You don't need to implement networking, test with multiple clients, or solve matchmaking. You need to:

1. Centralize state authority. All game state modifications go through functions that could become server-authoritative. In single-player, these run locally. In multiplayer, they run on the server.

2. Separate intent from execution. The player presses a button (intent). A function validates and executes the action (execution). In single-player, both happen locally. In multiplayer, intent is local and execution is server-side.

3. Use RepNotify-style updates. Even in single-player, update UI and effects in response to state changes, not in response to the action that caused them. "Health changed, update health bar" instead of "damage was dealt, update health bar." This decoupling means replication just works when you add it.

4. Design for ownership. Tag data as "per-player" or "shared." Per-player data (inventory, quests, abilities) will need bOnlyRelevantToOwner. Shared data (world state, NPC status) will replicate to everyone.

The Blueprint Template Library Advantage

The Blueprint Template Library ships 8 gameplay systems designed with this architecture in mind. Each system — health and combat, inventory and crafting, abilities and buffs, stats and attributes, branching dialogue, quest and objectives, interaction, and save/load — follows the authority pattern described above.

The systems work in single-player out of the box. When you're ready to add multiplayer:

• State-modifying functions are already centralized
• Authority checks can be added at clear boundary points
• Data is already separated by ownership semantics (per-player vs. shared)
• UI updates already respond to state changes, not action triggers

This doesn't make multiplayer free, but it reduces the retrofit from months to weeks. The hardest part of adding multiplayer — refactoring state authority and data flow — is already done.

A Concrete Example

Consider an ability system in single-player:

1. Player presses ability key
2. System checks: Is the ability available? Is it off cooldown? Enough mana?
3. System activates ability, applies effects, starts cooldown
4. UI updates to show cooldown, mana change, effects

Now, adding multiplayer to this system:

1. Player presses ability key (same)
2. Client sends Server RPC with ability ID (new: one RPC call)
3. Server checks: Is the ability available? Is it off cooldown? Enough mana? (same validation, now on server)
4. Server activates ability, applies effects, starts cooldown (same execution, now on server)
5. State replicates to clients (new: mark properties as replicated)
6. UI updates to show cooldown, mana change, effects (same, now triggered by RepNotify)

Steps 2 and 5 are the only additions. The core logic — validation, execution, and UI response — is identical. This is why multiplayer-ready architecture matters: when the time comes, you're adding a thin networking layer around systems that already have clear authority boundaries.

Performance Budgets

Multiplayer introduces performance constraints that don't exist in single-player.

Bandwidth Budget

A typical dedicated server can push 1-5 Mbps total across all connected clients. Divide that by your player count. For a 32-player game at 2 Mbps total, each client gets roughly 60 KB/s. That's not much.

Bandwidth hogs:

• Character movement: 20-40 bytes per update, 30-60 updates per second = 600-2400 bytes/sec per character. For 32 characters, that's 20-75 KB/s just for movement.
• Replicated properties: Each dirty property takes bytes proportional to its type. A replicated float is 4 bytes. A replicated FString is variable. A replicated TArray serializes the entire array on change (use FFastArraySerializer for delta updates).
• RPCs: Each RPC has overhead for the function identifier, parameters, and reliability metadata. Frequent RPCs add up.

Budget strategies:

• Prioritize what replicates. Movement and health are critical. Cosmetic state (animation blend weights, cloth simulation) can be lower priority or client-predicted.
• Use net update frequency wisely. Not every actor needs to update at 60Hz. Background NPCs can update at 10Hz. Distant players can update at 5Hz.
• Compress data. Quantize floats to fewer bits. Use enums instead of strings. Send indices instead of full asset references.

Server CPU Budget

The server runs game logic for all players. In single-player, your game logic budget is "whatever the player's machine can handle." In multiplayer, the server runs logic for every player on one machine.

Key constraints:

• Server tick rate determines how often the server processes input and updates state. 30Hz is common. 60Hz is expensive. 128Hz (competitive shooters) requires extremely optimized server code.
• Every replicated actor has overhead even when nothing changes (relevancy checks, dirty property scans).
• AI, physics, and gameplay systems that are per-player multiply by player count.

Optimization strategies:

• Run AI at reduced frequency on the server. Full pathfinding every frame is expensive with many NPCs.
• Use relevancy aggressively. Actors that aren't relevant to any client don't need to update.
• Profile your server separately from your client. Server performance problems manifest as "lag" for all players, not FPS drops.

Client Prediction Budget

Predicted systems (movement, ability activation) run logic on both the client and the server. This doubles the CPU cost of those systems. Budget accordingly.

Getting Started

If you're starting a new project and want multiplayer-ready architecture:

1. Read Epic's networking documentation. It's comprehensive and covers concepts not detailed here. Start with the Networking Overview and work through the replication examples.

2. Set up multi-client PIE testing. In your editor preferences, configure Play-In-Editor to launch multiple game instances. Test with 2 clients + 1 dedicated server. Add network emulation from day one.

3. Build with authority in mind. For every gameplay system, ask: "Who owns this data? Who can modify it? Who needs to see it?" Answer these questions before writing code.

4. Start with the Blueprint Template Library. The 8 gameplay systems provide a foundation that's already designed for authority-based state management. Extending them for multiplayer is straightforward because the architectural decisions are already made.

5. Prototype multiplayer early. You don't need full multiplayer support in your first build. But getting two clients connected and seeing replicated movement by week two saves months of retrofitting later.

The worst time to think about multiplayer is after you've shipped a single-player game and your community is asking for co-op. The best time is before you write your first gameplay system. The realistic time is right now, regardless of where you are in development. The earlier you adopt authority-based architecture, the less it costs to add real networking later.

Multiplayer isn't a feature you bolt on. It's an architecture you build into.