Good morning fellas,

at the moment I'm creating some stuff for reworking my old little game "Modern Armor" (watch on YouTube) but again I come over the all-time-question:
How do I do weapon firing wihtin the multiplayer system.


Well actually there are different attempts to do this. At least I got 2 in mind that make sense for me:
1. Clients send fire-triggers to the server (until now I prefered this one)
2. Clients do calculations for them selves

Both have pros and cons, which I'd like to explain in a short description.


1. Letting the server do the work
Pros:
- bullets/rockets/whatever fly and hit where all the objects actually are, thus you cant hit someone hiding behind a wall, while you still see him running to the wall
- hits can be distributed immediately
Cons:
- Due to latency the objects actually are not there, where the clints still see them, so they may aim propperly, but still miss the target
- until the server gets the shot data and creates the bullet, the firing client will notice a delay of a few frames, until his click takes action... very ugly since you see it every shot


2. letting the clients do the work
Pros:
- the client can aim and hit how he sees the world, not how the server sees the world
- no delay until a shot has been "confirmed"
Cons:
- when only animating the shots/rockets after a trigger like "player 1 is frigin, create a dummy rocket to show it!" they most propably won't fly exactly where player 1 fired them to on his computer. Thus the other player may be hit, while he sees the rocket fly by and wonder why.
- hits can't be shared to the hit player as fast as directly from the server



I'd like to try the second one fpr this time, but I'm not quite sure how it will turn out. So I'd like to ask you if you got some experience with this kind of problem or if there is a different way that I don't see.


Thanks in advance!
ShoreVietam

check my thread here: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=366712#Post366712 OR http://scionwars.blog.com/2011/04/06/multiplayereffects/

Heck yes, I do. This was tedious, but fun.

I think first of all its important to note 2 things: 1) I have in no way perfected this and am just speaking from the point of view of someone who's tried around with a few of these problems bfore. 2) I would always make sure to differentiate between the different game types and weapon types when speaking about where to handle them.
For example: Counterstrike uses a very different method from what CSiS uses and both work, simply because the games are so different.
I think your game comes closer to the CSiS-approach.

How I do things in my code:
My player-movement code is client-side. This means all other players predict and interpolate ship movement: They keep accelerating/decelerating with the same acceleration/deceleration (also done for rotation) and so they get pretty close to the position. If they messed up on a position (for instance when the client started accelerating shortly after the last update) then there's interpolation: The other clients don't let the ship jump, instead during the until the next update, they move a little faster/slower (I think I actually spread it out over a few updates to make it smoother).
This works very well because the movement is so fast you don't notice it when a player is off by a little.

Rockets move similar to these players, except that they always fly at the same speed.
When client A shoots a rocket, client A creates it on all other clients. But the rocket is not placed at the same place on all clients, instead it's placed to the position where each client thinks that client A currently is. This will make sure the rockets look like they're coming from the client's launchers.
Each client then receives a global pointer from client A which points at the targeted entity. So each rocket knows where it's going, and each client makes it rotate and fly towards the target. The server handles the rocket's collison and also sends movement updates to make sure the rocket stays on track on the other PCs. Whenever the movement is off, I, again, add to the movement the difference of the position the rocket is at and where it should be at to make up for the wrong positioning. Note that I never try to reach the position that was sent. But when I notice "I should be .1 quant further along the x-axis" then during the next wait for an update, it uses vector(.1*time_step, 0, 0) as the c_move's absolute vector, in addition to the current position. This makes sure that the rocket is on the right course at all times, will hit the player on all clients, will not make sudden moves, and will still be synchronized pretty exactly with the other clients.

Uhg, I hope I was good enough on explaining that. Maybe I need to draw pictures

Shots are handled differently. When a client shoots, a "I am now shooting" event is sent to the server, and the server creates the projectiles. This is not instant-hit beams, but fast unguided projectiles. The client sends along the position at which he is aiming, and then the server traces from the client position (the postion of the client on the server) to the position at which the client aimed. So this is a mixture between client-position (aimed at) a and server-position (where the server thinks the client is). Then the projectiles get created by the server on all other clients. All clients then position the projectiles where they think the client currently is (at his guns) and rotate them into the direction towards the position he's aiming at (which was sent along).

The beam guns are handled differently yet again: The server traces from the position he thinks the client is at to the position the client is aiming at and traces. He sends back the position of impact and then all clients show the effect from where they think the client is to the position of impact.

That's how I do it, I'm sure there's better methods, but in the past two years or so, no one has ever complained about lag or bad precision.

As far as I know, modern shooters (anything starting at the time of counterstrike) do step-back calculations: They calculate (beforehand) how high is the ping to the shooting player is. Then they move the players back by that much and then trace the shot. Crazy, calculation-wise, and I think you'll probably only need it for first-person shooters... Darkinferno has done some research on this, but I don't remember where the links are he showed me Or was it Adoado? Someone showed me papers on how valve did it.

Sorry, lots of text. But you asked

Edit: I see you already found the article, good!

Yes germanunkol i actually sent you links to a few papers about hit verification from valve, don't think it would be suited here though.

You say you create the shots at each players local position of the ships right? i guess this method can work for your game since its just empty open space, but i think it may be problematic otherwise. Sounds like you may have projectiles clipping through geometry in high latency situations, now that i think about it, it doesnt sound too bad at all.

Your method sounds like method 3 in this: http://scionwars.blog.com/2011/04/06/multiplayereffects/

I guess all methods have their pros and cons, none is perfect ...

What i do, though i use 'instant hit' weapons alot, is to send the start and end points of each shot when a client fires, each other client then creates the tracer at pointA and allows it to fly to pointB, muzzle flashes help hide the differences between it and where each client may see its supposed source. I had experimented with not sending pointA and just tracing from where each client sees the creation point(muzzle) however i thought it'd result in tracers clipping through objects under high latency, simply because each client may see the muzzle point at a different position.

I think for his game, what i'd do is use local c_move shots on each client that fires, if it makes a hit, i then let the server c_trace to verify if the shot hit possible, this also reduces some of the 'shooting a player that runs behind a wall' prob.

OR

You could send the position of both ships then use those positions to verify the shot on the server, i tried this before, it wasnt bad at all except i sent a timeID for both players, i'd then use the positions at those timeIDs for verifying the shot, i learnt this from valves method, they actually jumped all players back then retake the shot, but i figured some TEMPORARY object would achieve similar results, however i dont use it anymore, i use the method above

@Germanunkol

Yeah, that was pretty clearly discribed. Actually that fits what I had currently in mind. I think it is quite simple with targeting the other entity, but I don't use a targeting system. So I always thought of how to manage that the bullets/rockets/beams always appear at the weapon. So you gave me the final clue for that. Actually that's a server-based system, which I prefer since handling is not so complicated, combined with localized animation handling.

So I'd have those two versions:
1. Machine gun bullets and rockets as fast unguided entities starting from different positions everywhere, heading to a single point and closing up to the real position.
2. Laser beams from client weapon position to server defined impact position, calculated by client defined target position.

Thanks a lot, that sounds like a fine plan and is not to far away from what I'm doing right now.

Yes, exactly my point. Different games need different methods, and I figured I'd explain mine since it's somewhat similar to the Modern Armor approach.

Glad we could help, make sure to post your progress once you've got something to show!