0
\$\begingroup\$

The enemies in my game are underpinned with a FSM with the motion planning handled by vector steering behaviors, in short - It just calculates a new vector based on obstacles/other objects around it.

This makes it highly volatile as opposed to an A* path finder.

My question: How do multiplayer games handle 'complex' calcs for movement where the risk of de-sync is high? What is the recommended/general use pattern in this case?

Would the server & client both run the vector code and then simply have the server check periodically to correct?

Or would the server just handle all the logic and simply feed coordinates to the client to display the enemies? While this option seems easier and would work in theory. I feel in practice it wouldn't be very efficient having a server firing off packets for 50 different enemy units.

\$\endgroup\$
1

2 Answers 2

1
\$\begingroup\$

It's a good practice to never trust the client.

For NPC states that should be the same for everyone, it's better to let the server handle the calculations and behavior. If the NPC's behavior doesn't depend on specific player states, you don't even need to replicate the position because the server will handle the NPC movement. Instead, if the client dictates the NPC's movement and calculates the position, then that position needs to be replicated.

When it comes to player actions, rather than giving the client full control, have it request the server to perform actions. After the server verifies and approves, it can implement the changes and inform everyone.

This approach ensures consistency and reliability for everyone in the game.

\$\endgroup\$
1
\$\begingroup\$

First, of all, give authority of those NPCs to the server. They feed the client the positions and movement vectors, and the clients just render them as they arrive. Now all the clients will see the same behavior.

However, due to network latency, the behavior might look a bit choppy and incoherent at times. To compensate for that, you can let the clients do client-sided prediction. Which means they run the same simulation as the server does and render the results, assuming that the server will agree.

Now what happens if the server does not agree? What if a packet arrives that tells the client that their prediction was wrong and the npc went left instead of right? Then you need to correct the position.

  • With small enough differences, it might not be worth to correct at all. That might just result in constant jitter.
  • With medium-scale differences, you might correct by slowly interpolating the character back to their actual course over the next couple frames.
  • With very large differences, you might have no other option but to immediately snap them to the correct position.

What exactly does "small enough", "medium-scale" and "very large" mean in numbers? That's something you need to tweak through playtesting under bad network conditions and experimentation.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .