3
\$\begingroup\$

I'm not talking about something such as an object position, which changes very often. I'm talking about some object state that may be changed infrequently, such as a door opening and closing.

Would it be better to send an RPC to saying "The door is opening/closing" or would it be better to replicated a property that tells us the objects state? Obviously this can be done both ways, but what are the advantages/disadvantages of each?

As far as I know any competent implementation will only consider replication for properties that have changed. This means when the property does actually change, it should have the same cost( assuming it must be reliably replicated ) as sending an RPC. The other advantage to doing this would be removing the need for more complex RPC buffering. If a client connects, they get sent the state, no need to buffer/unbuffer things.

All I can see is advantages for replicating over RPCs in this case. However, I always see suggestions to have as few replicating properties as possible.

\$\endgroup\$
2
  • \$\begingroup\$ I think you've demonstrated above that, implemented well, both forms have very similar costs for this situation. It seems unlikely that the choice to property replicate vs buffer these infrequent state changes will be a major determining factor in the game's performance. Maybe there could be a significant advantage that's specific to the kind of game you're making (eg. if you have thousands of infrequently-changed state variables, and only a handful get changed in any one game session), but if there's no such case obvious to you right now then it may be premature optimization to fret over it. \$\endgroup\$
    – DMGregory
    May 9 '15 at 4:29
  • \$\begingroup\$ That's what I've gathered from reading and a small amount of experience working with networking in Unity and Unreal 4. Obviously I'm not expert, so I'm looking for more information on the subject. Is there any other problems I might have with using property replication? Is it unreliable? Could a major state change be missed due to unreliability with property replication? \$\endgroup\$
    – Ben
    May 9 '15 at 16:11
2
+50
\$\begingroup\$

If you're using, for example, Unity's standard networking without an authoritative server, an RPC would be better because syncing something every frame can be VERY expensive because the packet header is some 20-40 bytes of bandwidth overhead in addition to the identification of the object being synced. You end up sending a lot more data than necessary.

This, compounded with the potential of having many doors, leads to a very straightforward decision. Generally, the less objects you need to constantly sync, the better.

Using an RPC does complicate some things, as you've mentioned (i.e. player joining later). Buffered RPC's would be overkill since you only need the last state change - not all of them. Instead, you can just send an RPC to the new player from the Master Client giving the game state. Your game can be semi-authoritative in that you delegate the responsibility of syncing 'everyone else', people who join later or get desynced, to a single client.

Useful Note: RPCs are reliable in Unity networking (not sure about Unreal) so you don't have to worry about your doors getting desynced as long as you send the message and the client is connected. If the client disconnects then comes back to the game, its sync should be handled by the Master Client.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ This doesn't make sense, considering replicated properties are only synced when they've changed. \$\endgroup\$
    – Ben
    May 10 '15 at 1:47
  • \$\begingroup\$ Oh, you were talking about delta compressed syncs? That wouldn't be too bad then, but there's always the chance that you won't get the UDP packets (assuming this syncing uses UDP), depending on how this compression is implemented. It's better to take the safe route and just reliably sync these objects since they're not frequently changed. \$\endgroup\$
    – JPtheK9
    May 10 '15 at 2:18
  • \$\begingroup\$ Apparently, all the modern AAA shooters use lockstep which calls for syncing input like "Move Left" rather than positions. This is difficult to do perfectly because of floating point accuracy errors and whatnot. You can, however, do something quite similar for less significant parts of our game. A lot of games like TF2 open doors if a player gets within a certain distance. I'm not sure if this can work in your game, but it would be a neat thing to automate door opening. Anyways, just a little idea that could be useful. \$\endgroup\$
    – JPtheK9
    May 11 '15 at 6:10
  • \$\begingroup\$ PS: RPCs in Unreal are unreliable (so good for sounds, particles etc what does not influence gameplay). \$\endgroup\$
    – Roi Danton
    Mar 29 '18 at 6:44
  • \$\begingroup\$ To correct myself: In UE4, RPCs now have to be flagged as unreliable or reliable. \$\endgroup\$
    – Roi Danton
    Mar 31 '18 at 7:10

You must log in to answer this question.

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