[ltr_]

just curious: what would be the answer from FSF/OSS people to , cheating and opensource games/libraries?. i mean if for example dota2 were open source it would be fairly trivial to make scripts to send commands on events (even closed source games get cheat mods!).

off topic : on the other side, i think is inevitable that at some point in the future players will have AI assistants looking at their screens , making decisions and inputs just like a real human, (heck! you can sort of do that now with linux/x11 , screen grab and proton very easily), i personally would love to see competitive gaming involving AI agents and assistance.

[flushit]

Cheat mitigation needs to be server-side. Anything coming from the client has to be fair game. No matter what you do, this is inevitable in the light of reverse engineering and AI progress.

Chess is already there. It's really easy to cheat. You can though analyze games after the fact and pretty reliably conclude whether somebody cheated. That's one example of server-side cheating mitigation. No matter what the client feeds you, cheaters are detected and eventually banned.

[ddevault]

This is addressed a bit here:

https://writefreesoftware.org/blog/free-software-games/#but-...

tl;dr: access to the source code will help people develop cheats but it's not really required, your game's gonna have cheaters unless you do server side cheat mitigations.

[abdullahkhalids]

That covers things somewhat, but not entirely. In Dota (and other games), there are a lot of purely client side cheats, that are obtained by reverse engineering the closed source client. Some examples that can't be detected server side reliably.

* Keyboard macros. Actions that require multi keys pressed in sequence can be done with one key press.

* Bigger viewport. Your client has information about the entire visible map, but by default only shows a certain part on your screen. Client side hack zooms out the view and shows you a much larger area.

* Auto disable. A very strong cheat. If an enemy suddenly jumps on you from out of vision, immediately cast disable spell on them. Doesn't matter if you were looking somewhere else or doing something else.

Valve can't prevent people from creating these cheats, but they put code in other parts of the close source client that detects the usage of these cheats. Then they create a list of these cheaters and every few months have a ban wave. And change the code enough to break the cheat.

[pabs3]

The viewport issue sounds like something you could fix in the server; only send the client info about the area around them.

[abdullahkhalids]

Its a team game. So you can see anything that is visible to your allies, and you can (and should be able to) pan your viewport around to see that stuff. So the client needs to know everything that is visible to your allies.

Plus there are things that happen outside your viewport that affect whats in your viewport, and trying to limit your client from knowing those things would cause all sorts of graphical artifacts.

Eg. there are some spells that affect an entire area (and have graphical affects associated with the whole area). Even if part of the spell area is in your Fog of War, your client needs to know about it completely, for the graphic drawing algorithms to run. The client draws the whole thing, and then obscures the part that should not be visible to you. Otherwise, the graphic algorithms would become get additional complexity that will possibly have performance impacts.

[RobotToaster]

Some stuff can be detected server side, some can be designed around.

The rest IMO just becomes part of the game. Pure client side stuff like macros isn't unfair if everyone can use them.

[simiones]

What do you mean? It's already pretty trivial to develop cheats for fully proprietary games. The only way to prevent cheating is to do it server side. You'd then be protected even if the server itself were also open source.