I don't know, how long is a piece of string? Your question can't be answered exactly, it depends on how exactly you're processing them, your level of detail, etc.. why don't you try and measure? Try with, say, 64 bones, if it's too much, halve if, if it's too little, double it, and zoom in on the optimal amount (on average) this way?

Not only should you measure it for yourself as suggested by Bacterius, but you are also asking about 2 completely unrelated things.

It would be the same as me saying I wanted to make an egg sandwich and asking how many socks I need.

I will be wearing socks while I make the sandwich, but that has nothing to do with the process of making the sandwich.

Your objects will have bones, but that has nothing to do with network connections. You don’t send bones over networks.

Impulses, collisions, and error-checking gets sent over the network. 1 bone or 1,000,000 bones, if there is only one collision only one small packet of data gets sent over the network.

Each client simulates the result of that collision for themselves and the server does periodic checks to make sure they are closely synchronized.

And all of this heavy lifting is done for you by Unity 3D so I won’t go into details (there is too much to explain anyway).

Bottom line: Number of bones is completely unrelated to network connections, unless you put socks on your sandwiches (and who doesn’t, right?), so profile based on how much of a load you expect to put onto the CPU’s of each player.

L. Spiro

in this specific situation the number of bones and the network are related, as i plan to send packets of the position and angle of each of the bones as well. So if there are 64 bones, it will send quite a bit of information about the position and rotation of each bone.

I dont really want to be measuring it all out as that would require me to test with multiple connected clients, as well as needing me to do a bunch of stuff to them to see how much it takes to max out and get laggy, i was just looking for a generalised answer from where i can start at and work from.

Why do you want to send that information across networks?

More information means better-informed answers means maybe better ways of doing it means better…you…doing. It. More better.

L. Spiro

the game involves a lot of physics in the combat system, and the angle+direction can affect how an attack will hit.
and for a hard boss guy or something, you'll need to find and attack weak points in its armor to kill it, which may be just a tiny slit between metal plates.

i dont know how better to explain it...

you will be able to control the direction and angle of your attack/defense in real time.

Sending bones is not the way to go, and in fact will likely just make the experience jittery and laggy for players.

It will also give them much less smooth play (like, jittery, or…laggy).

Again, standard networking rules are your best bet. Send the collision information when collisions happen, verify each player is reasonably sync’ed periodically, and put some faith into the clients.

If I swing my Double-Edged Automatic Tail Stomper Blade into the kneecap of the giant enemy, the client only sends the fact that it hit the knee with this angle and this force.

The server sends this to the other clients and they all run the simulation from there.

L. Spiro

I dont really want to be measuring it all out as that would require me to test with multiple connected clients, as well as needing me to do a bunch of stuff to them to see how much it takes to max out and get laggy, i was just looking for a generalised answer from where i can start at and work from.

You can do it in theory instead of testing in practice.

e.g. let's say you've got a client-server game where:

* a bone is represented with a quaternion rotation and a 3d vector position, which is 7 floats (28-bytes)

* a character has 64 bones (1792 bytes)

* a character state packet has 1 32-bit character-ID, and 64 bone states (1796 bytes).

* there's 32 characters (57472 bytes)

* the physics is updated at 30Hz (1724160 bytes / second == 1.6MiB/s download per client).

* the server is sending this to 32 clients (55173120 B/s == 52.6MiB/s upload at the server).

You can tweak those numbers until they fall within typical DSL speeds (maybe 100KiB/s download per client, 3-10KiB if you want to be friendly).

Also, your choice of networking architecture makes a big difference. The above is based around the typical "FPS model" of networking, where you've got an authoritative server that updates the state of all clients (and also assuming that the state of the bones needs to be synced explicitly, which L.Spiro is trying to tell you isn't usually the case). If you were instead using the typical "RTS model" of peer-to-peer lock-stepping, things would be completely different (you could have unlimited moving bones at a fixed cost, because the state of the objects is never sent over the wire, only the inputs to the sim)...

What kind of game are you making?