Hello, I’m currently working on a game that primarily utilizes fast-paced, medium-sized projectiles that don’t adhere to physics or gravity. Basically, the projectiles need to be visually seen, however, they move extremely fast. The game will have a maximum of 8 players, and therefore there will probably be a maximum of 100 projectiles at any given time, but it will fluctuate from times with nobody firing to everybody shooting at once.
My main issue is figuring out the best approach. There are many methods for handling projectiles, but a lot of them are very expensive in terms of lag. Methods like raycasting seem incredibly efficient for projectiles like bullets and such, but the issue is that I still want a projectile that flies in the air, and the small delay wouldn’t be very pleasant.
I’ve heard from many people and forums that things like velocity, tweening, and lerping can make a game laggy, but I’m not sure to what extent (however, they are much easier routes to take). How many projectiles would it take for noticeable lag to occur?
Also, I don’t want to use any sort of pre-existing modules that others have made as I want the most control over my work, and it would be a good way to learn.
In conclusion, I need to figure out the best way to optimize projectiles while also keeping it as simple as possible for myself.
The way I handle a projectile type weapon system is to create a fake projectile on the client, where the server will divide the projectile into “sections”, where within those sections, it will perform a raycast to detect if anything got in its path while firing in a specific direction. Within each section is a delay of time (also divided by the amount of sections to ray cast is divided in) which add up to the total time where the bullet is attempting to reach its final destination
So if the projectile was traveling 100 meters a second, to an object a kilometer way, it would take ten seconds to reach there, but using “sections”, I divide the time up by the amount of sections being used, as well as the full range the raycast is traveling through, I then use a for loop to cast a ray with the split up direction, and a delay of the full time divided by the amount of sections being used.
If I used 10 sections to cover the bullet path, (1000/100)/10 would be one second, so the server will cast a ray every second to see if anything got in its path, and If something did, the loop would break, giving the results of what the projectile hit.
The projectiles I’m using are just particle effects created by using ParticleEffect:Emit(), however when giving them the correct lifteime (being calculating the time it takes to reach the target position) and speed, it will disappear at the spot of collision, however when something gets in its path, the server will delete the items holding the attachment, deleting the emitter as well.
While its probably not the most optimal way to handle something to this scale, its something I was able to get working properly, but I find that this approach removes the server from calculating any physics, or effects, and leaves the client to visualize what is going on. However I’m unsure about how it would perform if thousands of bullets would be fired at a time, which is where I think Hitscan systems would out-perform projectiles systems.
It HEAVILY depends on your game and what type of projectiles. If you’re using guns, I would say just raycast, and add some little fx. It’s too fast to reasonably render.
I don’t understand what you mean by this. There wouldn’t be a small delay using raycast. Are you inferring that raycast are unperformant, and would “yield” your code?
The problem with velocity is that it’s like throwing a ball, if it hits something, it’s going to stop.
Tweening has the opposite problem, first, it’s a bit taxxing, And it’s not good for customized things like curved projectiles with custom behavior.
Lerping I definitely would never do or recommend. You shouldn’t be lerping in a loop for a projectile, that’s VERY unperformant and even if you manage to make it not, it won’t look good.
Personally, I don’t you’re going to get a good solution without it being complicated. Systems like these are always unless you’re using an overly abstracted resource on THIS site designed to be easy, but you already stated you didn’t want to do that. You want to get down to the nitty-gritty so I think it’s a bit unreasonable to expect it to be simple.