dpadam is right. that's the issue I'm facing now. Basically what confuses me is when the server should tell other players about playerA location. That means the server MUST have the up-to-date playerA location. Which means it HAS to simulate path movement too. And it will synchronize the valid path perhaps once every 2 seconds. What do you guys think about it?

1. playerA tell the server it wants to move from 10,23 to 42, 21
2. the server checks the path
3. if it's invalid, send nothing to playerA
4. otherwise, tell playerA to simulate movement from 10,23 to 42, 21. the server simulates the movement too
5. if there's another player nearby, tell the player that playerA is moving from [current pos] to 42,21
6. once every 2 seconds server tell ALL players their true location in the server

that's just my design, and it hasn't been proven yet

What are you making? Why does the server need to do anything related to paths?

Uh well the server needs to tell the other people where this player wants to walk.
[-snip-]
[/quote]
Wait, what?

Do all the "other people" really need to know where the player wants to walk?
So, you're telling me that playerB needs to know where playerA wants to move? As in, he needs the actual path that playerA is moving along? I don't buy that...

Why not just let the client update playerA's movement -> server side correction -> propagation to other players. Done? Where in this does there ever come a need for all the players to know the path that playerA has chosen? (I'm genuinely wondering)

Client calculates path, from player indicating new endpoint and start point assumed to be current position (it might be rendering some catchup due to latency but will be at the 'official' current point eventually before starting next increment.

Server will validate each step of the path as it is fed each step one by one by the client. These steps have small enough increments in the coordinate changes so that the validation wont skip terrain features (triangles on a navmap or cells on a regular grid, or a squeeze check of a bounding box against the terrain mesh,etc).

Thus the server doesnt have to do heavyweight recreation of the pathfinding (and wont waste the effort when the player keeps changing direction and most of the path processing is invalidated and useless)

The server validation still may do a fair bit of processing (ie- the bounding box collision for a small movement step) but not for the entire path.

The client itself probably will only do a test a short distance along in the future moves (depending on how far out front the player can indicate the endpoint via input) and stop if the collision validation fails.

Some games simply stop the motion, others have the object bounce off or slide the edge (or even spin on impacts)

With games that have collision detection with dynamic object/terrain then the path can go invalid immedaitely as soon as something moves to block the expected path.
The data potentialy arriving late for dynamic movements (latency) in the environment may have to be handled specially (cleverly) to handle these immediate collisions

Of course the server won't send "playerA move" message to all other players, only those in playerA's vicinity...

@woodinooneeye, hey your idea's kinda good. Tell me if I'm wrong interpreting your ideas:


1. playerA request movement from 20, 21 to 40, 51
2. server checks if it's valid path
3. if it's invalid, send nothing
4. otherwise, tell playerA to simulate the path movement

5. while simulating(movement), the client send new coordinates each x MS (x is tweakable)
6. server get the new coordinates each x MS, and broadcast it to other players within playerA's vicinity

am I right? the thing is, the client could potentially cheat by sending new coordinates even if the path is invalid (the cheater could just ignore the "invalid_path" message)

EDIT: I just noticed that all of you're suggesting the same ideas, well I'm sorry for being so dumb. But still, please answer my question (about how to avoid cheaters) above...hehe

What you are doing is basically networking a real time strategy architecture with a fps style game. If there are only so many players and you control one of them, you can get away with just sending updates of the players position as what is suggested.

So you can either validate, and then continue sending movement updates every 15ms. Or you can validate movement while you receive them instead of up front. If you get a movement command, check the current tile the player is now on, if it is invalid then send a stop command and move them back or something.

wow it works!! well I need a bit of optimizations still, but thanks for sharing your ideas guys!!