Unreal Engine Networking: Minimal Viable Authoritative Design for Small‑to‑Mid‑Size Action Games

Problem Statement

When building a networked action game in Unreal Engine, the core challenge is to keep gameplay feeling responsive while ensuring that no client can cheat or cause desynchronization. The solution must use UE’s built‑in replication system without adding custom netcode, stay within modest bandwidth limits, and be verifiable with the engine’s diagnostic tools.

Requirements

• A single authoritative process (server) that decides all gameplay outcomes.
• Clients render predicted local state but never authoritatively change it.
• Per‑client bandwidth must stay bounded (e.g., < 50 KB/s typical for an action game).
• Perceived latency should be masked by client‑side prediction where appropriate.
• The design must rely only on stable UE 4.x/5.x networking features (AActor authority, replicated UPROPERTYs, RPCs, CharacterMovementComponent).

Smallest Suitable Design

For a typical small‑to‑mid‑size action game the following minimal setup satisfies the requirements:

1. Server: A dedicated server process (or a listen server for prototyping) holds ROLE_Authority for all actors.
2. Client‑to‑Server Intent: Player input is sent via a Server RPC (e.g., ServerMoveCharacter) that carries only the raw input (direction, jump flag).
3. Game State: All relevant gameplay data is exposed as replicated UPROPERTYs with ReplicatedUsing or OnRep callbacks. The server writes to these properties; clients only read them and react in OnRep.
4. Movement Prediction: The player’s pawn uses CharacterMovementComponent. For autonomous proxies the component implements saved‑move prediction: the client simulates ahead, the server simulates the authoritative result, and on correction the client replays its saved moves.
5. Relevancy Tuning: Keep the default relevancy system and adjust NetUpdateFrequency per‑actor only when needed (e.g., increase for fast‑moving projectiles, decrease for static scenery). No Replication Graph or Iris is required at this scale.

Trust and Data Boundaries

The server is the sole trusted entity. All client‑originated data must be treated as untrusted:

• Every Server RPC should implement a Validate function that returns false for malformed or out‑of‑range input, causing the server to disconnect the offending client.
• Inside the RPC implementation (executed only when Validate returns true), the server must re‑derive outcomes from the raw input rather than accepting any values computed by the client.
• OnRep callbacks on clients are notification‑only; they must not contain logic that could affect server authority.

Operational Checks

Use the following built‑in tools to verify that the design behaves as expected:

• PIE Network Emulation: Set latency (e.g., 100 ms) and packet loss (e.g., 5 %) to simulate real‑world conditions.
• stat net: Monitors total bandwidth, replication counts, and packet queues. Run it during a session and observe changes when you adjust NetUpdateFrequency on a test actor.
• p.NetShowCorrections 1: Visualizes movement corrections; green lines indicate successful prediction, red lines show corrections that triggered a replay.
• Unreal Insights (Net Traffic view): Breaks down replication cost per actor, helping spot over‑replicated properties.
• Soak test: Run the game for extended periods under simulated loss to surface gradual desyncs or memory growth in the reliable‑RPC buffer.

Failure Modes

Even with the minimal design, watch for these common issues:

• Reliable‑RPC buffer overflow: If a client queues too many reliable RPCs on a saturated connection, the server will disconnect it. Keep RPC frequency low and use unreliable RPCs for frequent updates (e.g., input).
• Bandwidth spikes: Raising NetUpdateFrequency on many actors or over‑replicating large structs can exceed the bandwidth budget.
• Rubber‑banding: Under high loss, prediction errors grow; the server’s correction snaps the client back, causing visible jitter.
• Stale dormant actors: Actors that become dormant (bNetDormant) stop replicating. If you mutate them while dormant, call FlushNetDormancy to force an update.
• Relevancy pops: When an actor crosses a relevancy boundary, clients may see a sudden appearance/disappearance. Adjust NetCullDistanceSquared or use SetIsReplicated judiciously.

Conditions That Would Change the Design

Revisit the minimal design when any of the following apply:

• Player count or replicated actor count grows into the hundreds or thousands; evaluate Replication Graph (UE 4.20+) or the newer Iris system for scoped relevance.
• The world uses World Partition with large streaming cells; relevancy must be integrated with partition streaming.
• Competitive integrity requires a strict authority model (dedicated server, hardened validation, anti‑cheat).
• The genre demands deterministic lockstep or rollback (e.g., fighting games); UE’s prediction model is unsuitable and a custom netcode or third‑party solution would be needed.
• You plan to support replays or spectating via DemoNetDriver; this adds determinism constraints that may require adjusting replication patterns.

Practical Verification Example

To confirm that client actions only take effect after server processing:

1. Create a Third Person template project.
2. In MyCharacter.h add a replicated integer UPROPERTY(ReplicatedUsing=OnRep_Score) int32 Score; and a ServerAddScore RPC.
3. In MyCharacter.cpp implement:

void AMyCharacter::ServerAddScore_Implementation(int32 Amount)
{
    Score += Amount; // server authoritative update
}
bool AMyCharacter::ServerAddScore_Validate(int32 Amount)
{
    return Amount > 0 && Amount <= 10; // simple validation
}
void AMyCharacter::OnRep_Score()
{
    // client‑side UI update only
    UE_LOG(LogTemp, Log, TEXT("Score updated to %d"), Score);
}

1. Run PIE with Number of Players = 2, enable Run Dedicated Server.
2. Set Network Emulation to 120 ms latency, 3 % loss.
3. Press the input that triggers ServerAddScore on the client.
4. Observe the server console: the score increments only after the RPC arrives.
5. On the client, the OnRep_Score log appears a few milliseconds later, confirming that the client never changed the score locally.

This test validates the trust boundary and the minimal replication flow without any custom netcode.

Limitations and How to Check Them

The described design assumes:

• Typical action‑game payloads (small structs, low‑frequency RPCs). If your game needs to replicate large arrays or frequent custom data, monitor stat net and consider struct compression or interest management.
• That the server is not compromised. For higher security, add server‑side sanity checks (e.g., position speed caps) and log validation failures.
• That you are using a stable UE version (4.27 or 5.2+). Console variable names and default replication values can shift; verify against your version’s documentation.

To check that you remain within bandwidth limits, run a session with typical player count, enable stat net, note the Outgoing bandwidth value, and ensure it stays below your target (e.g., 40 KB/s). Adjust NetUpdateFrequency or replication conditions if the value drifts upward.