Re: Increasement of the rotation limit of the X-Axis
Posted: 10 Dec 2006, 17:04
Great, sounds like an architecture for Netcode-MK2 is slowly taking form.
Lemme try to think-out-loude/brain-storm on this approach... (beware that I can be completely off base with many of the thing that follow)
So, I'm a warzone client, and I'm only interested in receiving data about units that are "probably within my radar-sight".
I'm playing against DevUrandom, who's another warzone client, so he needs to send me data on those of his units that I might be able to see.
In order to do this, he needs to know, to some reasonable amount of detail, what I can see.
We're playing on a big 512 by 512 tile map, so I could send him a bit map where a 1 bit means that I can see that tile, and a 0 means I can't see that tile. That means that I have to send him 512*512/8 = 32 KB of data w/o compression - although it's within the 64 KB limit of the UDP packet, it's still a lot of data, and we don't really think we need that amount of detail.
So we split the map up in 8 by 8 tile sectors. This means that I now have to send him a 64 by 64 bit map, that'll put us at 64*64/8 = 512 bytes of data. If we apply a deflate compression, a rough estimate says we'll cut 1/3 off the data, and land us at 512*0.6 = 307 bytes. Now, 8 by 8 might be a bit rough, so let's check on 4 by 4: 512/4 = 128, ((128*128/8)*0.6)/1024 = 1.2 KB.
A map that big is probably an 8-player map, so I will be, as a client, uploading 1.2 KB, and downloading 1.2*7 = 8.4 KB of data every time we exchange eye-sight data. The server will be downloading eye-sight data from each client (1.2*8 = 9.6 KB = 77 Kb), and unicasting data from the other clients, to each client (7*8.4 = 58.8 KB = 470 Kb) - a total of 547 Kbits on the server, and 76.8 Kbits on the client, for the eye-sight data.
And while I was writing it, I came up with another, and probably better approach anyway.
I remember reading this: http://trac.bookofhook.com/bookofhook/t ... Networking
It describes the networking model in Q3: UDP, delta compression.
The short of it is, that we all send the difference between last known state and current state, and the recepients sends a response to confirm that they have recieved our state update.
It's a bit harder to predict how much data will be transfered per second, but it's most likely less than the above approach, since all packages containes only the relative changes to the previous packet.
In order to get to the bottom of how much data is transfered, we need to know exactly what information needs to be send between the clients. We need stuff like eye-sight, unit locations and possibly a path-plan for each unit, and we need orders in relation to units (attack, target, repair) and in relation to locations (attack, target, repair, move, construct building, new unit created, what else?).
So we have a variety of data types. We could define a container format that helped describe and structure these packets. Probably something like this:
UDP already defines the full length of the entier body of the packet, so we don't need to do that.
And we could define the eye-sight data sector like this:
Thinking about it, this approach might work alright.
Tell me what you think.
Lemme try to think-out-loude/brain-storm on this approach... (beware that I can be completely off base with many of the thing that follow)
So, I'm a warzone client, and I'm only interested in receiving data about units that are "probably within my radar-sight".
I'm playing against DevUrandom, who's another warzone client, so he needs to send me data on those of his units that I might be able to see.
In order to do this, he needs to know, to some reasonable amount of detail, what I can see.
We're playing on a big 512 by 512 tile map, so I could send him a bit map where a 1 bit means that I can see that tile, and a 0 means I can't see that tile. That means that I have to send him 512*512/8 = 32 KB of data w/o compression - although it's within the 64 KB limit of the UDP packet, it's still a lot of data, and we don't really think we need that amount of detail.
So we split the map up in 8 by 8 tile sectors. This means that I now have to send him a 64 by 64 bit map, that'll put us at 64*64/8 = 512 bytes of data. If we apply a deflate compression, a rough estimate says we'll cut 1/3 off the data, and land us at 512*0.6 = 307 bytes. Now, 8 by 8 might be a bit rough, so let's check on 4 by 4: 512/4 = 128, ((128*128/8)*0.6)/1024 = 1.2 KB.
A map that big is probably an 8-player map, so I will be, as a client, uploading 1.2 KB, and downloading 1.2*7 = 8.4 KB of data every time we exchange eye-sight data. The server will be downloading eye-sight data from each client (1.2*8 = 9.6 KB = 77 Kb), and unicasting data from the other clients, to each client (7*8.4 = 58.8 KB = 470 Kb) - a total of 547 Kbits on the server, and 76.8 Kbits on the client, for the eye-sight data.
Alright, so that approach is too heavy - and I haven't even talked about the response t the eye-sight data yet.(eg. my upload is cut to 15Kb/s) and we also got modem players, which are lucky if they get my 15Kb/s for download.
And while I was writing it, I came up with another, and probably better approach anyway.
I remember reading this: http://trac.bookofhook.com/bookofhook/t ... Networking
It describes the networking model in Q3: UDP, delta compression.
The short of it is, that we all send the difference between last known state and current state, and the recepients sends a response to confirm that they have recieved our state update.
It's a bit harder to predict how much data will be transfered per second, but it's most likely less than the above approach, since all packages containes only the relative changes to the previous packet.
In order to get to the bottom of how much data is transfered, we need to know exactly what information needs to be send between the clients. We need stuff like eye-sight, unit locations and possibly a path-plan for each unit, and we need orders in relation to units (attack, target, repair) and in relation to locations (attack, target, repair, move, construct building, new unit created, what else?).
So we have a variety of data types. We could define a container format that helped describe and structure these packets. Probably something like this:
UDP already defines the full length of the entier body of the packet, so we don't need to do that.
Code: Select all
wz_delta_packet :=
<player_ID : Uint8>
<sequence_ID : Uint16>
<delta_since_sequence_ID : Uint16>
delta_sector
[delta_sector ...]
delta_sector :=
<data_type_ID : Uint8>
<data_body_length_in_bytes : Uint16>
<data_body : Unit8[]>
On top of that, as Hook suggest, we could apply a per-packet Huffman or deflate compression.eye_sight_data_sector :=
map_sector_coord_pair // the existance of a coord pair will flip the visibility boolean
[map_sector_coord_pair ...]
map_sector_coord_pair :=
Thinking about it, this approach might work alright.
Tell me what you think.