Currently I send a shootrequest from the client to the server and then the server sends a projectile.
The problems with this are that the shooting is inconsistent and it’s inresponsive.
So to fix this I should have the client fire a projectile locally and tell the server I shot. With the method above I don’t have to check collisions. since client and server are in sync with their projectiles. but if I fire locally it won’t
How do I verify if a player’s shot hit someone on their screen?
I would need to rewind the player’s positions, but I have no idea how to do that.
To “rewind” position, really just means you look somewhere in the history for that position.
In this case, you keep a history of the positions (say, the last 10 locations) in a rolling array. Then to “rewind”, you just search this array (in reverse, starting at current index) and see if the position matches. You will also need to account for interpolation (ie: the bullet hit the player while in-between two positions)
How do I know which of those 10 locations is the location that the client saw?
I think “rewind the player’s position” is confusing you.
I think the question you’re trying to ask is “How do I accurately determine if a player got shot in a FPS, in a client/server environment, while keeping the game-action fluid and responsive?”
really short version:
The server is the authority, so when clientB is moving around, it sends it’s location to the server, which clientA also does.
When clientA shoots at clientB – the server looks and confirms that clientA hit clientB. Then the server sends a message to both A/B about what happened.
longer version:
What the clients both need to do is use prediction, meaning – when you shoot on your client, you show the animation (and the bullet) on your screen, but ALSO send that info to the server. Everything on your client happens as if there is no server involved. IF the bullet hits the target (the server makes this determination), the server will send a message to both clients stating that clientB is hit.
On the server, you have to store position and speed (in math parlance, a vector), and then you can calculate (this would be on the both clients and server) if the bullet hit the other person. The server is the final authority, meaning – even if your client THINKS you hit the other player, the server says yes or no if it really happened. Usually, in this situation – the client will not show the “hit” or death animation until it receives a y/n from the server. On a really laggy connection (with the server), this means that a client will appear to die AFTER the point at which it got hit. There are lots of ways to mitigate this, but the only way to really learn is to read some papers on it.
Keep in mind, the following describe the generally accepted “best-answer”, and there are more than one ways to do accomplish this.
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
I get what you’re saying but if you calculate hit detection on the server without rewinding, clientB might have moved. Resulting in no hit. Which means that clientA has to lead his/her shots. What I want is anti-lead. if clientA saw himself/herself hitting clientB then it should count. but I don’t trust clients, so I need a way of doing this via the server. That would be looking where clientB was in clientA’s view. Now I don’t have any idea how to take this on.
The Latency compensating methods paper says how to solve this problem.
Here’s an excerpt:
[quote]The discussion will provide some background on how client / server architectures work in many on-line action games. In addition, the discussion will show how predictive modeling can be used to mask the effects of latency. Finally, the discussion will describe a specific mechanism, lag compensation, for allowing the game to compensate for connection quality.
[/quote]
Oh I see, if I interpolate 100ms i should store a position in the server that gets updated every 100ms right? So I then know what position it was.
Yes, something like that 
The only thing missing is the returntriptime, I suppose it won’t matter? AAA titles’ developers admitted their hit detection was 80% luck.