FilteringEnabled Networking - What about when 2 clients request a change at the same time? Undo?

Ok, new question. Let’s say I’m designing a cooking game where users interact with stations and objects on the stations. If keybind is on the client, and 2 users press Space at the exact same time (switch item from hand to station). Both clients would do the change instantly, causing the clients to now be out of sync with the items they are holding, and the items on the table. This is due to the fact that when the client does a change, a remote is fired to the server telling it to update the other clients of the change. If the remote gets rejected due to the station cooldown (one player already using it atm), would I have to go back to the other client and revert the change since the station is already being used? If this is the correct soultion, wouldn’t it appear weird how the client attempted to switch items, then the items switched back?

I didn’t want to create a new post, as this is a similar question, but not one that is quite answered in the comments below.

2 Likes

Do the effects on the client instantly, and then on the server to other clients. Do all game logic, such as hitboxes and damage, on the server.

1 Like

if I did a cool down on the server, how would the client know not to do the effects when he presses the corresponding key…?

Unless your cooldowns are completely random, simply do the same cooldown logic on the client.

1 Like

Now, what about exploiters firing to the server to signal the move? I think is have to do it on both the client and server.

Do it on both the server and the client.

1 Like

One of the most important things is having the server in control, not the client. So as @Kampfkarren said, do effects on the client instantly, then on the server do proper checks to ensure they aren’t exploiting or doing things when they shouldn’t. If it’s all fine then replicate the effects to the other clients.

2 Likes

Separating the client and server, and assigning tasks to each is one of the most important code-design decisions you will make during the creation of your game. Lets break down the main components you will need to go over:

Feedback Mechanisms

One of the most complex to maintain. Feedback mechanisms are anything which indicates the action is happening after the input, whether it is successful or not. Examples of this could be muzzle flash on a gun, sword slash sound on a melee weapon, unlocking sound on a chest, etc…

Feedback mechanisms can be separated into three sections: Player only, 3rd party only, or both. Player only and third party are relatively easy to get a grip on; you do the processing locally, to those who want to see it. When you intend for the entire server to see the effect, including the person who triggered it, that is when it gets tricky.

Referring back to our previous example: muzzle flash. In any feedback mechanism, you want the feedback action to appear instant to the player. In the meantime, you also want to replicate to the other players as fast as possible. How do you achieve this? Simple, you do both. The player handles instant processing of the action, generating the necessary feedback mechanisms. In the meantime, the server replicates the action to all other clients, ignoring our local player, since he already got the feedback.

On a quick side note, you should do the same checks you do in the server at the client too. We wouldn’t want the client getting feedback for something that ends up not happening.

Checks and balances

This is what you will hear any time you post about FilteringEnabled / Experimental mode on this forum. To keep your game safe, you must check every single thing that comes trough a remote event from the client to the server.

Do not trust the client

Movie-like quotes adverting to danger aside, what might be news to you, is that you should run the checks on both the server and client. Why is that you might ask? Simple, performance!

As a general rule of thumb, the client is much more processing-capable than the Roblox servers are. Use this to your advantage! If you avoid sending RemoteEvent calls to the server, by doing the checks first in the client, you safe processing power for other tasks!

This isn’t a hard-line rule; specifically in mobile-oriented games, you might want to avoid client processing of unnesesary checks

Damage and other mechanics

While this is the easy part, it’s also where most developers get things horribly wrong, and expose their games to unnecessary exploits.

Remember, just because you are checking for things in the client, in all of the scripts that will fire the RemoteEvent, this does not mean it won’t be fired at other times. One of the most common exploits around is the ability to fire RemoteEvents as the client. Expect exploits to fire your events with random assortments of arguments attempting to cause a change in server behaviour. A common example would be killing all players for an unprotected report-damage event.

Remember, all calculations, and all mechanics should be done strictly in the server. You cannot trust the client to do any of the heavy-work here, as an exploiter could easily rig the system in their advantage.

1 Like

I am going to try to ping the server to see if the change is valid, and if it returns true, the client does the change, and the server will ping the other clients of the change as well.

1 Like

Beware that this will cause double the delay and is therefore not recommended.

Any way to solve this issue the most efficiently?

have the client that requested the action do the action locally
send info to server
server receives info and verifies
Valid action: replicate to other clients (send to clients and have them do the action on their own)
Invalid action: don’t replicate the change

This way, no visual things are actually done on the server - only the game logic and verification is.

3 Likes

You’ve just found the real hard question.

The answer is that you have to somehow roll back one of the clients, in as undisruptive a way as you can given the particular circumstances. You have to get creative with things if you want to keep the level of disruption as low as possible for circumstances where there will be a lot of conflicts (such as an item dropper that a bunch of people will be spam-clicking to try to get first)

One trick that a lot of games do is to have an “winding up” animation where the character has to do about half a second or so of animation before they actually start interacting with the object that they requested interaction with. That way if their action conflicts and has to be rolled back, the “winding up” animation can just be stopped, possibly even with a “failure” animation of some sort. This happens without them seeing any visual oddities since when the “winding up” animation is long enough, the message that “there was a conflict” from the server arrives before the animation finishes and they actually start modifying their subject of interaction.

7 Likes