Need tips on starting with firing off projectile

So I started an almost rpg like game where you can have weapons, items, and skills(most of them are already made) but im mostly having problem with the skills part because I’m not very good with physics related scripting. So does anyone care to help me get started on projectile attacks like fireballs and stuff? I already figured out lookvector will be related to this but are there other things that I need to know?

You can either:

1.) Rely on the physics engine for projectiles and check collision with touched/region3

2.) Hardcode anchored projectiles and check collision with raycasts/region3

I don’t know which one would fit your application since I don’t know the specifics

If you want a projectile to be fired in the direction that a part is facing(lookVector) and don’t want to rely on BodyObjects, you could assign it a direction vector value, use .Heartbeat and every step tween the projectile’s position by 1/60th of its velocity multiplied by its direction. Then you could use :GetTouchingParts() to see when it collides with another object.

local tween = game:GetService("TweenService"):Create(OBJECT, TweenInfo.new(1/60), {CFrame = CFrame.new(OBJECT.Position + Vector3.new(OBJECT.VECTOR3VALUE.Value.X * VELOCITY/60, OBJECT.VECTOR3VALUE.Value.Y * VELOCITY/60, OBJECT.VECTOR3VALUE.Value.Z * VELOCITY/60))})
tween:Play()

Everything that you will need to change is capitalized. Everything else will work as expected if you leave it be. This is the method I use in Flight! for moving everything around and it works perfectly even with many projectiles.

Edit: This is just the logic for the movement itself, you should be able to work the rest out by yourself.

4 Likes

aaa don’t tween on the server! it’s really inefficient, you’d be better tweening it on the client.

This isn’t going to work the way you expect it to. Physics in Roblox and other games only update once every tick; the tick rate is usually 60 times per second (in line with goal fps). When you deal with fast moving projectiles, you can think of their motion sort of like if you took a video in slow motion. They don’t move like in real life, they move a certain distance every time the physics updates (once per tick). If a 1x1x1 stud block is moving 1 stud per second in a direction, then every tick, the block will have moved about 1/60 (0.01666666666) of a stud from where it was the last tick.

Usually this isn’t a big deal, since the number is so small. But eventually, as the velocity of the projectile increases, that difference between ticks will also increase. If you have a 1x1x1 block moving 100 studs per second, then the difference in location between ticks moves up to 100/60, or 1.66666666667 studs. You’ll notice that this difference is greater than the actual width of the block.

When a part affected by physics is moving, the Roblox physics engine will move a part, and if it’s then inside of another part that is collidable with it, the engine will push it back out the correct amount so it looks like the part is flush up against the side of it. However, when a part moves 1.6 studs every tick, there’s a potential that the projectile will never actually occupy the same space as a thin wall, so the engine will never push it back out, which means that in practice, it just flies right through it. This is why fast moving projectiles and other objects get less and less reliable as the speed increases (and also why, if your character falls fast enough, you’ll fly right through the floor). This problem is just compounded by the fact that most projectiles are tiny and player characters are also thin (1 stud thick when shooting head-on).

Therefore, the approach of using GetTouchingParts every heartbeat update (or .Touched) is unreliable, because it’s likely that, for fast projectiles, the projectile will never actually ever be touching anything. The correct solution here is to use raycasting to calculate your projectile collision. You can use more than one ray cast during the lifetime of the projectile if you want to have weapons that aren’t lasers.

15 Likes

You have a couple options.

  1. Body velocity and on touch

  2. Raycasting(most likely the most efficient)

  3. Anchored parts with cframe movements and ray casting

Your best bet would probably be the second option due to everything just lagging less.

The third option would probably be the most aesthetically pleasing but it would need a lot of work to pull off. You’d need a server script running non stop moving things in a table. That or a bunch of stuff with delays and whatnot.

Or if you have the best WiFi and you want to do something easy go with the physics engine. Just know that it gets obnoxious very quickly from all the lag the engine has. Ex: parts teleport backwards for a second and then continue forwards.

I’m not really sure which would be best for what you need to do. But those are probably the best options you have.

Unless you want to just do stuff with mouse.Target and call it a day.

Roblox has a thing for Psychics Rendering it’s called NetworkOwnerShip.

Basically what it does is, set the Psychics of a Part or Model to either a Server or Player to Render it.

So Player.Character is Rendered by that specific player rather than the server that is why when we move it’s feels smooth.

This should help with making the projectile move smoothly without “lagging” or “stuttering”

I know you’re trying to help, but it works perfectly for me and I would assume that OP wouldn’t need anything that moves insanely fast either.

I know you’re trying to say this won’t work for fast projectiles, which is correct, but I would assume the OP wants the projectile to be moving slow enough that you can see it, otherwise they would just use the raycast logic used with guns.

From my experience, you will also run into this when working with Projectiles.

Once you got everything on the client to work correctly you are going to send a RemoteEvent to the server so it can Create the Projectile, the problem is it has a small delay before it creates the Projectile.

Does anyone have a way to reduce the Delay?

Yeah Ilready figured that out since my game is only going to be a singleplayer game