FTS netcode in DBD
The recent changes over to a dedicated server framework have highlighted some issues with the net code. Whilst the dedicated servers have (mostly) resolved issues with terrible hosts, they have also increased the average delay between the killer and survivor POV. A result of this is in indirect nerf to certain skills that require pristine timing based upon a killers actions. Dead hard is the cleanest example, and the one I will be using, but this can apply to other abilities and perks as well.
Currently (and this knowledge is from experimentation, not back-end knowledge) the game seems to favor whichever action made it to the server first. Intuitively, this seems like a fair way to handle actions. Take the following example: A killer swings, and a player presses dead-hard to attempt to avoid the swing. Currently, if the killers swing registers with the server prior to the player's dead-hard, the player will take a hit.
This solution presents a couple of problems. First off, the priority decision is not based upon who acted first, rather which action reached the server first. This means the somebody with a lower latency to the server (lower ping) automatically gets a headstart in determining the winner. This is somewhat unavoidable and is a byproduct of how online gaming functions, but it can be mitigated (and I will show how later). Second, this results in a player "feeling bad". In shooters, people hate the feeling of being shot after moving into cover, or feeling like a death was a result of a laggy player. This applied to DBD as well. When a survivor dead-hards (and receives client feedback, something I will touch) but still gets hit, they feel as though their "skill" at the game is being undermined.
In Overwatch, the backend uses what's called "favor the shooter (FTS). In general, this means that the system will prefer the shooters side of the network story. It's possible DBD already uses a system like this, but i don't have access to that information. Regardless, Overwatch also gives certain skills "priority" over the FTS code. This, in essence, is what I believe can help out DBD immensely. The idea is to handpick certain skills that supersede the FTS (or server-first) code.
To go back to the Dead-Hard example, lets go in depth to how the play might emerge if Dead-Hard had priority over the system. Player A, killer, swings at Player B. B, noticing the first couple of frames of the swing, Dead-Hards. In the current system, it is extremely unlikely for Player B's Dead Hard to reach the server before the killers swing does (or the swing is preferred, again I'm unsure but it's ultimately irrelevant.). However, if Dead-Hard is a priority skill, then the killers swing will connect, but the server will wait around the duration of the current ping time from B (obviously with the cap). The idea is to give B 40~ MS to send back a "priority" skill packet, and if he does the server then interprets that (correctly) as the player having reacted to the swing, and lets him dodge the hit accordingly.
This isn't without its downsides. This does have the effect of "buffing" Dead-Hard in the hands of high-skill players. I do believe that core game play like this should be created, and then balance should be done around it, but it's worth mentioning. It also does result in a smaller, but still existing, "feel bad" for the killer. This however can be mitigated with client feedback, which brings us to my last point.
Currently, there is very obviously certain UI elements that trigger on the client end, and others that trigger off a server response. In Dead-Hards case, the skill usage and exhaustion pop-up will both appear in the bottom left of the screen for the client regardless if the skill was actually "used" in the servers mind. This is easily reproducible, and notably separate from the exhaustion timer in the bottom right of the screen. Regardless of whether the netcode changes are made, a simple way to "trick" players into feeling like they just mis-timed their dead-hard is to remove the very obvious client feedback that the skill went off without the server sending it out. Currently, a player can see that their client did infact register the dead-hard in time, but the server is saying "nope!".
On the killers end, changes only need to be made if the netcode changes are implemented. Their's is a little more difficult, but still doable. The best idea I have is for the players dead-hard to appear "shorter". The idea is that while the killer will swing and it will look like a clean hit, they will very shortly see a "short" dead-hard that catches the player up to the current position. This is the part I am least confident in, as I don't know the inner workings of DBD's interpol or anything like that, so I can't comment too much on solutions.
I didn't explicitly state this, but this can also function for pallets as well. However, I think the merits of giving pallet stuns priority is a much higher game-balance issue than skills, as pallets get used much more frequently. It's possible that simply increasing the amount of "trades (killer hits and gets stuns) is sufficient, but I don't have the metrics or info to make that decision.
Comments
Yes please. People when people asked for dedicated servers they assumed their would also be netcode that makes mechanics and abilities seem like they should from a feedback perspective. As it is right now, their netcode has worsened existing problems.
What if it's garbage tickrate budget servers? Wouldn't that make some hits connect when they shouldn't and other time just not register at all?
Tickrate in this instance doesn't change anything about the discussion. Yes, a higher tick rate would result in slightly smoother game play between players. But, that's an economic choice for the developers, and i highly doubt it's really worth the increase in server overhead to increase the rate. If anything, at a lower tickrate these kind of fixes are more important as their entire purpose is to smooth over the issues caused by networking.