As I read more of Rules of Play I’m finding it more useful as a jumping off point rather than as a source text. The anecdotes are still useful and interesting, but I often find the points they’re trying to illustrate to be irrelevant or misleading. I do still find their ideas on the play experience interesting and useful.

This latest chapter (15, for those keeping count) is all about uncertainty. They make an interesting point that all games are about uncertainty at their core, in that the outcome of a game is uncertain. While I don’t think that’s strictly required by the definition of game, I believe it captures an important aspect of good games. If one knows before starting whether they’ll win or lose, then the act of playing becomes more of an exercise or activity than a game. If that’s fun then great, but while the designer has created something enjoyable it is perhaps not actually a game. Does that matter? Perhaps…. I appear to have gotten sidetracked. For now I’ll just keep their ideas that games have uncertainty and I’ll move on.

Games are uncertain on the large scale of the final outcome. There are a few lower levels at which it also manifests. The next level down is the uncertainty of the game state from one turn (or series of turns) to another. At the lowest level are individual actions/events which are uncertain. Rules of Play lumps the latter two into the single category of ‘micro-level uncertainty’, but I find it useful to consider them separately.

The book also touches on the idea of different kinds of uncertainty, referring to Richard Epstein’s work ‘The Theory of Gambling and Statistical Logic’ in which he defines certainty (outcome can be predicted with complete accuracy and precision), risk (the odds are known), and uncertainty (the outcome is completely unpredictable). While that’s a mathematically useful breakdown, it doesn’t help me think about designing games because pretty much everything I care about falls in that middle category of risk.

I think of the uncertainty as a set of three triads:
* Strategically known (min-max strategy in tic-tac-toe)
* Strategically predictable (choosing a move in chess)
* Strategically unpredictable (circular advantage, a la Rock-Paper-Scissors)
* Socially known (Kim owes Tony a favor from last turn)
* Socially predictable (Jan likes to play aggressively)
* Socially unpredictable (I don’t know whether Anne thinks Bob or Carla is a greater threat)
* Mathematically known (each turn each player gets three coins)
* Mathematically predictable (the likelihood of making a draw in poker)
* Mathematically unpredictable (the odds are, so to speak, even, e.g. no one number on a die is likely to come up more often than another)

The book gets into the difference between true randomness and apparent randomness, but I don’t think it matters for game design. Whether a number cannot be predicted because the roller of a die is not sufficiently skilled to make it land on a particular number, or because the player does not know the algorithm used, or because it’s based on whether or not a particle decays in a given time does not matter at all from a game design perspective. In my thinking about design, ‘random’ is equivalent to ‘equally unpredictable to all players’.

Related to the uncertainty of outcomes is this triad of information / game state:
* Information is open/known (the points a player has won so far in cribbage)
* Information is hidden/known to a few (who has the rope in Clue) NOTE: partially known information is decomposed to open and unknown.
* Information is unknown (what’s the top card of the draw pile)

One could subdivide all of these into theoretical and actual, but I tend to operate with the idea that the theoretical should be the actual - I find it makes a cleaner board game. E.g. In Puerto Rico the points people win are technically kept hidden, but the it’s open knowledge when anyone gets any points, and how many. Since any player that knows that has a serious strategic advantage it behooves all the players to spend a lot of time memorizing or writing down who got what. The effort of making this theoretical actual bogs down the game and detracts from the [in my mind] more interesting parts. The game group that has a house rule for Puerto Rico that all players point totals are open. Unless we’re specifically designing a memory game, in the games we make we use the rule of thumb that all theoretically open information is actually open.

All these kinds of uncertainty interact on an event, game state, and over-all level. Players start a game with the outcome uncertain, and that uncertainty arises from the compounded uncertainties of the lower levels. The unpredictables give rise to mitigation and opportunism. The predictables give rise to plans / strategies, which are refined using the knowns. As the game progresses the players try to leverage the predictable and known sub-parts to manipulate the overall game state to one in which they’re the known winner.

There’s a lot more I want to talk about related to uncertainty, but this is long enough for now and it seems like a decent closing point.

The next section of the book (Chapter 14) focuses on complexity in games. I don’t find their examples / descriptions of complexity to be especially compelling, but the underlying idea is useful to consider. They tie meaningful play (which in their terms concerns the link between player decision / action and outcome) to complexity (which concerns the way the elements of the game system relate to each other), but by the end of the chapter it feels like they’ve kind of skipped most of the meat of the subject. They end up with a sort of circular reference, where meaningful play requires complexity and complexity is something that’s there when there’s meaningful play. It’s… unsatisfying.

It’s easy to fall into the trap of just writing some kind of critique of the book, but really that inclination isn’t very useful. For one thing, other people might find depth, use, and interest in the very sections I dislike. For another, it’s irrelevant to actual game design. The point of these writings is for me to articulate and formulate my ideas, not to start an argument with someone else about theirs. Thus….

Complexity and games….. actually I don’t find complexity (in a nutshell, the space/behavior between completely predictable and completely chaotic) in itself all that interesting as a game attribute. It’s not something I try to add to a game, at least not directly. Rather, I find it tends to be a side effect of a more elusive goal, emergence. Salen and Zimmerman also spend a fair bit of time talking about emergence this chapter. In brief, emergence is the property of a system that when the system is alive / in action patterns / behaviors appear that are not directly defined by the rules of the system. For example, if you had a billiards table full of animated, programmable billiard balls, you might try these simple rules:

1) all balls start moving at the same speed from random locations and in random directions, all railings provide 100% rebound and the surface is frictionless
2) when a ball collides with a ball of the same parity (solid vs striped) the speed of both balls is halved and ricochet is otherwise normal
3) when a ball collides with a ball of the opposite parity (solid vs striped) the speed of both balls increases by 50% and ricochet is otherwise normal

then you might well end up with an emergent pattern of the balls eventually sorting themselves into clusters of the same parity.

Salen and Zimmerman discuss emergence as a property of the rules of the game, whereas I think of it as a property of the play of the game, and the patterns that emerges are called tactics and strategy (i.e. what distinguishes a possible move from a good move). But call it what you want and place it where you will, emergence is an important part of good game design. Emergence is related to complexity in that systems that exhibit emergence are usually (always?) complex (at least on some level). The real difference between how I think about complexity and emergence and how the book does in this chapter is a matter of focus. The book presents complexity as something that’s necessary in a game and emergence as a side effect of that, whereas I think of emergence as the necessity and complexity as the side effect.

This gets into what I think of as elegance (in this context). Elegance is sort of normalizing emergence by complexity. Assuming for the moment that complexity and emergence are both quantifiable, a game with complexity 5 and emergence 20 is twice as elegant as a game with complexity 5 and emergence 10 or complexity 10 and emergence 20. For a given amount of emergence, the most elegant game is the one with the LEAST complexity. When I design a game I’m not trying to make the rules complex (my co-designers can stop laughing now), my goal (vis a vis complexity and emergence) is to make the rules as elegant as possible. That is, I’m actually trying to make the game as un-complex as possible (really, stop laughing) for the amount (and kind - not by a long stretch is every emergent behavior desirable) of emergence I want.

And that, I think, is where Salen and Zimmerman and I diverge in this chapter. When designing a game, Salen and Zimmerman seem to advocate for making the rules complex because then you get some kind of emergence. I think that instead you should consider what sort of emergence you’d like to foster and then add as few and as simple rules as possible to get that effect. Complexity is a necessary evil of the rules, not something to strive for.

An interesting subset of games are digital (aka computer) games. Computer games have many things in common with other games, but they also have their own particular aspects and issues. I just finished reading the Rules in Digital Games chapter in Rules of Play, and I disagree with most of it. Much of that disagreement arises from my fundamental split on what counts as a game rule, but a large part also comes from the way I go about categorizing games. It also becomes clear in this chapter that one of their rule categories, operational rules, is much broader than I’d thought.

So, digital games. One of the first questions is, what counts as a digital game? World of Warcraft? Definitely. Tetris? Certainly. Civilization? Absolutely. Internet poker? …Maybe, but probably not. Playing against a chess program running on a local machine? I’d say no. Clearly all the games are running on a computer, but I tend to make a distinction between ‘real’ digital games and computerized versions of non-digital games.

Salen and Zimmerman consider all games played on a computer to be digital games, and the elements of the user interface are part of the rules of the game. In some ways this makes sense, because the interface affects the feel and play of the game. However, a rule like “a player may type the left arrow key to move the current piece one space to the left” isn’t something I’d consider a rule of the game (in my mind the rule would be “a player may move the current piece one space left or right”, and whether they accomplish that by typing a key or moving the mouse or waving their arms is irrelevant).

A computer can simulate the physical world (with varying degrees of precision, but the principle holds). Likewise any mode of communication/interaction can (at least in theory, though practice certainly lags) be done in a virtual environment. There’s not a game that exists that couldn’t be implemented digitally. Virtually sitting in virtual Central Park, virtually moving your virtual chess pieces, I think you’re playing a board game, not a computer game. So, how to distinguish between digital and non-digital games? I do think the distinction exists and is useful, but it gets blurry at the boundary, and it doesn’t necessarily produce non-intersecting sets - some games exist as both digital games and non-digital games.

It’s probably useful first to consider some other divisions of games and then get back to digital games. Consider the two rule implementations Tic Tac Toe and 3-to-15 (towards the bottom of the post). You could then ask “is that rule set a math and memory game or a territory control game?”, but I think the better question is “which skin best represents the game state and presents the rules in a way that players understand and interact with most easily?”. The first question doesn’t really have a correct answer beyond ‘it depends’. I think most people would answer the second question as ‘the 3×3 grid where players mark Xs and Os’, and thus that rule set gets placed in the category of [very simple] territory control games.

Returning to digital games, I would define them as those rules sets for which a computer is the easiest/most effective way for a player to understand and interact with the game state and mechanics. A computerized version of Tic Tac Toe is still a simple territory control board game, not a computer game. Master of Orion is definitely a computer game. Risk… is on the fuzzy border. It was created and first produced as a board game, but the most natural implementation of the system is probably on the computer (IMO, other might place it squarely in the board game category). Magic is another game that could reasonably be placed as naturally digital, or naturally a card game, or more likely both.

Various aspects of game mechanics and state make a game likely to work best in digital form: lots of number crunching, information hidden from all players or known to an arbitrary subset of them, lots of randomizers of various kinds, many complex sub parts to actions, automatic changes (especially complex ones) to the game state, etc. You know what they are. I guess it might be worth trying to list them all at some point. Anyway, the point here is that if you’re trying to design a non-digital game and it has these kinds of attributes then maybe its natural representation is as a digital game. Likewise, if your trying to design a digital game and it DOESN’T have any of these attributes, then it may well work better as a board, card, dice, or other non-digital game (which of doesn’t mean that it can’t be implemented on a computer).

One question they examine this chapter is “Are the rules of a digital game the same thing as the programming code that makes up the game?” In some ways this is an interesting question. Certainly the code allows one to play the game. If you make the category of operation rules very broad, enough that it includes all UI, then it’s possible that you could consider that code also part of the game, but this gets you mired in gray areas very quickly. They bring up an interesting example in the game Thief, where the player and the opponents can hide in the simulated shadows. In one sense the code that determines just how dark a shadow is and whether or not a player is hidden might be considered a complicated rule. I could be talked into that. However, without such external influence I’d probably consider the rule to be that entities may hide in sufficiently dark shadows, and leave ’sufficiently’ as a changeable parameter. In designing a game with such a rule have to decide at design time exactly what light values are covered by ’sufficiently’ - that could be set later, or even left totally open. E.g. the game engine just creates and runs the virtual world and whether or not the player looking at the monitor can make out the figure standing in the alley determines what ’sufficiently’ is.

From my perspective the rules of a digital game are the same thing as the rules of a non-digital game; game rules are an abstract system. The computer is one way of implementing them, but I don’t think the game is different in any relevant way if logical bits and electrical signals are used to track and represent the game state rather than painted cardboard and carved wood. The rules of a game may be embedded/represented/implemented in the program code, but the program code is not the rules.

I’m mostly ignoring the realm of implicit rules in digital games. The book counts such things as “the program can be started, stopped, copied, deleted, renamed, etc. like any other program files” as an implicit game rule. Ummm… no. That’s not an implicit rule of a digital game any more than ‘the speed of light will not be exceeded’ is an implicit rule of chess. I’m just going to say that the implicit rules in digital games aren’t of a different nature than implicit rules in any other game, and leave it at that.

As mentioned previously, Salen and Zimmerman divide rules into 3 main categories:
* operational : how the players play the game, e.g. mark an X or O in any box in the grid
* constituative : the underlying formal structure of the game, e.g. given a set of 9 elements and two empty sets, elements are removed from the first set and added alternately in the second and third
* implicit : the unwritten rules of the game, e.g. a player takes their turn within a reasonable amount of time

They then consider as separate games unique combinations of operational and consituative rule sets, though the boundaries are necessarily a bit fuzzy (is it the same game if you use a die as a randomizer instead of a spinner? Or draw cards? Or keep score with chips rather than on a board? etc.) The question of how much a game has to change before it’s a different game is extremely difficult to answer. However, that particular discussion is one for another day. Back to rules…. Reading this section of the book got me thinking about the un-articulated ways I group rules. I haven’t really bothered to make it clear to myself before, and it’s probably a good exercise to do so.

When I design a game I don’t think too much about the implicit rules. There certainly are some, as well as some amount of assumed vocabulary (e.g. that ‘take turns’, ‘go around the table’, ‘deal cards one at a time’, etc. are terms that don’t need to be explicitly defined in the rules). So, I mostly think about what the authors call constituative and operational rules. However, I don’t mentally put them in those groups. I split them into two large groups, each of which is subdivided into two groups.

The first large group is the rules of meaning. The first subset of rules are the definitions of the parts of the game, which cover things like the attributes of the randomizers, the characteristics of the board (or other play space), the pieces, etc. The second subset of rules are the evaluations, which cover what the parts mean to the players. Basically, these rules allow the players to evaluate the state of the game - who’s ahead, who’s behind, is the game over, did anyone win, etc. The meanings rules cover specific terminology (symbol set maps, whether to words or objects), and underlying structures. The second large group is the rules of transformation. The first subset of these are the mechanics, which deal with how all the parts interact with each other. The second subset are the operations, which cover the way players may manipulate the game state. The transformation rules also deal with both the abstract game system and the representations the players use.

Looking at chess, for example:
meanings - definition: the board, the pieces, where the pieces start on the board, being captured
meanings - evaluations: check, checkmate, stalemate
transformations - mechanics: how each piece may move and capture, special moves (en passant, castling), capturing, promotion
transformations - operations: white first, take turns, dealing with check, castling conditions, resigning, touch-move

My division of rules arises from the way I design games. I don’t [usually] come up with an abstract game system and then lay operational rules on it (nor vice versa). The first rules I usually come up with tend to be mechanics and their related definitions. From there I consider possible related definitions (for what other things could that kind of mechanic be used), related mechanics (what other things can I do with those things I’ve defined). Then the evaluations and operations come into play, giving direction and interest. Also tossed into the mix are the skin (what sort of things do I want the player to be thinking about and doing), the theme (the topic or story, if any, e.g. Pirates, or Escape, or War, or Running With Scissors, or whatever), and the feel (serious, fast, light, silly, deliberate, etc.).

My approach could be considered just a different slice on the same set the authors talk about. One could stick definitions and mechanics together and get something like the constituative rule, and likewise evaluations and operations could be the operational rules. However, it’s not quite an exact match. The operational rules as described in the book lean a little more towards what I think of as the skin of the game (which is also related to the theme of the game…). This gets back into the question of how different do two games have to be to be different games. Basically, when I look at two games I consider them the same if their abstract systems are the same. To use the terms in the book, if two games have the same constituative rules I think of them as the same game.

Clearly, that’s a designer bias. From a player’s perspective, how you play the game can make a huge difference even when the underlying systems are the same. The book has a great example in this regard (Rules of Play page 128-129)-

Consider the standard game of Tic Tac Toe. Then consider the game 3-to-15 by Marc LeBlanc. 3-to-15 works like this:
1. players alternate turns picking a [whole] number from 1 to 9 that has not yet been picked.
2. if a player manages to get a set of three number that sum to 15, that player wins.
3. if all the number have been picked and no one has won then te game is a draw.
From a players perspective they’re completely different games. However, consider this matrix
294
753
618
which illustrates the winning sets of three numbers on the rows, columns, and diagonals, and also demonstrates that the abstracts systems of the two games are identical.

Wearing my player hat I’d consider the two games to be different (at least until I figured out the matrix). Wearing my designer hat I’d consider the games to be the same, but with different skins. Skins are highly relevant in designing a game, not just something that’s thrown on after the abstract system is created. The skin determines in large part how the player feels about the game and type of things the player tries to do, e.g. whether a player thinks about territory control and position or arithmetic and set theory. HOWEVER, I don’t consider myself to have designed a new game if I put a new skin on an existing system, I would probably call it a variant (of a particular kind, more on that when I get around to the what-makes-a-different-game discussion).

Salen and Zimmerman consider game rules to have these characteristics:
- limit player action
- explicit (more regarding this in a moment)
- unambiguous
- shared by all players
- fixed (on some level, even if fluid on others)
- binding
- repeatable

The first point is to them the most important one: “Rules Limit Player Action. The chief way that rules operate is to limit the activities of players.” For me that doesn’t work. I understand what they’re getting, but when I consider rules from that perspective I find it doesn’t help me in designing a game. To discuss why I have a problem with it I need to get into the discussion of kinds of rules.

Salen and Zimmerman break rules into three categories: operational rules (how the players play the game, e.g. mark an X or O in any box in the grid), constituative (the underlying formal structure of the game, e.g. given a set of 9 elements and two empty sets, elements are removed from the first set and added alternately in the second and third), and implicit (the unwritten rules of the game, e.g. a player takes their turn within a reasonable amount of time). Those categories aren’t exactly what I would have used (thoughts on my rules categories are for a later post), but they’re close enough. Reconciling the category of ‘implicit rules’ with the the trait ‘rules are explicit’ is… tricky. It’s not explored yet in the book, but for now I’m just going to use the simple distinction that operative and constituitive rules are explicit, and implicit ones aren’t.

The relevant complication arises in the interaction between the category of implicit rules and the idea that rules limit player action. While it’s true that rules do in fact limit player action, by counting everything that limits player action as an implicit rule in the game one quickly gets an unbounded list of rules, ranging from ‘players may not take too long on their turn’ to ‘players shall not shoot their opponents’ and beyond. By defining game rule in such an open ended manner the list of implicit rules ends up including every potential action that is not limited by physics alone. There are a number of problems I have with that. The biggest problem is that thinking of game rules as having such a broad extent is detrimental to my design process.

For my thinking, game rules have all the qualities that the authors state, EXCEPT, the first is replaced with this narrower concept:
Rules define meaningful actions. The chief way that rules operate is to define the actions that a player may do that affect the state of the game.

In my mind this gets much more at the idea of what is a game rule. Much of what Salen and Zimmerman would consider the implicit rules of a game is excluded by this. They use an example that in Yahtzee players don’t eat the dice because there’s a Yahtzee rule (implicit) that says ‘players may not eat the dice’. In my understanding that wouldn’t be a rule, implicit or otherwise. Most of that kind of thing I’d put under the general heading of what it means to play a game, with sidetracks into etiquette, sportsmanship, and nutrition.

One difficult thing with my approach is that strictly defining cheating is a little trickier, but far from impossible. For example, in most games of Monopoly stealing money from the bank would be cheating. With the authors’ definition of game rules, stealing would be cheating because there’s an implicit (or sometimes explicit) rule that a player may not steal (IMPORTANT NOTE: I haven’t yet gotten to the book’s discussion of play and cheating, I’m just inferring that’s how cheating is defined based on the definitions and framework the book has so far presented). With my definition stealing would be cheating because it would not be listed as one of the ways a player may manipulate the state of the game. In the authors’ version cheating is breaking a rule (and there are many, many implicit rules, proscribing the various ways that players might otherwise cheat). In my version cheating is manipulating the state of the game in a way that’s not listed in the rules (which is my general definition of ‘cheat’, and then there’s a single implicit rule of ‘a player may not cheat’).

I expect this very low level split in thinking about the purpose and definition of game rules will lead to many more divides as the book goes on. However, I have faith that there’s a good reason for the authors’ particular approach - I expect it will lead to some approaches to game design I have not considered (and likewise I expect some of my approaches to game design are excluded by the authors’ definitions).