How to handle NPCs

[rcorre]

Is there a suggested strategy for handling non-player characters controlled by the server? Should they have an Input and RollbackSynchronizer, where the server sets the inputs? Or should I perform logic in _tick and use StateSynchronizer?

[elementbound]

You've perfectly described the two strategies I'm aware of 😄

I've personally used the latter, where I've moved the NPC simulation to the tick loop on the server, so state is completely owned and simulated by the host, and then synchronized via StateSynchronizer. That was the original motivation for adding that node.

If for whatever reason you want to make NPC simulation part of rollback ( e.g. it needs to interact with something that needs to be in rollback ), you can treat it as a player avatar controlled by the server as you've described. In this case, you could even experiment with input prediction, so NPCs don't always have to wait for the server before updating.

In my opinion, neither is preferred over the other, you need to pick the right tool for the situation. I tend to go with StateSynchronizer if I can, as it's conceptually easier.

[rcorre]

Thanks! It's good to know I'm not totally off base.

e.g. it needs to interact with something that needs to be in rollback

If the NPC is a CharacterBody that players can collide with, does that imply it must be part of rollback, and therefore must use Input/RollbackSynchronizer instead of StateSynchronizer? I was thinking that if you roll back player positions but not NPC positions, it could mean collisions are calculated differently during a rollback.

[elementbound]

In theory, yes. In practice, I'd test it - depending on the amount of latency you want to support, and the NPC's behavior ( e.g. how much chance there is to collide ), it might hold up well enough.

You can also have a mixed approach, e.g. where you only manage position in rollback, and other stats in StateSynchronizer or even MultiplayerSynchronizer, and update them in NetworkTime.on_tick.