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.

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.

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.

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.

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.