Sending Command/RPC every frame? Question from a noob.

Unity Engine
1

I am setting up multiplayer for a 2d game using Unet. My game is heavily based on player collisions, so velocities and rigidbody positions need to be accurate. I wrote my own authoritative server scripts (Unet network transform didn’t work well, and although I got close with photon, I gave up on messing with the interpolate/extrapolate numbers after a while).

I haven’t decided the max number of players, i’m hoping I can handle at least 6 on a single server, but that will be reliant on the answer to this.

I need to send as much data about player velocities from server to clients as possible. It’s a very simple game, so I’d essentially need to send just one piece of information as often as possible.

  1. Is sending a command with a vector3 from each client every frame to server a viable solution? (50 commands a second).

if so:

  1. Is sending a clientRpc to each client from the server a viable solution if I use a dedicated headless server?
    2a) What if I allow a player to host the game? Will that be too much traffic for an average persons internet connection to handle?

  2. Am I even asking the right questions?

2

We have our own system. We call RPCs on the server all the time, so it’s definitely viable. Our character controller, for example, can send data every frame if it needs to. What you can get away with will depend on your code efficiency.

As for traffic, that should be easy to compute: One person is the host, connected to 5 others, 50 updates per second, and let’s say you have 4 bytes for your command and 12 bytes for the vector3, per person. Your packet size is 16*6 = 72 bytes. AT 50 updates per second that is 3600 bytes per second, per client. That means that host will have to sustain at least 144kbps to run the game. That’s pretty low, since even a crappy internet connection has 10x more upload capacity than that.

2 Likes
3

Thanks for the reply. I assumed that was the way to calculate it but wasn’t sure. I just implemented the stuff I found in this thread: Unet server-authoritative movement with client-side prediction and reconciliation and the movements are now buffered. Hoping this has solved the problem of getting a fast paced physics game together and compensates for lag.