I’m working on an RTS game to be playable in multiplayer mode, at least via LAN with 2 players. So far it works locally, I could test it only in PIE (no menu yet), and check data transfer by “stat net”. Depending on unit quantity, In Rate is between 25000-65000 bytes for 100-400 units respectively, and I really don’t know whether this is acceptable or not over a real network, and what other parameters should be checked carefully.
So I would be interested in your experiences, what can and what can definitely not work.
The units are actors using a custom pathfinder running on the server, just passing movement vectors by multicast RPCs, what can be optimized further (thus no CharacterMovementComponent magic used). Of course their skeletal mesh and capsule components are also replicated, plus projectiles (javelins, arrows), and there are some static stuff like buildings and resource objects.
That’s roughly 64KB (~512Kb) a second? That’s not terrible, especially on LAN. That said, the lower you can get your wire traffic - the better. Especially if your traffic increases per player.
You might want to audit what you are sending and see if you can achieve the same result without replicating everything. For example, rather than replicating every projectile - simple send information describing the projectile (start, end, time to target, etc), and then just play the actual effect locally. Take advantage of the NetQuanitize methods for vectors/floats to reduce the number of bits sent (at the cost of some precision).
Thanks!
I have already went through some optimizations (approx. halved bandwidth requirement), removed a lot of replicating uproperties, even movement and transform, kept only values which are nearly never changing after initialization (might be removed too), and I use multicast RPCs for movement, and passing uint8 or int16 and FVector_Netquantize values only instead of floats or FVectors (a vector and an integer per unit per tick), but I expected more decrease.
For projectiles it is a good idea, they are heavy currently.
…moreover, what I don’t really know how to optimize component replication, or can it be at all. Each unit has a skeletal mesh, a collision capsule, a flipbook, a static mesh, and a player ID component at least:
Skeletal mesh animation is solved quite well by sending only multicast RPC messages when animation sequence is changed (I use single node animations from C++) and one uint8 replicating uproperty is used, the actual weapon ID (animation played depends on behavior so cannot be decided properly on client alone).
Flipbook is similar (it was used earlier for far lod, maybe I would remove it).
I need collision only for unit selection on clients, collision events are handled on server only (unit-environment, unit-unit, projectile-environment etc.), and it is the root component, thus when setting actor location/rotation it is managed fine, and not requiring any RPCs or replicating uproperties.
Static mesh is not yet used.
Maybe player ID component parameters could be set by RPCs too instead of replicating the values…