I have been thinking about FPS frameworks for a while now and something that has me stumped is how people handle hit detection for automatic guns. I understand that raycasting is the best method for detecting if something has been hit, but from what I understand firing a remote event every single time you want to fire a bullet is inefficient, especially when you are dealing with many players in a lobby using weapons that have high fire rates. I have seen people talk about raycasting on the client and then verifying the hit on the server but then there is an issue with replicating the audio.
If anyone has any thoughts on this, please let me know.
PS: I don’t post often so please let me know if this isn’t the right category for this topic.
I’ve seen a question like this asked before. This is the code sample I gave them:
local bullet = game.Workspace.Bullet
local uis = game:GetService("UserInputService")
local plr = game.Players.LocalPlayer
local Mouse = plr:GetMouse()
local distance = 100 -- distance you want it to travel
local ttime = 3 -- time in seconds you want it to take
local reloadtime = 5
local debounce = false -- debounce variable (of course)
Mouse.Button1Down:Connect(function()
if not debounce then
debounce = true
local pos = Mouse.Hit
Bullet.CFrame = CFrame.new(plr.Character.HumanoidRootPart.Position, pos)
local iteration = distance
while iteration > 0 do
iteration -= 1
wait(ttime/distance)
Bullet.CFrame += Bullet.CFrame.lookVector * distance
end
wait(reloadtime)
debounce = false
end
end)
Simply put, this code takes an input that you give it (Mouse.hit) and fires a bullet in that direction.
When Roblox determines where the Mouse’s position is in in-game coordinates, it actually uses a ray, so this is an easy way of accomplishing the thing you want, without using rays, simple.
First, the script creates a variable (Mouse.hit) and positions the bullet in front of the character, facing the Mouse.hit position… Then, it creates an iteration variable which is how many times the loop will run.
Inside of the while loop, the bullet (Bullet) is moved up by it’s lookVector, and then the loop waits a specific amount of time.
This doesn’t really answer my question though. I’d simply like to know when the best time to handle the client to server communication is. I should have clarified this in my post, but I’m not looking for any scripts; I’d just like to know what is the most efficient way to handle the remote events
Generally, for big projects, you want to avoid stress on the server as much as possible, so for your case in an FPS game where bullets are constantly going to be fired, you would want to simplify this process as much as possible.
Personally, I wouldn’t handle a bullet firing with the method you’re talking about, I would script it entirely on the client, and only fire a remote event to send the data to the server about where it hit, and other things like damage and streak.
The only reason I sent you this code, was to demonstrate how you can script it entirely on the client side.
That’s what I was thinking and so far that is the best method that I have read. However, I’m still not sure how I would handle audio replication using this method.
While yes, this does result in a load on a server when too many bullets are being fired, most of the time you shouldn’t have too much of an issue depending on what you’re doing on the server. I would say it’s a tax that’s really necessary for a weapons system that feels responsive and has a good UX.
To answer your question about replicating audio, the method that I have adopted and is commonly presented would be something like:
- Client receives input
- Client raycasts and gets the necessary data
- Client plays effects locally ( firing sound, muzzle flash, impacts, etc )
- Client sends data to server
- Server receives data, does sanity checks
- Server tells all other clients to play the effects on their clients
- Server deals the damage / does the other needed functions
This method would provide a good UX, as feedback would be instant, though server side security and sanity checks will be vital since it’s trusting the client with sending over the data.
So essentially what you’re saying is it shouldn’t be too taxing to fire it every time you fire a bullet? And is ti safe to assume that the delay on the server sounds/effects would be very minimal?
Yes, as long as the server only acts like a “bridge” and doesn’t handle any effects, from what I’ve seen it hasn’t had any performance issues in most cases.
Assuming the second half is talking about the other clients having delayed effects, yes, it should have a fairly minimal impact as no matter what method you use, there will always be a delay in effects for either all clients or all other clients, though this will most likely be unnoticeable 99% of the time.
Alright. Thank you for your help!
I have made a bullet handler that coincidentally fits @luvebrainz’s description, you can see what it’s like below if you’re still curious about server performance:
[Unknown] is the bullet handler
Turret are the physical turrets that’s following my mouse
Marker is a separate script used to track hit registration (the red dots throughout the video)
Do note that I didn’t implement any clientsided optimization
Thank you for this. Seeing this in use with little script usage definitely helps with proving what others have said.
Forgot to clarify on the numbers-- The “[Unknown]” in the dev console is the actual bullet handler, the “Marker” is a separate (and irrelevant) script used to track hit registration
Ideally, the client shouldn’t be in charge of hit registration and its physics. That job should go to the server. The client is only responsible for telling the server when and where to shoot and the server does the rest. Sanity checks on that would be easy
You can detect if the target is inside of the user’s fov. You can also rsycast from the player head in their looknvector to check if the plauer is looking at the target. Both of these have their issues though
This is actually very crucial for exploitation prevention.
Usually secure games have the important tasks on the server, to prevent hacked clients to access data and other sensitive info. Putting all your scripts on the CLIENT-SIDE is dangerous, because hackers and exploiters can access them.
Hacked clients can’t access the server-side scripts.