Implications of server-sided weaponry?

Currently, I am in the process of making a weapon system that does not utilise tool instances. I find it to pretty difficult to get an appropriate balance of what I want though and I want to try out some new styles. The first I’d like to attempt is server-sided weaponry.

The system works exactly how it sounds; I intend to implement everything in regards to the weapon on the server. The client’s involvement is mainly only with keybinds. This is by far one of the easiest approaches I can take, which is putting the tool’s entire functionality on one environment.

I intend to create both ranged and melee tools, for reference.

What are some of the implications that fully server-sided weaponry would bring? What are some ways in which I would be able to mitigate these concerns? If you prefer a roundabout question or a tl;dr to this thread, what are the pros and cons of server-sided weaponry?

Before you post: I am not looking to appropriately divide the work between the client and the server for this system, so unless it’s relevant to the content of this topic, please do not suggest that. I am specifically looking at server-sided weaponry and it’s pros/cons.

I’ve created both melee and ranged weapons using predominately server side code. However, they were tools.

Only thing I used client for was animations, so I mean, if you can get animations to work on the server, then I wouldn’t see any real con towards using purely server side code

Yeah, this run of tools I want to experiment with will also be predominantly server-sided. That also includes animations, won’t be having the client run them.

Since the client has to send a signal to the server, and wait for it to replicate back as well, the weapons may seem to lag as there will be a delay in input for the person who is using the weapon.

1 Like