Start Building

With your FPS running well in single-player, the next step is multiplayer: making movement, shooting, and game state consistent across multiple clients and a server. This lesson introduces Unreal Engine 5’s replication model, how to replicate properties and use RPCs (Remote Procedure Calls), and how to keep authority and latency in mind so your networked FPS feels fair and predictable.

By the end you will have a clear mental model of client, server, and replication, and a basic multiplayer setup you can extend in later lessons.

Why replication matters

In a multiplayer FPS, the server is the source of truth. It runs the authoritative game state (positions, health, score) and tells clients what to display. Replication is the process of copying that state from server to clients so everyone sees a consistent world. If you only move characters on the local machine, other players will not see that movement; you must run movement on the server (or have the server accept client input and update) and let replication sync the result.

Pro tip: Design with “server authority” from the start: the server validates important actions (shooting, damage, pickups) so clients cannot cheat by sending fake data.

Step 1: Understand client, server, and authority

  1. Server – Runs the main game logic. In a listen server, the host is both server and a client; in a dedicated server, the server has no local player.
  2. Client – Each player’s game instance. Clients send input to the server and display replicated state.
  3. Authority – The machine that “owns” an actor or decision. The server has authority over game state; sometimes a specific client has authority over one actor (e.g. their own character for prediction).

In Blueprint and C++ you will check Has Authority (server) or Is Locally Controlled (this client controls this pawn) to run code in the right place.

Step 2: Enable replication on your project and actors

  1. Project settings

    • Edit → Project Settings → Engine → Replication (or search “replication”). Ensure replication is supported; default is usually fine.
    • For packaged builds, use Listen Server or Dedicated Server as a target; clients connect to the server’s IP/port.

  2. Replicate the right actors

    • For any Actor that should exist on all machines (players, projectiles, pickups), enable Replicates on the Actor (in the Class Defaults or in code SetReplicates(true)).
    • The server spawns these actors; replication then creates and updates them on clients. Do not spawn replicated actors only on a client if the server should own them.

  3. Replicate variables

    • In Blueprint: check Replication on a variable so the server’s value is sent to clients.
    • In C++: use DOREPLIFETIME(ClassName, VariableName) in the constructor.
    • Replicate only what is needed (position, rotation, health, animation state). Avoid replicating huge arrays or data that changes every frame unless necessary; use replication conditions (e.g. only when changed) when possible.

Step 3: Replicate movement (Character or Pawn)

  1. Use built-in Character replication

    • If you use a Character (or similar) with Replicate Movement enabled, Unreal’s Character Movement Component replicates position and velocity from server to clients. That is the easiest way to get walking/running in sync.
    • Ensure the Character has Replicates set and that movement is driven on the server (input runs on server in a listen server, or client sends input to server and server moves the pawn).

  2. Client-side prediction (optional)

    • For responsive feel, the local client can move the pawn immediately and the server corrects (replication) if needed. This is already handled for Character movement when Replicate Movement is on; the server is authoritative and clients see smoothed or corrected positions.
    • Do not let the client set health or score; those must be server-authoritative.

Step 4: Use RPCs for one-off actions

RPCs (Remote Procedure Calls) let one machine run a function on another.

  1. Server RPC (Client → Server)

    • Call from client; runs on server. Use for actions that must be validated: “fire weapon”, “pick up item”, “request spawn”.
    • In Blueprint: set the function to Run on Server. In C++: use UFUNCTION(Server, Reliable) (or Unreliable for non-critical calls).
    • Only the server should update health, inventory, or score; the client requests, the server executes and replicates result.

  2. Client RPC (Server → Client(s))

    • Call from server; runs on one or all clients. Use for effects that don’t need to be replicated as state: “play hit effect”, “show message”, “play sound”.
    • In Blueprint: Run on Client (or “Run on Owning Client”). In C++: UFUNCTION(Client, Reliable).

  3. Multicast RPC (Server → All)

    • Call from server; runs on server and all clients. Use for one-off events that everyone must see: “spawn explosion VFX”, “play global sound”.
    • In Blueprint: Run on Server and All Clients (Multicast). In C++: UFUNCTION(NetMulticast, Reliable).

Common mistake: Calling a Server RPC from the server (e.g. in Blueprint) does nothing unless you run it on the listening client. Always call Server RPCs from a client.

Step 5: Replicate weapon fire and damage

  1. Firing

    • Client sends a Server RPC “request fire”. Server checks (ammo, cooldown), spawns the projectile or applies hit (e.g. line trace), and replicates the result. Projectiles should be replicated and server-spawned so all clients see the same shot.
    • Optionally use a Multicast RPC to play muzzle flash and sound so everyone sees/hears it at the same time.

  2. Damage and health

    • Health should be a replicated variable owned by the server. Only the server applies damage (from projectile overlap, line trace, or other logic). When health changes, replication updates clients so UI and death state stay in sync.
    • On death, server can run a Multicast to play death animation and effects on all clients.

Step 6: Test with multiple clients

  1. Play with multiple windows

    • In editor: Play → Advanced Settings (or Multiplayer Options) and set Number of Players to 2 or more. Unreal will launch multiple client windows; one is usually the listen server.
    • Walk, shoot, and take damage; confirm the other window sees the same state.

  2. Dedicated server (optional)

    • Package the game and run one instance as Dedicated Server (no window or with -server). Connect two or more client builds to the server IP. This tests the real “server authority” path.

Common mistakes

  • Running game logic only on client – Replicated state must be updated on the server; clients send input or requests via RPCs.
  • Replicating too much – Replicate only what is needed for gameplay and visuals; use replication conditions to reduce bandwidth.
  • Trusting client for damage or score – Always apply damage and score on the server; never let a client set another player’s health.
  • Forgetting to set Replicates on actors – If an actor is not set to replicate, it will not exist (or update) on other machines.

Troubleshooting

Other players don’t see my movement

  • Ensure the pawn has Replicates enabled and uses the Character Movement Component (or your movement runs on server and replicates). Check that you are not moving only on the client without server authority.

Shots don’t register for other players

  • Firing and damage must run on the server (Server RPC for fire; server does trace or projectile overlap and applies damage). Ensure projectiles are spawned on the server and set to replicate.

Lag or rubber-banding

  • Normal with high latency. Use Replicate Movement and avoid replicating every tick manually; let Unreal interpolate. For advanced smoothing, look at network smoothing or prediction in the Character Movement Component.

Mini challenge – multiplayer checklist

Before moving to advanced graphics and testing:

  • [ ] Enable Replicates on your player Character and any projectiles/pickups.
  • [ ] Replicate health (and other critical state) and update it only on the server.
  • [ ] Implement fire via a Server RPC; server spawns projectile or performs trace and applies damage.
  • [ ] Use a Multicast RPC for muzzle flash or impact effect so all clients see it.
  • [ ] Test with Number of Players = 2 in editor and confirm movement, shooting, and damage sync.

Recap and next steps

You used replication to sync state from server to clients, Server RPCs for validated actions (e.g. firing), and Client/Multicast RPCs for effects. With server authority and replicated movement and health, your FPS has a solid multiplayer foundation. In the next lesson you will tackle advanced graphics and rendering to make the game look even better before QA and launch.

For more on replication, see the Unreal Engine Networking and Multiplayer documentation. For performance with many replicated actors, revisit Lesson 12: Performance Optimization & Scalability.

Found this useful? Bookmark it and test your first multiplayer session with a friend.