Replication Delay Reduction?

Help and Feedback Scripting Support
, ,
#1

Hey so I have made a combat system and when a player is hit, they are supposed to be stunned, however, after I get the player’s hit (client-side) I need to send the list of characters to the server to check if these player’s are blocking or not… After the server confirms they aren’t blocking, I use a Remote Event to send the information to the hit player’s client and stun them locally.

(my stun includes a walk speed reduction, jump height reduction, and an animation)

Unfortunately I’ve noticed there is a noticeable delay from when a player is hit to when they are actually stunned. (this delay is only there for the player that is hitting) I don’t know how to reduce this as I NEED to check if they are blocking/parrying and those values are located server side, also, I don’t think that’s the reason for the delay because when a player is stunned, it looks instant on their client, the delay only shows for the other player (who is hitting).

I’ve done some research online and on here, however, most people seem to just say “ah nothin you can do about it” so I’m looking for different solutions (I hope).

I may be ignorant, but I don’t think my exact code is needed in this post as I don’t think it has to do with my current scripts (I made sure I have no manual delays like “task.wait” or “task.delay”)

But, if any code is needed to help me out please let me know!

TLDR; In my combat system, I check if a player who’s been hit is blocking on the server, if they aren’t I stun them on the client…There is a significant delay between when I confirm they aren’t blocking (server-side) and when they are stunned (client-side) but the delay isn’t visible for the player who is actually getting stunned.
(I’m using remote events)

Here’s a video demonstrating the delay: (delayed)
https://i.gyazo.com/5973a1923da815b7b4ae2ea7f14c4e44.mp4

What it looks like from the client’s perspective (no delay)
https://i.gyazo.com/5e68afa3f4a25385d14ac7368a589ee8.mp4

1 Like
#2

This is actually a problem which has no solution, and why melee combat feels bad in online multiplayer games that have a client-server model, rather than peer-to-peer UDP. Roblox is always client-server, and mostly TCP. Sorry for the bad news, but there’s not much you do about this. If you show the stun locally, before waiting for the server to validate it, there’s a chance it could be wrong and leave the attacker confused (they saw their stun land, but the other player isn’t stunned). There’s no perfect solution.

2 Likes
#3

Damn whattt, how do some games make melee combat feel so responsive then??

1 Like
#4

P2P networking, UDP packets. Latency is a lot lower if clients are communicating directly with each other, rather than all communicating to a central server, especially if the players are near each other. And UDP packets don’t have any resend mechanism, because they don’t try to preserve order. Lots of games will redundantly send packets too, if there is packet loss. Spamming packets is a thing, but not something Roblox does. RemoteEvents are TCP as far as I know, since order matters, and this is a lot slower than UDP and can block if packets are lost.

1 Like
#5

some udp related info, remote event might be TCP as there are spam checks and others but maybe u can abuse the replication system to deliver info thru udp

1 Like
#6

That post is interesting, but I feel like given the fact that we are right beside each other when the stunned animation is supposed to play, increasing the the speed of updates at a higher distance from the player prob wont effect it too much, unless I understood the post wrong.

#7

there are two ways to deal with this problem

the first is to do the simulation using fixed time. This is used in games like WoW for synchronization. There was a great article on this but I can’t find it.

The other way is to adapt your game to the technology (by the way this is a recommendation in Jesse Schell’s book “The Art of Game Design”.), which is what many games do. So the sword hits can be probabilistic instead of exact, that is, some of the hits will be normal, some critical and some missed. When an attacking player sees that his hit was successful, but the server finds that it was not because the other player was out of range, the hit would be considered a miss. Or things like that.

4 Likes
#8

So, UDP packets are packets that go from player-to-player? But what about the animation delay between when it plays on the one client to the other, shouldn’t that be UDP?

(talking about the stun animation in the vid)

#9

Hm, have you tried using attributes and then having the client read the attributes of the player they just hit? Of course latency will always be in an online setting but earlier today I had this UI that would invoke the server to check if an event was in progress and there noticable delay and all I was checking for was a if it was true or false and I was in a server by myself… anyway I think if you have the clients read data that the server has set your system will be much more responsive

1 Like
#10

Thats not a bad idea, I guess my issue is more so with the client-to-client replication though, my server-client and vice versa doesn’t actually have a delay, its the replication of the stun animation from the hit players client to the “hitter’s” client that has a delay, although I’m currently trying to implement a variant of @lumizk 's solution by:

  1. Changing the stun animation priority to movement
  2. Upon the server receiving the list with characters who’ve been hit, I immediately tell the hit character’s client that they have been hit
  3. Then, client-side, I check if they are blocking, if they are, I don’t actually stun them, if they aren’t I continue with the stun

Ill update this post if that works, as well as granting @lumizk the solution!

1 Like
#11

i don’t think there is any client to client in roblox, it might be client to server thru UDP and vice versa, which has lower latency due to being connectionless, I don’t think Roblox uses P2P as that’s not safe for the players

#12

Ohhh yes you’re right, does that have something to do w/filtering enabled?

#13

no, p2p means u send to that person, that involves u sending data directly to him, which means he can track ur ip

1 Like
#14

ah okay yeah I can see the insecurity with that.

#15

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