Is it "bad" to use RPCs to synchronize movement?

Questions & Answers
1

I hear that RPCs can be slow if you’re using them to synchronize player positions. People say to use NetworkViews instead.

However, my situation is a bit more complex…
I’m using RPCs as “pings”, which go to straight to the server. The server receives the ping, then sends an “update” to all other clients that need to know where the pinged player is. Those clients simulate where the player is by using a list of places that the player has to go, and having the player move through each position in the list one by one, kind of like following the same path the pinged player took.
Each client keeps track of the last time it pinged its position, and only pings it if it’s been so much time since then.

The way I’ve set it up makes it hard to just “start using NetworkViews”, because I relied on the method of using RPCs to convert positions into ‘orders’.

My question is, is it “bad” to do it this way? Will I experience a lot of lag issues if I had lots of players “pinging” their position and jumps and everything through RPCs instead of NetworkViews?
If so, would it be best to use a NetworkView with Unreliable state synchronization for the best performance?

Thanks for any answers!

2

If you’re sending them as “orders”, then what you’re doing should be fine. There are potential issues though, depending on what sort of game it is. Due to floating point rounding, execution order and such, it’s possible that clients may simulate the movement slightly differently, which can cause all sorts of problems.

For example, when doing pathfinding, it may cause a character on one client to choose a different path from another client, and all of the ramifications that follow from that.

So, this may or may not be a problem for you. If only the target position matters then you’re probably fine. If where the player is while moving to the target position matters you may have some problems.