RPC vs. OnSerializeNetworkView

I have a question concerning network performance and traffic.

I have a couple of guys to be synchronized, typically some FPS avatars running around in a P2P enviroment.
Right now I'm sending RPC calls 10 times a second for every avatar to be in sync. I was wondering if the use of OnSerializeNetworkView instead would have less overhead and would increase the performance of the game.

I'm not 100% sure, but I think using OnSerializeNetworkView everything is running first through the P2P server, before being distributed to all other clients. So I thought a RPC call from any client to RPCMode.Others is more efficient. Is that right?

 

No, RPCs are also routed through the "server", even if you use RPCMode.Others or the like. One advantage of using the built in synchronization would be that you could use "Reliable Delta Compressed" which should be a bit better from the bandwidth perspective.

You might not even need to implement a custom OnSerializeNetworkView for that.

 

Jashan, have you implemented any dead-reckoning for your TraceOn game?

 

Kind of ;-)

Basically, what happens in Traces of Illumination (previously TraceOn) is that everything is moved both on the clients and on the server. Every "once in a while" (that can be configured online depending how well the server is doing, but I usually have it between 5 to 10 times per second), the server sends the positions of all tracers, and they synchronize on that (position + time the message took to arrive * currentVelocity). Usually, I could even put that rate down to once per second without significant effects, because ...

... certain "events" also come with locations, e.g. when you do a turn, the client sends its current position (I'm doing some distance checks on the server to prevent cheating, so you can't just send any position and expect the server to trust you on that ;-) ).

Also, when you speed up, slow down, jump, start bullet time and the like, you get specific location-synchronization for these events to assure that they start (and end) the same on every client as much as that is possible ;-)

As I'm using my own logic for moving everything, I decided it would be better to handle everything with RPCs instead of NetworkView-synchronization.

 

Thanks, that's interesting to know.
I'm assuming everyone travels along a grid, so you probably don't need that much dead-reckoning, especially if you are doing a simulation heartbeat 5-10 times per second. Would make the traffic heavy on the P2P host with more than 4-5 players, no?

 

Yo, the grid simplifies things quite a bit ;-)

That's particularly important because Traces of Illumination is built upon an "authoritative server design", and each one of these servers should support as many clients as possible (for now, I only have one running). Theoretically, I could support hundreds of players on a single server (even with multiple game sessions taking place in the same levels - which was fun to implement because neither do I want collisions between cycles in different game groups, nor do I want network messages from them; and I implemented that pre 2.1 ;-) ).

Only testing will tell how much really is possible on a decent server machine (anyone got a few 100 players available? ;-) ) - but I have a "special load-testing mode" in the beta-clients so that if your machine is powerful enough, you could simulate a couple of clients on a single machine (on my Mac Pro, 8 clients is "still okay", with more it's not really that much fun anymore ;-) )

That said: If it turns out I'm running into trouble, there's still plenty of room for optimzations...

 

thanks for the answers