this post was submitted on 18 Dec 2024
79 points (98.8% liked)
PC Gaming
8768 readers
218 users here now
For PC gaming news and discussion. PCGamingWiki
Rules:
- Be Respectful.
- No Spam or Porn.
- No Advertising.
- No Memes.
- No Tech Support.
- No questions about buying/building computers.
- No game suggestions, friend requests, surveys, or begging.
- No Let's Plays, streams, highlight reels/montages, random videos or shorts.
- No off-topic posts/comments, within reason.
- Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Excellent defense: "You sent me the packets revealing where all the other players were. If you didn't want me to know they were behind walls why did you tell me precisely where they were?"
Yeah, doing such checks on the server side of things is more computationally intensive but it would solve that problem entirely and you wouldn't need client-side anti-cheat bullshit anymore.
The first rule of network programming is never trust the client. How does anti-cheat software work? By trusting the client.
It is impossible to do these types of checks on serverside. Your PC needs to know where to render the enemy character ahead of time, otherwise they'll pop into existence after you are dead. Bonus points for packet loss. Programming games isn't the same as validating input from some rando trying to log in on a site, it's an unsolved problem that all games have an issue with - from FPS like CS, RTS like Starcraft 2, to mobas like League.
If the client can make a determination as to whether or not to draw a player the server can too (and refuse to send those packets). It's not impossible, just more computationally intensive and thus, more expensive (on the server side of things).
Naive way: Render exactly what the player will see on the server. Do this for every client and only send the data to the client if the another player enters the view.
More intelligent way: Keep track of the position and field of view of each player and do a single calculation to determine if that player can see another. If not, don't send the packets. It will require some predictions but that's no different than regular, modern game-specific network programming which already has to do that.
Servers these days have zillions of cores. It really isn't too much to ask to dedicate a thread per player to do this kind of thing. It just means that instead of one server being able to handle say, 500 simultaneous players you can only handle say, 100-250 (depending on the demands of your game).
If your players host their own servers then it's really no big deal at all! Plenty of cores for their personal matches with their friends or randos from the Internet. If you're a big company with a game like Fortnite then it's a huge burden compared to the low-effort system currently in place.