Logical Completeness and Consistency in Game Design

Another overly complex look at games. First, some history of logic.

In college, I took several classes on formal logic. I started with history of philosophy courses to get the scope of writing about thought. Then I moved into classes about propositional logic. This is your stuff like “If A, then B. A. Therefore B.” Part of this also involved symbolic logic, which is closely related to math, and involves using logic as a language that can be manipulated like equations, such as A→B (Read as “A implies B”). Then I moved onto the hard stuff: Metalogic. This deals with what sort of things can be said and done in a language.

The short story here is that for a time, people assumed that logic was perfect. This is a natural assumption because in every day use, anything you can prove to be true using logic always turns out to be true (assuming including no factual errors or errors in logic). But for a formal language, there are two parts: the language itself (e.g. in English, the sentence “The sky is blue”) and facts about the world (e.g. whether the sky actually is blue or not). If you want to know whether a language is reliable, you need to prove two things. First, that anything you can prove to be true using logic is actually true. This is known as “consistency”. The second half is that anything that actually is true can be proved using the language. This is called “completeness”. Again, the difference is subtle: consistency is “if it can be proved, then it is true”, while completeness is “if it is true, it can be proved”.

Kurt Gödel
Image from Wikimedia Commons

But a clever guy named Kurt Gödel realized that if your language is powerful enough (in this case, anything that can be used to do arithmetic), you can always create a statement that can’t be proven true. This is called Gödel’s Incompleteness Theorem. The details of how this was done aren’t important for this article. But it means that knowing whether the rules work won’t always tell you whether the rules are useful.

That’s the history lesson done, so what does this have to do with board games? Well, board games are a lot like formal languages (that can be used to do logic), because they both originate from a set of rules that tell you how to manipulate objects. So board game rules are like a language. In fact, a recent post from Ben Marshalkowski talks about how game design is like programming, and programming languages are closely related to formal logic.

So consistency is one very important part of designing a game. It means that the rules act the same all the time. (Even if there are rules about changing rules, “meta-rules”, the meta-rules act the same all the time. And then there are meta-meta-rules, etc…) What does a game designer need to watch for with consistency? One very important consideration is “edge cases” where players do something not originally intended to be covered by the rules. In Dominion, you can buy a curse card. There are very few cases where you would actually want to do this, but the rules for buying them are exactly the same as any other card. This means that the basic rules are very powerful. Designers should be wary about adding rules just to cover edge cases, because there can be other conditions that haven’t been found yet. Obviously a designer should try to find them all, but often, this just isn’t possible. Another thing that designers should watch for involving consistency are places where rules conflict, especially with timing.  Overall, consistency tends to be easier to achieve in a board game. (And it is in a formal logic system, too.) The important part is making sure that if players follow the rules, they will have a successful game.

Completeness is much more difficult and subtle. It is important part of designing a complex game, because you can set up arbitrary arrangements and see if the rules work to test for consistency, which is useful. But it won’t tell you what conditions the players can be expected to achieve in the game. There may be ways you can set up the board that will lead to an unplayable, unfair, or just uninteresting game. So it is important to step back and look at the rules to see what the game can actually do in action.  This means starting with setup and playing through as soon as possible in the design process. You might find that players never make use of an interesting strategy, and you have to re-balance rules to drive players toward the experience you want. You might find that your ending conditions might never be triggered, and you need some extra criteria to bring the end of the game. It might be that strategies that seem balanced are actually thrown off by the inclusion of a third party, or by some rare but completely legal set of circumstances. These are things that simply studying the rules won’t always tell you, but playtesting might. It might also tell you where you need to clarify and explain rules that are consistent, but don’t explicitly explain what to do in special circumstances.

Fortunately, game designers usually don’t have to worry about the incompleteness theorem. The rules are too limited to create a formal logic system inside a game. (And I’d love to find some games where the game mechanics can be used to create a small computer.) But the concepts of consistency and completeness of a set of rules remain very important to a game, and designers can use them to create rules that work.


, , , , , ,

  1. Today in Board Games Issue #149 - Last Chance to win Dark Horse! Warhammer 40K Conquest - Today in Board Games

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: