Hi guys, how are you?

I'm working in a game, with movement similar to WoW. Basically, most Creature's will do a RandomMovement (from point A to B). What I'm doing now, is just get the timestamp from the server to the client (I have a system to know the time between them) and lerp between client A to server B, and the duration is the duration given by the server minus the internet latency.

Now, I don't need much precision, but I'm concern, because in order to aggro the creature, player need to run nearby it, and if the client doesn't show a correct position, u can run by pass it, going unnoticed, since in the server the position is different, because the server start position (point A) is different than client start position so the angle to destiny will be different. I don't want to force to start the movement from server position, or it will cause a little "tp effect" due to latency between client and server.

Is there anyway to interpolate from client A to server B, following the angle between server A to B? Or do a little adjust each frame, I want it to look smooth.

Only the server needs to identify if the monster is triggered. The player position is likely very small increments sent frequently, and the server knows exactly where the monster is.

Check to see if this is an issue in practice. If so, the server needs more / better updates about client position. My guess is that the server knows close enough, any issue would be the sensitivity to trigger the creature.

Yes, but if the player don't see the correct path, it can lead an issue where the player run next to the creature on his side, but since in the server, the path is different, it will not trigger the chase, and will be annoying for the gameplay. That's why I want to try to simulate a similar path that the server took. Because if I only set the destination to what the server told me to, like go to B, and I interpolate from client A, if the client due to latency is too off the last server position (which is the server point A), the line is totally different, even tho the final dest is the same one, and player could try to aggro the creature, but nothing will happen, since in server side the path is different. (Just in case, the average duration of a movement is 4s, so if line between A and B isn't the same as the server, can be a really big difference, even if the final dest is the same).

Issue is more on the client side of prediction, since Player's send regular updates of their position each 100ms to the server, but to avoid sending too much packets, for the random movement of the creatures I only send to the client, Creature ID 1 move from (8, 5) to (16, 32).

I was thinking on using Bezier (with one control point at the middle), or Hermit interpolation.

Yes, but if the player don't see the correct path ….

As frob said, build the basic setup first, and test how it works. That should give you a better idea how often the “if” happens, and you're in a far better position to judge if additional work is needed (and if so, what can be done).

@Rewaz To deal with the problem of different angles due to mismatched starting positions, you can include direction correction in the lerp function. This should help.

Fosixo said:

@Rewaz To deal with the problem of different angles due to mismatched starting positions, you can include direction correction in the lerp function. This should help.

Well, isn't really different angle, is more like a different path, due to latency, because let's assume I have 150ms of ping, if the server say go from point A to B, client will be off point A for 75ms, and if the start position doesn't match, the traced line from point A to B, will be different, ending in a case scenario that I explained, which u will go through the creature, but it willn't aggro, because in server side that traced line is different.

Rewaz said:
I'm working in a game, with movement similar to WoW

Rewaz said:
will be off point A for 75ms, and if the start position doesn't match, the traced line from point A to B, will be different

These don't align.

The issue about points being off is a sign of your math being wrong, not a latency issue. Generally the simulations don't need to be lockstep, nor do they need to be deterministic, but the destination points are set by the simulation authority and shouldn't be “wrong” in the way you describe.

Again, build it first and then look for actual problems. What you're describing doesn't track with typical network games. Yes there is latency, yes the tick rate matters, but the thing you're describing isn't typically an issue in the real world. If it is an actual problem, then it's going to be an issue with your radius rather than latency.

Ifrob said:

Rewaz said:
I'm working in a game, with movement similar to WoW

Rewaz said:
will be off point A for 75ms, and if the start position doesn't match, the traced line from point A to B, will be different

These don't align.

The issue about points being off is a sign of your math being wrong, not a latency issue. Generally the simulations don't need to be lockstep, nor do they need to be deterministic, but the destination points are set by the simulation authority and shouldn't be “wrong” in the way you describe.

Again, build it first and then look for actual problems. What you're describing doesn't track with typical network games. Yes there is latency, yes the tick rate matters, but the thing you're describing isn't typically an issue in the real world. If it is an actual problem, then it's going to be an issue with your radius rather than latency.

I just want to be as precise as it can be, but I don't want it that precise as a FPS, like WoW is okay. What I say is imagine this scenario. Client and Server first position is the same, server send move ID 1 to (4000, 300) and it should take 3000ms (dur), then client lerp from A to B doing accum += dt and t = accum / dur.

With 150ms of ping, server can say now move ID 1 from (4000, 300) to (3690, 297) the facing is (310, 3).normalize(), but on Client side ID 1 is still moving and haven't reach that first final destination, so if I lerp from current client position of ID 1 will go from (3897, 295) to (3690, 297), that path taken by the client, will be different than the one from the server, the thing could be like, set a threshold of x meters, and if the client pos is off 0.5m from the server, then use server position could be one fix.

Is it okay to have that “difference”? All games do that and we don't notice? That's what I'm afrid of, maybe WoW does a Lerp, and don't care and since it's just lerping it's almost always in the same position as the server, prob with a check like I said before, that's my concern, that it become and issue later.

Different games do different things to keep systems in sync. If they're goal-directed they may indicate the goal and let the clients do their own thing. If they're kept in sync with a view-based interest system (like Unreal) they may send the updates very frequently if that's a creature on the screen.

Even so, the path differences you're talking about seem minor. If it is distance only often you'll have two rings, one where they'll alert and another where they'll trigger. The two will be large enough that players will know they're in range long before the creature alerts. and when they're bordering by the alert point the server will either notice or not, it will be very near the border at the point where the player won't particularly mind if it is off by a few milliseconds. There are many issues around latency, those distances aren't typically one of them.

Rewaz said:
That's what I'm afrid of, maybe WoW does a Lerp, and don't care and since it's just lerping it's almost always in the same position as the server, prob with a check like I said before, that's my concern, that it become and issue later.

For any sufficiently complex system, the number of potential problems and number of possible corrections just explodes. So you can try to avoid all problems by trying to incorporate all corrections into the design, but that design then explodes in complexity.

In addition, since you cannot test anything without building it, your complex design only exists on paper. you cannot obtain judgements like “this problem doesn't exist”, or “this is good enough”, or “this needs work”. Theoretical design is good with numbers, it's much less good with qualitative judgements.

This leads to the idea that the better tactic is to build a design early. Yes it may not do what you want exactly, it will need improvements or even a rebuild, but it gives direction. You can find out what the real problems in game-play are by testing it, rather than thinking about all the problems that exist in theory, but may not play a role in practice.