What would the best way be to move gigantic amounts of bullets?

Help and Feedback Scripting Support
#1

You can write your topic however you want, but you need to answer these questions:

  1. What do you want to achieve? To move roughly 4000 visible bullets at once, without the server exploding.

  2. What solutions have you tried so far? I’ve experimented with for loops, while loops, and tween service to handle bullet movement. I haven’t ran into a problem yet, but I’ve never really tested it above 10 bullets.

Before you even think “raycasting”, I’m not talking about gun bullets, I’m talking about bullets like in bullet-hell games, where they are visible, and look all sortsa ways. Or arrows, cannon balls etc etc, basically things that shouldn’t be done with raycasting.

Some things that I’ve thought of are:
-handle the bullet model on the clients side, having only one little cube on the server’s side to be the bullet.
-teleporting players to sub-places so there wouldn’t be as many bullets at once in a server, making boss fights etc much smoother.

Think of this post as a discussion rather than me having a problem, I believe discussing this could be useful for many developers, in present, and in the future as well.

The reason I’m even making a discussion, is because I’ve tested part-count lag alone, although on my old PC, and even 5000 anchored cubes were a problem.
So I just can’t really imagine 1000 parts moving, without extremely massive amounts of lag taking place.

It’s also a good question to answer, wether all bullets should have their separate thread (yes yes i know lua or roblox lua is single threaded, I’m of course talking about spawn() and coroutines), or be on the same thread.

To make it clear absolutely clear, I’m not asking for someone to make me some ultra super bullet system for free, but again, a discussion about handling large amounts of bullets that can’t be replaced by raycasting.

Another thing I thought of, is to have a single-sided triangle-plane instead of a cube as the server-sided bullet, that way it would have the bare minimum amount of tris (being 1).

But I mainly think that the problem will be with the movement of the bullets, especially when its not simply just moving forward, but using sine waves etc to move in a wavy pattern, or all sortsa crazy patterns, like wavy for 6 seconds, but then backwards straight for 4 seconds etc.

I’m not really sure if this is the right place to post it, but I do honestly think that this is a better place to do so than Development Discussion, may be wrong, can’t know.

#2

Contrary to what you said about raycasting, I think it would be quite handy for you.

Rendering the bullets on the client and moving them on the client is a must. I assume that in your game, bullets will move fast enough that once fired, a person has no time to dodge if it’s already headed at them. If this is the case, then simply raycast to identify what has been hit on the server. This shouldn’t be taxing on the server, while allowing fluidity across every client.

Long story short, render the bullets and handle visual effects on the client while handling the actual track of the bullet as well as what happens on impact on the server.

Touched events and GetTouchingParts will create all sorts of issues, by the way, so avoid those. FindPartsInRegion3 is unnecessarily taxing on whatever is calculating what has been hit.

1 Like
#3

To give you an example, think of Undertale’s “bullets”
Edit: Or Realm of the Mad God’s bullets

#4

have you ever heard of fast cast? it makes casting for you without lag

link:

1 Like
#5

Bullet hell games actually use a technique known as part pooling to move those bullets as seen in the thread below. (The bullets are not created or destroyed but stored somewhere else) Plus you can even see the example gifs below it’s been done before:

However, boatbomber pointed out in that thread that the PartCache module is better due to using CFrames and instead of reparenting so yeah I suggest following him.

1 Like
#6

Wow, that is, actually super cool!
Never thought that such a thing could even work…
I would even mark your post as the solution, as that just seems like such a universal fix/method, but I want to keep it open for discussion

I have heard of it before, but never personally tried it, which I will do when I can

#7

Woah chill 4000 bullets is a bit to much don’t you think?

First of all I think you need access to low level code. It just isn’t possible to have 4k bullets at once due to roblox being high level and not giving you enough control of what happens underneath.

Now what is reasonable. I’d say 1.5k bullets is possibe currently in my game I can handle 800 bullets.

And this is with client rendering implemented.

Actually mine do raycast but they are projectiles, the model moves to the next position and raycasts from it’s previous position. You basically need to raycast to the next position the bullet movies, Discrete collisions is not a good idea for this .Touched events, continous collisions are, if you wanna learn more about them see my reply here.

Nope don’t do that make the server just raycast to the next position from the previous position, don’t make this projectile have ANY physical representation all the local rendering should be done on the client.

What you should do is make a projectile on the client when fired, then the server to make this projectile WITHOUT a model which just raycasts to the next position. Then the server also tells all the other clients except you to make the projectile. The projectiles should be simulated on the clients by themselves no interpolation with the startinginfo given.

if you really need constant interploation because your projectiles don’t just depend on the startinfo and projectilebehavior (how the projectiles work), then you might need to do that. However you won’t be able to handle that many projectiles doing that (constant interploation).