I recently had to go to court over a traffic citation. It was a simple misunderstanding, the officer was very courteous and professional, and when provided the evidence, the prosecutor agreed that the case should be dismissed before going to trial.
During the months leading up to my court visit, I spent an enormous amount of time researching the law as it applied to my case. Probably more than most. I went in there with my entire defense planned out, down to a list of questions for the officer under cross examination, all of my arguments, what objections I expected to raise, etc. Everything. Most important, I went out of my way to make sure that I had every law properly cited in my notes.
Of course, you’re probably thinking, “what does this have to do with games?”
What I was doing in preparation for that case was all of the things that a Dungeon Master would have to do if he/she had a particularly “litigious” group of players, or what a litigious player would do if he/she wanted to get something over on the DM.
On Steve Jackson’s site, he provides a few recommendations for students seeking to get into game design. He recommends journalism courses to teach you to write quickly and clearly, classes that cultivate a logical mind (math, science and logic courses), and law courses in writing legislation and contracts. The purpose of this is to ensure that you are able to see how rules interact, and are able to find inconsistencies and conflicts within the rule structure.
Logical rule progression is a particularly important part of tabletop game design because you don’t have the same inherent feedback mechanism that a video game designer might have. For example, if you code something incorrectly in a video game, the error of that coding will become visible relatively quickly when you play test it. That is, the machine will not overlook the error, but rather will show it to you in all of its glory. On the other hand, if you are producing a tabletop game, it is very easy to overlook or misunderstand a design problem, particularly if your testing process doesn’t explicitly seek to break the game.
If you can’t see the potential for abuse within your own rules as you write them, then your only option is to play test, play test, play test with people actively seeking to break the game. These people are your “debuggers,” and they are always helpful.