Tank Combat

In two-player tests, the client couldn't see the host's tank at all, while the host saw both. The client's own tank was fine, and so were the bullets.

Unreal only replicates an actor to a client while it is relevant to that client, and by default relevancy is a distance check from the client's viewpoint. This game uses a fixed, orthographic top-down camera placed far from the arena, so measured from the client's viewpoint, the host's tank was always beyond the cull distance and never replicated. The client's own tank escaped because an actor is always relevant to its owner; bullets escaped because their C++ constructor already sets bAlwaysRelevant.

The fix was to mark the tank pawn Always Relevant. With two players in one arena, every tank has to reach every client anyway, so distance culling had nothing to save.

Later, with both tanks driving side by side, the client's tank covered about half the ground the host's did, and both screens agreed. It wasn't a display desync; the server really was moving the client's tank less.

The cause was in the server tick: after moving the tanks, it reset the stored input to zero, treating each Server Move as a one-tick impulse. The host's own Server Move runs locally every frame, so the host always had fresh input. The client's RPCs cross the network and don't land exactly one per server tick, so some ticks had nothing new, and those ticks moved the client's tank by zero.

The server now keeps the last input until it's replaced, and releasing the key (Completed or Canceled) sends an explicit zero. Input became state instead of a per-tick event, and both tanks move at the same speed.

Firing is a Gameplay Ability rather than a plain function call, so the rule is configuration instead of code. GA_FireBullet lists TankCombat.DisableFireBullet as an Activation Blocked Tag: while the tank owns that tag, the ability system refuses to activate it.

The ability only does work where it has authority. On the server it takes a bullet of the tank's current type from the pool and ends; anywhere else it ends without spawning anything.

Bullets are never spawned or destroyed mid-match. A UWorldSubsystem pre-spawns each game mode's bullets on the server when the match starts, marks them replicated and parks them until they're needed.

Anything poolable implements IPoolable, a C++ interface whose events are implemented in Blueprint. The pool drives Blueprint bullets through that interface without depending on their classes, and every entry point checks that it is running on the server, so a client can never hand out or reclaim a bullet.

UINTERFACE(Blueprintable)class UPoolable : public UInterface{    GENERATED_BODY()}; class IPoolable{    GENERATED_BODY() public:    UFUNCTION(BlueprintCallable, BlueprintNativeEvent)    void ActivateFromPool(AActor* Activator);     UFUNCTION(BlueprintCallable, BlueprintNativeEvent)    void DeactivateToPool();};

The pool's events don't set the bullet up directly. They write an ActivationInfo struct, holding whether the bullet is live and which tank fired it, into a RepNotify variable. OnRep_ActivationInfo runs on the server when the value is set and on the client when it arrives, then routes to ActivateBullet or DeactivateBullet.

Inside those functions, Switch Has Authority splits the work. The server positions the bullet and adds or removes the fire-lock tag; every machine updates the bullet's visibility and collision. The tag is a loose gameplay tag added with Should Replicate, so the client's copy of the tank carries the same lock as the server's.