Server ComputeAsync() vs Server-Client-Server ComputeAsync()

Let’s just cut to the chase:
Path:ComputeAsync() is fine on the Server until you start attaching it to Heartbeats, Stepped or rapid loops etc. At that point, the server starts basically suffocating if you had multiple NPCs (ideally for an open world game where there are many NPCs).

So, has anybody else thought of sending a RemoteFunction from the Server to the Client, have the Client/s do ComputeAsync(), return the waypoints and have the server handle the MoveTo()s?

Am I being silly? Is this more performance intensive? Is this even slower?

NOTE: Yes I know sending RemoteFunctions to Clients can cause infinite yields but I’m thinking of using Suphi Kaner’s new RemoteFunction module.

Your proposition is interesting and the idea of off-loading the server to the client is already in use in distribution of network ownership. The server is releaved of some of the physics calculations by delegating them of the responsiblity to the nearby areas of the clients.

Your idea has quite some merit. What concerns me is the validity of the received data, because exploiters could temper with the waypoints. The second concern is network bandwidth. Take into account how much data is to be sent and how frequently so that you stay within the soft limits.


Perhaps you can start by maximising performance on the server. ComputeAsync() is, as the name suggests, asynchronous, so it is only supposed be called when the path should change. If a few wandering NPCs cause problems, then they should be looked into first.

Some NPCs don’t have to be handled by the server at all. The others can have their simulation paused when they are not in the perceivable range of any player.

You would compromise security for that. I would recommend just computing the path via the server. You could make the clients MoveTo though. Or all together tell the clients to solve the path and move it. Your goal is to lower the amount and size of packets via remoteEvent.

I would like to add that disabling HumanoidStates has a large performance impact (a good impact). So you could control the NPCS via the server, disabling majority of the humanoid states.

As @fellow_meerkat suggested, creating a radius or condition at which these NPC’s active would be beneficial to performance.

1 Like

Adding to the scope of the original question, what @paswa said about HumanoidStates is very important to consider regardless of your pathfinding. Good to keep in mind that humanoids are computationally quite expensive, so while suitable for most games, if yours features hundreds of units, you’ll probably benefit from avoid them altogether and handling states and animations yourself.

If you decide to go through this effort there are some examples in #resources to learn from, which dive all the way in and render characters locally. The server remains the authority over CFrames and states and the engagement with players, but the client renders the character and animates its states.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.