Sorry your browser is not supported!

Not sure where to put this, as it isn't really game design or language specific - so I'll just ask here

What exactly happens (or should happen) to timer-based movement when moving up to networked multiplayer games?

I've looked around on the net and can't really find an answer for how movement should work (which takes into account the different speeds of the possible clients)

Should the server just 'take charge' and apply its timer factor to every movement, or should the server do something to account for the speeds of each client? Or none of the above?

It seems like a simple enough problem but I can't really think of a solution that makes any sense (or a solution which won't create blatant out-of-sync issues)

Suggestions + Answers + linkage to explanations appreciated

The timer system should be run off of the timer on the server, then applied to all clients. This would ensure that each person on the server would be running real-time to each other, because there is one server timer, that would be networked to all players. Funny, I was actually having this conversation the other day.

I don't understand - why should they be going at different speeds? In a timer based movement system, 25m/sec should be a constant, almost reliable speed. If the controller inputs, positions, angles and velocities are being synchronized regularly enough there shouldn't be any problem. The server shouldn't really be processing much of the players' physics, just relaying them. Anything not under player control should be handled by the server. When the players can interact with world objects, that's a bit of a grey area. In theory, the player-world interactions should be loosely synchronized. If I kick over a box, for instance, should the server have detected I ran through it between pings or should my client say "I hit this box, this way, this time"? If I hit the button in a lift, should my client say "I hit this button" or should it say "This lift is going up"? The former is more reliable but the latter should result in less latency.

I'd say each client determines the time for its movement. 1 second on your computer takes the same amount of time as anyone else. That shouldn't be an issue, not until latency becomes a factor. In which case the user can continue to move about their world while its the other players who stand still because the server hasn't been able to update their positions with you yet. But on everyone else's computers, only your character appears stationary during lag issues.

I did a paper several years ago about the affects lag has on a game and how designers overcome it. To limit the amount of noticable lag on a clients computer, those characters which aren't being updated or communicated to the server your computer will predict their movement. If a guy is running at you in a particular direction, it seems probable that a lost packet was going to advance that unit in the same direction yet again. For small lag spikes, like maybe a single packet every now and then gets dropped, this helps smooth out game play a lot. A lot of multiplayer games incorporate such a system. This obviously won't help where the lag delays the game for 500ms or more, thats how you end up with seeing characters walk straight into walls and continue to try walking forward. And if the predicted movement was incorrect, you'd only see a tiny motion jerk, almost unnoticable, as the character is thrown back on course, no worse than had the prediction never been applied.


Also, the server shouldn't do the processing, that's the clients' jobs. Rather the server is more of a relay to let others know what's happening on the other clients. So as Nex said, a client tells the server it hit a box, the server tells everyone else that client has hit a box. Each client then determines the appropriate action for when that character hits a box. The calculations are done by the clients for other clients.(if that makes sense)

Yeah, put like that, my question doesn't really make any sense and the solution is fairly obvious (as you mention). Since the timer on the server just needs to work and apply movement in relation to Hz rather than just per frame (i.e. regular timer based movement and send the results to the clients).

Thanks (This seems to have been a case of something obvious that just became complicated in my mind because I'm not used to thinking of it in terms of sync between multiple machines)



Whilst the lag + prediction stuff makes sense (and I've also come across it before) I completely disagree with this bit. Yeah, each client should have logic (for client side prediction) but the server should be the logical/gamestate "authority" - doling out anything other than trivial stuff / prediction to the clients isn't a very good idea (trust problems, for example) - although I suppose it may depend on the game.

And isn't the server-is-the-ultimate-authority concept more suited for a game in which you run a dedicated server? Certainly if you're doing a peer to peer architecture with a pseudo-server host client (point fingers shamefully at Infinity Ward), do you still make the host responsible for the game state? This can introduce lag and a major advantage for whoever happens to be host.

In almost all cases, the server is not run from the host's computer, but from a rented server. Most servers that are rented for games, are pretty good.

I know that's the case for the classic PC FPS games, but what about the new slew of games that don't use rented servers, like MW2? I know Halo 2 for sure had these issues.

With routers being so common these days, it's not common to see peer-to-peer networked games anymore.

I've posted this link many times on the forums already so you may have seen it, but I'll post it again anyway: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking.

However, that doesn't cover in detail what you want to know. I figured out a suitable system which is probably the same as the way Source and other engines manage it, although it's pretty detailed and I don't want to type it all out here.

Here's some brief idea of what you have to do:

1. Client: Every tick, sample user input (up/down/left/right/jump/etc) and store this in a queue as a user command, along with the time of the previous tick (this will be how long the command will operate over) and a sequence number.

2. Client: Every networking tick, send the server any queued commands (but do not remove them from the queue yet).

3. Server: Every tick, process all user commands for each client, using the time stored. *[1]

4. Server: Every networking tick, send all coordinates to all relevant players (you should send players their own coordinates too so that they may adjust if an error occurred).

This is the very basic system you should use for handling movement server-side. However, this alone won't be satisfactory as there will be a delay for each player as they press keys and wait for their updated position from the server. So what's the cure here? Client-side input prediction, using the user commands stored. For each tick on the client, execute one of the stored commands and increment a counter to point to the next command.

So far, under good conditions it should perform pretty well, but not perfectly. There are a couple of things that will produce synchronization errors between the server's copy of the player object, and the client's copy. For example, due to delays between receiving other networked object data, the client will sometimes register (or not register) collision with an object which is not there anymore (or is there), and aside from this you have to account for packet loss. You may think that when an error occurs, you can simply have the client set the player object to the latest position received, so what's wrong with this? Due to the latency between the user commands being generated and being processed, the client's player object should always be at least slightly ahead of the server's copy. If you place the player at the server's last indicated position, you'll be placing it at an old location - and the server may have processed other commands since then.

So what do you do? Well, when the server sends each players coordinates, it must send the sequence number that corresponds to the last acknowledged user command. This way, when an error occurs you can start interpolating the player coordinates from the last known position, through to the latest command. This way, the client-side prediction can stay slightly ahead (and correctly) as it should be.

Also, I haven't mentioned it already, but user commands must be stored on the client until they are acknowledged by the server. After that they can be removed from the queue.

*[1] You'll probably be thinking "but if the client dictates the amount of time for each command, surely they could cheat?" but I'm afraid this is about the only way you can make sure the server processes the commands in an identical fashion to the client's own input prediction. And besides, all you have to do here for security is track the amount of time a client uses, and make sure it doesn't change at a rate different from the server's clock (though you must allow for packet jitter). It's by far simpler than trying to prevent cheating where clients are allowed to dictate their own coordinates.

Of course, there's more to it - you'll probably want to adjust things for estimated latency, and add lag compensation, and I may have missed minute details from my explanation as it's all off the top of my head, but that should give you a basic idea of what you need to do.

Modern Warfare 2 uses Steam servers, must be hacked to "create dedicated servers". As for Halo 2, you do need a really good computer, have the server set up on that, then just leave the computer alone, play Halo 2 on a different computer. Running a dedicated server from home, unless you have the hardware already, is a mistake because the server is always controlling the speed.