Which Is More Efficient (Less Lag); BodyMovers or Cframe?

I’m making a special kind of training course that has a fair amount of these moving platforms (see pictures below) that move in various directions. I know BodyMovers look smoother (BodyGyro and BodyPosition are what I’ve used in my tests) but they also are designed that way and have dampening and what not. Cframes, on the other hand, involves having less clutter and less for the game to load in I assume since you don’t have those body movers in each moving part. Which one will have less lag overall.

Just so it’s known, I’m using meshes I converted from unions to reduce part instances (same ones being reused) however are in models. The game is fairly small which is why the meshes have some detail to them.


(Just a prototype, some will be going upward and I still need to make a version that just floats).

I know there’s a few ways to move groups via Cframes but this is what I’m using for those scripts:

X=script.Parent

while true do
		wait(2)
	for i= 1, 8 do
		X:TranslateBy(Vector3.new(0, 0, -.5))
		wait()
	end
		wait(2)
	for i= 1, 8 do
		X:TranslateBy(Vector3.new(0, 0,.5))
		wait()
	end
end
1 Like

I have no experience with this so I will recommend looking at checking the performance stats.

It can be activated in settings or read using the game:GetService(“Stats”).
(This is useful for seeing how you game runs)

1 Like

Makes sense. I’ll play around with it and check.

However, realized if I use BodyMovers the objects can’t move through this wall unless it’s noCollide but I need it to prevent players from glitching out so it might not be as viable. I did a little test with a client-side part but I guess the server still interacts with it because the platform wouldn’t go through it after the player touched this part. Unless I can think of an alternative way to allow BodyMovers I might need to do Cframe anyway I realize.

In general I always go through CFrame because it has a lot less bugs. BodyMovers / Constraints tend to depend on ‘physics’ which as we all know is wack on roblox.

Either way id say just give it a go and you know for future reference.

You’re using while true do and for loops this is a horrible combination! You should use Body Velocity to move it much cleaner and less lag! These are my tips! By the way sorry for last post I barely wrote.

Try Tweenservice

6 Likes

It depends he might be trying to make controls so the best option is BodyVelocity because you can destroy it etc.

body velocity also has potentially to cause lag and a ton of bugs. If done correctly I understand it could be a good option. But for ease there are better methods.

1 Like

For all my projectiles I do use BodyVelocity so I can see why it’s not recommended.

if your making a lot of stuff id reccomend looking into other ways.
I generally use CFrame and lookvector to move it in the direction its looking.
and for the .touched i turn collision on and then off with each move to detect if its moved into a part.

theres tons of ways but its worth finding something bettter

CFrame is less costly, as it can run on a 60hz clock (runservice.Heartbeat, don’t use wait()) instead of a 240hz clock like the physics do, and the parts you CFrame can be anchored, which reduces the amount of updates the physics engine needs to process.
btw your game looks pretty cool, nice job on it :wink:

4 Likes

I can’t use BV I need it to get to specific locations so I’ve been using BodyPosition as I said and causes even more lag than either option.

Thank you. And I’ll look into using Heartbeat instead of wait(). I don’t really know the difference so I’ll read up on it more.

I read through that page but I still don’t know as to how I could implement it. Assuming I use that Cframe code from my example (unless that’s somehow incompatible?) how would I go about practically using tween services? I did read through that page but I just don’t know how to implement it for what I need.

Tweens play like animations, so they can have some problems. however for just moving from one place to another they would work

I understand what they are I just don’t know the logistics of using them. Like I don’t know to either replace or add it to what I have. In the end tbh, the fact that I don’t know shows that I think lol

To optimize the performance and reliability of the server-client interaction for in-game movement and collision detection, it is recommended for linear velocity to be applied on both server and client sides. This ensures smooth and consistent movement experiences for players.

Additionally, to maintain efficiency and responsiveness, a hidden hitbox should be created on the server for detection purposes, while the visual representation remains on the client side. This approach prevents server overload and potential choppiness by reducing the workload on the server.

It is crucial to manage hitbox and damage calculations on the server side, and to avoid granting network ownership of the server hitbox to any player. Utilize overlap parameters for hitbox detection on the server to maintain accurate gameplay interactions.

Lastly, to facilitate seamless integration of visual effects, develop a library of modules that can be called upon using a remote event. This allows for easy creation of effects on the client side and streamlines the process of requesting these effects from the server.

Here is a simplified list of steps to optimize server-client interactions, explained in a way that is accessible for newcomers:

1. Apply linear velocity: Use this body movement method on both server and client sides to ensure smooth movement and other benefits.

2. Create a hidden hitbox on the server: This allows for server hitbox detection without overloading the server with unnecessary effects.

3. Keep visual representation on client: By doing this, you avoid server overload and potential choppiness in the gameplay.

4. Handle hitbox and damage on server: Ensures consistent and accurate gameplay interactions for all players.

5. Avoid granting server hitbox ownership: Prevents individual players from controlling or manipulating the server hitbox.

6. Use overlap parameters: Implement these on the server for precise hitbox detection.

7. Develop a library of modules on the client: Create a collection of modules that can be called using a remote event for easy visual effects integration.