Question about RPC calls in C++

Hello,

I’m working on a multiplayer game where one of the players is the listen server. At the moment I heavily use the pattern of using an server RPC that calls a NetMulticast RPC. For example if I want to pick up a weapon I do the following:

void ABbPlayer::InputAction_PickUp()
{
	InputAction_PickUp_Server();
}

void ABbPlayer::InputAction_PickUp_Server_Implementation()
{
	if (GetNetMode() != ENetMode::NM_ListenServer)
	{
		return;
	}

	InputAction_PickUp_Multicast();
}

bool ABbPlayer::InputAction_PickUp_Server_Validate()
{
	return true;
}

void ABbPlayer::InputAction_PickUp_Multicast_Implementation()
{
	TArray<AActor*> OverlappingPickUps;
	GetOverlappingActors(OverlappingPickUps, ABbPickUp::StaticClass());
	if (OverlappingPickUps.Num() > 0)
	{
		ABbPickUp* PickUp = CastChecked<ABbPickUp>(OverlappingPickUps[0]);
		PickUp->PickUp(this);
	}
}

So this makes sure the server is in control of what happens and also all the clients are up to date about the situation. I use this double RPC calling alot in my project and since I haven’t seen it done alot on the internet I’m wondering if this is a good way to do it (performance wise, or stability wise).

To be clear, my code works as I expect it would.
Any input is welcome, thanks in advance!

It is not good for performance to do a double RPC for everything, in my limited experience.
Wherever I can get away with it, I just do a client-to-server RPC to change the replicated variable or spawn the replicated Actor on the Server, and then let the Server decide when and if to replicate.

For things that need to happen right now no matter what, then I use the double RPC.

For things that need to happen no matter what but can wait until the next replication update, I use client-to-server RPC to set a RepNotify variable and let the clients handle the repnotify function it fires.

My worst performance on network has happened when flooding it with repnotifies every tick just to let other clients see a change in my tank’s engine glow brightness. I changed from that to just tracking the changes clientside, sending an unreliable client-to-server RPC every 0.25 seconds, and letting the server decide when and if it thinks clients need to see the change, and it still looks great, and is way less laggy! I can do it on that feature because it’s not game-play critical.

For things like explosions when a tank dies, I use a double RPC to make sure everyone knows that it happened at that moment, and they all spawn the explosion on their own client side. I am thinking maybe I should change it to spawn a replicated particle emitter actor instead though, and make it a single RPC. There is a noticeable stutter when I do it the first way.

Optimization is going to be about figuring out which of these 3 cases your client-side changes fall into (those that other clients need to see happen).

Hello, these videos are from the unreal engine networking tutorial that were unlisted long ago because they are out of date, but %99 percent of the content is still the same, and even though it is blueprint the concept is pretty much the same.

This is the first video of the networking tutorial. There are 6 networking tutorials in the playlist, and the next one is a live training talking about replication.

Hope you can find something useful here!

Thank you both for your replies, I had the feeling it might not be good for performance but it’s nice to have someone elses thoughts on this. There are probably some things that dont need the double RPC I’ll go over my code again.
I’ll check out those vids too thanks! :slight_smile: