ID:133606
 May 3 2008, 12:28 pm
|
|
Possible feature to allow a game to control how large the packets being sent to clients should be?
| |
One hypothesis is that some synchronization could improve if packet sizes were larger.
Consider this, suppose you have hundreds of objects who move together in a synchronized way. IF you are running the game offline, these objects will stay together and perfectly synchronized because there isn't a need to transfer packets of data over the internet. And that is exactly what I've seen. However, if you are hosting the game on a server, the packets have to be sent to the clients who will be watching these synchronized objects. The problem arises however, when the data for all these objects can't be sent in a single packet. When the synced objects move, the player might only recieve half of the object's movements in one packet, and the other half of the objects will send their movements in the next packet. Even though the delay between recieving the packets is very small, it is enough to cause a visually noticeable difference. The result is choppy looking synchronized motions, and it is a problem that is current plaguing my game. At least, that is one possible source of the problem. It would still be possible to end up with choppy sync even with bigger packets, but probably not as likely. | |
Not only would that take up a lot of work (IIRC Dan left the networking a mess) but it would not get rid of the problem entirely.
George Gough | |
I don't think this is a good enough reason for such a major revamp, as it won't necessarily help much anyway. I assume it would take a long time to implement.
Did you try lowering the tick_lag? It might improve your problem, though I'm not sure. | |
Obs wrote:
One hypothesis is that some synchronization could improve if packet sizes were larger. For the most part, objs are already sent as kind of a package deal. What might be less synchronized are their appearances, which, if the client hasn't seen them before, have to be requested in a batch. However, if you are hosting the game on a server, the packets have to be sent to the clients who will be watching these synchronized objects. The problem arises however, when the data for all these objects can't be sent in a single packet. When the synced objects move, the player might only recieve half of the object's movements in one packet, and the other half of the objects will send their movements in the next packet. If all the objects are in the client's view space, the movements will all be received at once. Something else is likely driving this problem. Lummox JR | |
Well you never know, it could have been possible that the packet sizes were determined by certain variables and it would be easily changeable. But who knows.
I've messed with tick_lag and it has no affect at all. | |
If all the objects are in the client's view space, the movements will all be received at once. Something else is likely driving this problem. Like what? It's already going as fast as I possibly know how. Each object is moved purely by increasing or decreasing the coordinate variable by 1 for the direction of travel. So that's about 230 something calculations for 230 something objects on any given movement of the objects. And they are all in the client's view space And it STILL ends up choppy when you are doing this over the internet. | |
Just to put in perspective of how small of a delay we are talking about here, using : instead . to reference location variables actually resulted in slightly better performance, in that more objects stay perfectly synchronized through the motions. However, the other half of the objects still lag behind by about a tenth of a second or so.
However, I think I am close to finally closing in on some kind of solution, but the problem will still remain. | |
Obs wrote:
I'm not sure. How do I check. http://www.speedtest.net That is the site IIRC. George Gough | |
George Gough