Guys, as I told you probably 100 times by now. I'm making a multiplayer paintball game.

I've just finished with setting up the sending of my position and rotation to all other connected clients and I tested it on my PC( I've loaded both a server and a client on my PC ) and when I move forward in the server app, the same forward movement is made on the client app, cool. Everything works perfectly fine.

But when I send the client version of my game to a friend of mine who is in another country, he says that my movement is very laggy, and the game is not playable. I'm wondering why the packets are sent so slowly. I'm using RakNet and RakPeerInterface class which is based on UDP, so it's not a TCP problem and I don't know what to do.

2nd bonus question:

Ok, TCP guarantees the arrival of every packet and while this is good for some applications, it causes slowdown in games, because if one packet is dropped, the router waits for the same packet to be resent and this messes things up, OK.

But then in this link here:http://www.raknet.net/raknet/manual/introduction.html There is this sentence:

"At the lowest level, RakNet's peer to peer class, RakPeerInterface provides a layer over UDP packets that handle these problems transparently, allowing the programmer to focus on the game rather than worrying about the engine."

So actually RakNet provides a layer over UDP packets that provides the functions a normal TCP would have. Everything is messed up in my head because of this.

Why would someone use UDP and write code to add TCP functionality ( right order, reliable packets ) instead of just using TCP. Of course there should be a very logical reason, and I know I'm missing something. Do you have any suggestions why this may be?

Guys, I think I know what the problem is. My game runs on 500 fps when only 2 players are joined( I don't have a map or some graphics or anything, just two running models, 1 for server, 1 for client ). What I do is send my coordinates every frame. So this actually sends my coordinates 500 times every second, so this is really not a good idea to do networking. There must be some other way.

EDIT: I could try aggregating the movement, so it could be send with 10 packets per second only. Or I could make some kind of state machine based on inputs. What do you think?

There are several issues at play here.

Firstly, you shouldn't really be running at 500FPS simulation framerate. That's absurd! Most games with any physics will ask for at most 60FPS. You should lock your simulation frequency to something like 60Hz, and render separately to that timestep.

Secondly, you can't hope to send data every tick. You'll flood the connection. Running at a reduced transmission rate, and keeping packets small reduces the liklihood of this happening.

Thirdly, the speed at which information can travel between two end points is finite and non-zero. At best, it's the speed of light distance, realistically though the path between two nodes is not a geometric minimum, and isn't entirely vacuum (instead copper + fibre). In short, there will be latency, and it's calculable for a ballpark figure.

The clients do not need "new" state for each sim tick. You can interpolate between recent states, or extrapolate the latest state to smooth the timestep between two simulation states from the server.

Why would someone use UDP and write code to add TCP functionality ( right order, reliable packets ) instead of just using TCP. Of course there should be a very logical reason, and I know I'm missing something. Do you have any suggestions why this may be?

TCP provides multiple features that are useful in different scenarios that aren't all useful to real-time software like games, and can be slower than UDP because of that.

Thus, games often take UDP and add ontop of it only the requirements they need. Even in a single game, not every packet needs the same garuntees. In the same game, some packets might need reliability. Others might need correct ordering. Some packets might need both, some might not need either.

If you continue reading that same paragraph, you'll see:

"Can" implies that it's optional. :wink:

If you keep reading slightly further, it says:

RakNet does not incur overhead for features you do not use.

...which is the difference between TCP - where it costs you, regardless of whether you want that feature or not. :)

TCP is great for many purposes, just not real-time applications with large numbers of packets going back and forth.

Guys, thanks a lot for the helpful answers. I think I got it.

I want to add that, from what I've read, dropped TCP packets are just waited for at the router to be resent again.

In UDP, instead of waiting for a dropped packet to be resent again, you can just make 100 copies of the same packet and send them all in case some of them are dropped. You kind of flood the network a little bit, but it's faster than the TCP way of handling dropped packets, which is what is needed in FPS games.

So from what I gather, UDP is just a very little layer on top of IP and you have more flexibility to add your own functionality, and TCP is a fat protocol that does almost all the stuff for you, which saves you work, but it's not good for realtime apps. Right?

And second:

Guys, you forgot to answer my first question, which I underestimated because I actually have to choose a proper network model for my game in order to solve the problem with synchronizing the game between players and I got in deep waters here. As far as I know, multiplayer strategy games send input because commanding large forces actually changes a lot of positions and rotations and if you try to send coordinates for every unit, it's too much packets, better just send input and process it on the other PC.

But I have a FPS game, I just have position, rotation, health, and current weapon, this is all the info that needs to be sent. It's really not much if I manage to do it properly.

But I want to go step by step here, the first thing is to find a way to send the position and rotation with the best approximation.

What is the method used in current FPS games and what is the easiest method a beginner like me should start with? What do you think?

I wanted to make a mmorpg, but I can't even send a stupid position for a basic FPS. -_-

In UDP, instead of waiting for a dropped packet to be resent again, you can just make 100 copies of the same packet and send them all in case some of them are dropped. You kind of flood the network a little bit, but it's faster than the TCP way of handling dropped packets, which is what is needed in FPS games.

That's a bad idea. First, you would increase the bandwidth by two orders of magnitudes, which is not just a little bit. Second, today the majority of packet drops are caused by congestion, meaning that not just one but many packets are dropped, so if you send many at the same time you still risk losing them all.

Back to the original question, your solution is to not only send position but also velocity (and possibly acceleration, depending on the game), as well as a timestamp. On the other end you will then be able to calculate the expected position at any time from the last known values of these parameters. You can improve this further by using various techniques for interpolation and clock synchronization.

But when I send the client version of my game to a friend of mine who is in another country, he says that my movement is very laggy, and the game is not playable. I'm wondering why the packets are sent so slowly. I'm using RakNet and RakPeerInterface class which is based on UDP, so it's not a TCP problem and I don't know what to do.

Just to add, latency is generated by multiple factors, like distance between you and your friend, routing, quality of network cables etc. Sure, you can control what to re-send when using UDP, but games often requires some of the messages transferred reliable as well, so you need to implement TCP-like features on top of that - which means more latency.

What is the method used in current FPS games and what is the easiest method a beginner like me should start with? What do you think?

I wanted to make a mmorpg, but I can't even send a stupid position for a basic FPS. -_-

I would argue that MMORPG (because of scalability requirements) and FPS (because of strict latency requirements < 100ms) are two most difficult game genres to implement. So if you want to make something simple, I think those are not the type of genres you should be doing as a beginner. But then again, I don't know your background of implementing network games. In any case, I think the dumb client model (similar to Quake) is the easiest to implement at first; you press the button, send input to the server, server calculates/updates the game state and sends response to you and interested receivers which in turn updates their view of the game. Once that is done, you can move on to do something like client-side prediction / interpolation.

Back to the original question, your solution is to not only send position but also velocity (and possibly acceleration, depending on the game), as well as a timestamp. On the other end you will then be able to calculate the expected position at any time from the last known values of these parameters. You can improve this further by using various techniques for interpolation and clock synchronization

Too hard for me. Not impossible, but better to do something simple first.

In any case, I think the dumb client model (similar to Quake) is the easiest to implement at first; you press the button, send input to the server, server calculates/updates the game state and sends response to you and interested receivers which in turn updates their view of the game. Once that is done, you can move on to do something like client-side prediction.

This sounds like a pretty good start. One negative side is that it kind of sucks to press W and wait a century to move because you need to receive position from the server, but I need to start with something, so this is the solution that I need.

Internet is a lot faster now than it was in the quake days and I'm only making 1v1 match, that's why I'm pretty sure this dumb client quake style will be sufficient.

Thanks a lot for all the suggestions, guys.

In any case, I think the dumb client model (similar to Quake) is the easiest to implement at first; you press the button, send input to the server, server calculates/updates the game state and sends response to you and interested receivers which in turn updates their view of the game. Once that is done, you can move on to do something like client-side prediction.

This sounds like a pretty good start. One negative side is that it kind of sucks to press W and wait a century to move because you need to receive position from the server, but I need to start with something, so this is the solution that I need. Thanks a lot for all the suggestions, guys. Dumb client is the way to go for now.

Yea, I never said that it is the version you should ship with. :wink: Just start building the easier functionality first, measure/study it. Then decide what you should be doing next to make the game feel more playable. Otherwise, you end up making a system you don't understand and it is hard to debug/fix that later on.

Otherwise, you end up making a system you don't understand and it is hard to debug/fix that later on.

True.

Yea, I never said that it is the version you should ship with

I'm far away from shipping a game. :lol: I'm just doing a demo in order to torture some game studio with it until they are tired of me and give me the job. ^_^