5 ms·

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 agree

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.

ThatPlayer 1y ago
> 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.
- SamInTheShell 1y ago
  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.
  - ThatPlayer 1y ago
    > 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.
    - SamInTheShell 1y ago
      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.
      - ThatPlayer 1y ago
        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.

ThatPlayer 1y ago

> 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.

SamInTheShell 1y ago
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.
- ThatPlayer 1y ago
  > 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.
  - SamInTheShell 1y ago
    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.
    - ThatPlayer 1y ago
      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.