• Advertisement

Archived

This topic is now archived and is closed to further replies.

How often should I update the clients?

This topic is 6425 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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-

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
> 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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Code both, and test it ;-)

sorry, i know it wasn''t very helpfull, but i would write diffrent netcodes for diffrent things... why stick to 1 model?
So in the optionsmenu u could choose if it is a LAN or a Internet game...
does that sound ok?

And, yes, tell me if your game is done, me and my friends sometimes got times during Lanparties where it gets boring...
I''m sure all of them would like to test it ;-)

ok,
good luck,

Phil

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think your on the right track using method #2. For instance using spatial sorting you can ignore the inputs of players outside your view, and as i mentioned previously you can compress down all input command packets into about 2 bytes. So even if all say 10 players pressed fire at that tick and were in your view, it would be about 20 bytes. Using tcp-ip will simplify your network architecture however it will suffer badly if your connection is noisy, and droping packets. Since this is a starter project i dont suggest tackling the complexity of a purely UDP based protocol yet.

-ddn

Share this post


Link to post
Share on other sites
Hi ddn or BlackSideSnap,
thanks so far !

So I will try to realize way #2! So I only send the player input to the server. The server will validate the input of all players and send it back to them. How often shall I validate the player input? 2 times a second ? I only know that the server has to update all players at the same time, to make them stay in sync.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I suggest validating the inputs at 10 update per second. Yes, you''ll have to send the input changes (no need to send redundant inputs) to all the players if you want to keep them in sync. Unless your using the spatial filter I talked about previously. In that case you''ll need a special state packet which initializes a players position when they enter the screen area of the current players viewable area. In that case you only need to send the player inputs of current visible players but there is no need to add this complexity if the number of players are low (about 1 - 20).

Note when you validate and proprogate the users input, is when you apply it server side. That is postpone processing of the user input you recive out of sync to the 10 ups. The reason for this is becuase your not sending absolute states of the entities but the relaitve state changes, which is quite time dependent. The small error of applying the input at time of arrival and the proprogation of input to the clients will eventually acculmulate and the clients will diverge from the server drasticlly.

So basiclly dont forget to send the timming tick every tick, this frames the user inputs packets and guarrenttes they are executed at the proper time and durration. (with TCP IP)

If your up to it, there is a simple extension using a UDP only protocol is possible, with the exact same network architecture.

Bascilly to compenesate for packet drop, you have to add a absolute state packet, which is sent peroidiclly. So lets say at 1 ups a absolute players state packet is sent to the client. Each player is on its own timmer so the packets are spread out over time so they dont flood the line. A absolute state packets contains the players postion, direction, and speed if you use speed.

Also the client side timming algorithim needs to be flexible enough to compensate for loss of a timming packet. So given that you know the rate of update on the server side you should be able to predict the next tick packet, whether it arrives or not.

The framming of the player inputs isnt so important as the absolute state packets will synchronize the player state every 1 sec.

I look forward to seeing your game.

Good Luck

-ddn

Share this post


Link to post
Share on other sites
Mhmm
I wanted to make it easy for the beginning. Just wanted to send the input updates and the time passed since last update. The only problem I had was the time between one update and the next. When a frame takes for example 15-30 ticks and I only get a validated update all 100 ticks. Shall I then create 5 identical frames?

Share this post


Link to post
Share on other sites
Aaaaaahhhhhhh
so you mean sending a small packet with 1 or 2 bytes for example, containing the time passed since last tick packet. And when e.g 100 ticks happended since last input update, I send a new input update. Ey Cool! Thats great!
So the clients can draw/calc new frames every time a new timing packet arrives.

Thank you Thank you Thank you!

You should really write a tutorial, covering all the stuff you wrote above!!

Hey GameDev.net- staff get this guy, and make him write tutorials.

Share this post


Link to post
Share on other sites
i second that.

even if it''s just a "formalized" version of what has been posted in this thread. it''s good material.

a2k

"Save early. Save often."

a2k

Share this post


Link to post
Share on other sites

  • Advertisement