52
Delta Force devs say Desktop Linux support is 'not part of our agenda in the future'
(www.gamingonlinux.com)
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME
away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
WWW:
Discord:
IRC:
Matrix:
Telegram:
The whole "kernel anti-cheat" PC multiplayer thing is just an endless game of whack-a-mole that I don't want to get involved with. End of the day, PC hardware is open, and that's a big part of what's nice about it. With open hardware, though, comes the fact that you can change things, and one thing that people love using that ability to do is to cheat. And with multiplayer games, a cheater can ruin the game for a non-cheater. Trying to figure out some way to make an open PC be locked down is hard, unreliable, and ultimately just making the thing act like a bad console. If there's enough demand for it and money in it, a game developer can keep playing that whack-a-mole, but it's never something that can really be permanently fixed all that well.
Consoles are really good at blocking players from doing things that will make the playing field not level. They are in a good position to stop fiddling with memory, or modifying game binaries, or extracting information that should be hidden and showing it to the player. They can restrict people from getting a controller or a keyboard or a mouse or a fancier GPU or whatever that will give Player 1 a pay-to-win edge over Player 2. That's a desirable characteristic if you goal is to have players playing against each other on even footing.
I really think that the long-term, realistic route to deal with this is for PC games to shift towards single-player, or at least away from competitive multiplayer.
It used to be that PC multiplayer games were rare. There were two major changes after this that made PC multiplayer games a lot more viable:
The Internet came along. Now anyone can communicate with anyone in a very wide area cheaply.
People moved off POTS analog modems. This not only provided a lot more bandwidth, but slashed latency
a POTS modem inserted a bit over 100 ms of latency. A tenth of a second of latency at the hardware level was a serious issue for some genres, like first-person-shooter games, so getting rid of that solved a lot of problems.
Okay, great. That unleashed a flood of multiplayer games. And making a game multiplayer solves a lot of problems:
Writing good game AI that stays competitive against a human is hard. Humans are pretty good at that.
Humans are good at coordinating, so any cooperative games have humans doing well with humans.
Some people specifically want to play against other people, to spend time with them.
The problem is that I don't think that there is going to be any future big jump like that improving the multiplayer competitive situation. Those two big jumps are pretty much the end of the road in terms of making multiplayer significantly better. Maybe it's possible to see some minor gains via better predictive algorithms to shave off perceived latency, though I don't think that there is going to be game-changing stuff there. Maybe someone can improve on matchmaking. But I think that we've seen all the big improvements that are going to come.
And multiplayer comes with a host of problems that are very hard to fix:
By-and-large, realtime multiplayer games cannot be paused. There are a few exceptions, mostly for games with a small number of players. This is a real problem if you, say, have a kid and want to play a game and in the middle of it you hear something smash in the next room and the kid start screaming. Real life is not friendly to people requiring uninterrupted blocks of time.
People don't always do things that are fun for other people. Griefing, spawn-camping, cheating, whatever. Even minor stuff like breaking out of character making the game less-immersive. You can try to mitigate that with game design, but it's always going to be an issue. Human nature doesn't change: humans come firmly attached to human foibles.
Multiplayer games stop being playable at some point, when they no longer have enough players. Often before that, if they have centralized servers operated by the publisher
which is almost universally the case today
and the servers get shut down.
Even with modern networks, latency and flaky connectivity is a factor for real-time games. For people living in remote areas, it's particularly annoying.
For multiplayer competitive games, one can only win at some given rate; for a player to win against a human, that other player will lose. I'd wager that that rate is most-likely not the optimal rate for game enjoyment. If a player isn't competing against humans, that constraint on game designers goes away.
On the other hand, while it is hard to make sophisticated game AI, hard to make it as good as a human...there are also no real fundamental limits there. I am confident that while we are not there today, we can make an AGI comparable to a human, and that for the simpler problem of making game AI, it's possible to make much-less sophisticated AIs that solve many of the problems that humans do in games. That's expensive to do on a per-game basis -- game AI is hard -- but my guess is that most games have a fairly-similar set of problems to solve, that it's probably possible to abstract a lot of that, have "game AI engines" used in many games that solve a lot of those problems. We've done that with graphics engines and physics engines; there was a point where having the kind of graphics and physics that we do in many games was prohibitively expensive too, until we figured out how to reuse a lot of work from game to game. And improvements in that game AI is a ratchet: it's only going to get better, whereas human nature isn't going to change.
I'm not saying that multiplayer games are going to vanish tomorrow. But I think that the environment that we're going to see is going to differ from the one that we've seen from maybe the 1990s to the 2010s, where technological change specifically dramatically relatively improved the situation for multiplayer games
I think that there's going to be a continued trend towards the situation relatively-favoring single-player games.
A very basic rule in developing any app that has a server and a client is that you never trust the client. Never. What do game devs do? They trust the client and try to make it trustable. That will never work. The anti cheat should be on the server : a player flying would be very easy to detect. Don't send the position of every players to every players.
I do think there is quite an obvious solution that game developers dont yet realize.
The client is always compromised
Instead of relying on increasingly invasine client side anti cheat, with a zero trust mentality it doesn't matter how many cheats the client has installed.
Ofcourse this is't easy to do, but its the only thing that actually works, client side anti cheat will always be broken.
It would be interesting to see an FPS game with a "default cheat mode" that exposes all info about other players that it has by default. And then the devs work to minimize that... server-side occlusion, misdirection, reduced damage / bad aim when no direct line of sight, etc. Players can then learn to minimise their footprint despite the necessary leakage and how to take advantage of the info they get.
You can run an entirely-untrusted client, but that creates very substantial limitations. I'd go so far as to say that doing so rigorously makes most genres of multiplayer games impractical. Some examples:
If the client has no information about visibility of non-visible enemy players in a first-person shooter, it creates delay due to latency in an enemy becoming visible, collision detection issues, and so forth.
If all random number generation needs to happen server side, then the client not only can't be trusted to generate any important random numbers (probably avoided today for many games) but also cannot run an RNG with the same internal state as the server (else a client could "peek ahead" to see the future). As a result, every action that involves randomness requires a server round trip and a sluggish response until a player can see the outcome.
On any network without guaranteed minimum bandwidth and guaranteed maximum latency (which is generally not the case for the Internet today), a client can not send packets and pretend that the network just dropped them. There, either one has to seriously restrict predictive movement or one can pull stunts like briefly disabling packet transmission and "teleporting" across dangerous areas, preventing an enemy from taking a shot at one.
All hidden information in a game that a client could expose to a player must be exposed to maintain a level playing field. Even stuff that isn't even specially available to only a client. So, say players figure out that Monster X in an MMO has a respawn timer that causes it to respawn at time T, and someone can modify the client to indicate the remaining time with a timer. For a level playing field, that feature has to be built into the base client for all players, immersion-breaking or no.
Any large amount of state on the client probably has to also be exposed to the player, because transmitting it over the network in real time isn't practical due to bandwidth constraints. So players have to all have minimaps with no obscured terrain, because their client has map files with the geometry. They need to be able to see at least terrain through walls, because their client has that information. Maybe you could try to hide map data in encrypted chunks the very first time through, but that's going to lead to performance issues and also the next issue if maps are the same across multiple players (almost certainly yes):
Any information that another player's client has should also be available, as players can have clients that collude. So if any other player can see an enemy player, then since their client could tell you about them, the vanilla client must have a wallhack showing any enemy visible to any other player to keep level footing.
Almost all simple mechanical operations (e.g. responding quickly to counter an enemy action) must be automated or removed from the game, because otherwise someone could modify their client to do this instantly in response to an enemy action and gain an edge. Dodging needs to be totally automated or gone, for example. The only player actions that can remain are those that require human-level reasoning, where the client can't play better in some respect than the human using "bot"-like code. Relying on reflexes or having a player managing load from having to deal with many simple things at once can't be in the game. Aimbots have to be in the base client for first-person shooters.
For something like turn-based card games, yeah, it's possible to create games where the client is completely nontrusted. There are no real time constraints, and you can deal with the client (or server) gaming the RNG via mental poker techniques. Keep in mind that even there, the client might be doing things like running probability calculations and telling a player the mathematically-optimal card to play in many cases. Poker would basically be reduced to trying to detect player tells, because playing poker optimally outside of that was solved by von Neumann, and the client could probably tabulate data on other players, like speed of response, to try to help a player identify tells.
But for most real-time games, providing an experience comparable to the current one is probably going to require some level of client trust. Maybe one can achieve the lesser goal of reducing one's trust a bit, make it harder to cheat, but a true zero-trust real-time game has to have a great many very serious limitations placed on it.
I do think some of these limitations can be resolved. But it indeed poses a big challenge. You can go to big lenghts with server occlusion checking to prevent wall hacks but under zero trust any game with directional sound already has build in wallhacks.
I mostly speak from experience with my developing my own game which is not an FPS. Previously the client would send "i build on this position". Which could very easily be abused. Which I then changed to "i build with this angle and this distance from the previous node" the client would then already show the newly constructed "ghost" node while the server would check if that construction is valid and then send the real position to all clients. The only thing a player would notice is that with high ping the constructed node would move slightly as it got the definitive position from the server. While being significantly more cheater proof.
I suppose im biased towards this kind of thinking since im not working on a FPS game, what for me might be a simple change is a massive undertaking for other genres.
Yeah, if you had proper account security and server side checks, a bunch of cheats would be easily detectable. If someone cheats, ban them, and eventually you'll clean out the user base.
Some stuff would be harder to detect, but the blatant BS you see in GTA Online wouldn't be possible.