game updates
Author
Im working on a client/server game, but now Im a little confused on how I should update gamestates on the server and client. It's an action game where events happen fast and lag can cause the game to snap. For each aspect im not sure about i've listed the options I thought of (please correct me when wrong or some option is missing)
Client:
1.)send updates from client to server periodically (fx every 30ms out from a message queue) or
2.)send updates from client to server imediatly when a event that the servers needs to know about happens
Server:
1.)send 1 update containing whole gamestate to all players at a fixed rate
2.)send a queue of updates to each player at a fixed rate (so this could be fx 4 different messages to each client)
For client updates on the server:
1.)accept the update message and update the new client information on the server immediatly
2.) accept the update and place it in a queue which will be handled in the server loop at fixed intervals
If you'd willing to share any expirience with what's best in what scenario's i'd greatly appreciate it!
Thanks!
I would recommend 1) 2) 2). You would have a fixed update rate on the server and the clients (graphics can of course run faster or slower). Every event would happen at a time granule that's part of your update loop.
However, this depends a bit on the actual game you're making, what gameplay is, how physics (if any) works, etc.
However, this depends a bit on the actual game you're making, what gameplay is, how physics (if any) works, etc.
Author
So you'd recommend always to put the messages in a queue?
But as this is done twice (at the client & the server) that adds an artificial lag of max twice the loop rate (fx 2x30ms + transmission time) to each remote update. I can imagine some message's would need to be send right away (like position updates) or would this lead to other problems when also using a message queue for other message types?
The game is a pong clone, but with extra dynamic elements. There are for example other collisions possible than wall/bat/ball collisions, there can be multible balls which can collide with each other too. The physics are fairly simple, just linear motion. So simple Euclidian integration would suffice in this case?
But as this is done twice (at the client & the server) that adds an artificial lag of max twice the loop rate (fx 2x30ms + transmission time) to each remote update. I can imagine some message's would need to be send right away (like position updates) or would this lead to other problems when also using a message queue for other message types?
The game is a pong clone, but with extra dynamic elements. There are for example other collisions possible than wall/bat/ball collisions, there can be multible balls which can collide with each other too. The physics are fairly simple, just linear motion. So simple Euclidian integration would suffice in this case?
Yes, simple forward integration is sufficient for Pong :-)
You might want to run your step rate much faster -- say, 120 times a second -- to alleviate some of the latency. However, if modems are involved in the networking, the step latency (16 ms for a 60 Hz physics engine) would still be small compared to the modem latency. A networked game needs to be designed to cope with latency, no matter where it comes from.
Now, you're saying you could send messages "immediately" -- but how would they be received? On the receiving side, you do "other things" for a while, then you go to the network and ask for new messages, and put them in a queue of messages to process, and when you're done polling the network, you process the messages. That really doesn't add any latency compared to immediately dispatching the messages within the network polling.
For a game as simple as Pong, you may of course get away with using a variable frame rate, and sending/receiving messages on-demand, but you'll still need some kind of rate cap (1000 datagrams a second is a bad idea). It's also a bad habit to get into IMO, because more complex multi-user games are much harder to get to work well that way (eventhough some early versions of Quake did it like that).
You might want to run your step rate much faster -- say, 120 times a second -- to alleviate some of the latency. However, if modems are involved in the networking, the step latency (16 ms for a 60 Hz physics engine) would still be small compared to the modem latency. A networked game needs to be designed to cope with latency, no matter where it comes from.
Now, you're saying you could send messages "immediately" -- but how would they be received? On the receiving side, you do "other things" for a while, then you go to the network and ask for new messages, and put them in a queue of messages to process, and when you're done polling the network, you process the messages. That really doesn't add any latency compared to immediately dispatching the messages within the network polling.
For a game as simple as Pong, you may of course get away with using a variable frame rate, and sending/receiving messages on-demand, but you'll still need some kind of rate cap (1000 datagrams a second is a bad idea). It's also a bad habit to get into IMO, because more complex multi-user games are much harder to get to work well that way (eventhough some early versions of Quake did it like that).
Author
I've run into a kind of practical problem when implementing this message queueing...
As how I've implemented it right now it prereserves a queue of a fixed size (lets say 30 messages). But obviously an overflow could occur. What I've done now is that you can set to drop messages or overwrite older messages when a overflow occurs:
When the queue is full (there wasn't a chance to read messages from it in the server loop, but more than 30 messages arrived.) When I chose overwrite, the queue will "loop". It will start at the beginning again and overwrite older messages with the new messages.
If I chose drop messages, it will just drop new messages that come in but cant be put in the message queue.
Should I just make sure to have the queue tweaked to have a good max size and work out an ack system (to ack all processed messages)? I didn't want to do this because it seems to be overkill for TCP communication. Or should I have my message queue grow dynamically?
As how I've implemented it right now it prereserves a queue of a fixed size (lets say 30 messages). But obviously an overflow could occur. What I've done now is that you can set to drop messages or overwrite older messages when a overflow occurs:
When the queue is full (there wasn't a chance to read messages from it in the server loop, but more than 30 messages arrived.) When I chose overwrite, the queue will "loop". It will start at the beginning again and overwrite older messages with the new messages.
If I chose drop messages, it will just drop new messages that come in but cant be put in the message queue.
Should I just make sure to have the queue tweaked to have a good max size and work out an ack system (to ack all processed messages)? I didn't want to do this because it seems to be overkill for TCP communication. Or should I have my message queue grow dynamically?
I suggest having it grow dynamically, but if you receive too many packets from a single user, start dropping them or kick the user from the game, etc. The limit should be higher than you think the game will ever actually use - if you have 60 updates per second, you might want to set the per-second limit to however many packets would be in 300 updates. Without some kind of hard limit, a client could kill the server by simply sending as many packets as possible (either editing the client exe or by making a custom program to flood the server).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement