How to prevent automation-type cheating?

Question

Lets say I'm making an incremental game, (e.g. cookie-clicker-like). The premise of the game is simple: players send inputs that advance their game state. Players convert their own real-life time into progress in the game.

Obviously, players can cheat on the client-side, so to prevent this - the entire game logic happens on the server, and the client's only role is to render an interface that lets the players send their inputs to the server over the network. Thus, players can't take any actions that aren't allowed by the game's rules, because each action is validated on the server.

However, this still brings up a problem: what about this type of cheating:

Instead of playing the game manually, a player just writes a script that plays the game for them. They leave their PC running 24/7, and make progress in the game, all within the game's rules, but without using their own real-life time to play.

Obviously, this gives an edge over "legit" players that only play using the game's intended interface for committing actions.

Is there anything I can do to prevent this type of cheating, or is this a lost cause with no solution?

For the sake of this discussion, assume that the player that wants to cheat is able to easily reverse engineer the clientside code. For example lets say it's an HTML5 game with JS code, and that the cheater is smart enough to read minified code (which is not a far stretch at all). This means they can basically copy the code to their own machine, set up a server (with the JS example, setting up a Node.js server takes about 2 minutes), add a bit of their own code for the automation, and make their server send requests to my server with spoofed headers in a way that it pretends to be a regular user agent.

[Edit] in response to questions in the answers: The game has no player interaction, but there's an online scoreboard, and higher-ranking players get rewards; in other words, cheating is not isolated to the cheater's local machine, and cheating can ruin the experience for other players.

Answer 1

If players are not interacting with each other, I wouldn't suggest worrying about it too much, whatever a player does on their local copy, is their business. If they have this much knowledge to reverse-engineer and spend so much time to do it, let them.

If players are interacting with each other, the only solution is to detect "bot-like" behaviour and punish it. When a human plays the game, the input is "clumsy". Humans can't move a mouse on a perfect straight line, and when clicking the same button, it's very difficult to click the same pixel twice (assuming they moved their mouse in-between). You can take advantage of that, and if you detect "too many" very precise movements, then you know something is up.

There's a lot you can do code-wise, but be careful. Do not punish a player that is legit even if their actions look robotic. You can counter that by influencing the gameplay to be more active (at least the non-idle part).

Answer 2

The good news is that it's very difficult to design a bot/script that can fool all attempts to distinguish it from a real player.

The bad news is that it's very difficult to design a detection process that will catch all bots/scripts. And harder still to avoid catching legit but oddly-robot-like real players in the net.

So these systems end up being arms races between the cheaters and the developers, with the battle ebbing and flowing with the stakes at play. If cheaters can make real money by farming with bots, then expect to face a dedicated adversary. There are some strategies that can help though:

1. Don't punish cheaters right away.

   This might sound counter-intuitive, but the closer your punishment comes after the offense, the more information you give to the bot-builder about what actions gave them away.

   If they have a bunch of bots get blocked after their 10th time clicking on a particular in-game button, then they have a strong clue that there's a rate limit or position-of-click check (like Tom Tsagk suggests) in place there. So they build a bot with a slight randomization in how it clicks that button, and lo and behold it's not banned after the 10th click, so they know they've successfully defeated your detector, for now.

   Instead, flag cheaters and let them go about their business for a few days, then ban bunches of them in big batches, so the ban isn't directly attributable to any one action. That keeps them guessing about how your detector really works, and means they have to run every experiment for days before they find out if their guess was right, slowing down their adaptation.

   This also gives you more time to gather data on the suspected bot accounts. You can analyze this to find other tell-tale behaviours of the bots beyond what originally flagged them, so you can diversify your detection methods - letting you still catch the bot even if the original giveaway gets patched.

2. Look for patterns

   Once you take this long-term view of cheaters, many more potential signals become available to you, like play schedules & frequencies of particular actions. Human players will occasionally sleep or put the game down for a minute - do your suspected bots? Human players will usually buy an upgrade pretty close to the time when they can afford it - do you have some accounts that build up large stockpiles overnight then go on a spending spree when their human wakes up?

   Machine learning algorithms can be useful for identifying these types of patterns. Especially if a particular cheater uses the same script for a whole botnet for farming, or distributes their script, you'll have a group of accounts all playing exactly the same way (to within whatever randomization parameters the script uses), a cluster that stands out like a sore thumb to ML approaches.

   You'll still want to keep the decision of which accounts to punish manual - use algorithms to highlight suspected cheaters, or assign them scores based on how many humanity tests they fail, but always keep a human in the pipeline who can inspect the data, spot new patterns, and override the algorithm when it's flagged an account believed/known to be a real (if curiously consistent) human.

3. Use game design

   As ddyer points out, one of the most robust ways to protect your game against farming is to put limits on how much a player can do in a day. That way even someone with a perfectly undetectable bot can't do better than a human using their full action count / energy bar for the day.

   (This also gives you an opportunity to monetize players to whom longer play sessions/faster progress is worth a microtransaction or two. Just ensure you're doing this honestly - being up-front about what value they get for their investment, and not abusing players' cognitive biases or gambling addictions)

   The trick with this though is if your action caps are generous enough to not impinge on your most dedicated players, then there's still headroom for a more casual/occasional player to use a bot to fill-in the extra time & max-out their progress dishonestly. But we can find game design approaches to this too.

   Consider including elements in your game that humans can perform easily, but scripts would have a harder time keeping up with - like an optional, time-limited bonus round every so often that involves clicking on a particular object in an image. You generate the image and check the click zone on your server, so a client-side script can't just peek under the hood to see where it's supposed to click, or memorize every image possibility. While still possible for a bot to solve, we've upped the programming challenge from emulating human clicks & timings to neural network computer vision, putting the bar for cheaters that much higher.

   If you make the bonus round very profitable but optional, you help narrow the progression rate gap between humans who can do these bonus rounds easily, and bots that can't. You also get another useful signal to use in highlighting potential bots: are some accounts ignoring these super-profitable bonus opportunities? Or getting the very easy-for-a-human challenge wrong routinely? Maybe flag those accounts for additional inspection...

Answer 3

Put an activity limit on your game. Think of it as enforcing bathroom/nutrition/sleep breaks. If you do this gently, real players won't even be aware that limits exist. If you want to be nasty about it, when limits are exceeded restart the next session where this session started.

Answer 4

Modifying your reward design seems the best approach. If being at the top of the leaderboard is giving a player extra advantages that may just perpetuate the problem of power gap seen in most pay to win games out there. If the only way to stay on top is to be on top I'd consider that a design flaw.

Perhaps participation, mission, or milestone rewards would be better?