How can i secure this?

Soo i decided to make a shooter game and i also decided to use client-sided raycasting to detect hits, but then i have another problem, see i need to fire remote at start to tell others about VFX and then apply debounce, but then i have to send second remote to indicate that specific shot was hit, here is the main issue, i don’t know how to apply debounce to sending detect shoot remote because some shots may be shorter than others, soo remote can be sent in different times and if one shoot was hit almost instantly after other, it can simply not do it in debounce, soo it may not be detected

how does the code look like?
i mean you can leave it as it is and make it singleplayer/pve coop or handle the raycast on the server, up to you.
it just no one can be much help if you don’t provide atleast a snippet of code

2 Likes

for now it’s concept, but main idea is that to secure client-sided raycasting i’ll use debounce first but then send another remote to indicate shoot and do some security checks, but to prevent remote spam i’ll use debounces, here comes the problem, if i debounce shot detection it can go like this:

  • 2 Shoots are done
  • One shoot goes very far and second very short
  • Two remotes are send at the same time
  • Debounce makes only 1 shoot hit, let’s say this second shoot was more important, what now?
1 Like

You could add visual feedback or smth that masks the delay between shots, maybe even disable the thing entirely on singleplayer modes and run it off the client? I’d say fake the shooting on the client-side while server does the validation, that way the client still retains that feedback. I.e client shoots, fakes the hit visually while server does the final hit.

So client does the initial firing of the remote, and masking the delay and server does the validating (i think there is word for this, but i can’t remember :skull:)

If you also have singleplayer modes, you can also disable this on those and run the old method, i.e client-sided since at that point, instant feedback is more important for that.

Idk how to explain this properly, but that’s the best case i can think of.

1 Like

singleplayer games in roblox still need server, also my game wouldn’t be single player, problem with server sided hits is that it may not be smooth, because there is delay and this delay can destroy experience for many players with weaker internet connection

1 Like

Don’t trust the client - don’t rely on the client to verify shots. Have the client fire a remote to the server, the server fire a remote to every client telling them to locally create VFX, and only do a raycast on the server. The client should tell the server small things like the direction, which the server cannot directly obtain. Things like the position could be obtained on the server without the client. Sanity check everything which comes from the client. Relying on the client for crucial mechanics is a big security risk.

1 Like

Dont’ trust client is old rule that don’t work all the time, client sided projectiles are used very often in big games to increase immersion and overall performance, you can sanity and visual check them to make sure they don’t cheat, but i have problem with one of the crucial sanity checks which is debounce for shoots, for now i have idea to store all the shoots in table on server, and if there is no current shoots in table then the server remote will deny request, i think still it’s bad methood to do it

1 Like

Visuals should be created on the client, the server should handle the calculations and the core logic.
You can’t sanity check client objects because they only stay on that client unless the server goves them network ownership, in which case such a prijectile is possible with security.

With your debounce, do you mean like an ammo system? You could create an all-encomposing system with OOP to handle visuals, ammo and other systems on the server (but only their data).

1 Like

With debounce i mean anti-remote-spam, each time remote requests comes it will check if debounce time of some fraction have passed, if it doesn’t it deny requests

Client-sided projectiles are best option to go, but as i said it’s harder to work with them due to sanity checks required on server to validate them, while also keeping consistent and smooth gameplay, as i said my problem is that if two shots are done in very short period of time, and one shot hits almost instantly after another, then only one from both requests may be processed by server

Imagine if in this situation player will hit ground and also his opponent, but only ground hit was processed, in this case player can loose the game due to this

1 Like

Wouldn’t be an issue if shots were handled on the server! sorry. I’ll stop that now. XD

So you need to differentiate between fast shots and denial of service/exploiters?

You could try checking the position where the shot hit and compare it in relation to the player’s movements and shooting direction. It could help to identify legitimate shots, but it’ll be difficult to implement and secure.

I’d also recommend using an UnreliableRemoteEvent if you aren’t already because they seem better suited to this than normal RemoteEvents.

gtg a few hours ill try help later

2 Likes

Unreliable remotes use Unsecured non-sequenced Protocols which aren’t good for shooting, because they aren’t guaranteed to be delivered, also i want to fix the problem of remote spam which can simply crash entire server if there is no request limiter, (I’ve got an idea with request limiting and overall more complex cooldown but i’ll experiment with it later) The simpliest request limiter is debounce based off table of player and setting tick() value, then subtracting current time from saved time to obtain, but it may as i mentioned deny some requests

1 Like

What you could do is allow a certain number of requests before requests are denied. A server won’t crash from about 10 or so requests, so you could allow, say, 5 and then kick them if they do any more in a given time period.

2 Likes

yh, i talked with friend and decided to go for this aproach, soo there will be request limiter, i can also determine the maximum requests based off shots that were made (each shot adds, each hit removes), and because guns have debounce, it’s almost impossible to remote spam efficiently, thx for help

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.