How would I go about properly allocating resources between the server and the client as I remember reading a post about how you would actually want the client to handle all the effects, sounds, etc and to let the server handle practically everything else.
For example, let’s say I want to create a fireball attack.
Would I fire a remote to the server to handle all the physics, data and other information which I don’t want exploiters to tamper with, and then from there, fire a remote to all the clients to create and add particles, sounds, etc?
I’m hoping that experienced developers who have used this method or a similar method to this one can point me in the right direction and correct any mistakes/assumptions I’ve made in this post.
Thank you.
EDIT: For anyone reading after this post was marked with a solution, I would still highly appreciate any additional information regarding this system as I haven’t stumbled across any topics on the Developer Forum that talk about this sort of thing.
Please do DM me if you’d rather do that instead of replying down below.
I appreciate the reply, however, this is not what I was asking. The post wasn’t about protecting my game and how to use the basic Client-Server model , it’s more of how I can allocate resources so performance improves.
You have the right idea. So basically, you only want to use client scripts for displaying data to the local player, but anything that effects other players should be handled on the server.
Here is normally how I go about ranged weapons, or things with a gun-like structure.
Listen for input, such as the MouseButton1. When I get notification that the player has clicked their mouse, I perform client checks to make sure that firing in the desired direction is allowable.
If the click is valid, I run all of the client related actions that you want the local player to see first( shoot audio, local effects, animations ). This means that the FX will be very responsive, since they are created instantly. This is of course optional, and you can have the server replicate them to your client later.
Then it is time to send a request to the server via a RemoteEvent, who’s parameters contain information about where to shoot the projectile. Once the server received the information, it performs it’s own set of checks to make sure that the shoot request isn’t bogus or fired an exploiter.
If the checks return true, I create the projectile, and replicate the audio and other effects to every client except the one who fires the projectile( since it already played them as soon as the mouse was clicked ).
This is a basic little system a lot of developers use, to ensure that the player who shoots the projectile gets visuals instantly, which results in the game being more subversive.
Note that it is very important to re-perform checks on the server( such as making sure the origin of the shot, isn’t too far from the character ), so that the baddies aren’t able to pretend to shoot the weapon, from wherever / at whatever they want.
Thank you for the informative reply, although I do have a question.
How would you deal with latency issues between what the clients see and whats actually happening on the server, especially in an environment where visuals are extremely important?
Let’s say we use your example, If an enemy player sees your weapon being fired due to the visual effects emitting from the weapon itself, but doesn’t replicate to the server within a small timeframe for some reason such as yielding or something else, can you instead fire the remote to ALL clients including the one who fired the actual projectile in the first place so that everyone receives the same visuals at roughly the same time?
You could do without showing the client the visuals first, and just let them replicate back to them normally, and you wouldn’t notice much difference. The reason you would do this at all, is to cancel out that little bit of latency, that would only be noticed by the player who fires the projectile.
For the most part, it doesn’t matter if the clients see the visuals at exactly the same time, since visuals are only for the aesthetic value. What matters most is that the damage, health, and other important factors are replicated to the clients at the same time, so that no one has a unfair advantage.
Is there a limit or certain threshold I should maintain while allocating resources between the server and the client? How much information on the client/server is too much? How much is too little?
Should I use this system everywhere? Or are there only certain applications where this is more beneficial than not?
As long as you are not spamming the remote events 20 times a second, you should be fine in that regard.
I did mention briefly in my first comment, that it is good to perform client checks first as well, to prevent from requesting the server to check when it doesn’t need to. If you have a gun or spell that shoots instantly, you can Raycast on the client first, and then ask the server to re-check, and possibly inflict damage, if you get a successful hit from the client. This eliminates any missed shots from using up server processing power. This is not a necessity, but is something to keep in mind if you need to fire a plethora of shots.
The idea of letting the local client see/hear VFX/SFX first, is only really necessary when you are working with something that needs to be responsive, and engaging ( such as a gun ). Otherwise the player will never notice, and it’s not really worth it. When working with weapons it is more important, since you want the gun to fire as soon as the player clicks. Hearing the gun shot ring out even a few milliseconds after you press the click fire, can be a slight letdown, and make the experience less immersive.
Although this isn’t necessarily related to the topic, regarding your first answer, wouldn’t exploiters be able to bypass that client check either way such as by deleting that script and/or manually firing the events themselves?
Yes, they 100% can. This is why you also redo the check on the server before inflicting any damage. The client check is only to prevent the majority of normal players from firing the event unnecessarily.
!