.
Every client only sends the Userinput and other ClientEvents to the server. The game logic happens only in the server, so the clients just receive the updated data and then draw the next frame. My Question: Should I try to send the updated data for every frame? Will this be fast enough/possible when I have a packet size of more than lets say 270 bytes and a desired frame rate of more than 30hz. Or should the player try to calculate the next frame?
I am afraid that when the LAN is to slow that the data will only refresh all 0.5 secs and the Client draws 15 frames with the data and the next 15 with the new. Won''t this look ugly ?
Thanks in advance
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
How often should I update the clients?
Author
Hi there,
I am currently writing a small Client-Server Game for the "boring" breaks during lan-sessions .
Every client only sends the Userinput and other ClientEvents to the server. The game logic happens only in the server, so the clients just receive the updated data and then draw the next frame. My Question: Should I try to send the updated data for every frame? Will this be fast enough/possible when I have a packet size of more than lets say 270 bytes and a desired frame rate of more than 30hz. Or should the player try to calculate the next frame?
I am afraid that when the LAN is to slow that the data will only refresh all 0.5 secs and the Client draws 15 frames with the data and the next 15 with the new. Won''t this look ugly ?
Thanks in advance
.
Every client only sends the Userinput and other ClientEvents to the server. The game logic happens only in the server, so the clients just receive the updated data and then draw the next frame. My Question: Should I try to send the updated data for every frame? Will this be fast enough/possible when I have a packet size of more than lets say 270 bytes and a desired frame rate of more than 30hz. Or should the player try to calculate the next frame?
I am afraid that when the LAN is to slow that the data will only refresh all 0.5 secs and the Client draws 15 frames with the data and the next 15 with the new. Won''t this look ugly ?
Thanks in advance
Jesus, you just asked one of THE big questions. How often to send data, and if/when to interpolate. This all depends on what you''re trying to do with your game, whether or not packets can be lost, etc. For a game like Quake you broadcast mad data and update the game with that data when it gets there. If a packet gets lost, no big deal, there are 20 more coming within the second. If you go with TCP, where you won''t lose packets, you can send packets once a second (if you wanted) and interpolate in the mean time, because everything would stay in sync.
What kind of game are you making?
-BacksideSnap-
What kind of game are you making?
-BacksideSnap-
Author
I want to program a Bomberman-clone. Since Atomic Bomberman caused several problems during our lan sessions, I thought I should write sth better Well for the first try I will limit it to 8 Player, each of them may drop 10 bombs at once. The coordinates of the objects and bombs are integers, but the bombs may be kicked and moved between the integers. The player coordinates are always floating points. I will use TCP.
PS: During our lan games IPX turned out to be much more instable than TCP. That''s why we called our clan and network club "Out of Sync" (screen output of Duke Nukem).
Well for the first try I will limit it to 8 Player, each of them may drop 10 bombs at once. The coordinates of the objects and bombs are integers, but the bombs may be kicked and moved between the integers. The player coordinates are always floating points. I will use TCP. PS: During our lan games IPX turned out to be much more instable than TCP. That''s why we called our clan and network club "Out of Sync" (screen output of Duke Nukem).
hmmm 30*270 = 8100 bytes per second, that well beyond a 56k modems maximum througput arounf 2000 bytes per second. If your intending this for lan or high bandwidth connections this wont be too much of a problem. I suggest for a starter project going with the simplest server client model.
-Server sends timming info (current tick) every tick, that''s assuming the smallest message is 1 byte, 30*1 bytes = 30 bytes. The client doesnt update its frame unless it recives this tick packet, to keep everyone synchronized. You should be able to squeeze the timming info into 1 byte.
-Send players command info instead of their state. That is if the player moves left, send the move left command instead of the x,y positon of that player. The reason for this is that all the action commands can be fitted into 1 byte while you''ll take up about 8 bytes for 2 floats, and you would constantly send player state info if you use that method. (8 players * 1 byte command + 1 byte player id )* 30 = 480 bytes.
-Just in case there is a possible desynchonization send player state info . Player state can include x and y for a bomber man clone. Lets send the state info once per 3 seconds. So thats ((8 bytes state / 3) + 1 byte for player id)* 8 players = 30 bytes per second. This isnt nessecary for TCP/IP since there will be no loss.
For every packet there is an overhead in adition to any protocol overhead used by TCP/IP or UDP. So the overall bandwidth requirement is just a rough figure. Also there is an initization packet which inits the players state, which isnt part of the bandwitdth calacuation as its done once per life, which could be many seconds long.
So it''s possible to design a bomberman clone game which uses about 600 bytes per second, and thats peak bandwidth requirement. It''s unlikely that you will need to send 1 command every frame for every player, proably you''ll have 1/3 that.
The drawback is the simple synchornization scheme is very sensetive to line conditions. Packets dont arrive in the orderly spacing as they were sent. Since the game has such a simple synchonization scheme, packet clumping will result in sticking frames and frame skipping. I dont know of a good solution to this problem.
Also bomberman clone games are reflex action games which work best with minimum latency, so packet buffering should be use only on the packets generated that tick. Send all packets out at the end of the tick, and disable Nagles algorithim in TCP/IP.
Good Luck
-ddn
-Server sends timming info (current tick) every tick, that''s assuming the smallest message is 1 byte, 30*1 bytes = 30 bytes. The client doesnt update its frame unless it recives this tick packet, to keep everyone synchronized. You should be able to squeeze the timming info into 1 byte.
-Send players command info instead of their state. That is if the player moves left, send the move left command instead of the x,y positon of that player. The reason for this is that all the action commands can be fitted into 1 byte while you''ll take up about 8 bytes for 2 floats, and you would constantly send player state info if you use that method. (8 players * 1 byte command + 1 byte player id )* 30 = 480 bytes.
-Just in case there is a possible desynchonization send player state info . Player state can include x and y for a bomber man clone. Lets send the state info once per 3 seconds. So thats ((8 bytes state / 3) + 1 byte for player id)* 8 players = 30 bytes per second. This isnt nessecary for TCP/IP since there will be no loss.
For every packet there is an overhead in adition to any protocol overhead used by TCP/IP or UDP. So the overall bandwidth requirement is just a rough figure. Also there is an initization packet which inits the players state, which isnt part of the bandwitdth calacuation as its done once per life, which could be many seconds long.
So it''s possible to design a bomberman clone game which uses about 600 bytes per second, and thats peak bandwidth requirement. It''s unlikely that you will need to send 1 command every frame for every player, proably you''ll have 1/3 that.
The drawback is the simple synchornization scheme is very sensetive to line conditions. Packets dont arrive in the orderly spacing as they were sent. Since the game has such a simple synchonization scheme, packet clumping will result in sticking frames and frame skipping. I dont know of a good solution to this problem.
Also bomberman clone games are reflex action games which work best with minimum latency, so packet buffering should be use only on the packets generated that tick. Send all packets out at the end of the tick, and disable Nagles algorithim in TCP/IP.
Good Luck
-ddn
wow, ddn, have you ever thought of writing an article for gamedev? there are plenty of "how to use winsock" articles, but one that covers packet data, synchronization, latency, and the like would be greatly needed.
good stuff.
a2k
good stuff.
a2k
> Should I try to send the updated data for every frame?
Please don't send more than 10 packets per second over the Internet, or you'll see data loss and bandwidth problems (as well as being a bad netizen). Besides, how often can the player change his inputs in a second?
> I am afraid that when the LAN is to slow that the data will
> only refresh all 0.5 secs and the Client draws 15 frames with
> the data and the next 15 with the new. Won't this look ugly ?
There is a good discussion about interpolation and prediction in the latest article at this address: http://www.codewhore.com/
Edited by - fprefect on June 30, 2000 11:45:56 PM
Please don't send more than 10 packets per second over the Internet, or you'll see data loss and bandwidth problems (as well as being a bad netizen). Besides, how often can the player change his inputs in a second?
> I am afraid that when the LAN is to slow that the data will
> only refresh all 0.5 secs and the Client draws 15 frames with
> the data and the next 15 with the new. Won't this look ugly ?
There is a good discussion about interpolation and prediction in the latest article at this address: http://www.codewhore.com/
Edited by - fprefect on June 30, 2000 11:45:56 PM
Author
Thanks for the replies!
I read them, yes I really read them.
And today I thought about the architecture of the game again. Well, I could reduce the size of the paket to 2+n_players*2 Bytes sent from server to every client, and 3-4 Bytes sent from every client to server. That way I only send, the time passed since last update, the player inputs and errors. BUT then all clients would have to calculate the whole frame on thier own.
Which way should I go?
1. Let the server calculates the frame update and sends all updates to the clients.
2. The clients only send and receive player inputs over the net, and calculate everything on their own.
??
Edited by - TheMummy on July 4, 2000 4:24:55 PM
I read them, yes I really read them
.And today I thought about the architecture of the game again. Well, I could reduce the size of the paket to 2+n_players*2 Bytes sent from server to every client, and 3-4 Bytes sent from every client to server. That way I only send, the time passed since last update, the player inputs and errors. BUT then all clients would have to calculate the whole frame on thier own.
Which way should I go?
1. Let the server calculates the frame update and sends all updates to the clients.
2. The clients only send and receive player inputs over the net, and calculate everything on their own.
??
Edited by - TheMummy on July 4, 2000 4:24:55 PM
I see two problems with #2:
A. Raw player input must be sent reliably or the simulation can desynch on a single dropped packet. For example, if you miss the packet where a player turns to face right, your simulation will constantly disagree with his. Instead, send player locations and velocities -- so that each packet contains absolute information for the player. (You can even do simple compression, such as sending an empty packet if the values haven''t changed)
B. A client/server model will generate 2*(n-1) packets per network frame, but that number jumps to n*(n-1) if each host sends packets to every other host. For Internet games with 5 or more players, that is simply impractical (you might be able to use subnet broadcasts to get away with it on LANs, but that''s a special case).
The advantage of #1 is that the server can perform double duty: accumulating then resending each player''s status updates, and acting as the authority simulation against which all of the others are synchronized.
A. Raw player input must be sent reliably or the simulation can desynch on a single dropped packet. For example, if you miss the packet where a player turns to face right, your simulation will constantly disagree with his. Instead, send player locations and velocities -- so that each packet contains absolute information for the player. (You can even do simple compression, such as sending an empty packet if the values haven''t changed)
B. A client/server model will generate 2*(n-1) packets per network frame, but that number jumps to n*(n-1) if each host sends packets to every other host. For Internet games with 5 or more players, that is simply impractical (you might be able to use subnet broadcasts to get away with it on LANs, but that''s a special case).
The advantage of #1 is that the server can perform double duty: accumulating then resending each player''s status updates, and acting as the authority simulation against which all of the others are synchronized.
Author
A happy hello to all netizens out there!
Thanks you for your reply!
Way #2: I wanted to send the player input up to the server!
Maybe only when the input/error state changes. Every second or half second the server sends the input state of every player back to each client.The protocol of my choice is TCP/IP, a 'physical' friend (you know these kind of friends you have to meet in the outside world) told me that it is dumb safe (a german 'slang' [no explanation availabe ] expression for bug proof), because TCP does some checksum tests, and when a packet gets lost it sends it again. Well I am not sure if this is true but I think so.
Edited by - TheMummy on July 6, 2000 2:49:53 PM
Thanks you for your reply!
Way #2: I wanted to send the player input up to the server!
Maybe only when the input/error state changes. Every second or half second the server sends the input state of every player back to each client.The protocol of my choice is TCP/IP, a 'physical' friend (you know these kind of friends you have to meet in the outside world) told me that it is dumb safe (a german 'slang' [no explanation availabe
] expression for bug proof), because TCP does some checksum tests, and when a packet gets lost it sends it again. Well I am not sure if this is true but I think so.Edited by - TheMummy on July 6, 2000 2:49:53 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
