Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#3579 closed task (duplicate)

Rethink Anti-Cheat

Reported by: Josh Owned by:
Priority: Must Have Milestone:
Component: Core engine Keywords:
Cc: Patch:

Description

There's been a lot of discussion on how we should handle anti-cheat in #3155 and #2676 but very little consensus (resulting in a hacky mishmash of fixes).

There have been proponents for two key views:

  1. This game is alpha and if anti-cheat will compromise our ability to debug the game, it should not be included.
  2. We need to prioritize user experience and disable things like the developer overlay in multiplayer games.

For view number one, quoting historic_bruno from #3155:

On a number of occasions, it has been necessary to have a user access the developer overlay to look at things like the selection state, that can't be known any other way, and the other options can be of similar value when submitting good bug reports (why should e.g. reveal map not be allowed to show a bug?). Many bugs aren't easy to reproduce or the steps aren't clear to the user, by then it's too late to change the match settings and it may not help to restart the game.

For view number two, quoting elexis from #2676:

  • The developer overlay has been abused often for:
    • Defeating other players
    • Send fake chat
    • Quit the application of other players
  • Spectators can use it too and ruin one game after another without participating.
  • ....

View number one seems too permissive, but view number two seems out of context. I think that there is a position which both; a) limits the ability for players to cheat while, b) still allowing reasonable levels of debugging.

First some definitions and background. Some debug features like "Control all units" and "Change perspective" are cheats. They have uses for debugging but can be (and are) used to give one player an unfair advantage over another. However not all debugging features are cheats for example, "Display selection state" and "Restrict camera". The sole use of these features is for debugging, they will never be able to give players an unfair advantage.

Following the logical trail:

  • debug options that are not cheats should never be disabled and
  • debug options giving unfair advantages should never be enabled when a user disables cheats. It would be a violation of their wishes.

So, how could we do this? I propose that the boolean cheat setting become a globally accessible property in C++, and that anti-cheat should be performed in the JS <-> C++ interface. Adding more options would be beside the point and in avoidance of the core issue.

Thoughts?

Change History (2)

comment:1 Changed 4 years ago by elexis

Cc: leper elexis historic_bruno removed
Keywords: design removed
Resolution: duplicate
Status: newclosed

I have the same opinion as expressed here - developer cheats (sending commands for other players) should be prohibited. Read-only stuff like revealing the map (change perspective), showing the selection state, can't be fixed either way and has less impact. Also in my experience replays are more useful for debugging.

Further discussion please in a forum thread (maybe even staff) or the mentioned tickets.

comment:2 Changed 4 years ago by elexis

Milestone: Alpha 20
Note: See TracTickets for help on using tickets.