I was having a bit of a debate about CFrames versus constraints (physics simulation by extension) in terms of how to control pet movements. It’s worth noting that CFrame refers to pure CFrame math and constraints refers to possibly CFrame but mainly relying on physics. This debate then prompted me to wonder how others who create pet systems handle pet movement.
I know that a lot of games have begun adding pet systems. Just for knowledge and discussion’s sake, I’d like to gather some data about pet position handling. What method do you use? If you don’t have a pet system or intend to change it, what would you use?
Welding (no animation, rigid connection to player)
CFrame (pure CFrame math equations)
Constraints (body movers, physics simulation)
Other (please specify to help!)
0voters
I’m generally curious as to what system developers would approach this with or what seems like a good way to move forward. Of course, everyone has a different system they want to use, but sharing can set a ground for some as to what they may want to use or open up discussion for each type of practice.
Feel free to provide feedback or discuss. Please keep it relevant to the post.
Note: Poll voters are hidden. I’d like to keep this purely data-oriented.
I’ll admit that I would probably use CFrame if I didn’t plan ahead but since the poll here gives me the chance to plan ahead, I would absolutely use constraints.
It’s generally better to let the engine do the hard work for you and constraints facilitate that. No point in doing it manually (as with most Roblox API).
I personally use CFrame (pure math CFrame) ran on the client.
Reason being that I can eliminate server processing of pets (they’re just visual anyway, so no need to exploit proof their positions, for my use case) and possibly stop rendering pets > X amount of distance away. I can also then add onto this and do some nice local animations on the pets if I’d like to.
As a quick heads up, the client is equipped with a physics engine too. You might read the client’s quality settings, and switch to client-sided physics (just creating the constraints using clientside scripts should work last I checked) if the client has a higher settings number (6 → 7 is a relatively minor change – shaders turn on at quality 8, and quality 5 is an in-between step for a lot of systems like LoD)
The reason you would want body movers instead is that their physics are calculated through the underlying C++/polymorphic engine instead of on the (slower) Lua engine, would which save frame time and allow you more operations per frame, especially on more budgetary devices like phones.
