Dry up the cheating ecosystem #SaveApexRanked ðŸ—¡ï¸

As many of you are aware, ToS (terms of service) violation is quite common in Apex Legends, especially in the highest ranked. As a fan, I want to leverage my technical background, not my player skill, to make the game experience better.

# The North Star

Before starting, let me clarify the goal of this discussion. The goal is to maintain a sustainable playing environment at a reasonable cost. The most feasible approach to achieve this goal I believe is: to keep raising the bar for ToS violators to satisfy. If their efforts hardly pay off, only a few will buy bots. Obviously, it’s relatively easier to make most of the cheating activities worthless than actually wiping them off completely. In other words, we focus on minimizing the illegal market size per se.

# Project Data Knife

As one with a bit of knowledge in Cyber Security, the discussion initiated by this tweet was interesting:

The bottom line is that anti-cheating is primarily Respawn‘s job. So here I want to suggest an approach to empower Hideouts to do their jobs efficiently. Should you know Ash’s passive skill that shows surviving attackers on the map by sticking her data knife to a death box. Likewise, Respawn can spot malicious players grounded in ex-post information. What does it mean? For ease of description, I’ll call this methodology #ProjectDataKnife (PDK).

Pretty much any online video game including Apex Legends is implemented by the client-server model. PDK detects violating activities based on the data accumulated on the server-side. The logics on servers and data already sent to servers are tamper-proof unless the servers are actually exploited. So the server-side data can be a reliable source of detection.

As an outsider, it has been strange that online games heavily count on the client-side anti-cheating systems. Why don’t they take advantage of the server-side data? My best guess is to deliver the real-time performance required by PvP games. In a nutshell, you can do a few on the server before responding to the client requests. Then don’t! Just make sure to keep activity logs so that you can evaluate them later on, technically saying, by event-driven.

Now, PDK outcomes can vary upon violating activities:

  • Impossible behaviors: Something expected to be denied by servers in the first place. i.e., floating in mid-air, armor swaps out of nowhere, etc. As described, such actions can be allowed due to the severe performance requirements. If you collect server-side logs, it’s safe and easy to ban the involved accounts retroactively every time a particular activity pattern is recognized, with little game experience tradeoffs. Not to make cheaters’ efforts pay off, the mean time to ban (MTTB) is ideally 10-60 min considering a match takes about 20 min on average. Start from the easiest detection target. For example, illegal matchmaking can be a good starter such as Switch glitches (unexpected cross-platform matches) and tier leaps (bronze in the predator lobbies). To avoid false-positive operations, you may want to try a 3-out-per-day basis. More modestly, you can suspend the suspicious account for hours while Hideouts manually double-check per its session ID. Since the detection process is no longer bound by the severe performance requirements, you can put multiple layers of validation. Note: further study is needed but certain mouse-to-controller converters can fall into this category as the input patterns seem to be recognizable mechanically.
  • Gray areas: some actions possible by specs but unrealistic through an experienced eye. i.e. aim-bot, wall hacks, teaming, etc. Best to rely on machine learning. The server-side logs can be the training data indicating whether the action is from the players previously banned by Hideouts. Certain machine learning models can produce a confidence score, which helps prioritize Hideouts operations. Once or twice every season, Respawn bans ToS violators. With PDK, this cadence can be multiplied to say every two weeks up to the resource.
  • Out of scope: PDK would struggle with the violation needing information outside of the game. i.e., boosting, smurfing, account trading, etc.

As seen above, PDK will make the whole operating process flexible and effective.

# Potential Impediments

The most challenging part should be to design the logs – what to record and what not to, with a minimum latency compensation. Once the logs are ready, you might want to hold a contest on kaggle.com as a proof of concept. Then you can go back to redesign the logs upon feedback.

広告

コメントを残す

コメントを投稿するには、以下のいずれかでログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中