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 unreliable RPC and rolling my own reliability system (that guarantees only arrival but not order, unlike reliable RPC which does guarantee order)? Is sending packets every frame simply too much traffic?

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?

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 this 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. Reliable RPC also has an ordering guarantee which I don't need because an out of order RPC will be resolved by the rollback logic. Would it be a better idea to use unreliable RPC and manually track my own "packet" numbers, asking the other client to resend unreceived packets, to ensure none get dropped, or is doing this myself likely to be slower than reliable RPC?

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 unreliable RPC and rolling my own reliability system (that guarantees only arrival but not order, unlike reliable RPC which does guarantee order)? Is sending packets every frame simply too much traffic?