I am working on MMOARPG (Action RPG), please don't point and laugh or something saying "You need a team" or something. If I fail then let it be.
Well anyways, controls are similar to Shooter/FPS games have (WASD controls, mouse to aim), but with RPG element (skills, levels, etc).
I've decided to add first attack; it's ranged attack which is affects by physics and does damage on first collision (or basically missile).
At this point, I can't decide how to handle damage, I have in mind 3 ways:
1. Player1 shoots missile, Player2 reports if he is hit by it, if not - then nothing
2. Player1 shoots missile and reports if missile hits Player2
3. Player1 shoots missile and server tells who is hit

I figured some synchronization problems can be fixed by sending exact position of missile, and it's direction (rather than just telling Player1 shot missile), this way missile will appear at correct place, and fly in correct direction. On the other hand, there is ping.

Why Action RPG? Instead of click to target and just spam skills, you have to actually target, actually dodge etc. This causes some extra problems in my mind, as it won't make sense if Player1 sees as Player2 is hit, and Player2 sees as he dodged it.

So my question is, which way of handling missile physics/damage is better to implement? Maybe you know something even better?



P.S. Assume hackers don't exist.

Quote:Original post by Ripiz
P.S. Assume hackers don't exist.

Well that's a pretty big assumption. But anyway I'll explain the concept.

Option 3 is the best option. The client will use dead reckoning for the missile and players. That is the server will tell the clients the current state of the game and after that point the changes to that state. (Player 1 firing a missile is a state change). The client will then extrapolate that state. (So the missile will act like a missile on the clients).

Okay so lets break things into a timeline.
1) Player 1 fires missile at Player 2 which queues up an action (Fire Current Weapon and probably orientation data) that will get sent out on the next client tick (fairly soon usually 20 times per second the queue is flushed to the server).
2) Server receives event and on the next server tick (again fairly soon) the action will start. At the end of that tick delta packets are sent out with the action of Player 1 to Player 1 and 2 (that's right Player 1 is informed that he shot the missile).

Now you can do a few things at this point when the clients get this message. For Player 1 you could have performed the action immediately then corrected the missile data when it was received. Or live with the latency and only create the missile when you get the data from the server.

Now you mentioned Ping. The server is running its own authoritative simulation of the game. When clients get state information it's delayed by the one way latency (assuming the server isn't extrapolating effects based on the client latency). So the client will get the missile position then need to extrapolate it forward based on the latency (it's latency / 2 for simplicity) in order to match the current state on the server. This is one of the simplest implementations.

Now about how to report damage. Don't do any client-side damage. Just wait for the server to tell you who got hit and you should be fine. The problem if you don't is you run into cases where player will fall down dead even though they might not really be killed.

Also I recommend if you game is very fast paced that you might want to read the CS:S networking. (Look in the FAQ)

Thank you.

However I wasn't able to find CS:S article, any chance you could give link?

Thank you.

Extra question:
Wouldn't it take a lot processing power to simulate physics for lets say 1000 players and 300 missiles?
On top of that, missiles can hit buildings, trees, terrain, other things and server would need to load all that, memory usage could be a problem too.
Or I understood something wrong?

Quote:Original post by Ripiz
Wouldn't it take a lot processing power to simulate physics for lets say 1000 players and 300 missiles?

Use a physics engine. If not just use spatial partitioning. Chances are with proper handling your players are only adjacent to the terrain and a few objects/players so you'd be doing <10 collision/response checks. Shouldn't be that big of a problem.

Quote:Original post by Ripiz
On top of that, missiles can hit buildings, trees, terrain, other things and server would need to load all that, memory usage could be a problem too.

Depends on the amount of geometry. If your trees are all the same or can be quickly represented by AABBs then things are going to get much simpler. Loading the objects around the players is another option.

Honestly I think with proper optimizations you wouldn't have much of a problem.

I'm using Bullet Physics engine.
I don't think it'll make sense if missile explodes in mid-air when it's near to tree.

Quote:Original post by Sirisian
That is the server will tell the clients the current state of the game and after that point the changes to that state.

So player input should be handled by the server too?:
I tell server I pressed W;
Server simulates;
Sends my new position;
My client interpolates?

Quote:Original post by Ripiz
I'm using Bullet Physics engine.
I don't think it'll make sense if missile explodes in mid-air when it's near to tree.

I meant like the trunk. Lots of old games used bounding boxes separate from the actual geometry. Take CS:S. It uses oriented bounding boxes (OBB) for the player's skeleton. A tree can be represented a similar way with the branches and trunk. Just something to think about.

Quote:Original post by Ripiz

Quote:Original post by Sirisian
That is the server will tell the clients the current state of the game and after that point the changes to that state.

So player input should be handled by the server too?:
I tell server I pressed W;
Server simulates;
Sends my new position;
My client interpolates?

In 2D that technique works well. I'm not sure if you can 100% rely on it for a 3D game. But yeah that's the general concept. Also extrapolation would be the idea. Then again the CS:S article and others disagree and use a different approach where they interpolate to a known frame. I have to imagine it's because twitchy movement causes the extrapolation to be wrong a lot.