How to correctly set up a simple, client controlled, fully broadcast RPC using UNET

Let me just get this out of the way first. I've been making professional multiplayer games for more than 8 years, so I don't need any explanation of basic communication strategies.

Anyway, I'm new to Unity networking and I'm trying to get some simple stuff setup, but I want to make sure I'm doing it the "correct" way. Here's the situation:

I have a multiplayer session with, let's say, 4 players, one of whom is the host/server. I have a client controlled action which is to trigger a teleportation (but this could be anything, like shooting, jumping, yelling). This teleportation includes a bunch of visuals that need to be shown on all instances (clients and server). Importantly, there needs to be no delay on the client who is initiating the action i.e. I don't want to have the round trip time of making a request to the server and waiting for a response.

Now, I've looked into Unity networking a bit and found some stuff about RPCs (Command/ClientRPC). This sort of seems like what I need, but the main problem is getting the message from the client, to the server, and then to the other clients in the session, but not the initial client.

Am I being clear enough here? Basically, if I set up a system where the client sends a message to the server and the server just forwards that message to all clients, it means that each client will have to manually check for isLocalPlayer on receipt of that message to avoid running the code twice (and thus showing duplicate visual, for instance).

Does Unity networking have something built in that manages this sort of (very, very common) pattern? Or is the "correct" solution simply to check for isLocalPlayer and just take the hit on wasted bandwidth and CPU?

 

Any help? Even just some other opinions and perspectives would be appreciated.

 

no, you got it right - you would have to check for isLocalPlayer in your RPCs so you don't do things twice.

 

Yes, the really need an "all clients but me" mode, particularly considering you will get charged for the bandwidth to receive a message you won't need to process In our architecture, essentially 1/4 of all messages in a 4 player match are "wasted."

 

That's a bit of a bummer, but I'm not surprised. Thanks for the replies.