I’ve heard that Humanoid is not optimized. I am pretty sure it is not problem unless you want to create a huge amount of NPC, which is common in Dungeon games or Tower Defense games.
(Correct me if I am wrong)
For example, I want to make tower defense game. I currently have this concept in my head:
Server
Server is calculating the distance between the two waypoints in path.
Then, server calculates the time NPC will need to reach the next waypoint.
After waiting the time, NPC gets teleported onto the next waypoints position.
Add attributes for future manipulations on client, such as WalkDuration, CurrentPosition, TargetPosition
Repeat same process until all waypoints are ended or until the NPC dies.
All this above is only server’s logic.
Client
We’ll use the attributes we added on the server & track if the attributes are changed (GetAttributeChangedSignal or whatever it was).
Then, we’ll use TweenService to move HumanoidRootPart for the client.
No humanoids is heavily unoptimized
There is multiple factors about them
If you are going to have more than 10 NPC at a time you should consider that
Next you should interpret them client side
its not efficient for server to replicate heck ton of information
You can use character controller instances instead
They basically function like humanoids kinda but no clothing/avatar rendering behavior and more customization
I really dislike humanoids but i just cant not use them in my game because of how clothing works on roblox
Dumb mesh texture filtering-smoothing behavior i cant disable nor can i upscale texture because of dumb EditableImage restrictions to fix that
Which forces me to still use humanoids sadly
So if your characters are static pretty much you dont need humanoids
The only reason humanoids still have a use is 2D clothing that cant be replicated in any way currently
I dont really see why your NPCs have to exist on the server at all (physically), wouldn’t it make more sense for them to exist purely as data?
You can easily decide where an NPC should be on the server without even having to simulate by having some sort of lerp function for them.
You could run the same logic on the client, except actually render the NPC (possibly as you’ve said with TweenService, but I would believe setting position directly with BulkMoveTo would probably be both more optimized and provide more control).
This way you wouldn’t need to replicate data except when you wish to reconcile or send extra data
(And you can still do sanity checks on the server if you need to validate requests from the client)
Haven’t personally implemented NPCs but I do believe the logic should work
Don’t spawn character models on the server side, only client side rendering.
Humanoids are indeed unoptimized. You can avoid them and run animations with AnimationControllers. For clothing to work, you can export a rig with 2D clothing as an .obj file and get the rig with proper UV wrapping and the unwrapped texture that you can apply on all the body mesh parts, which helps using clothing without Humanoids
NPCs should only exist on server as data structs
You can dynamically calculate NPC position on the server by lerping their movement using their speed. That makes sure you can implement stuff like slowdown/stun easy by just adjusting their speed
To reduce replication, you can replicate only when the NPC’s target point changes. E.g. on corners. Also when their speed changes as another example.
As mentioned above by another poster, you should avoid Tweening in best case scenario. :BulkMoveTo is much more optimized for moving large arrays of objects
Another tip that is not exactly related to the Humanoid or NPC itself directly, but with large entity counts, if you use BillboardGui’s for overhead display (like HP), it takes a huge toll on performance. Billboards are heavily unoptimized in big quantities. I’ve personally overcame this issue by making a custom Billboard recreation using SurfaceGui’s that are adorned to invisible blocks and rigged with Motor6D, then Motor transform aligns the angle by looking at camera using C0