Preface: this is my first foray into multiplayer.
I'm unclear on how to work this out - because I need to call GNetSync as often as possible in order to decrease the potential gap between someone firing a shot and the result of that shot to something not-noticeable.
If I update 30x a second, or every 33ms - worst case: the gunshot can be sent after 33ms from the originating computer, then 33ms after that the host picks it up, creates gunshot fx etc, then 33 ms later sends it, and then 33ms after that it's picked up - so the click-effect time to the user is around 120ms in the worst case - and thats with no network lag either, unless im misunderstanding this.
Also, GNetSync only transmits objects which have been modified, and I only modify objects which have moved, etc - so there doesn't seem to be any wasted space in the send.
However, with 4 gnet objects updating it takes 12k/second, and with 20 or so updating gnet objects - 8 players (in two game instances) and 12 guns, it uses constant up/down of about 10-12k a second. And with 60 guns, its about 60k/second. I think this must be related to what you were saying MichaelB about a minimum size.
However if I have 2 players and 4 guns (in 2 instances), it's around 12 k - adding 1 player and another 2 guns in another instance it leaps to 36k!
This is, I assume, because each game instance (which uses 6k to communicate its state to a partner) is now communicating to both, and so sending 12k each.
This is already waaay above the acceptable limit to join a player on ADSL in my hometown of Providence Rhode Island - where I tend to get around 20k upstream.
Does this mean its time to give up the project using GNet and peer to peer, and attempt to rewrite using a peer / server model? Or am I missing something I can use to fix this?
I don't need the customary 32 players, but 8 would be nice, and 4 is absolutely minimum. I'd also like regular DSL subscribers to be able to play it.
I'm unclear on how to work this out - because I need to call GNetSync as often as possible in order to decrease the potential gap between someone firing a shot and the result of that shot to something not-noticeable.
If I update 30x a second, or every 33ms - worst case: the gunshot can be sent after 33ms from the originating computer, then 33ms after that the host picks it up, creates gunshot fx etc, then 33 ms later sends it, and then 33ms after that it's picked up - so the click-effect time to the user is around 120ms in the worst case - and thats with no network lag either, unless im misunderstanding this.
Also, GNetSync only transmits objects which have been modified, and I only modify objects which have moved, etc - so there doesn't seem to be any wasted space in the send.
However, with 4 gnet objects updating it takes 12k/second, and with 20 or so updating gnet objects - 8 players (in two game instances) and 12 guns, it uses constant up/down of about 10-12k a second. And with 60 guns, its about 60k/second. I think this must be related to what you were saying MichaelB about a minimum size.
However if I have 2 players and 4 guns (in 2 instances), it's around 12 k - adding 1 player and another 2 guns in another instance it leaps to 36k!
This is, I assume, because each game instance (which uses 6k to communicate its state to a partner) is now communicating to both, and so sending 12k each.
This is already waaay above the acceptable limit to join a player on ADSL in my hometown of Providence Rhode Island - where I tend to get around 20k upstream.
Does this mean its time to give up the project using GNet and peer to peer, and attempt to rewrite using a peer / server model? Or am I missing something I can use to fix this?
I don't need the customary 32 players, but 8 would be nice, and 4 is absolutely minimum. I'd also like regular DSL subscribers to be able to play it.