Cheaters shouldn't be the problem they are now.
All these talks about cheaters, here and on Youtube, make me think of one particular event.
Back in September, I had one match at low or med MMR where I've versed two cheater friends.
The first one.
The second one.
I was used to get cheaters in my Nurse or Huntress games because I was playing them adequately.
But my Blight was average at best. Getting two stains like these at once was a very bad surprise.
They are also the reason I don't do reports anymore : I've kept track of their Steam profile and they've never got a game ban. That's not really the point though.
The point is that the server should be able to detect an invalid move.
A survivor instantly going through the ground or to an point too far? Flagged!
I say survivor because of this match but it is obviously also true for killer.
The server knows the four perks of everyone, their cool-downs, their benefits. It should know at what speed someone is supposed to move. It should know when perk can or cannot be used.
That's one example of course.
With server-side validation, and ensuring moves for a character are only allowed from the computer/IP address of that player, the server can flag players who cheat. Maybe not all of them, but at least a chunk big enough that'd make it impractical for the majority of these natural-born losers.
I'm not even talking about getting collisions validation with the map because that would require for the server to load said map.
Just this, "simple" validation. That's all we need to get rid of them.
It's not rocker science either. "Everyone" who knows anything about how there thing works know that's the first line of defense. Anti-cheats like EAC or Vanguard only catch low hanging fruits.
P.S. I'm not a youtuber, that channel is only a dumping place for videos. There is nothing to see there.
Comments
-
its really not that easy considering just how many things would have to be taken into consideration.
They would have to look at every single perk, add ons, killers, etc. and go through all of them to see how they interact with each other. They would then have to revisit the thousands of lines of code every time a new chapter releases and how they interact with the already existing content. The game would then have to constantly run this code to do checks and make sure everything is in order, which would have a very big impact on performance.
1 -
It's not that difficult, actually, if done correctly. The server is already making similar checks every tick, just add a few conditions into the checking routine, like checking coordinates and velocity against limits. Other games do this, for example, there is a good reason why in Team Fortress 2, with their abundance of cheaters, such cheats as speedhacks and flying are completely impossible. Even Minecraft servers can detect speedhacks and flyhacks with trivial measures. It's hard to find a multiplayer game nowadays where speedhack is even possible because of how trivially it is fixed by the server-side validation, it's truly a mystery why DbD still allows this in 2024.
3 -
yep the biggest reason cheaters are so common is they have lots of power to do “fun” stuff. If cheating was regulated to just wallhacks people wouldn’t be able to make entire channels around cheating in dbd .
3 -
Something like a speedhacks can't really be checked because its still possible to run absurdly fast even in normal lobbies. You're essentially writing thousands of lines of code to take in consideration every single perk in the game. Doing some thing like: Oh this person is moving at 175%. Do they have Lithe? No. Do they have Balanced Landing? No. Do they have Sprint Burst? No. Do they have Smash Hit? Yes. But now theres still that 25%! Now they need to check what else is giving them speed, which can be something absurd like: Them ALSO having Background Player, but they're under the effects of Forced Hesitation and a Clown bottle, but they ALSO so happened to be under the effects of a Refined Serum.
"Oh well just add if they run fast for too long then obviously they're cheating!" Ok so lets say the person moved .2 seconds longer than normal. The server would not only have to check everything above (which btw is just 1 example, there are thousands other scenarios related to movement speed alone) but they would also have to check for latency. Since even tho they actually moved for 5 seconds, the server saw it as 5.2 seconds.
Then you have something like being out of bounds. Then you would have things like Billy, Demo or Victor who are able to cross certain barriers to be able to go out of bounds (which btw for the twins they would have to do an additional check since the person could of switched back to charlotte) and I don't think some one should be labelled as a hacker because they were able to surf off a funny shaped rock.
Its also funny how you mention Minecraft considering their own speed and fly hack detection is so heavily flawed. A server which is slightly underperforming can see some one moving faster than they actually are, same goes if the person themselves have a poor connection to the server. I've seen the message "You moved too quickly" (or something like that) too many times just because I went onto an EU server or a server was just having a bad day.
Is it possible to do something like this? Absolutely. But it was have to do ALL of these checks constantly for every little thing in this game every tick, and theres nothing that could kill this games performance more than that.2 -
Once again, it's not that difficult if done correctly. What you described, with checking every existing perk in the game, is the spaghetti way of doing it, that would be inefficient and error-prone. The correct way of doing it would be having a single value like "sprint speed", and having different perks change it on activation. Then the check would be just against this one value, and the check for having a specific perk would be needed only upon events of activation of those perks. That would be much simpler.
Once again, look at Team Fortress 2. It's ridden with sniper bots with spin-aimbots and the anti-cheat is virtually non-existent there, but yet none of those cheaters can ever use a speedhack. Even though game mechanics also allow different speed boosts for players with specific loadouts, the servers easily validate it, and no player can go faster than he should, even if the target speed is achievable by in-game means. Demoknight can't go with his charge-speed if he is not charging, and he can't charge when he shouldn't be able to. And no hacks can change that. Also, sniper bot can never do something like shooting rockets or any other weapon they don't have, but in DbD a Ghostface can fly to the sky and start shooting endless Huntress' hatchets (literally what one famous cheater is doing regularly).
Most of other multiplayer games do these trivial checks and make such cheats impossible to implement, even though all of them have some kind of speed-boost mechanics, different loadouts or perks. DbD is not that much deeper in this regard. The more probable reason is that the DbD code is so spaghettified that it's now impossible to change the core logic without breaking the whole thing apart.
2 -
Thats the thing tho, even if the server checks for a speed value, theres still sooo many modifiers, and this is for movement speed alone. It would still need to do these checks regularly and that would definitely have an impact on performance. Which I dont think our poor old gen friends can handle anymore.
I will admit though I am going off of my very limited experience with coding, so this may be a lot simpler than I think it is I just cant see how it can be with how many variables that need to be accounted for.
0 -
I'm not sure what you have in mind but the cost of such validation would be minimal. I'm talking a few cycles.
What? No, that's an horrible way to do it. (And now I understand why you think it's costly.)
The proper way to implement validation is using something akin to a state machine (multiple ones but the principle stands).
In essence there are a few very simple graphs created and each tick the position in the graph changes (usually to move back to the same node). There is never any question. Only limits known and updated quite trivially.
Yes, much better. And the best way to keep that "state" is to implement it as a (set of) state machine(s).
It shouldn't even take that long to implement. If I was doing it, I'd create an editor to create the representation of the perks so they don't have to do it "by hand". (So designers could do it instead of just "programmers")
0 -
There really arent, and "regularly" means each tick.
Still it's nothing. The most costly part computationally is computing the square of the speed. Everything else is additions, substractions and assignations.
0 -
I would like to see Behaviours Response to this thread. I’m curious to know their thoughts.
3 -
they need a paywall and better server sided checks. Seems like their last update had a security breach which is why there are so many cheaters .
0
