game networking
-
ChebbyShabby
- Enthusiast
- Posts: 121
- Joined: Mon Jun 26, 2006 10:47 am
game networking
in online multiplayer games, are the coordinates of each player sent to the server continuously or are they sent at regular (larger) intervals and extrapolated (i.e. vectors)? im programming a game right now, and i have coordinates sent continuously -- that creates big lag even in LAN. can anyone point me in the right direction?
-
Joakim Christiansen
- Addict
- Posts: 2452
- Joined: Wed Dec 22, 2004 4:12 pm
- Location: Norway
- Contact:
For games maybe UDP is best to use instead of TCP (google to find out why).
What I would do is to send the player position plus direction and speed at regular intervals (every 200-500ms?). By sending the direction and speed the other clients can anticipate your next position (while waiting for the next update) by moving your player towards that direction and then just correct it at the next update. And if the player stands still no position updates should be sent; only send necessary data.
At least you should be able to improve it somehow, because even games like Crysis can be played smoothly over a network
Good luck!
And btw, many people new to networking may think it's nice to send data as strings, but that is not a good idea. To send a position, direction and speed update only 8 bytes may be needed:
commandId (1 byte) | x (2 bytes) | y (2 bytes) | direction (2 bytes) | speed (1 byte)
And when the server sends that to all the other clients a playerId (1 byte) should also be added of course. The server may also want to validate that its data received by the clients is somewhat "realistic" (hacking protection) before it sends it to the other clients.
What I would do is to send the player position plus direction and speed at regular intervals (every 200-500ms?). By sending the direction and speed the other clients can anticipate your next position (while waiting for the next update) by moving your player towards that direction and then just correct it at the next update. And if the player stands still no position updates should be sent; only send necessary data.
At least you should be able to improve it somehow, because even games like Crysis can be played smoothly over a network
Good luck!And btw, many people new to networking may think it's nice to send data as strings, but that is not a good idea. To send a position, direction and speed update only 8 bytes may be needed:
commandId (1 byte) | x (2 bytes) | y (2 bytes) | direction (2 bytes) | speed (1 byte)
And when the server sends that to all the other clients a playerId (1 byte) should also be added of course. The server may also want to validate that its data received by the clients is somewhat "realistic" (hacking protection) before it sends it to the other clients.
Last edited by Joakim Christiansen on Wed Sep 02, 2009 7:22 pm, edited 3 times in total.
I like logic, hence I dislike humans but love computers.
few tips:
1. For things like position etc. dont use strings - use floats integer whatever ( depending on the game even 16 bit accuracy instead of 32 bit does it ).
2. prioritize packets. you notice lag for ex. in movement but who cares if a chat message is 1s late ?
3. Quake for example has 10 fps in network code ( with low settings even less ). You dont have to update every frame. Instead interpolate between. This also would allow you to ignore a few "missing" position packets if you eventually switch to UDP later.
4. You dont have to update things that are out of viewing range. Use "Lazy initialization" Create what is in your "Zone" and let the clients "ask" for more information on an object once its relevant ( distance / radius check ) or else.
5. Dont send raw positions all the time - do check intervals and use offsets from points instead. That way you can transmit even smaller numbers and due that less data every frame.
Cheers,
Thalius
1. For things like position etc. dont use strings - use floats integer whatever ( depending on the game even 16 bit accuracy instead of 32 bit does it ).
2. prioritize packets. you notice lag for ex. in movement but who cares if a chat message is 1s late ?
3. Quake for example has 10 fps in network code ( with low settings even less ). You dont have to update every frame. Instead interpolate between. This also would allow you to ignore a few "missing" position packets if you eventually switch to UDP later.
4. You dont have to update things that are out of viewing range. Use "Lazy initialization" Create what is in your "Zone" and let the clients "ask" for more information on an object once its relevant ( distance / radius check ) or else.
5. Dont send raw positions all the time - do check intervals and use offsets from points instead. That way you can transmit even smaller numbers and due that less data every frame.
Cheers,
Thalius
"In 3D there is never enough Time to do Things right,
but there's always enough Time to make them *look* right."
"psssst! i steal signatures... don't tell anyone!
"
but there's always enough Time to make them *look* right."
"psssst! i steal signatures... don't tell anyone!
"That depends on what kind of game you are creating.
1. For an online RPG/RTS, you would want to use TCP. For a fast pace game such as an action game, UDP hands down.
2. The other thing is to never, ever use strings for packets/networking. They are teh evil bane of networking.
3. Always have your networking run in it's own thread (client side) or threads (server side). Or else you would end up with the networking failure known as Eve Online
Where the gui and the rest of the client just halts until data is send/rec via networking. (they may have fixed this in the last year ...).
4. Again, much of this depends on what kind of online game you are making. If its the rpg/rts kind, then you need to send the update co-ords as they happen. Since these kind of games uses way less bandwidth (if coded correctly), then an action game, you are ok.
If its an action game, it's a different issue. (as mentioned above).
1. For an online RPG/RTS, you would want to use TCP. For a fast pace game such as an action game, UDP hands down.
2. The other thing is to never, ever use strings for packets/networking. They are teh evil bane of networking.
3. Always have your networking run in it's own thread (client side) or threads (server side). Or else you would end up with the networking failure known as Eve Online
Where the gui and the rest of the client just halts until data is send/rec via networking. (they may have fixed this in the last year ...).4. Again, much of this depends on what kind of online game you are making. If its the rpg/rts kind, then you need to send the update co-ords as they happen. Since these kind of games uses way less bandwidth (if coded correctly), then an action game, you are ok.
If its an action game, it's a different issue. (as mentioned above).
Re: game networking
I'm not sure we can help you bianka, unless you are asking for us to program a networked game of chess with this functionality...
there is no sig, only zuul (and the following disclaimer)
WARNING: may be talking out of his hat
WARNING: may be talking out of his hat
Most use extrapolated I think!
At least Anarchy Online does use extrapolation.
The Client tells the server "I moved this far in this direction since my last movement packet",
the server then extrapolate coords from that, but it also does a check to make sure that the distance is not farther than
the character is supposed to move during that time interval. (prevents speed hacks or warp/teleport hacks)
How hings like latency is calculated into that and how rapid direction changes or jumping etc ties into it I have no idea.
Maybe look at the network/movement code for a opensource MMO or Multiplayer FPS?
The Client tells the server "I moved this far in this direction since my last movement packet",
the server then extrapolate coords from that, but it also does a check to make sure that the distance is not farther than
the character is supposed to move during that time interval. (prevents speed hacks or warp/teleport hacks)
How hings like latency is calculated into that and how rapid direction changes or jumping etc ties into it I have no idea.
Maybe look at the network/movement code for a opensource MMO or Multiplayer FPS?