Support us on Patreon
PayPalOne of the big topics of discourse in the Linux gaming sphere recently has been Tim Sweeney's statement on porting Fortnite to the Steam Deck, where Sweeney argues that Linux would be too difficult of a target and the market not big enough to warrant the amount of resources it would take to bring all of Fortnite on the platform.
The central crux of the issue, from Sweeney's point of view, is that making Easy Anti-Cheat, with all of its capabilities, run on Steam Deck (and thus on Linux) would be extremely difficult. He argues, that for a game of Fortnite's size this would open the flood-gates to significant influx of cheaters.
There have been some responses to this from the Linux side, with some accusing Sweeney of exaggerating the difficulty of such a port or that his statements are conflicting, because he simultaneously believes the Linux market is too small to be worthwhile but also would provide a way for too many cheaters. I will address some of these aspects a bit later, but for now let's focus on the main technical blocker, which is Easy Anti-Cheat.
Easy Anti-Cheat, or EAC, is an anti-cheat solution which apparently comes in a few configurations. We know that it can be run in a configuration where it is compatible with Linux/Proton apparently with just a relatively simple toggle. However, this mode of operation is seemingly a comparatively high-trust configuration, where only part of the anti-tampering protections of EAC are active. This may prevent some cheats but fail to detect others, which can be perfectly reasonable for games, where the number of cheaters and potential cheaters are fairly low or other systems complement the anti-cheat solution. There are plenty of games, even some popular free-to-play titles, which at best have this level of anti-tamper protection and they don't seem to have a major cheating epidemic, so clearly in many cases this should be enough. We also don't know the scope of cheats that are detected by EAC in this configuration, so this system by itself may already be fairly comprehensive.
EAC also contains a kernel-level component, which on Windows is installed as a kernel driver. This allows EAC code to run at a very privileged level and inspect essentially any and all parts of the system in order to detect tampering. This provides a very broad level of monitoring, which is also harder to bypass. Based on Sweeney's comments, this is the mode of operation used by Fortnite. It is also a mode of operation that is technically incompatible with the Linux way of doing things.
In Linux, the standard way of delivering drivers is by submitting the driver into the kernel source code tree, which naturally requires that the driver be open source. Most drivers are delivered this way, where the driver gets tightly integrated into the kernel and the drivers are updated when the kernel is updated. There are of course some notable exceptions to this rule, the largest of which is the Nvidia driver. The Nvidia driver is instead loaded as a separate kernel module, which allows Nvidia to keep its source code hidden, but also allows the driver to be updated separately from the kernel. So, EAC could surely use this approach as well, right?
The separate kernel module approach comes with some gotchas. Firstly, the kernel is licensed under GPLv2 and many of the parts in the kernel require the calling code to also be GPLv2 due to the "viral" quality of GPL. This means that, legally speaking, if Epic were to turn EAC into a kernel module and started poking around the kernel APIs, they'd have to open source EAC or they'd be in a legal grey area. The first approach is obviously not possible due to their business model and the second is at least not a great look.
Another problem with separate kernel modules is that the Linux kernel only guarantees a stable user-facing interface. This means that almost anything is allowed to change inside the kernel as long as user-level programs continue functioning. This is also the reason why sometimes the Nvidia driver stops working when you upgrade from one kernel to the next without installing an up-to-date Nvidia driver as well. So, when Sweeney is complaining about the multitude of kernel configurations, he's not wrong. EAC would need to maintain a compatibility shim similar to that of the Nvidia driver, which ensures that the EAC kernel module functions with each kernel version out there. Every time the kernel updates, an EAC engineer would need to go over the changes and update the compatibility shim every time there's a breaking change while still maintaining the compatibility with older kernel versions.
Theoretically you could overcome this problem somewhat by only targeting the Steam Deck and its SteamOS. This would give you a single kernel version to target, although Epic would need to negotiate with Valve in order to ensure their driver is somehow shipped with SteamOS.
But the problems don't end there. Since Linux is a fully open platform, there is technically nothing that would prevent a determined cheater from cracking open the Linux source code and making some tactical changes to how the kernel behaves, building the kernel and then making the EAC kernel module blind. On Windows the EAC developers can assume that the black box that is the NT kernel is at least somewhat difficult to modify by users. This means that in kernel-space they can assume some level of security through obscurity. On Linux this assumption does not hold. The only way for Epic to overcome that problem would be to negotiate with Valve to lock down the Steam Deck, which Valve has already decided not to do.
So, from EAC's point of view the Linux platform can never be quite fully trusted, which is entirely fair, because from the user's point of view EAC can never be quite fully trusted.
But surely Epic could still somehow bring Fortnite to the Steam Deck, right? Surely they could ship a version of Fortnite without the kernel-level component, right?
That they could, which brings us to the points about market share and the viability of cheating. Sweeney argues that the Linux market is too small, which initially sounds a bit odd because he then goes on to worry about the large numbers of cheaters. The kicker is here that the small Linux market doesn't necessarily guarantee a low number of cheaters. If it turns out that certain cheats are possible via a Linux version of Fortnite, this will attract some cheaters to use the platform in order to bypass EAC. It won't be all of the cheaters, many casual cheaters would likely not bother to learn Linux in order to cheat in a video game, but there is no doubt a group of cheaters that would take the opportunity. So, Fortnite would see some increase in cheating, but without good data it is hard to determine how big that effect would be. However, considering the popularity and free-to-play nature of Fortnite, it could very well be that it would be an attractive enough target for cheaters to attack even if there is a slightly higher initial investment. Cheat makers on the other hand would probably eventually find ways to package their offerings in an accessible enough format, like boot-to-cheat USBs or pre-configured VM images.
Some solutions to this problem have been proposed. For example, they could silo Steam Deck/Linux users in such a way that they will never come into contact with the rest of the playerbase. This would contain cheating, but it's also a hard-handed measure that would likely be unpopular. It would also require some amount of work to accomplish and I think it's fair for Epic to discount options that would cause extra work on them.
So, what's the solution to the problem? Here's the thing: I don't think there is one. My personal opinion is that client-side anti-cheat is fundamentally limited and taking it into the kernel is a bandaid that comes with excessive cost and is simply incompatible with the Linux platform. So, as long as Epic insists on maintaining its current anti-cheat approach with Fortnite, I just don't think there's going to be Fortnite on Linux.
And that doesn't mean Tim Sweeney is wrong or lying about the difficulties of adapting that approach to Linux. It just means that a new or different approach is needed in the future.
Article taken from GamingOnLinux.com.
For someone who pretends to be doing stuff "for the good of the industry", SweeneySomehow I suddenly can't get out of my mind the Joker's laugh from shortly before he makes the pencil disappear.
Something like that could work for players who get automatically flagged or voted as possibly cheating. Modern, multiplayer shooters have some pretty detailed player statistics. You could use those, maybe add player's camera angle and how much of the target's hit box was even visible, to form an algorithm to detect anomalies.
Sure takes the fun out of game development, huh? Well, it could still be handled by a 3rd party in the form of licensed software you package into the game or your game servers and feed its API data from your game. It's all behind the scenes to the player and will work on any operating system that the game's engine works. The game dev has to put some effort into implementation but doesn't have to "recreate the wheel" every new game.
Last edited by 14 on 12 February 2022 at 5:00 pm UTC
slaapliedje Feb 13, 2022
The whole thing was about Epic wanting to be able to have their own store within the game that didn't use Apple's payment methods (thereby skipping giving Apple a cut).For someone who pretends to be doing stuff "for the good of the industry", Sweeney is displaying a remarkably short-sighted stance.Sweeney couldn't care less about the industry, he sued Apple because they are a bunch of whiners. Apple ofc did the right thing, any app that wants to take control of your wallet looks SUS to me. He is just a Tencent puppet and he'll do the Tencent "dance" or anything they'll ask. At this point if you consider Sweeney as someone "neutral" and with "fair" opinions, I'm sorry to tell you, but, unfortunately you are being played. He is just a snake oil salesman and a puppet, the opposite of being independent (like ie an indie dev).
I am on the fence about this, as for one it is about two greedy bullies trying to figure out who should get all of the kids lunch money they are picking on. Think of Apple as the mob racket, and Epic wanting to move into their territory without paying their cut on the new 'service' they provide.
There is a solution to this Fortnite business... Valve should work on a better game! Guaranteed if something similar enough, but better comes along, Fortnite will be left in the dust, and 20 years from now when the kids that enjoy it get nostalgic, they will have recreated server side software to be able to play it themselves.
Last edited by slaapliedje on 13 February 2022 at 10:38 am UTC
source:
Anti-Cheat for Multiplayer Games
https://youtu.be/hI7V60r7Jco
time: 12:40
this was before they were acquired by Epic.
There is a solution to this Fortnite business... Valve should work on a better game! Guaranteed if something similar enough, but better comes along, Fortnite will be left in the dust, and 20 years from now when the kids that enjoy it get nostalgic, they will have recreated server side software to be able to play it themselves.I don't feel like Valve has enough developers to create a wildly popular game. CS:GO and Dota 2 have been going strong a long time and have "production mode" dev teams. Half-Life: Alyx was a good step for the gaming industry, but a little niche and experimental as far as the market goes (VR only). So I don't think they even have a desire to compete with a game like Fortnite and PUBG. Do I think a Dota 2 world of characters in a first-person or third-person battle royale setting could be fun? Yes! Would it feel great if it was built with Source engine? No! It would feel stiff and old. Also, Valve already has a black spot on its record with the poor reception of Artifact; if their next game isn't great, their game invention and credibility will majorly tank if they have two bad eggs in a row. Come to think of it, weren't both Counter-Strike and Dota 2 rip-offs of other games (or mods) at the time? Maybe Half-Life is their only glorious original creation. Portal is amazing, although, IIRC, they hired on someone who made the concept of the game, so that was an acquired creation.
I'll stop my drabble. Anyway, I would be very surprised if Valve tried to compete with Fortnite.
Android is moving towards hardware-based attestation, which means that Magisk will come to an end eventually, regardless.that probably can be easily bypassed with MagisK. There's actually nothing preventing me from patching my own kernel and building a custom rom image, with a patched kernel to run on my android device (and running fortnite with full customized kernel). I don't see that being any different from Linux distros, It might be a little more complicated to setup and compile, than lets say installing xanmod or liquorix kernel, but it's totally doable.what I don't get about this whole article... is how does the heck Fortnite for Android works? and I think there's enough android "distros" out there, that have plenty of different kernels. Did google let them run a proprietary module on their kernels?
I'm sorry if my question is too stupid I simply ignore this.
They will detect if you are running with root, or running with an unlocked bootloader, or try to see if you're running a custom ROM and block those things.
Anyway... I think that clearly, they are not relying on a kernel module on android, so all this about GPL incompatibilities with EAC and the kernel is all nonsense.
Besides let's not make it about Linux only tho... I think that probably Apple wouldn't allow a kernel module for anticheat on their kernel, for the obvious security reasons.
In my opinion...this is not about Linux only, Google banned fortnite from their play store, Apple did likewise. So maybe the problem is Epic here. Maybe their app wants unlimited trust, their app needs more permissions and priviliges, than anything out there, so it's getting banned, for security reasons.
And Sweeney is so blinded with greed, that cannot see the Elephant in the room here.
The reason why this practice of kernel-based anti-cheat is ok on desktop but not on mobile is because the OS vendors (Google and Apple, respectively) do not allow it.
The desktop security model however, is so broken that nobody even cares anymore.
The standard way to combat this in a normal TPM / remote attestation scenario is to encrypt the communication with a key where only the TPM has the private key to decrypt it. So only the trusted non-manipulated software can read the communicated data. However, routing FPS gaming network traffic through a TPM admittedly is prohibitive ;)Doesn't matter, the private key has to get there somehow. And how would you verify server-side that the client uses a specific individual TPM? The client could just lie to the server and then reroute the attestation request again.
Like I said, hardware-based attestation does not fix the idiotic idea of trusting the client, and neither was it intended for that to begin with.
If your security model involves placing trust onto the client in any shape or form, then it is deeply flawed, period.
Cyba.Cowboy Feb 16, 2022
Correct me if I am wrong, but I would imagine that this would be easier to maintain and it would be far more difficult for potential cheaters to bypass...
Couldn't they just implement anti-cheat software on the server instead?
Correct me if I am wrong, but I would imagine that this would be easier to maintain and it would be far more difficult for potential cheaters to bypass...
If we could, we would. There is a server side component of course, but it is more reactive than preventive. You cannot pipe everything through the server in a fast paced game, e.g. you cannot control mouselook from the server (to prevent aimhacks), or moving the mouse would feel terribly laggy. Same thing with wallhacks because at least some object culling needs to happen on the client otherwise quick strafing left-right next to a wall (or a door) would result in players popping-in late. The devil is in the details like this.
Couldn't they just implement anti-cheat software on the server instead?
Correct me if I am wrong, but I would imagine that this would be easier to maintain and it would be far more difficult for potential cheaters to bypass...
They could. But it's equivalent to investing into sophisticated enough AI. They don't want to spend on it. It's cheaper to push spyware junk on the user.
Last edited by Shmerl on 16 February 2022 at 11:32 pm UTC
But it is more reactive than preventive.
No one said you need to have a preventive anti-cheat. Or to put it differently, the elephant in the room is that you don't need it to make the game good enough. But good reactive anti-cheat is a hard and expensive problem to solve. Not impossible.
Last edited by Shmerl on 16 February 2022 at 11:34 pm UTC
Cyba.Cowboy Feb 17, 2022
with everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.
Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?
Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.
Think you've just shot your own argument in the foot there.
It's a given than 99% of cheaters have no clue on how to write a cheat let alone a kernel driver on windows, Which also would be true for Linux side or the deck.
So the entire premise fails as a result of that theory.
The simple fat is that he has no intention of allowing fortnite on the deck. Am sure if the deck had been produced by say Samsung it wouldn't have been an issue.
with everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.
Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?
Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.
From everything I've read, they do try to prevent custom ROMs from playing the game. Even when those Custom ROMs do get it running, they have to have root disabled, play services must be installed, and safetynet must pass its checks, among other things.
So, it still requires a fairly locked down Android OS to run the game.
So in other words, they manage to implement some safeguards even when run under the evil Linux kernel :-)
Exactly. They just don't want it (Fortnite: Battle Royale) to run on their direct competitor's platform (i.e. the Steam Deck)…
with everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.
Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?
Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.
Think you've just shot your own argument in the foot there.
It's a given than 99% of cheaters have no clue on how to write a cheat let alone a kernel driver on windows, Which also would be true for Linux side or the deck.
So the entire premise fails as a result of that theory.
The simple fat is that he has no intention of allowing fortnite on the deck. Am sure if the deck had been produced by say Samsung it wouldn't have been an issue.
There is one solution: ship a cloud version of fortnite. Not the best solution but depending on how it is implemented could work.
Several games on the Nintendo switch are cloud based like Control and Kingdom Hearts. There are companies that port your game to the cloud.
Not the best solution, still a solution.
Cloud gaming requires a pretty robust internet connection, though (significantly more internets than you need to simply connect a locally installed game to a server). But given that Fortnite already is (was?) available on mobile platforms, I guess Epic is not particularly worried about delivering a suboptimal experience for their very popular digital clothing store for ten year olds.
To all people saying that not trusting the client or moving the game to the cloud is the solution - you seem to ignore the existence of network latency.
False.
Gforcenow latency is pretty fine on LOL, GW2 and BDO which are the competitive games I've played. I can assume other gaming clouds to have similar results. And I'm not a resident of a first world country by any means.
Those calling for Fortnite: Battle Royale to run "out of the cloud" have obviously never been to Australia... Australia's "high-quality" broadband struggles with Fortnite; Battle Royale in its current form; I'd hate to see how bad the experience would be if the entire game was run "out of the cloud". 🙄
what I don't get about this whole article... is how does the heck Fortnite for Android works? and I think there's enough android "distros" out there, that have plenty of different kernels. Did google let them run a proprietary module on their kernels?
I'm sorry if my question is too stupid I simply ignore this.
They will detect if you are running with root, or running with an unlocked bootloader, or try to see if you're running a custom ROM and block those things.
The whole thing was about Epic wanting to be able to have their own store within the game that didn't use Apple's payment methods (thereby skipping giving Apple a cut).For someone who pretends to be doing stuff "for the good of the industry", Sweeney is displaying a remarkably short-sighted stance.Sweeney couldn't care less about the industry, he sued Apple because they are a bunch of whiners. Apple ofc did the right thing, any app that wants to take control of your wallet looks SUS to me. He is just a Tencent puppet and he'll do the Tencent "dance" or anything they'll ask. At this point if you consider Sweeney as someone "neutral" and with "fair" opinions, I'm sorry to tell you, but, unfortunately you are being played. He is just a snake oil salesman and a puppet, the opposite of being independent (like ie an indie dev).
I am on the fence about this, as for one it is about two greedy bullies trying to figure out who should get all of the kids lunch money they are picking on. Think of Apple as the mob racket, and Epic wanting to move into their territory without paying their cut on the new 'service' they provide.
There is a solution to this Fortnite business... Valve should work on a better game! Guaranteed if something similar enough, but better comes along, Fortnite will be left in the dust, and 20 years from now when the kids that enjoy it get nostalgic, they will have recreated server side software to be able to play it themselves.
This is what I would like to see...
Believe it or not, I only started playing Fortnite: Battle Royale late last year ('The Last of Us: Factions MP' is usually my go-to multiplayer game) and it is primarily these three things which appeal to me in the game:
* The "battle royale" concept (start with "x" players and no weapons, scavenge for weapons and fight your way down the the last player), which I've never seen in a game before;
* The expansive maps, which change every couple of months to offer new challenges / content / quests;
* The difficulty of the game, which seems to be "just right" (not too easy, not too difficult), so that one can play and not always win or lose (in comparison, I find that most other multiplayer games are usually either too easy or too difficult).
These are things that could easily be implemented in another game, so an alternative to Fortnite: Battle Royale is not entirely out of the question... Who is up to the challenge, and wants to get a head-start on the Steam Deck?
Couldn't they just implement anti-cheat software on the server instead?
Correct me if I am wrong, but I would imagine that this would be easier to maintain and it would be far more difficult for potential cheaters to bypass...
They could. But it's equivalent to investing into sophisticated enough AI. They don't want to spend on it. It's cheaper to push spyware junk on the user.
Ah, so the real reason Fortnite: Battle Royale won’t come to the Steam Deck anytime soon is because Epic Games is to cheap and lazy to implement server-based anti-cheat stuff?
Got it.
But it is more reactive than preventive.
No one said you need to have a preventive anti-cheat. Or to put it differently, the elephant in the room is that you don't need it to make the game good enough. But good reactive anti-cheat is a hard and expensive problem to solve. Not impossible.
Well a Steam Deck would be tied to a particular ‘Steam’ account and presumably there’s some sort of hardware identifier (a serial number or something) that’s sent to Valve Software’s servers or is readable by software running on the Steam Deck… So just ban those ‘Steam’ accounts and / or identifiers that are known to be cheating.
Even if server-based anti-cheat software was reactive rather than preventive, this’d be a possible solution.
What I don’t understand, is how there are so many online games throughout the world – including for many, many Linux-based operating systems – that operate their own, respective solutions to prevent cheating… Yet Epic Games is adamant that there is absolute no possible way they could do the same?
As has been pointed out by loads of people, this says an awful lot about their anti-cheat solution and I think the real question is (albeit off-topic), is why would a developer even want to consider their anti-cheat solution now that we know how inadequate it is?
No one said you need to have a preventive anti-cheat.
This is a rather bold statement to make, without having the data or likely even an idea about the health of the game. I don't know what grounds you have to state this, but I trust people in the trenches whose full time job is fighting cheaters, and they say otherwise. If you have relevant experience in the area, you're welcome to apply and join the anti-cheat team...
Or to put it differently, the elephant in the room is that you don't need it to make the game good enough. But good reactive anti-cheat is a hard and expensive problem to solve. Not impossible.
As I said before, there is a server-side anti-cheat and it works in conjunction with the client-side one. Contrary to what is assumed here in the thread, the client isn't absolutely trusted. However, limiting the attack surface is essential to keep the scale of issues small.
What I don’t understand, is how there are so many online games throughout the world – including for many, many Linux-based operating systems – that operate their own, respective solutions to prevent cheating… Yet Epic Games is adamant that there is absolute no possible way they could do the same?
There are multiple possible explanations for this. First, the games vary wildly in their player base. Cheaters tend to attack popular games where they can make money selling the hacks, if the market for the hacks is small they won't care about the game. Game distribution model matters a lot, too, if the game is behind a paywall, it makes cheating naturally more expensive than when it's free to play. Last but not least, Fortnite security is one of the best in class, as exemplified by statements like these:
https://www.reddit.com/r/FortNiteBR/comments/ftqic7/muselk_speaking_facts/
https://www.reddit.com/r/pcgaming/comments/b1giwg/why_didnt_fortnite_have_a_major_hacker_problem/
https://www.essentiallysports.com/fortnite-keeps-cheaters-at-bay-unlike-valorant-and-call-of-duty-epic-games-esports-news/
All in all, I understand the emotions in this thread, but it doesn't help anyone when people go for the simplest explanation possible - "oh, it's because they are stupid | evil | cheap". Cheating in online games is a serious problem even on consoles, where it is mostly contained (I again encourage watching this video to see how this was achieved: https://www.youtube.com/watch?v=U7VwtOrwceo), much worse on Windows, which is still a relatively open platform (although it moves to become more sealed, which isn't something I personally like), whereas Linux is not even designed to limit their users' freedom, which poses a fundamental and philosophical issue - how to prevent bad behavior on a platform that trusts their users completely? People who are smarter than me are working on this and don't have a good (or economical at least) solution so far.
Last edited by RCL on 17 February 2022 at 2:32 am UTC
This is a rather bold statement to make, without having the data or likely even an idea about the health of the game.
It is bold and based on a simple idea - messing up user's privacy and security becasue developers don't want to spend effort on proper solutions is unacceptable.
which poses a fundamental and philosophical issue - how to prevent bad behavior on a platform that trusts their users completely? People who are smarter than me are working on this and don't have a good (or economical at least) solution so far.
Simple - you don't (do it on people's systems). Same as you don't put police cameras in people's homes (wouldn't it help preventing more crime?). Same reason there is the Fourth Amendment and such.
No matter how "serious" this problem is, current idea of preemptive user side anti-cheat is not a solution. Not any more than let's say the Watchbird is a solution to crime.
For those who want to better get the reference, see:
* https://www.gutenberg.org/ebooks/29579
* https://www.gutenberg.org/files/29579/29579-h/29579-h.htm
Last edited by Shmerl on 17 February 2022 at 3:35 am UTC
Cyba.Cowboy Feb 17, 2022
So how then, is it that Fortnite: Battle Royale is available on Android-based operating systems - which are famously easy to "hack" (lock and unlock the bootloader; replace kernels; run custom code; replace ROMs and loads of other things) - yet it is not going to be coming to the Steam Deck?
Then there's the numbers.
Steam has approximately 25 million active users (the number varies, but it's around this figure) who are all playing games (i.e. every one of them is a potential Fortnite: Battle Royale player); Android-based operating systems have somewhere in the vicinity of 250-300 million active users, but only a portion of those will be actively playing games on their smartphones (most of which are so-called "casual games") and only a portion of that will be Fortnite: Battle Royale.
For comparison's sake, let's say half (about 150 million) are actively playing games on those smartphones on a regular basis and let's say a third of that are actively playing Fortnite: Battle Royale on their smartphone, instead of playing it on a console or computer.
That makes about 50 million users playing Fortnite: Battle Royale on their smartphones instead of a console... 50 Million users is not all that much more than 25 million, particularly if you consider that I'm being generous with my numbers, with a bias towards Fortnite: Battle Royale.
Of course, most of this is guesswork - but I'd be awfully surprised if it's much more than 25 million who prefer to play Fortnite: Battle Royale on a tiny smartphone over a console or a portable console.
In essence, the potential market for Fortnite: Battle Royale on mobile devices is probably about the same and the ability to cheat the game is probably easier on (some) mobile devices (remember, Fortnite: Battle Royale is also available on the Nintendo Switch and Sony PlayStation Vita via Remote Play)...
As I said above, I personally don't care because if Epic Games don't want to bring Fortnite: Battle Royale to the Steam Deck, it's only a matter of time until there's a viable alternative available... It's not a question of "if" an alternative will become available, but rather "when".
But I do struggle to wrap my head around the business decision, because people that know more about this stuff than I do seem to be able to easily discard most of Epic Games' arguments with ease.
It is bold and based on a simple idea - messing up user's privacy and security becasue developers don't want to spend effort on proper solutions is unacceptable.
Arguing from this position (that Linux shouldn't have any kind of DRM) would make any non-DRM-free game distribution platforms on Linux a non-starter, would it not? I though it is a commonly accepted position here on GOL that _some_ DRM is acceptable as a trade-off, otherwise why we're even discussing Steam Decks which aren't DRM-free.
Abstracting away from that, there's a deeper philosophical issue here. Freedom of one user ends where the other's freedom begins. In a multiplayer game, be it commercial or not, there exists a shared trust that needs to be enforced. You are trusted to obey by game's rules, and the others need a way to enforce or at least confirm that. There's no good solution for that (as far as I know) in a FOSS OS, except, as you said - "doing everything on the server". Which, if you try to actually implement that, will result in either a _very_ thin client (like a video player to replay the stream rendered on the server), or an extremely unresponsive, unplayable except on the LAN, game. You seem to maintain that there's the "proper" solution that avoids both of those downsides and yet doesn't limit the user's freedom. I am afraid that if that solution truly existed, it would have been found by the industry already... So far all anti-cheating solutions in current practice involve a compromise, i.e. some form of the DRM on the client. Respectful of the users' privacy and not overstepping what's not needed to protect the game, but limiting some of their freedoms nevertheless.
Last edited by RCL on 17 February 2022 at 3:46 am UTC
Your comments imply that you work for - or have some direct involvement with - Epic Games, @RCL...
Yes, I do work there, not on the anti-cheat though. And here I'm privately, as just another Linux user.
So how then, is it that Fortnite: Battle Royale is available on Android-based operating systems
I don't run the numbers, nor if I were I could disclose them, but my hunch is that Android is still a much more locked down platform than a regular desktop Linux. Or at least the proportion of the players on that platform who are willing to seriously mod their systems for cheating is low enough. Again, I trust the judgment of the anti-cheat people who are experts in their area.
You seem to maintain that there's the "proper" solution that avoids both of those downsides and yet doesn't limit the user's freedom.
There is. Develop an AI that will analyze user behavior while running server side and will detect patterns that will be deemed as "illegal" by the game. Same as police would monitor people's behavior in the street, but wouldn't sit in people's homes because they "need to suspect everyone to maintain the level of trust".
How you define those patterns is totally up to developers. The more sophisticated ways they'll come up with and the more they train it, the better the AI will be detecting what they define as "cheating". I don't see any unsolvable problem there.
It's not a perfect solution, but it can be a sufficient solution for the level of trust you need. Same as policing in real life is. Point is - there is no perfect solution for it. But there can be good enough ones.
Basically, I don't see any huge philosophical problem here, it's the same old privacy vs policing idea that's been handled for a long time in some acceptable fashions that don't cross important boundaries.
Last edited by Shmerl on 17 February 2022 at 4:20 am UTC
There is. Develop an AI that will analyze user behavior while running server side and will detect patterns that will be deemed as "illegal" by the game.
This is indeed an open area of research and work. However, as far as I am aware - and I'm not an anti-cheat specialist - there isn't enough robustness as of now yet, to avoid false positives or missing the cheaters, and more importantly, the current solutions have a fairly long lead time, which cheaters can beat by recycling the accounts faster (in a free-to-play game at least). So while a promising area, this is far from a solution that can be enabled "right here, right now" to combat today's cheaters, unfortunately.
Last edited by RCL on 17 February 2022 at 4:05 am UTC
This is indeed an open area of research and work. However, as far as I am aware - and I'm not an anti-cheat specialist - there isn't enough robustness as of now yet, to avoid false positives or missing the cheaters, and more importantly, the current solutions have a fairly long lead time, which cheaters can beat by recycling the accounts faster (in a free-to-play game at least). So while a promising area, this is far from a solution that can be enabled "right here, right now" to combat today's cheaters, unfortunately.
I don't see it as an excuse to resort to unacceptable solutions. Rather it should be an incentive to invest more into such AI.
Also, the way this works is a slippery slope. Once these companies manage to portray this as "acceptable" and people start ignoring the issue, it becomes very hard to get rid of it even if there are better solutions. Because they don't want to give up power and control.
Same thing with other areas with similar issues.
I recommend reading the above Watchbird, it's very on point.
Last edited by Shmerl on 17 February 2022 at 4:19 am UTC
See more from me