FreeGameDev

Is it generally considered a requirement for high-speed network games like FPS's, that to remove any lag, clients must attempt to "predict" where a moving object might be at the current time (based on it's previous position and movement direction), rather than simply wait to be told where it is by the server? Is it a waste of time even attempting to write such a game that purely relies on server updates?

Probably, unless it is meant to be played on LAN only.

Using udp rather than tcp might also be important for realtime/highspeed network games.
UDP is faster, but packets can be lost, but since the server continously sends the positions of the players, it doesn't matter if some packets get lost, since their position will be overwritten by later packets anyway.

possibly interesting article about motion prediction and other things in fps :
http://developer.valvesoftware.com/wiki ... Networking

First thing to remember is that you don't need to be continuously sending position data more then 60 times a second, even that might be too many. The reason for this is because your game is running around 60 frames a second. Updating more times then your frame rate is just wasted bandwidth.

I think the reason for predicting where the player is going to be moving to is more for smooth transitions then anything. Without it when you update all the positions it will look like players are jumping around rather then moving smoothly.

Try to use UDP rather then TCP because it's much faster however it doesn't guarantee the packet will get there. I use the Enet library for my game which is a UDP networking library which will attempt to send the packets in order as well as on time.

It is very important for an FPS to at least predict where the player at the keyboard will be and render from that location.

Otherwise, well say the ping to the server is 60ms, and the framerate is 60fps, then that's about 3-4 frames of rendering between pressing a move key and seeing the resulting movement. It would look and feel really bad (especially if turning with the mouse was done the same way too).

I think (io)quake3 and Darkplaces have an option to toggle this in-game. I'm not sure what the general consensus is for dealing with the whole lag issue though...

beltsonata {l Wrote}:I think (io)quake3 and Darkplaces have an option to toggle this in-game. I'm not sure what the general consensus is for dealing with the whole lag issue though...

There generally is a tickrate AFAIR. I don't really remember more from Q/HL tech though.

Disclaimer: I don't have any other experience with networked games than playing a lot of them, and reading about the subject.

My suggestion is; Write the "world/physics" code in a way that allows you to use the exact same code in both your server and client, then let the client run it's own physics, but let the server be the authority which updates the clients with the current state.
This way, when the game runs smoothly on the client, and only long periods of no data will be noticable. This is, afaik, what quake does.

Example;

Server - (State; Enemy At pos xyz, velocity xyz) -> Client.
The way, everything seems like it's running smoothly, except if there is a really long lag, and the enemy stopped maybe 1/4 second before the server gets to tell the client, then the enemy would seem to "warp" back to it's correct position, which is also evident in many FPS games under really bad conditions.

It might also be a good idea to have some server-dictated time, so that a client can tell "I shot at direction xyz at exactly THIS many milliseconds into the game", I think quake 2 didn't do this, and the player had to take lag into account, and "aim ahead" of people moving past them..

dusted {l Wrote}:It might also be a good idea to have some server-dictated time, so that a client can tell "I shot at direction xyz at exactly THIS many milliseconds into the game", I think quake 2 didn't do this, and the player had to take lag into account, and "aim ahead" of people moving past them..

Even Quake3 does not do that, and you have to lead your shots ("aim ahead") there too.

OpenArena and other projects have "unlagged hitscan" code, the server knows what was on your screen when you fired the shotgun or lightning gun, and hence you can use those weapons effectively even at very high pings (as I have done).

Unlagged hitscan is expensive to implement though (memory wise0, since the server must remember the game state for the whole last second or so (e.g. about 20 full states if the server runs at 20 game-frames per second).

dusted {l Wrote}:My suggestion is; Write the "world/physics" code in a way that allows you to use the exact same code in both your server and client, then let the client run it's own physics, but let the server be the authority which updates the clients with the current state.
This way, when the game runs smoothly on the client, and only long periods of no data will be noticable. This is, afaik, what quake does.

As the developer of a "stateful" open source game I can say that it's not a matter of "just" sharing this. Especially if your game requires any level of precision. We made our motion fully stateful and it nearly eliminated discrepancies between clients and the server but introduced this 10-100ms "pause" while you wanted for your "request to move, move acknowledgment" to process across the network. While 100ms doesn't seem like much it is enough to be really annoying if you're not an "order" based motion game (e.g. you give your avatar an order to move to a waypoint.)

I'm not saying don't do a stateful simulation. On the contrary I still think it is a great idea. I just came to realize that event tracks need to be timestamped and the running times used for these must be synchronized (e.g. a latency compensation based on "ping/pong" messages) with the server. By time-stamping and running in the past (less than 100ms, preferably) you can run your local simulation independent of the server and correct based upon updates from the server (e.g. a dead reckoning message).

That being said my motion system is in awful condition and needs some TLC if any young enthusiastic programmers would like to take it on. (=

Here's an article with interesting pointers about physics in networked games
http://gafferongames.com/game-physics/n ... d-physics/

Regarding UDP, keep in mind that not only packets can be lost but they may also arrive out of order, so you have to deal with that as well.

Zlodo {l Wrote}:Regarding UDP, keep in mind that not only packets can be lost but they may also arrive out of order, so you have to deal with that as well.

You could use enet for out of order problem

Zlodo {l Wrote}:Here's an article with interesting pointers about physics in networked games
http://gafferongames.com/game-physics/n ... d-physics/

Thanks for this, looks like it could be an interesting article!

Zlodo {l Wrote}:Regarding UDP, keep in mind that not only packets can be lost but they may also arrive out of order, so you have to deal with that as well.

The other thing you have to keep in mind is that you cannot necessarily rely on TCP to manage this for you because while it's really good at compensating for lost packets it's also not very good on high-loss connections with a high level of throughput. Take a look at a blog entry by AI War's Christopher M Park entitled Choosing A Network Library in C# where he talks about how he decided TCP would be quickest/easiest.

With that in mind I anticipate that my game will remain on TCP because I don't expect to have hundreds or thousands of objects in motion at a given time so I don't think I'll have the same collision/loss problem that he has. But his article is worth a peek at least from an anecdotal perspective.