Hello , ive been wondering whats a better way to make a fireball , shooting projectiles etc. is it BodyVelocity or Tweening Cframe/Position or if there are any other better ways than those two what is it?
6 Likes
Personally, I always tween the CFrame with projectiles, so I’d say that is most likely better.
Never had created a fireball though, I would still try tweening the CFrame.
2 Likes
If you consider using Tweening, then you have more control over the movement itself. Meaning, you are able to change factors like EasingStyle very quickly. I personally use TweenService for UIs, and it has proven to be extremely good.
3 Likes
Can’t find anything on the developer wiki that would suggest this?
3 Likes
Hmm. I really thought they were deprecated. Maybe I got them confused with something else. Thank you for notifying me.
2 Likes
I thought so too. Body movers are actually marked as legacy and they were superseded by constraints.
4 Likes
Tweenservice for sure, trust me, I’ve done these at least 3 different times in 3 different magic games quite awhile back, with BodyMovers, you’re gonna get an issue with delays, but if you draw the arc and use tweenservice to move it, you’ll achieve a more desirable and responsive impact upon hit/collision.
There’s many debates that I ran through my head back then when I started working with these,
Bodymovers have that delay but they use much less memory coding-wise, in fact they barely use any, but the projectile isn’t as responsive upon collision as one coded via TS. Another downside is that they are also inconsistent depending on the server / client speed ( depending on whichever owns the physics for your projectile ), sometimes they could travel further / closer depending on the speed
Tween on the other hand, is very responsive upon collision but the downside is the memory usage in comparison to body movers, however, this depends also on a few factors, mainly on how you handle your game, memory-management, network ownership for the projectiles ( whether you choose to have the server/client handle them, both having their pros and cons ) etc.
I ended up using TS mainly and there was barely an issue with server slowing down etc during major battles, but again, this heavily depends on how you manage your memory throughout the game 
5 Likes
I don’t think this is a fair comparison or a well-thought out one either. Faulty implementation of either system can result in problems others do not encounter and they certainly aren’t interchangeable depending on the use case.
Physics-based movement doesn’t cause delays so long as you’re actually handling the movers properly. That means managing network ownership and being cautious about what it is you do with them. Remember that physics operates at a game step. Employing best practices for body movers and ensuring efficiency of the rest of your code base is important.
Physics will ALWAYS be more responsive than tweening and that’s an indisputable fact. Physics are handled by the engine and you can accomplish most or all real world movements and forces on objects. Tweens are very static and rely upon a specified goal parameter. Again, in addition to how each item operates, you must also take into account best practices and efficiency to further help each.
Tweens ran by the server are always going to be expensive. Tweens are a strain on the server to need to update a property every few ticks depending on the parameters given. This is in addition to needing to replicate changes for the object. This is usually why tweens are recommended to be handled client-side for smoothness.
8 Likes
Video Example of a projectile I coded with TweenService
External MediaI don't think the second half is exactly necessary
I’ll have to point this out before anything, the assumption in the second half of this statement is unnecessary, it could be seen as condescending to some people, just because something isn’t right, does not make it not well-thought. Someone’s best thought could be your worse just as how another’s poor thought could be your best.
Everyone make mistakes, including yourself, when you approach someone else with the intention to correct their misunderstanding, approach them in a manner that is respectful. Education is best received when it is delivered politely, the moment you make it seem insulting, you’re also robbing the recipient of a possible educational lesson and yourself of the respect your knowledge deserves. I used to be a common guilty victim of this bad habit too when I try to correct someone, it often results in the opposite of our intention, even when we didn’t mean to insult them. Sure it’s not entirely our fault how they manage their emotions but when my purpose is to educate, it does teach me to have better judgement of the words/phrases to use when I am correcting another.
Most definitely, as with everything else, incorrect use of it will result in undesired bugs.
Most definitely, as with everything else, incorrect use of it will result in undesired bugs. However I do strongly feel that between TweenService and BodyMovers, I would pick TS over the latter any time, especially with things like fireball, which is often Non-Collide in games, which takes away the reactive factor of the collision. What I meant by Collision was the impact when hitting a target, with BodyMovers it’s much more difficult to recreate a physical collision than it would using TweenService when the projectile is non-collide.
Physics is more responsive in collisions, absolutely, but
Physics is more responsive in collisions, absolutely, but as a projectile? I wouldn’t really say it’s better than a modular collision script via TweenService, say you launch a non-collide fireball in the air with BodyMover and let physics handle the arc drop while having the impact binded via OnTouched, you will most definitely run into issues where you can’t get that collision hitpoint perfectly to create the impact effects. And if you code the bullet drop arc into BodyMovers and use raycasting to get the hitpoint, you might as well be using TweenService really since you’re already negating the default physics advantage of BodyMovers. Especially when the projectile speed is extremely fast ( for long-ranged powerful projectiles ), you’ll get very noticable difference in the collision point when you rely OnTouched.
However, with TweenService, I don’t have any issue with those, as shown in the video shared above
In regards to NetworkOwnership, this point applies to both methods, same goes with efficiency and memory-cost. With BodyMovers, NetworkOwnership, and with TweenService, Local/Server Scripts.
On the other hand, if you have a way to get the hitpoint of a high speed projectile using BodyMover with a code that doesn’t negate the physics-based benefit of it, I would absolutely love to learn more in regards to it
2 Likes
If you have an issue with my post, you can private message me instead of hiding it under a block. The intention of that first statement was in reference to the fact that your post made anecdotal assertions about the differences between tweens and physics.
Turning off collisions on parts doesn’t take away from whether something is reactive or not. This is based upon your implementation and solely that. If you don’t handle it well, then yes you aren’t going to get much of a reaction.
Forces are reactive. When you apply a force to something, you don’t know if it’ll reach it’s goal or not, but you apply it in such a way that it should. The effect then takes place only if it does reach its goal or the time for the object to be alive expires in which it’s cleaned up in some mannerism.
TweenService isn’t reactive: you’re simply coding something to happen when it reaches a fixed goal, which is to disperse the projectile at the end of the tween. That’s akin to hard-coding something. It follows a path and then disperses.
Note that I said multiple times that things differ heavily depending on your use case.
No. Again, depends on your implementation. You can handle these cases yourself in many different mannerisms, up to simple operations per tick or through raycasting. Whatever you like.
Saying it again: depends on your implementation. You’re relying heavily on the argument of a projectile having CanCollide off as a dependency, as well as using the Touched (not OnTouched) signal that checks for physics-based intersections. This set is just one way to do things. There are many more ways to check for collisions. That’s why I said not well thought out: these points are honing in on only one way of doing things while ignoring the others.
How so? Projectiles can follow arbitrary paths and still incorporate raycasting for the sake of accomplishing goals. Doesn’t mean you should use TweenService. They aren’t interchangeable and have their respective use cases. TweenService doesn’t automatically become an alternate solution just because you apply raycasting to a projectile.
It doesn’t. Network ownership is for physics replication. TweenService is property modification in which standard object replication rules apply.
What you're giving here is the general explanation behind
both Forces and TweenService. I’m sure if you read the explanation I provided previously in regards to what I meant by TS being more responsive in regards to obtaining the exact Hit Point etc, you could conclude that I wasn’t referring to TweenService in itself being reactive.
Hardcoding the direction is exactly why I prefer TweenService over BodyMovers on the topic of OP’s goal. You’ve given a general explanation thus far while withholding a neutral point. Give me a use case with OP’s goal in mind, where BodyMovers is the ideal method as compared to TweenService.
I’ve provided both a video and a written explanation based off my experience to further explain why I find TS to be the better one in the objective OP wishes to produce.
I’m well aware, however with what the OP wish to create, I simply don’t see a case where BodyMovers would be the better option. Thus my opinion.
Do provide the other methods of checking for collisions
in relation to the topic, where BodyMovers would be the ideal method as compared to TweenService. Just saying that there are other ways to check for collisions doesn’t really help me or others who share the same opinion see how and why TweenService isn’t the better option to use.
The complete quote here is,
In regards to NetworkOwnership , this point applies to both methods, same goes with efficiency and memory-cost. With BodyMovers, NetworkOwnership, and with TweenService, Local/Server Scripts.
As explained in the ending of that quote, what I meant by the fact that it could be applied to both methods is that, BodyMovers could be handled on the client/server depending on who the part’s Network Owner is. And TweenService could be handled on the client/server depending on whether the code is ran on the Client or the Server, which also, requires the change of the part’s Network Owner if you would like it to replicate to the server perfectly had you choose to have the Client handle the execution of the tween.
I’m not really sure how many times I’ll have to say this, since I did so many times in my responses alone. Choosing between body movers and TweenService is use case dependent. What I’m speaking against is the assertions you’ve made that TweenService is better than body movers as well as the falsities propagated by your replies:
-
Body movers cause delays: This is not necessarily true. What delays are you speaking of? Most delays in game code are going to come from your own implementation and not anything else, so you can’t blame body movers for causing delays without employing best practices yourself all the way.
-
Physics projectiles aren’t responsive: This is definitely not true at all and is completely dependent on how you handle the projectiles. There are many games that rely on both real and pseudo projectiles for functionality without any prominent issues.
-
Inconsistent timing: See network ownership. Client-server desynchronisation is a problem in any system. This point is almost moot to bring up.
-
Tweens are responsive to collisions: False. Tweens are property changes, body movers are physics. Collisions fall under the physics pipeline, tweens do not. Most tween work involving “collisions” is completely developer-dependent. Talking operations such as per-step calculations and checking to emulate collisions.
They each have a time to be used and in a lot of cases its preferential. OP’s use case is no exception.
Didn’t catch that part, thanks for the explanation. Admittedly in that case I cherry picked and didn’t see the rest of the context, or it was unclear to me at first.
1 Like
No I got that part already, as you just mentioned, you’ve said these already. My point generally is that TweenService for me is the method that works best for OP’s use case, yes in OP’s use case it can go both ways but for me, TweenService is the better of the two,
now you’ve mentioned that for the argument of " TweenService vs BodyMovers ", it depends on the use case. Understood, I get that, but since it depends on the use case,
for OP’s use case, yes it can go both ways, but which one is the better suited for that case? Yes there’s many different ways to go with both ways but what I’m curious about is how one use case of BodyMovers in OP’s Case, can be better than TweenService in the case OP provided in topic.
What are the best practices for BodyMovers if I want to recreate the video I showcased above, in a manner where it either bests or can compete with the one shown in the video?
Because personally I’ve avoided the use of BodyMovers when handling cases like OP’s case on this topic due to the lack of an efficient way to retrieve the Point Of Impact/Collision accurately to position the explosion effect for the projectiles
OP’s question is fairly ambiguous and doesn’t specify anything specific, which leaves this question majorly in the preferential area. There isn’t really an answer to this question.
There’s a lot that goes into best practices for body movers and to account for them as well. As physics is reliant on the physics pipeline managed by the engine, this means that you’re also looking to make your game generally efficient so as not to impede with the execution of physics steps.
-
Best practice is different from scenario to scenario, which is why I didn’t answer with anything specific. Best practice often comes down to getting the best out of a situation while using minimal resources, effort or strain on any machine, at least from what I’m aware of.
-
With body movers, there’s not a whole lot of work involved. Set up your projectiles, your forces (calculations vary from each action) and set a network owner. Have the server perform checks and security measures to prevent exploitation.
In the case of a fireball or explosion such as your own, you don’t really need a point of contact. To determine when to disperse, you need to detect when at the very least an intersection occurs, but otherwise when a projectile hits something and needs to disperse, it’s of the actual projectile.
1 Like
If you’re looking for something relatively fast, I suggest using FastCast. Using .Touched on parts with BodyVelocities of high magnitude is unreliable as the part could be further along its path on the server than it looks on a client (which registered .Touched)
3 Likes
I am having this issue right now, my game is lagging out cause of tweens it seems, when I am in the studio testing it is fine but once I go on Roblox it is a shit show, I tried using body movers before but the thing with those is that they do not have easy to use has tween, an example is that even when I set parts to massless they sink into the ground when I try to move them with Align position and I can’t know when a projectile has reached its destination with constraints, I tried to rotate a fireball to give a spinning effect but that also look choppy and horrible, I did get it to work a few times but it too inconsistent. is there any resource I can use to help me better understand body constraints?