RE: How often should I update the clients?
Author
Hi!
I just read through that whole thread because I have the same question(s). (ie What should the server/client calculate? What should who send to who...)
To be honest, I was a bit confused with the bottom line. What did they decide on?
Perhaps this is because I am not inherently a network programmer myself, but rather I use a networking engine (basically a wrapper for Win32 socket stuff with support for UDP and TCP/IP) that my friend wrote for me.
Here are a few questions that I had (which were mostly answered in the other thread that was a little confusing.):
1) Should the Server take in client inputs, and spit out positions for players?
2) If the server does that, wouldn''t it make any sort of client side prediction imposssible?
3) Should the server just act as a distributor, telling all of the other clients about input updates that it has recieved, and allowing the clients to handle to physics and movement?
4) Should it be something in between, where the server calculates the physics and movement, but sends positions AND velocities & orientations, allowing the other players to keep a player going in that direction until another position/velocity/orientation is recieved from the server?
5) I''m thinking that number 4 is the best idea. If it is, should I send the p/v/o updates whenever I recieve (and calculate) an input update from a client?
6) How do you keep slower machines from getting bogged down by messages from the server? That is, how do you avoid there being so many messages, that by the time one is processed by the client, there are already 2 more waiting?
I think that covers the basics, though I have plenty of questions!
On the technical side, I''m currently using tcp/ip and working on the single player part of the game. (I''m making both use networking things -- think Quake-style) While the net code for a single player will be different, the architecture and what not (who sends to who and what etc...) will remain the same for both single and multiplayer.
Any ideas?
Thanks for any help!
-Snowman
For starts I would make all input go to the server for validation and make it so that there is zero prediction. Once you get that working, then I''d mess with prediction.
If your client is overburderned with messages, it''ll skip frames but all the information will still be current. If it''s running faster than the messages, it''ll just render extra frames while it waits.
I''ve got my server with zero prediction. Basically the client is just the graphics engine. I''ve got the packets so small (between 1 and 89 bytes) that the client can''t keep up and it skips frames. Nearly all 16 needed to render to show a smooth move. The key is figuring out what the client actually needs and then how to compress it to the fullest extent. Needless to say it''s looks great over a 56k modem. The target is 28.8 but I don''t have one to do a test.
I.e. tinker around. Eventually I''ll probably get around to doing a DirectPlay tutorial since they seem to be lacking.
Ben
If your client is overburderned with messages, it''ll skip frames but all the information will still be current. If it''s running faster than the messages, it''ll just render extra frames while it waits.
I''ve got my server with zero prediction. Basically the client is just the graphics engine. I''ve got the packets so small (between 1 and 89 bytes) that the client can''t keep up and it skips frames. Nearly all 16 needed to render to show a smooth move. The key is figuring out what the client actually needs and then how to compress it to the fullest extent. Needless to say it''s looks great over a 56k modem. The target is 28.8 but I don''t have one to do a test.
I.e. tinker around. Eventually I''ll probably get around to doing a DirectPlay tutorial since they seem to be lacking.
Ben
Author
KalvinB:
If you use no prediction (and it works well), what do you send from the server? Just something simple like the matrix of the object? It seems like things would need to be running *VERY* fast in order to make it believable, right?
Anyway, I have started to tinker around with the stuff, but have yet to get anything usable. For some reason, my structure is coming out screwed up on hte other end.
Is it ok to have a structure such as this:
struct NM_UPDATE
{
// Random things here...
char Name[MAX_NAME];
VECTOR3D m_v3dVector;
};
Where VECTOR3D is another class or a structure? Is that acceptable? Or do I need to send those differently? (As opposed to sending the whole NM_UPDATE structure). What do you think?
Thanks for your help!!
-Snowman
If you use no prediction (and it works well), what do you send from the server? Just something simple like the matrix of the object? It seems like things would need to be running *VERY* fast in order to make it believable, right?
Anyway, I have started to tinker around with the stuff, but have yet to get anything usable. For some reason, my structure is coming out screwed up on hte other end.
Is it ok to have a structure such as this:
struct NM_UPDATE
{
// Random things here...
char Name[MAX_NAME];
VECTOR3D m_v3dVector;
};
Where VECTOR3D is another class or a structure? Is that acceptable? Or do I need to send those differently? (As opposed to sending the whole NM_UPDATE structure). What do you think?
Thanks for your help!!
-Snowman
To the first poster I would suggest.
1)Yes the server should recive the clients inputs but not spit out the player position, rather validate the input, and if and only if the other clients (including the sending client) needs to be updated then it could either send an absoulte state packet (postion, movement vector etc..) or it could send a relative state packet (turn left , etc..). That depends mostly upon how you''ve set up your networking archiecture.
2)That depends upon how much additional information you give the client. For instance you could decouple the absolute state packets position and movement vector for instance. They could be updated asynchonrously, so every 1 sec you update the postion, and every 1/3 sec you update the movement vector. I use somehting like this and it works well.
3)Depends on your game, but if you''ve made your network protocols secure against client side hacking (using a form of encyptions on the packet stream and perhaps even within the game state data itself.) you could trust authoritive client side events. Or if your not willing to do that you can still use client side simulation of the physics and collision to improve the games appereance (so players wont go through walls, shots hit walls, etc..)
I use the later, and it works well.
4) & 5)That''s the idea.
6)Decouple your game simulation form your frame rate, instead base it on time. Time passes nearly equally between the server and client 8^) There are minor issues but this is the better way to go. Remeber any unprocesses packets waiting in the buffer, equates to more latency for the client. You want to give the player the most up to day information possible but still maintain the appearance of a smooth and continous simulation form one frame to the next.
From my expereience tcp_ip will not work on noisy and lossy lines. Be prepared to support the udp protocol and design that into your network archiecture if you want to make a game playable for the vast majority of people, but that really depeneds upon your project goals.
Good Luck
-ddn
1)Yes the server should recive the clients inputs but not spit out the player position, rather validate the input, and if and only if the other clients (including the sending client) needs to be updated then it could either send an absoulte state packet (postion, movement vector etc..) or it could send a relative state packet (turn left , etc..). That depends mostly upon how you''ve set up your networking archiecture.
2)That depends upon how much additional information you give the client. For instance you could decouple the absolute state packets position and movement vector for instance. They could be updated asynchonrously, so every 1 sec you update the postion, and every 1/3 sec you update the movement vector. I use somehting like this and it works well.
3)Depends on your game, but if you''ve made your network protocols secure against client side hacking (using a form of encyptions on the packet stream and perhaps even within the game state data itself.) you could trust authoritive client side events. Or if your not willing to do that you can still use client side simulation of the physics and collision to improve the games appereance (so players wont go through walls, shots hit walls, etc..)
I use the later, and it works well.
4) & 5)That''s the idea.
6)Decouple your game simulation form your frame rate, instead base it on time. Time passes nearly equally between the server and client 8^) There are minor issues but this is the better way to go. Remeber any unprocesses packets waiting in the buffer, equates to more latency for the client. You want to give the player the most up to day information possible but still maintain the appearance of a smooth and continous simulation form one frame to the next.
From my expereience tcp_ip will not work on noisy and lossy lines. Be prepared to support the udp protocol and design that into your network archiecture if you want to make a game playable for the vast majority of people, but that really depeneds upon your project goals.
Good Luck
-ddn
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
