Awesome template, it’s great to see platformers get some love!
With that being said, I do have some feedback.
I noticed a pretty major networking issue with the moving platforms that this template doesn’t account for.
If multiple players are on the moving platform or if another player is blocking its movement (e.g. a client with high latency is standing on a platform that moves up and down), the platform will jitter, get flung to the side, and quite a few other nasty side effects:
For moving obstacles in a platformer, you typically don’t want the obstacles to be purely serversided. Network ownership automatically switching will result in a jittery, non-smooth physics assembly which is gamebreaking in a platformer. This can be avoided by doing the following:
On the server:
- Create three physics groups, “PlayerAvatars”, “Obstacles” and “LocalAvatar”.
- Ensure “PlayerAvatars” cannot collide with itself or “Obstacles” via
PhysicsService:CollisionGroupSetCollidable() - Set all obstacles to be in the obstacles collision group, and all avatars to be in the avatar collision group
On the client:
- Clone the physics rig on the client, delete the server’s copy
- Reparent the clone to the same parent the original copy was in
- Remove the localplayer’s avatar from the “PlayerAvatars” collision group, and set it to be in the “LocalAvatar” collision group.
What we did here:
- By locally cloning the physics assembly & reparenting it, we’re preventing network ownership from affecting the simulation entirely. Because this is a platformer, we want 100% smooth simulation 100% of the time. If the server had network ownership, there would be replication delay & jittery movement if on an unstable internet connection. With automatic network ownership, the platform cannot support having multiple players standing on it at once.
- By preventing other player avatars from colliding with obstacles, we prevent other player avatars from affecting the local assembly’s physics simulation. Without this, another player’s avatar falling through your local platform can drag it with them and other problematic behaviors!
Another thing I highly recommend changing - don’t use the humanoid for movement. Instead, use Roblox’s new physics controllers. Utilizing these physics controllers with a custom state machine is infinitely better for the complex custom movement of a platformer. As someone who has made a successful platformer, using the humanoid is going to cost you a LOT of time & headache in the future. You are going to be constantly fighting with its internal states & hardcoded physics behaviors.