Hi! I am brainstorming ideas of how I can make the best pet movement system possible.
In the past, I’ve made many different types of pet system, but for the most part, they’ve trickled down to one thing:
Attachments
AlignOrientation
AlignPosition
I am looking to make this system better, with the pets walking around you in a ratherly random pattern rather than sticking to you in one spot. The current solution that I’m thinking of this is the following:
I would do the same method as usual, attaching each pet to a pre-created attachment in a player’s HumanoidRootPart, but in random time intervals, tweening (using TweenService) to move the attachments randomly around the player.
This would run into some difficulties, the pet may walk through the player sometimes, etc.
A good example of a pet movement system that I would be interested in trying to re-create / modify would be Bee Swarm Simulator.
Any ideas, tricks, tips, or anything at all would be greatly appreciated. Thank you!
Simply use SetPrimaryPartCFrame and set the CFrame of the pet. You can use radians to position each pet evenly around the player. Lerping the CFrame will remove the need for TweenService.
SetPrimaryPartCFrame will make the pets appear to have no life. They will be stand still and remain in the same position around the player at all times. I will still look into this suggestion. Thank you
Personally I would recommend using body position, updating the position value every 0.1-0.75 seconds, our players experience next to no lag, gives pets a bit of life, and creates a cool following effect with it being very simple to use and little scripting involved
A majority of pet systems currently out there use body movers so I would definitely opt to continue playing around with those the best you can to produce a result fitting to what you want. CFraming is too rigid and you’d be better off welding in that scenario.
I’m not entirely sure how you can accomplish random movement (that honestly seems difficult). Maybe you’d like to take a look at LineForce and see if it has any use to you? The main thing to note is that physics pet systems involve body movers, so that means you’re limited to the options you’ve listed plus some others.
One thing you could consider is a proxy part which you move around the character and the pet follows this proxy part around. You can move the part around rigidly with CFrames and whatnot, while the pet goes around with it with body movers (by extension, physics). The proxy part would, of course, contain an attachment so that the constraints remain functional.
Helps to read the thread. OP wasn’t asking how to make pets stay with the player, they’re asking how to improve their current system from floating near the player to moving around them randomly with respect to the character space. The solution you provided is fairly bad.
SetPrimaryPartCFrame tears apart models after continuous usage.
Rigid CFrame sets requires constant replication, which means you’re introducing network traffic and a bottleneck. The CFrame proxy part in my proposal can stay on the client and the network ownership of the pet can be given to the player. Therefore, the physics replicate.
I haven’t tested that myself though, fair warning.
:ToObjectSpace() can help pretty nicely at getting relative positions, this can help with finding where the position of the player is respective to the pet and thus allow you to tween around said player. Alternatively you could just raycast to make sure the path to a point is clear.
I’m assuming this is for tweening, but for the most part you can just update a point to the server(and if needed towards clients) and allow clients to do that themselves without needing to constantly set CFrame. Once again, my assumption towards what you mean could be entirely incorrect, so fair warning.
No tweening. The point of the proxy part is to set an objective point so that a client network owned pet can move over to it using the outlined body movers in the OP. Server doesn’t need to get involved at all.
Thank you for this response. I was thinking to do something of that sort, but you clarified it much better and made it more clear than I originally envisioned. I’ll be sure to test this out when I can. Thanks again!
I haven’t the slightest where you’re getting your information from or if it’s just a personal dislike towards them, but please do not attempt to seed doubt into something completely untrue. Constraints are not inefficient at all, they are in fact very helpful and used by many developers for a number of purposes.
There’s absolutely no substance or basis to claim that constraints are inefficient. If they supposedly are, please back up the claim and demonstrate.
Hard to manage how? If you have a bad implementation and lack abstraction, yes it will be. Manageability and maintainability of a system is on the developer, not the engine. Constraints aren’t at fault for your lack of management.
There is literally no difference between the amount of management you can get out of using CFrame and using constraints. You still have to code in behaviour for each and handle them the same way. One relies on physics simulation and the other uses mathematical functions to get through.
Forget all this, it’s not even a proper counterargument as to why you claim constraints are inefficient. You’re jumping topics and intertwining unrelated points quite a lot.
Case in point: constraints aren’t inefficient and management has nothing to do with anything here. You don’t have any empirical evidence either, just unsubstantiated assumptions (and possibly biases against constraints?).
CFrames are two lines. Constraints use many. Not sure why this is such a big deal that I don’t like constraints for pets. I’m simply telling you the way 99% of all games that have pets manage them.
The problem here is that you’re making completely untrue, unnecessary, unsubstantiated and irrelevant assertions, as well as straying from the original topic to push the usage of something that someone else doesn’t want to use.
Lines of code don’t matter in the grand scheme of things and that’s implementation specific as well. Your code doesn’t automatically lose out because you write more. Not sure why this was brought up.
I’ll sum up my suggestion quickly. My five games each with a pet system be the than the last is what I’m basing my suggestion on. CFrame are better for a pet system than constraints. Why am I suggesting this? Very simple. Instead of creating constraints, setting the values etc etc, you can simply use a basic math equation to position the pets around the player. Then you can use a very customizable animation to add some life to the pets. You may not think my suggestion is worthy enough to be used by serverModule, however I’d rather have a few lines of code then hundreds of constraints needing the be kept track of. Yes this is opinion based. I’m not biased against constraints by any means. I’’ actually using many constraint systems for my current project. It’s been fun experimenting with them. I just don’t think they’re appropriate for something as simple as a pet system.
I’m not sure you’re understanding where I’m coming from. This is an unwarranted suggestion and not what OP is looking for. In simple terms: it’s off-topic.
CFrame math is not objectively better than constraints because you can’t be bothered to set up a few properties and rely on physics simulation over mathematical equations. Each implementation is different. As for the lines of code argument, I shouldn’t even have to tell you why this is not relevant and doesn’t matter at all. It’s moot.
I’m not discussing this further with you because there’s no reason for this to have been brought up in the first place. Below.
