Quote:Original post by staticVoid2
I've read the links you posted and about quake... they basically send all object states every frame and use delta compression?

You delta compress in-memory, using the difference for each entity state between the ack state and the latest state, and you can compress that packet further with Huffman compression. Entities that haven't changed since the client ack number don't need to be sent. That means that the first state sent to a client (snapshot), will be much bigger than updates, since you need to send the base state of every entity in the game.

But since the sending is done during map loading, or can be throttled easily for clients joining games in progress, that's not a problem. Loading can take quite a while depending on the size of the initial game state.

Quote:what happens if they run out of room to store everything in one packet, or is this a limitation they impose.

No limitation is necessary. You can design a packet segmentation and reconstruction manually, it's not that hard. But you can use the UDP limit (64K) if you think your packets will never reach that limit.

Quote:
I think I'm getting mixed up about the server client model... would the server calculate everything such as the current frames in animation etc. and then send this to each client?

pretty much. Although the more dead-reckoning you can do on clients the better (basically, make educated guesses to save bandwidth.

Quote:
and what does the client send to the server, just the key/mouse input or more?

Commands usually. Not really inputs, but what the inputs should do (move left, move right, look towards (30, 123, 537), ect...).

Look at Gaffer's article on Networked physics as an example and case-study.

Quote:Original post by oliii
But you can use the UDP limit (64K) if you think your packets will never reach that limit.

While 64K is indeed the protocol limit, routers tend to fragment anything much over about 1200 bytes, which makes large packets extremely unreliable over anything except a LAN.

Quote:Original post by staticVoid2
thanks for all your help, I have one more question (if you don't mind)...

for data that remians fairly constant such as player names etc. would this data also need to be sent every frame?

Nope. The static data would be part of the initial base state. However, since the data doesn't change, as soon as the client aknowledge the base state, that data does not need to be sent again (the delta compression will detect no change and will not send it).

This can work better if you 'lock' your update until the first state is aknowledged. If you can send the initial state reliably and wait until the client aknowledges it before sending further updates, you can 'throttle' the bandwidth and make sure you are not sending data more rapidly than your connection can handle (something TCP/IP does automatically, but you can roughly emulate that protocol through UDP).

But that's if you have a lot of static data with a large initial state. Say your initial state is 24K kilobytes in size, and if you limit your outstream bandwidth to an 4KBytes per client (16 clients -> 64kBytes outstream -> 512 Kbits outstream, what a pretty good DSL line could achieve), it could take up to 6 seconds to send that initial state to every clients. So it's not something to be sniffed at :)

Sending the initial state reliably can be as simple as sending each segment (say your UDP packets are 1200 bytes in size, and your state is 24K total, that will make about 20 segments) one after the other and repeat, until the client aknowledges that he received everything. Packet loss may mean some of the segments might get lost in the process, so you'll need to resend them.

It's not optimum, so it could take quite a while if you have lots of packet lost.