We are making a multiplayer co-op game, where players will shoot not each other but AI enemies (creeps), controlled by the game. The chosen implementation is client-server with an authoritative server. Edit: we use client-side prediction for both creeps and avatats to give the illusion of immediate responses. So far we managed to make creeps movement syncronized on the client and the server, that is at the same point in time each and every creep are located in the very same place on the client and on the server.

However, the player avatars cannot be syncronized in this way - it is simply impossible. Player avatar will always lag on the server. Now the problem arises when we try to shoot and hit the creeps. The two avatars (client and server ones) will fire bullets in different places (because one lags from another), but the creeps positions are equal. Bullets hit almost instantly, which means that quite often the bullets will not hit the creeps on one of the machines and, as the server is authoritative, it will have the final say in what actually happened. Ofcourse such behaviour is unacceptable.

One solution would be to force creeps to lag on the server, but that is a poor solution as the lag (ping) may vary dynamically and, more importantly, the game is designed to allow for up to 4 player multiplayer mode and I cannot even start to think, how to fit this solution to other players' bullets.

The only thing I could find so far on the internet is the fact that in FPS multiplayer shooters you see your opponent in the past and the server "rewinds" each of you before hit-scanning. But how do you exacly implement this? Do you keep the list of recent positions/actions on the server? But what if hit-scanning involves taking skeletal animation into account? Do you store recently played animations aswell? Any advice would be appreciated.


1 Answer 1


Something seems wrong to me in your implementation of the authoritative server. Basically an authoritative server controls everything. It is the pivot of your network architecture. Clients just "ask gently" when they want to do some actions, and the server has the authority to say "NO I DON'T WANT YOU TO DO THAT BECAUSE I'M THE BOSS HERE!"...

That said, I don't understand how your avatars can be at different positions. In a basic authoritative server, players can't move by themselves. Instead of something like :

Player00: "Hey Server, I moved and my new position is {x:42,y:24}! Deal with it!"

The communication with an authoritative server is more like :

Player00: "Hey Server, I want to move on my right... can I?"

Server: "Yeah, Player00, you can, your new position is {x:42,y:24}."

Server: "HEY OTHER PLAYERS! Player00 just moved to {x:42,y:24}!"

As you can see and as Tim Sweeney wrote : "The server is the man!"

Of course such strict authoritative server has hard time to be visually correct and synced when lag comes to play, and I would suggest you to read further readings about that, such as this very interesting piece from Valve about input prediction.

But for your "bullet position" problem, it will do the job. As the players will just inform the server that they want to shoot bullet, the server knows how they are oriented, and if they are allowed to shoot, so the server can say to every other players that a specific player has just spawned a bullet. That way every players is informed about spawned bullet position, orientation and time.

Time is an important thing to add to your network code. If you know where and WHEN things have been done, and if at moment you know that clients' internal clocks have been synced to server clock, then you can interpolate and predict the current exact position and state of things.

That's the trick.

I hope it helps.

  • 1
    \$\begingroup\$ You did not understand my problem. First: I am not trying to spawn a bullet, but to make sure server and the client both hit the same creep correctly. Second: I did not mention that, but obviously we use prediction, that the whole point of the avatars being not in sync: the server serves as a controller, who can discard an illegal move, but the client tries to predict the server's response to give the illusion of immediate responses. So the problem here is the fact that when the client shoots the bullet spawns immediately, but when it actually spawns on the server, the target creep can move... \$\endgroup\$
    – cubrman
    Commented Sep 26, 2014 at 7:26
  • \$\begingroup\$ ... which will make a clear hit on the client result in a miss on the server. How to deal with that? How to hitscan creeps that are syncronized, when shooters are not? \$\endgroup\$
    – cubrman
    Commented Sep 26, 2014 at 7:27
  • \$\begingroup\$ From your article I can conclude that I have no choice but to move creeps back in time for each important event. I'm screwed... \$\endgroup\$
    – cubrman
    Commented Sep 26, 2014 at 7:33
  • \$\begingroup\$ "How to hitscan creeps that are syncronized, when shooters are not?" They ARE synchronized on the server, EVERYTHING should be a reflection from the server view, because the server is the man. So, even if locally the player or the creep have moved you don't care as long as the server version is the one that counts. So yes you have to rewind position and replay them. And no, you're not screwed, it's hard work but it's possible :) keep faith. \$\endgroup\$
    – lvictorino
    Commented Sep 26, 2014 at 8:01
  • \$\begingroup\$ Also, I'm sorry if my post made you think I didn't understood your problem. What I explain is how make everything synced (bullets, players, creeps, flying toasters...). Using bullets as example was maybe not a smart choice. Sorry for that. \$\endgroup\$
    – lvictorino
    Commented Sep 26, 2014 at 8:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .