Should I use the built-in physics or CFrame for vehicles? I’m aware that if I use CFrame I’m going to have to do some replication and have the other clients tween the vehicle for a smooth effect.
Which method is better on a large scale? 50+ players?
I’m stuck on what to use.
It depends. CFrame is more performant server-side, because you don’t have to worry about the physics throttling, but physics is simpler to set up.
A vehicle that CFrames it’s self? Do you have any examples of this? It sounds extremely unlikely as this would be incredibly complex.
You may have the wrong idea. Games such as Jailbreak and Mad City ‘replicate’ vehicles physics similar to how a hover car would behave using thrusters.
As for advice I have programmed my own simulated physics for cars and it was by no means a trivial task. Roblox physics is more simple and easier to set up so use their constraints.
Doesn’t necessarily have to be vehicles, could be AIs too. I’m pretty sure every player’s character in this game is using CFrame.
Mention that you’re referring to characters in your OP/Title… Vehicles usually refers to cars. Using the term vehicles to refer to player characters is weird and confusing.
As someone that works with vehicles a good bit and sees the performance difference between the two methods (we have a few vehicles that use a hybrid of the two), it depends on what you’re trying to accomplish. If its a plane, use a hybrid of the two to create a more realistic feel. If its a hover/repulsorlift vehicle, use physics. If you’ve got more standards cars/trucks, use physics because it will make the vehicles feel a lot better and more realistic to the user. As mentioned, you will hit some limits with physics throttling but this can be mitigated by reducing the part count of your vehicles and making efficient usage of the physics systems in place. One trick that we implement for our vehicles is to give network ownership to the client so that the physics calculations and such are all done there, rather than on the server and it does seem to work well even on lower end devices, though keep in mind that if you have complex calculations that you will need to have some form of compensation if you have a racing game or something where consistent speed matters regardless of device performance. But if its something like a logging simulator where the speed is not that important, such compensation is not as important, but it would still be best practice to include it. Hope this helps.
Yeah I originally was focused on vehicles but realized I wanted to know more about AI too.
I’m using Humanoids and the MoveTo function on my NPCs which still uses physics.
The reason why you want to avoid CFraming especially when it comes down to movement and not teleportation is because it’s not smooth, and it definitely doesn’t have any collisions. Therefore it will walk through anything and everything.
Also default characters don’t use CFrame. It uses Velocity. MoveTo is also Velocity, the walk animation is simply a loop. Characters auto rotate to face the direction they are traveling and you get the effect that it’s moving.
Some people remove the Humanoids from AI because it’s more performant. I actually agree to this tactic. But Roblox implemented Humanoids for us to use, and make our lives easier. So I’m pretty determined to get them working. So far I’ve gotten 300 NPCs to spawn and move. Thus if it doesn’t work I’ll just complain to Roblox 
Removing Velocity, and Humanoids out of the equation, there’s a lot of things you’d need to re- implement. Just because one thing might work on one use case doesn’t mean its good for another use case as well.
Cheers.
By the way, I wanted to use CFrame because I’m thinking about making a vehicle that definitely isn’t like a humanoid but isn’t exactly like a car as well.
I’m pretty sure jailbreak’s cars use BodyMovers… I would suggest not implementing vehicles using CFrame because there is no easy way to prevent your vehicles from going through walls. I would suggest BodyMovers personally because they give you tons of control over physics and are reliable.
Also if you don’t want physics throttling to take place you can have a root part named HumanoidRootPart in a secondary model under the vehicle’s model and insert a Humanoid into that model. Set the RootPriority to something like 127. The BodyMovers can go anywhere after that and you shouldn’t have any throttling issues at that point.
This happens because Humanoids aren’t throttled (and vehicles really shouldn’t be throttled either)
I would use either a combination of CFraming, body movers, and joints or just body movers and joints.
In what way is CFraming and body movers combined?
You can use CFrame (C0 of welds) for rotation related stuff for example while body movers are what actually move the vehicle.
I have a physics-based chassis that doesn’t use any body movers / CFrame whatsoever. Just constraints.
Motors for wheels, PrismaticConstraint for steering. I don’t use servos though, you have to use Lower/UpperLimit for steering because servos are glitchy and screw everything up.
While you’re in the vehicle you have network ownership and steering, movement, and skidmarks are handled by the client.
Since you have network ownership all physical movements are replicated automatically. Not the skidmarks though, the server does physics-synchronized skidmarks to be replicated to other clients.
Maybe if you ask nicely, I’ll reveal the magic of what SpringConstraint configuration I use, as well as the mass of the car body. :>
Just describing a little of what worked for me. I have a place featuring this chassis, it’s on my profile if you’re interested (not linking it here, because I’m not really here to advertise)
