Should Your Game Be Designed to Prevent Cheating?
Stopping cheaters. I've engaged in discussions of this with other designers, and I've gotten the occasional suggestion from playtesters. They tell me about how they think I should change my game rules to stop cheating before it happens. After considering this for a while, I have figured out where I stand on the subject of cheaters and how to foil their nefarious plans.
Designing your game around cheaters is a bad idea.
Why? Shouldn't cheating be discouraged? The answer has to do with making a good game.
A good game follows Occam's Razor. Its rules should be exactly as simple to understand as possible, but no simpler than that. For that reason, there should be no if's, and's or but's in the rulebook.
I mean this literally. Okay, mostly literally. You can have a few if's and's or but's, but they need to earn their place in your game. Take, for example, this monstrosity: "If you have a red card, but you don't have a blue card, and there's an orange card in play in front of you, then do this."
If this kind of conditional information is in the rulebook and nowhere else, it won't work. The rules will quickly turn into spaghetti, and people will spend more time reading rules than they will spend playing the game because each rule is so heavily situational.
For a real-world example of this madness, take an older version of my game, SysHack. In this game, there are two teams, the hackers and the professionals. At the end of each round, there is a processing phase where you secretly select another player to do a thing.
In older versions of SysHack, I had a lot of different conditions that defined what would happen. If you are a hacker, but not the lead hacker, and you select a professional, then he does this. If you are a professional and the recipient is a professional, he does that. If you are a professional, and the recipient is a hacker, but not the lead hacker... you get the idea.
It all made perfect sense to me because of course it did. I designed it, so I was blind to the spaghettitude of it all.
Lucky for me, some very humbling playtests cleared that right up. What I found over and over was that that was the part of the game that most consistently tripped up players, even after they had a couple games under their belt. And many of these were smart, seasoned gamers.
Because of this, a lot of my focus was on refining the processing phase until it reached the point where it is today. Now, the only thing that matters during processing is, "Is the recipient a hacker, or a professional?" This is a neat condition because you never change teams once the game gets going. Once you know your team, that's your only answer to that question for the whole game. Nice and simple, so the game can maintain its flow.
Side Note: This action is also written on the team cards, which as a whole is a great way of dealing with situational things: Put it on a card. But I digress...
You might think of conditions as being like hoops. Each decision you have to make is a separate hoop. Jumping through one or two on occasion is fine, and can even be fun. But consistently jumping through 4 or 5 hoops before you finally know what to do? That's not fun, that's drudgery.
Now let's move the conversation back to cheaters...
It's SO easy to cheat in SysHack. During processing, only two people will have their eyes open. If you're one of them, you could do any number of things to cheat. You could peek at cards you're not supposed to, show the other guy your cards, and so on. If you've got your eyes closed, it's pretty easy to peek for just a second and see something you not supposed to see.
I'm not entirely sure what rules are even possible to help monitor the behavior of people in that situation. Some have suggested that I include something akin to sleeping masks as a game component. I could also designate one person to be a moderator, remaining outside the game and making sure the rules are kept. But both of those options add clunkiness to the game with very little benefit. These, in effect, are as good as adding an if, and, or but to the rules.
But that's my point.
When you start adding in rules to curb cheating, often what you're doing is punishing honest players by making them jump through more hoops than necessary. You're taking them out of the experience of the game. What you're NOT doing is stopping cheaters. They'll find another way; I guarantee it.
If you can set up rules in a such a way that they prevent cheating, but do not complicate the game for honest players, then by all means, do so. But, often enough, that's just not possible.
When it comes down to it, cheaters gonna cheat. Designing around them is a great way to over-design your game without helping anybody who actually wants to have a good time, win or lose.
The best way to stop cheaters is to not play with them. So don't design around them, either. Your game isn't for them, anyway.