Trying to make a pvp bullet hell here
For the current example, I am firing 1 star that travels and then splits into 25 stars; 26 bullets in one shot in total
Currently this doesn’t lag on it’s own. However, when you have 8 players constantly firing this, it can get very laggy (even if each one fires only once a second) because that is 208 bullets at once, and this isn’t counting if they used other stuff as well. Although the lag isn’t severe at 208 bullets, in a normal server including everything else it would cause extreme lag that would harm gameplay experience.
My current system uses a module script that transforms inputted server data into a table, which is then fired to a client script that takes the info to render the bullet visuals. Because it is a PvP game, i made the server make invisible, real bullets and have the clients simply make a version with all the visuals (particles, trails, meshes) and just weld it to the moving server bullet, while the server does the actual moving, as the projectiles vary greatly in trajectory and it would be impossible for the server to do sanity checks that are effective against exploiters if the server doesn’t have the bullets themselves (hence why this isn’t fully client based).
I am wondering how I should make it less laggy, such as if it is possible to do it fully client-sided and have it not extremely vulnerable to exploiters, or if there is some method i should implement, or if I should change how i am moving the bullets/creating them.
Sidenote: this might also have PvE aspects, so it would be appreciated if the solution could also allow PvE (because in a full client sided system, this is very hard to do)
EDIT: Object Pooling has shown some success, but wondering if there’s other things I can do
I’m not sure how I would use fastcast to reduce lag here (haven’t yet gone to the hit detection part, the main goal is currently trying to be able to handle a large number of bullets without lag or too much lag, preferably in the 200 range) although if there is some way this could help me (since i’m not familiar with it and not sure how I would utilize it in this situation) then please let me know
i can see use for fastcast when i get started on doing the collisions (as it seems to be especially designed for handling accurate collisions) but not too sure about how i can use it to reduce the lag of having many projectiles at once.
if you’re using physics to use all those projectiles, then that would be a reasonable source of your lag. by using fastcast, you’re moving your system to use raycasts, which should be much better performace wise for that many projectiles
When creating a part on the server you’d be ruining the whole idea of “Handling visuals on the client and letting the server do the important tasks”, there is no need to have the part created on the server.
In my opinion, have the server raycast like the user above suggested rather than creating the part and then you just fire to each client to render the bullet, do keep in mind that most fps games handle everything on the client other than damage control, they just validate the data sent by client on the server and then send them to every other client!
I would think, that your “real bullets” server-side in the Workspace, even if they are invisible / fully transparent, will still replicate their frequently updated positions to all clients (thereby causing “lag”). - You should not think “I cannot see it, so it isn’t there”, as the server’s Workspace (and ReplicatedFirst & ReplicatedStorage) objects (even when invisible) still needs to be synchronized from the server out to the clients.
It sounds like your “bullets” (stars?) are ‘slow moving objects’, so it would most likely help to not have any actual “bullet”-objects in the server’s Workspace. - Instead when a shot is fired, the server would send instruction to all clients via a RemoteEvent, that they each should create their own client-side “bullet”-object with velocity/direction/etc., and let the clients do the visuals/animation of the “bullet”.
Then server-side, I guess the suggested ‘fastcast’ library, could do the actual exploit-proof calculations, of where and how the “virtual bullet” moves in the perceived 3D-world, and what it may hit.
I think i didn’t clarify this or it wasn’t obvious, but the game is not a FPS and is going to be a PvP based bullet hell. Because it is a bullet hell, it is likely that many bullet trajectories would be too non-linear to model on the server (or if there is a way to model curved trajectories or irregular paths, then I’m not aware of it), it would be hard or impossible (again, not sure) for me to validate all the shots and it would be vulnerable to exploiters who may just teleport bullets on top of people’s faces, Because dodging is a very large part of the game, it is also important that all clients see the bullet at the same position.
Irregular as in: A bullet travels in a curved direction that curves clockwise, but then pauses, before moving again while curving counter-clockwise, before finally returning back to the caster
And I quote from the post I posted, “Sadly there is no actual way to combat latency to where each player screen will be 100% synced with the server.”
The fantasy of “Each client see’s the bullet in the same position” won’t be a thing if the bullet is a moving trajectory because obviously each client will receive the data at a different time ( but it won’t be that much of a difference either since it’s the same data ).
The thing that people seem to forget is the server can also be considered a “machine” yet not as strong as the client’s, hence why handling visuals on the client is the best thing to do in most cases.
Please do keep in mind that the server has to REPLICATE everything for EACH client, when you spawn a bullet on the server it has to calculate the physics and everything and send that data to the client, which is why handling the physics/visuals on the client’s machine is the best course of action!
I believe that the FastCast module was exclusively made to be used with trajectories, yes your game may be not classified as a “FPS” → First Person Shooter, but it still has what any FPS has which is “Bullets” or “Stars” in your case which is what I was exactly talking about.
From the FastCast Post : " FastCast works by splitting up the line from start to goal into a ton of tiny pieces. These size of these splits is entirely based on velocity and distance. Each piece is used for its own individual raycast. Better yet, this script runs based on RunService’s Heartbeat event - Each heartbeat will make the next cast in line fire off."
so in an irregular path, would i have to create multiple different paths to compensate for the individual phases of the bullet’s trajectory? (using fastcast)
who would manage the collisions if it should all be client based (since if everyone creates their own bullets, wouldn’t they each see people damaged at different times and therefore cause problems where one person is dead for someone but not dead on their own client?)
lastly, how would PvE be achieved in such a case if it was all client sided (should the client each create their own mobs?) (this isn’t as important as the other 2 points, more of an if)
I have never used the FastCast module, though it does seem like that to me ( Haven’t read the whole post ). However since FastCast uses raycasting you’d be handling the “collisions” well hit detection in your case on the server.
The server is always truthy and trusted, damage and hit detection is not something to trust the client with but sadly most games have failed to achieve that because of latency, they usually handle hit detection on the client and like I said validate the data on the server then damage accordingly.
Yes you’re right! when a client has very bad lag/latency the damage will be seen in a different time frame, though since you’re handling the damage on the server it’d be a priority to replicate, there is really nothing to do when it comes to this.
When you see a player moving in any game what you really see is an interpolated estimation of their position between ticks, this is a completely different topic but I’ll say some stuff about this :
The client will always see it’s position in a different position than the server when moving, that’s because of latency, It’ll look something like this :
Which is exactly why most games that have shooting handle hit detection on the client, in your case I think it’d be completely fine to handle hit detection on the server as well ( Since the game is PVE and not PVP).
The whole point would be raycasting on the server but handling visuals on the client so the server doesn’t have to simulate the physics for each client for the parts created or visuals.
The client shouldn’t create it’s own mobs, the mobs should be on the server and all handled by the server for the best possible outcome since FastCast would handle hit detection on the server too.
So if I am understanding what you said correctly, the projectiles should be on the client (fully), but the trajectory should be on the server and i should use fast cast to do the hit detection and damage on the server?
i think that will work, but just sort of a side question, how would it handle large projectiles (since from what i know, raycasts are 1 stud sized)
Since the client will be handling the visuals it shouldn’t be that bad on the server, the server won’t calculate anything other than check if it hit something or not and then proceed to the next raycast.
Raycasts shouldn’t be that expensive I think they were made to be lightweight ( not really sure ).
with large projectiles if you mean like big amount of projectiles? Then I’m really not sure that’s for you to find out when trying but this should probably be the best course of action to take!
Sorry for the bump, so basically the server should just raycast to the next point of the path, and everytime the server raycasts the server fires an event to all the clients to lerp there position to this point?
You could’ve messaged me if you were afraid of the bump, but no I don’t think that’s how it should be.
There is no way to achieve real time responses between server and client when it comes to visualizing the projectile.
Basically, The projectile is both raycasted on the client and server, but we would use the server hit detection and the client to actually “visualize” it, the projectile would move from the current path to the next one as long as it did not hit, and if it did then on the server it would too.
Obviously the client’s projectile is ahead of the server one due to latency, so what we would do is send the hit stuff the client did, and we could either 1. Validate it with the server raycast and check the directions etc, or 2. Just wait until the server projectile actually hit and apply damage accordingly.
Both ways work, except the client one is a bit “less secure” yet better for gameplay experience.
(And if you’re wondering, yes I implemented something similar and I might use it in production under a new game I am working for (the server method that is), and it seems to work perfectly fine)
As for the client one, I also implemented that into production in another game, and it works also perfectly fine (Except more code verification wise), I had to implement the client one since the raycasting type of was hit-scan not projectile
I don’t think it’s more secure doing the hit detection on the server because you can add a lot of validation checks to approve the client side hit detection. I think its better to use client side hit detection because it will make your game still playable for laggy players, and exploiters are still going to spoof the mouse position even if you do server-side hit detection so it will still not be any better.
Hmm the problem would this way would be adding random values would be hard. For example, If I wanted to adda random recoil value on the server, I would also have to add the same random value on the client. For example if the server one had a recoil the client one wouldn’t see it making it as if the hit detection was messed up.
There are a lot of ways to combat that especially if the hit detection is purely on the server, and yes, by all means it’ll be much more secure if the only thing the client can send is the projectile direction.
As to @CoolShank8, those random values could be calculated on the client on run time and sent to the server along with other things.
Though I still prefer doing the hit detection on the client and validating on the server as it’s much more user-friendly and will enhance gameplay experience by much more.
How so? There is no way that you can prevent a exploiter from spoofing the mouse position. Client side hit detection is just as secure as server side hit detection if done correctly.
You can confirm that they spoofed it? Like you said yourself, server validations are simple.
And yes, there are huge differences between telling the server that the client hit x and telling the server to tell the clients that it hit x while going in the direction y.
I could sit down and argue about it all day but it doesn’t really matter, if the server is done correctly then you have nothing to be afraid of when it comes to exploiters (again like you said yourself), so you could get away with raycasting on the client likr phantom forces for example (even if they did suffer from many exploits and they still do)
but this should probably be the best course of action to take!