Quoting: Cyba.CowboyCouldn'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.

View this comment - View article - View full comments

EAC and other anticheats don't try to be watertight. It is as of now impossible on PC. Even consoles do not try to be watertight. The platform owners set a goal that cracking a console should cost the user an equivalent of buying 10 AAA games (watch this video for the details: https://youtu.be/U7VwtOrwceo [External Link]), and then it is a sufficient deterrent.

I.e. it is understood that nothing will stop a _very_ determined individual. But if you raise the threshold so high that 99[.99]% of people give up trying, the goal is achieved.

PC is slowly moving towards this as an architecture, but it will always remain more open than a dedicated hardware.

Doing everything server-side is an unacceptable latency (as of now). Yes, the tech is also improving in that area, but for example if you wanted to prevent aimhacks, you'd need to make the server authoritative over the mouse movement - and good bye the feeling of smoothness when playing at 60 or more FPS.

So the critique and ideas voiced here are often indeed underway, but in the meantime existing anti-cheat mechanisms need to work with what we have - PCs that cannot be fully secured, games that cannot relegate everything to the server. And they do make a difference, very noticeable one for the players.

View this comment - View article - View full comments

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. This is a real issue for the fast-paced games that Fortnite is. Client-side prediction and control is essential to providing the smooth feeling of playing the game. So no, unfortunately there is no easy way around "client-side anticheat" problem. This is not about the laziness.

Also don't think that the cheaters are not going to be Linux-savvy. They are eager to learn any tool that gets their job done, and they aren't fanatical or ideological. Here's an example why we cannot have nice things: https://aixxe.net/2017/06/kernel-game-hacking [External Link]

View this comment - View article - View full comments

The whole conundrum is because you're trying to use a free, infinitely modifiable software environment (known collectively as Linux for its kernel, because the kernel and maybe C library is the only permanent component of the mix) for distributing closed source, binary only, compiled once and never updated, games.

Of course that's not going to work well and it is not working well. FOSS system needs FOSS games that are developed according to its rules and can be patched as the system evolves. Alternatively, FOSS system needs an "emulator" for a more stable environment, which can be adapted so users can play the same "frozen" images of console or Windows games while the underlying system changes under them.

Asking for more native closed-source, binary only, "frozen" Linux games is asking for trouble. Why? They will quickly bit rot in the ever-evolving Linux environment. If you have a closed source game that was released in 2010 for Windows and can be played via Proton now in 2020, chances are, you'll be able to play it in 2030. Can we say that about native Linux games released in say 2012 with the Humble Bundle? FWIW Valve recognizes that and started working on its own containerization system ("pressure-vessel"). Which, if it works, is going to be a solution for Steam-distributed games only, not for any random native Linux game...

EDIT: this is not to say that Windows doesn't change. But Microsoft is taking great care to not disrupt the games with its changes, recognizing the value of its ecosystem. Linux, in contrast, is developed mostly not for the games, and the major distro vendors often don't care enough about them (even Ubuntu, as recent attempt to remove 32-bit support showed). Moreover, it can be said that running closed-source binaries is an explicit non-goal for many distros, something that they tolerate on pragmatic grounds, but do not wish to endorse (understandably), because it undermines the FOSS principles and also security (you may have no concerns about running someone's closed source binary you just downloaded from the web, but for majority of non-gaming Linux users this is a big security risk).

View this comment - View article - View full comments

Thank you for the "thank you" :) As for the question, the commit message says it all - it helps folks who use UE4 on headless setups (usually without X11 as well), like e.g. this case [External Link]. As for other changes to SDL2, they mostly stem from the fact that UE4 uses SDL to open and manage multiple windows and as such sometimes runs into edge cases / bugs which a typical game (that only opens a single window, often a fullscreen one) doesn't hit.

View this comment - View article - View full comments

The offscreen backend has existed in the SDL2 lib bundled with Unreal Engine since 2016 (see here [External Link], although you need a github account that is associated with an Epic account or you'll get a 404). Throughout the years, we have been upstreaming our SDL2 changes (e.g. this [External Link], this [External Link], or this fix [External Link]) to improve SDL2 and minimize the differences with the bundled lib.

(P.S. I work for Epic, although here I'm just another Linux gamer speaking privately).

View this comment - View article - View full comments

Quoting: ShmerlExcept Windows users will have access to it no matter what.

Nope. Sometimes a significant percentage of Windows users are excluded due to bad drivers, weak hardware (think of all Intel embedded graphics users) or some third party software they installed that doesn't work well with your game. Windows PCs are not a console platform, no game works out of the box on 100% of Windows computers because people don't upgrade their drivers since 2015, people customize their system to run some fancy tools like Rainmeter and then have problems due to this (see e.g. https://forum.rainmeter.net/viewtopic.php?t=28334 [External Link] ) etc etc.

Think about that. You, as a developer, are facing the choice: spend your next month solving problems that unblock additional 10 thousand of your userbase on Windows (by e.g. trying to find workarounds for driver problems or solving that Rainmeter issue, or optimizing your game to run on poorer hardware), or spend your next month adding a thousand or so potential Linux users (whose setups are going to be probably even more diverse and come with worse problems than Rainmeter).

Also, I think your political analogy is wrong. A lot of Windows users with bad hardware are poor, whereas Linux gamers can be rich enough to afford beefy PCs and good graphics cards. So if you're thinking along the political lines, think who you're going to exclude in the above scenario - some poor kids playing on their mom's Intel laptop from work running Windows, or some rich 20-something who built himself a Linux PC and wants to play your game.

My point is: don't judge the people. Monopolies are bad, I agree, but people using monopolistic products - both users and developers - are not bad themselves.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: tuubi

Quoting: RCLLinux gaming squarely is in the same place when it was in 1999

Well that's obviously not true.

Indeed, that statement is completely false. Linux gaming has progressed a lot.

I dunno how you measure that... Here's what leads to my impression. I remember 1999-2000 peak well (my college years).

- There was a lot of hype that Linux is going to be the next big thing not just for games, but overall replacing Windows. A lot of folks around were converting to Linux, myself included (I have always dual-booted though). There were first "memes" (then not known by that name) that Microsoft will release a Linux distro (Microsoft Linux 98 [External Link]).
- Top games were appearing for Linux, with proper 3D acceleration. You could play Quake, HoMM III. Unreal Tournament was being ported to Linux by Dan Vogel (currently of Epic Games, then of Loki).
- Market share was not measured accurately but the impression was that Linux desktop users were far more than 1%
- Literature about developing Linux games started to appear, including a book on SDL that I still have.
- There was even a Linux console in the works (Indrema). A new AmigaOS was supposedly based on Linux etc etc.

Then it all went bust after 2001.

Then there was a rise again in mid-2000s, when XP got stale, Vista screwed up and Ubuntu had it 15 minutes of fame. Open source games finally caught up on tech and while commercial releases weren't many (PC was dying as a platform altogether), Linux again got some credibility as an entertainment platform.

Then a rise in mid 2010s again, after a yet another PC renaissance. First Humble Bundle, then Steam. And again a down-slide.

Perhaps in absolute numbers of games currently runnable on Linux there's a change. Percentage-wise and attitude-wise, it feels the same. Similar technical problems, similar support issues, similar lack of market forces, similar market share.

View this comment - View article - View full comments

Game development is maybe 20% "art" at best. The rest is hard work that you need to pay people for. Bugfixing is not art. Hitting the deadlines is not conducive to art. QA is (largely) not art. Game development needs to be sustainable. People will draw for free, but people will not clean up the mess for free. A typical game has a small "drawing" period and a very long "let's clean up this mess and ship it" period.

Right now game development is still a risky business even on platforms where a reliable monetary feedback exists, Linux gamedev is more a philanthropy. I don't see any factors that would change this on the horizon - Linux gaming squarely is in the same place when it was in 1999, it goes in circles (remember Indrema? Same fate happened to Steam Machines 15 years later). I think only the "emulation" approach (I know that Wine is not an emulator but running a Windows game on Linux is conceptually not that far from running a Xbox One game on Linux, so I'm using the term broadly) is viable. Happy to be disproven by some new unexpected development on the platform.

View this comment - View article - View full comments

Quoting: ShmerlGames aren't distributed as part of the distro, so distro shouldn't really matter. Same as today, you can play games using any distro you want.

This was in context of a gaming-oriented paid distro a la SteamOS proposed by someone earlier.

View this comment - View article - View full comments