Sign in to follow this  
Bru

UDP

Recommended Posts

i dont get it. UDP seems to be a better option than TCP for movement and actions that need to be recieved fast in real time online games,but i cant figure how it can be used if it's so unsafe. i like to build everything from the basic librarys,including my network in my game,so i cant simply load some library that makes udp using easy. i mean,UDP sometimes does not arrive,if a player starts moving and the packet does not arrive to the server that's a serious problem,how do you overcome that? and let's say i do find a way to overcome that,what if a player first moves right and then left,yet the packet are recieved in the wrong order? the result would be that the server and other players will see the moving player first moving left and then right. so far i've been using tcp for movement and it seems to be problematic,so how do i overcome these UDP problems?

Share this post


Link to post
Share on other sites
Quote:
Original post by Bru
i mean,UDP sometimes does not arrive,if a player starts moving and the packet does not arrive to the server that's a serious problem,how do you overcome that? and let's say i do find a way to overcome that,what if a player first moves right and then left,yet the packet are recieved in the wrong order? the result would be that the server and other players will see the moving player first moving left and then right.
If the game relies on packets being recieved in the right order, then you have to implement a reliable stream on top of UDP (something like TCP does out of the box), and for this UDP has no real advantage over TCP.

The advantage occurs when you have some data that doesn't have an explicit order. For example, lets say we send out the player position at a rate of 10 packets per second - if one doesn't arrive, no real loss, because the next one will give you a newer position anyway. If a packet arrives after a newer packet, you just check the packet number, and drop the older packet, because a newer position has already been recieved.

Share this post


Link to post
Share on other sites
The best way would be to look at how other games have solved these problems. See Q12 in the forum FAQ for some great links.

The thing you must remember is both TCP and UDP are layered on the Internet Protocol, or IP. IP is best effort, which means that it is unreliable.

TCP ensures delivery by adding a lot of extra information to the packets and adding in an acknowledge protocol. UDP on the other hand, adds multiplexing (so that more than one program on a single computer can use UDP) and a rudimentary checksum.

You can add in some reliability checks to UDP packets - this is how UDP based games handle "important" information. Note though: UDP isn't magically faster -if you choose to make almost everything reliable you will probably end up with the same issues as TCP has which make it "slow".

My advice to you is: until you understand the precise reason that TCP is considered slower than UDP for real time data, do not try and write your own reliability layer. There are many existing ones out there, again the forum FAQ provides more than a few links.

Share this post


Link to post
Share on other sites
but wait,isn't sending position just a waste of bandwidth? i thought everyone simply sends position + velocity every time the player changes direction. and in this case loosing a packet or recieving at the wrong order is a mess.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bru
i thought everyone simply sends position + velocity every time the player changes direction.
That might work for some games, but consider a first person shooter: all players are continuously changing velocity and direction, and the 'twitch' style of gaming requires very fast response - thus you continuously broadcast positions.
Quote:
but wait,isn't sending position just a waste of bandwidth?
Even if we send positions as 3-dimensional vectors of floats, which take 12 bytes each, and send them at the relatively high rate of 30 packets/second, that is only 360 bytes/second, which is viable even over dial-up.

Share this post


Link to post
Share on other sites
oh i see,that's great :) i didnt realy want my game movement packets to be velocity since it just felt like a lot of work and trouble making it work good.
time to study how to use UDP! hyah!

also,thanks a lot :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Bru
oh i see,that's great :) i didnt realy want my game movement packets to be velocity since it just felt like a lot of work and trouble making it work good.
time to study how to use UDP! hyah!

also,thanks a lot :)


You might want to throw in velocity aswell though, it makes it easier to reduce the negative effects of latency.

Share this post


Link to post
Share on other sites
Quote:
Original post by SimonForsman
Quote:
Original post by Bru
oh i see,that's great :) i didnt realy want my game movement packets to be velocity since it just felt like a lot of work and trouble making it work good.
time to study how to use UDP! hyah!

also,thanks a lot :)


You might want to throw in velocity aswell though, it makes it easier to reduce the negative effects of latency.


The client could estimate velocity from the difference between consecutive position updates. But if the bandwidth allows I would probably include the actual velocity.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this