I am implementing a fighting game in Unreal Engine and I want to implement "rollback". The way I envision it so far is that in every frame, the client will send the inputs it received in that frame (30 fps max for now) to the client. Dropping any inputs is unacceptable. To me, it looks like the best way to do this is with RPCs, and if there are inputs in one frame, I will send an RPC to the other client with those inputs. Since inputs can't be dropped, it looks like a good idea to use reliable RPCs. However the documentation explicitly warns against making a reliable RPC every frame.

Warning: Overuse of Reliable functions can result in overflowing the queue for them. This will result in forced disconnections. If you call a replicated function on a frame-by-frame basis, you should make it Unreliable. If you have a Reliable function that is bound to player input, you should limit how often the player can call that function.

Should I really be concerned about hitting this limit if I am making only one RPC per client every frame, and at 30fps max? 60 fps? During a match, theoretically these RPCs will be the only network traffic, as everything gameplay essential will be computed client side from the inputs, and nothing else needs replication. It would be the simplest method by far.

A second question is, even if I don't hit this limit, would reliable RPC introduce noticable latency over, say, using TCP, or some other method I am unaware of? Is sending packets every frame simply too much traffic?


1 Answer 1


You should try to avoid sending Reliable RPCs whenever you can. Unreliable RPCs however you may send as much as you want. The engine will send them, but they may get dropped due to the nature of underlying network implementation (UDP)

The downside of using Reliable RPCs is that they need to be re-transmitted and they won't go thru the network and arrive the server faster than they can. If it's physically impossible to send a packet over they won't go thru regardless of reliable or unreliable. They simply get re-transmitted.

Reliability basically incurs a cost of having to resend your RPCs, having to order them and also waiting, to make sure they all arrive in order. This can eventually increase latency and may not be what you want for a fast paced game.

What you could do is queue up your input commands and re-send them manually, and order them on your end. Most of the time you only care about the latest input anyways.

I'm want to refer you to the old UDK docs which provides a pattern you could use.

Pleas see Semi-reliable function calls



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .