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)
All shooter games on roblox will suffer from some exploits because the mouse position can be spoofed easily since their is no way to validate it on the server, since it relies 100% on user input.
You’re making it sound like it’s impossible to confirm where the client was looking when they shot their bullet (which is very easy to do).
Like I said, yes you’re still relying on the client to send their mouse position over, but that doesn’t mean you can’t confirm that they did actually point there or look that way (at least on x,z).
Yes for fps games, what about third person shooters? Also, that validation would be terrible for laggy players who request will come later than expected, hence they may be no longer facing that direction. That is why imo server side hit detection is not that much more secure than client side hit detection. If it is so effective then explain to me why most. if not all, popular fps games use client side hit detection? Since your saying doing it all the server will stop 100% of exploits. The best thing to do would be to do a mix of server side and client side hit detection/
I’d like to address a few things and stop replying since I know this will never end.
No, Raycasting on the server doesn’t stop all exploiters, never said that, to clarify what I said as you’ve clearly misunderstood raycasting on the server is more secure than raycasting on the client because there aren’t a lot of attack vectors.
Why don’t fps games do it? Quite simple, if you refer to my posts above I mentioned why:
“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.”
Your opinion, I see that I’ll never be able to change it, perhaps once you read more maybe you’ll notice a difference but for now I won’t be arguing since I don’t see a point in proving to you something that’s been proven multiple times.
Take CS:GO for example, how does silent aim work there (silent aim is moving the projectile towards your target, not your cursor), on the client they’re looking where ever they want, but the other clients they snap to the person they’re targeting.
How come valve is able to achieve such results where cheat developers have to mimic a cheat because they’re unable to genuinely do it?
Simple, they use server hit detection, if they used client hit detection would it be much better? Doubt.
Again, anything the client can give to the server is easily exploitable, but that doesn’t render the server just as bad as the client when it comes to sensitive things.
but this should probably be the best course of action to take!