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.
Why impossible? Server-authoritative programming is common in PVP gaming, even high-performance recent games. I don’t think anyone is suggesting lazily loading chunks of player data like wandering into a new chunk in Minecraft. Just write efficient, clean code that anonymizes or encrypts player data so it can’t be read client-side.
The issue here was that fortnite broadcasts locations of enemy players in packet data, not that it trusts clients “with anything”… where did you get that from?
That’s an excellent issue for you to research on your own time! If you know anyone on the OverWatch development team you could ask for their input as well. Please report back to this thread with your findings, we’re all very interested in the results.
Work arounds are for devs to solve, not schmucks on lemmy. CS:GO used to use something similar to occlusion culling to prevent this exact problem. Don’t send the client all of the enemy locations/data unless the client is within roughly the right distance/sight to see that enemy. This is not a full fix, but dramatically nerfs wall hacking.
I’ve seen community plugins for TF2 and other source engine games that will add “ghost” players. Generate ai characters, turn them invisible, and send their data to clients. If someone keeps shooting at the ghosts, they can easily get caught and banned.
There are entire industries dedicated to finding solutions to this problem, check out this research paper about this exact subject if you want.
It is impossible to do these types of checks on serverside.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
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.)
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.
Why impossible? Server-authoritative programming is common in PVP gaming, even high-performance recent games. I don’t think anyone is suggesting lazily loading chunks of player data like wandering into a new chunk in Minecraft. Just write efficient, clean code that anonymizes or encrypts player data so it can’t be read client-side.
Show me one multiplayer fps that does not trust the client with anything.
The issue here was that fortnite broadcasts locations of enemy players in packet data, not that it trusts clients “with anything”… where did you get that from?
how else should it inform the client of enemy players
That’s an excellent issue for you to research on your own time! If you know anyone on the OverWatch development team you could ask for their input as well. Please report back to this thread with your findings, we’re all very interested in the results.
awful
Sorry to hear that. Best of luck with your future projects though.
be nicer to people
Work arounds are for devs to solve, not schmucks on lemmy. CS:GO used to use something similar to occlusion culling to prevent this exact problem. Don’t send the client all of the enemy locations/data unless the client is within roughly the right distance/sight to see that enemy. This is not a full fix, but dramatically nerfs wall hacking.
I’ve seen community plugins for TF2 and other source engine games that will add “ghost” players. Generate ai characters, turn them invisible, and send their data to clients. If someone keeps shooting at the ghosts, they can easily get caught and banned.
There are entire industries dedicated to finding solutions to this problem, check out this research paper about this exact subject if you want.
Okay, now the player data is encrypted and unreadable by clients.
How will the client display where the players are without data…
Why are you bothering to spend cycles sending this useless, encrypted data…
If you mean to decrypt the player data once it reaches the client, then you have solved no issues…
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.
Immortal gates of pyre does it, and it’s just sc2 but better.