Comment by spookie | Hacker News Reader

Comment by spookie | Hacker News Reader

Parent Full thread

Server side check for what?

My dude, we are at the point where AI's are trained on images resembling the enemy player (you know the ones appearing on your screen, good luck not showing those) and a little programme rolls a mouse around and clicks heads.

We ONLY have this problem BECAUSE the game publishers want to OWN the server infrastructure themselves.

In the old days you had dedicated servers where one of the players, at least, had full control over that server. Any sus behaviour would be met with rods from god right into the cheater's home router location. I'm being really theatrical here but really this worked, and was sustainable. Mods were able to fight the criminals in their small servers. A distributed cyber police if you will.

Today, we rely on a singular company (the one who published or developed the game) to be able to automagically pinpoint sus behaviour across a million servers and NOT have collaterals.

We had the perfect scheme to handle them, we have just lost to greed. No amount of client or server side shenanigans will ever be enough to fight cheaters. You need actual humans in there.

Genuine question, why are people confused on what user input is here?

Suppose the game is a solo game primarily with additional multiplayer features. The agreement there is simply that they enter multiplayer with a valid game state (edit: you validate on join).

Upon entering multiplayer, monitoring begins. Player moves, is it valid? Player shoots gun. Is this valid? Ray cast reached target and does damage. Was that valid?

Did you track the player state during the replication streaming? If no, then there are user input validation gaps.

To be completely fair, most people aren't out writing their own game engine to account for this stuff and it's a lot of work to do that. None of the major game engines on the market do this.

In large database systems, log replication occurs all over the place and validation takes place (some systems better than others for sure). Difficult to implement, sure, but when you know, track, and monitor the state; you can validate and respond.

> Player moves, is it valid?

The problem isn't whether or not it's valid. It is whether or not it is a human doing it, or an aimbot. This isn't unique to games, websites/browsers do the same thing: scraper and other bots all give valid inputs, but not always human ones. That's why captchas exist, and those only detect "only-bots", not a bot assisted by a human or vice-versa.

> Ray cast reached target and does damage. Was that valid?

This one is very hard to replicate because of latency. By the time I see and shoot at an opponent at position A, on the server the opponent will be at position B. And on the opponent's computer, position C. In the time it takes for my packet to reach the server, the opponent is now at position D.

So my "shoot gun" network message not only has to include my current timestamp, but also my current position of the opponent. Because of latency, my opponent's position on my client wouldn't even be the last packet I got (A-1), but rather A-1 interpolated based on how long it took for the packet to reach my client. You have to trust the client on what it thinks is a valid position for the opponent, because no one wants to play a game where you can't hit the opponent. This leeway gives you a lot of room to fudge inputs.

These differing game states also leads to peaker's advantage in games.

Everything other than the isHuman part is absolutely detectable. It's just a matter of building a system for it.

The ability to detect isHuman just seems to be on chopping block as far as I can tell. There is little to no barrier remaining today to prevent people from leveraging AI to get around this entire problem. There's a few outlier solutions that work for now, but AI does two things really well given time: solving classification and regression problems.

What can still be done is maintaining short lived replication logs and pattern analysis in this space. There is no reason that a player's actions can't be logged, analyzed, and responded to. It doesn't even need to be real time, it can just be latent. The server doesn't need to rely on reported timestamps for the analysis part, because the server can use it's own timestamping upon arrival to at least see how far apart the order of operations occur.

I know it's not an easy problem space to be in, I don't envy it, but I can't agree with the sentiment that it's impossible knowing how these systems are already designed in larger engines.

> the server can use it's own timestamping upon arrival to at least see how far apart the order of operations occur.

The server's timestamp isn't going to be representative of the user's actual input when you're using UDP. Especially over consumer wifi which is hardly the most consistent network, but is still used by a majority.

It sure doesn't. Any reason you couldn't just slap a TCP connection on top of it to make your replication log for analysis though?

As I mentioned in my last comment, someone would need to design a system to better deal with this type of stuff. The way things are stem from decades of decisions made, starting with more design constraints than we have today.

TCP still doesn't solve timing of packets not matching the timing of the inputs because of jitter, retransmission, and other overheads. You would still have to rely on user client reported timestamps to tell how far apart actions are taking place.

Seems like a non issue to me, time is just relative. Analysis on receipt is still possible, because you can calculate latency.

I'd recommend checking out Leslie Lamport's work, you can probably derive some ideas. I'm not be prescriptive here because this isn't a space I plan to work in to solve problems since it's just games. Entertainment isn't really my thing, I tend to lean heavily into systems and security knowledge which has served me well broadly.

Reply on news.ycombinator.com