I want to create my own custom, from-scratch, FPS gun system. I’m fully aware there are dozens of other already made systems I can use that are leagues better than whatever I can whip up, but I’m doing this more as a personal challenge. I have a general idea of how to approach this, but I want some advice before I start.
Common pitfalls, best practices, things to keep in mind, useful resources, good reads, etc.
Here:
You would need some mathematical and physics skills, but there are great tutorials to start making your own fps.
It really depends on how you want to approach it.
There’s a secured approach:
The only thing the client has control over is input which is all sent to the server and validated for fire-rate control and other things, when fired the gun will shoot on the server and replicate to the client and hit validation is done completely on the server.
This approach while being the most secure is probably the worst. There’s a ton of latency and it’s very noticeable and not fun to play.
There’s the unsecured approach:
Everything is handled on the client including hit detection, input, etc. This approach is by far the easiest and would have the best user experience, but is the least secure and easily hackable.
And there’s the approach that many multiplayer games use which is somewhere in the middle:
Input is handled on the client along with minor hit detection. Input is also sent to the server to replicate it to other users in a way that is validated to prevent others from seeing possible hacking. In the event of a hit, the client sends all the hit data to the server which does all the calculations independently and verifies that the shot is legit then processes everything. This approach is pretty secure all things considered, if a player is hacking or using an auto clicker, the other players wouldn’t see it because the replication is validated before being sent out. It doesn’t have the latency issues of doing it all from the server because the client handles its input separately from what is replicated, they will see their gun fire as soon as it happens and if it hits something then it will be sent to the server for validation. Of course this means it’s also the most expensive involving the most client-server communication and redrawing raycasts on the server for validation can introduce hit-lag.
Once you decide what’s best for your game you’ll also need understanding of remote events. Remote events will allow you to process things that happen on the client on the server as well (these usually have little server-client communication, but remotes are capable of both client-server and server-client, an example of server-client would be to show the player a hitmarker or play a local sound on hit, depends on what you want). Most of our communication goes to the server. Such as sending hit data, input and anything else you might need. It’s important to remember all of these systems can work and it really depends on what you want. If you don’t care about security and want the lowest input delay possible, you can go ahead and do everything on the client. But in multiplayer games it’s typically important to do at least some server side validation. The best overall approach, imo, is the one in the middle which is what many multiplayer games do.
Some games do the server side approach successfully though. For example valorant does it like this:
Hit registration is done entirely on the server, but the thing is valorant servers are ran on dedicated servers and they do full simulation of the shot from the frame it was shot at and then returns this data back to the client. Valorant servers are also ran at 128 tickrate which is >double roblox’s
But like I said all of these systems work you just need to find which one suits your game best.
do you want to use tools or actual viewmodels? (the fake arms without the tools)
because making a tool one would be easier.
if you want to do the viewmodels, you have to script alot more so yeah
