25 Jul 12, 08:07PM
I think it is possible to do so.
Looking through the source recently I saw that a demo is basically just the packets sent by players to the server(obviously). So each part of the packet describes position, yaw, pitch, and other values at that point in time.
When you play a demo you are reading the positions, yaws, pitches, etc. from each packet and interpolating to fill in the gaps. I don't see any reason you couldn't play those packets in the opposite direction. Or even skip packets.
Speaking of packets, I noticed that the packets have the potential to vary in size. I wonder if it would be possible to reduce the size of packets sent to the server while some constant action is taking place.
For instance, when a player is afk/dead, must they really attempt to send 25 packets per second telling the server their position, yaw, pitch, etc? If something like a variable width packet is possible the first bit of data might describe whether any action was taken by the player. If no action is taken the server knows they must be standing still and there is no need for the server to receive position data(or any data for that matter). The first bit tells the server no change was made and the server just uses the previous packet's data.
More generally, until some change has taken place between two packets is it really necessary to update the server with every bit of data? If I'm running in a straight line down a corridor, maybe swinging my aim around, the only thing that has changed is my position, yaw, and pitch. Why not just send the data that has changed? Upon firing my weapon I can report to the server that such action has taken place and the server becomes aware of my new status. And maybe every 25th packet is a standard packet updating the server on every detail.
If it's not possible to do so during a live game I would like to at least see it done in demos. I think you could reduce the file size of demos substantially by doing so.
Looking through the source recently I saw that a demo is basically just the packets sent by players to the server(obviously). So each part of the packet describes position, yaw, pitch, and other values at that point in time.
When you play a demo you are reading the positions, yaws, pitches, etc. from each packet and interpolating to fill in the gaps. I don't see any reason you couldn't play those packets in the opposite direction. Or even skip packets.
Speaking of packets, I noticed that the packets have the potential to vary in size. I wonder if it would be possible to reduce the size of packets sent to the server while some constant action is taking place.
For instance, when a player is afk/dead, must they really attempt to send 25 packets per second telling the server their position, yaw, pitch, etc? If something like a variable width packet is possible the first bit of data might describe whether any action was taken by the player. If no action is taken the server knows they must be standing still and there is no need for the server to receive position data(or any data for that matter). The first bit tells the server no change was made and the server just uses the previous packet's data.
More generally, until some change has taken place between two packets is it really necessary to update the server with every bit of data? If I'm running in a straight line down a corridor, maybe swinging my aim around, the only thing that has changed is my position, yaw, and pitch. Why not just send the data that has changed? Upon firing my weapon I can report to the server that such action has taken place and the server becomes aware of my new status. And maybe every 25th packet is a standard packet updating the server on every detail.
If it's not possible to do so during a live game I would like to at least see it done in demos. I think you could reduce the file size of demos substantially by doing so.