Rethinking Game Design

The original formulation of the Situation Model specified that the list of possible Game Inputs to Results for a Situation was the totality of the game's Design.

That's not the case. That listing is called something, but I want the term Game Design to mean something else. And here's why.

Chess is a game (and, when played on a computerized system, a videogame). Basically, Chess the game is just a list of rules. The rules state what the game board is, what the pieces are called and what they can do (not necessarily the look of the pieces), a few special-case rules (castling and en-passant), and what the victory conditions are.

Nowhere in that is any mention of Situation.

Actually, that's a lie: there's one thing I forgot to mention. The rules of Chess state what the initial arrangement of the board is. Or, in our terms, what the initial Situation is.

That's it. The rules of Chess give you a starting Situation and tell you how other Situations resolve from there. In short, the game rules of Chess define how to derive the Game Input and Results.

The Situation model is focused on what a particular player experiences when playing through a game. The player doesn't experience the rules so much as the situation and what can result from them. Now, with Chess, if you don't know the game rules, you can't be expected to perform well; the Knowledge of the game's mechanics is the minimum set of Knowledge needed to play. Then again, that Knowledge is, effectively, Player Input (as well as an understanding of what your opponent can do against you), which as previously stated was vital to the player having any real ability to play the game.

As a player plays through games of Chess, certain facts start becoming evident; Knowledge is gained that is not immediately obvious from the basic rules of Chess. For example, the Queen ought to be the most powerful piece, for she can capture in 8 directions at any range. But her value is only potential value in the beginning of the game. You can move a pawn out of the way such as to be able to deploy your Queen significantly, but then you used a move to do that. Your opponent may counter this.

A Queen stuck in a corner can be far less useful than a Bishop in a more viable region of the play field. In fact, most pieces lose significant power along the edges of the board; that hard barrier cuts off movement possibilities and hamstrings how a piece can move.

These kinds of "emergent Knowledge", where you start to understand something about the game that the rules create, are vital towards effectively being able to play the game. They are a form of Knowledge, and as such, are a part of the Situation Model.

So, in effect, we have a set of game rules that define how the game gets played, but the player doesn't really see that. Instead, the player simply has what the player believes are the possible inputs. The player's understanding of the game comes from being able to determine the emergent Knowledge that the game produces. What are good strategies, etc. Indeed, the player may even ferrit out the game rules themselves, if they are not obvious from the player inputs.

The game rules don't say explicitly that "Queens in corners are bad" or that "Pieces can be pinned in place by other attacking pieces" or that "You can potentially protect a piece from an attack by a valuable piece by moving a piece so that it threatens the square that your piece resides in, thus promising the opponent that he/she will lose that valuable piece". However, each of these is fundamentally built into the rules of the game; they exist because certain rules create these specific effects.

What happens if the Chess board were wrap-around lengthwise? All kinds of things change from that. What if Knights couldn't hop over other pieces? Other things change because of that. And so forth.

So, what is a game's Design? Simple: it is the set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation. The Game Design fully defines how Situations move from one to another, thus the Game Design is what make the Interactive Loop. Game Design is what the game designer creates; the rest (particular Situations, etc) is built implicitly based on the Game Design.

If that's Game Design, then what is the set of Game Input to Result mapping in a Situation? Well, to be technically accurate, the best way to model it in the Situation Model is to have the Game Input pass through the Game Design and then a Result is output. However, I find it useful to consider this to be a potentially enumerable mapping table rather than some black-box process. Therefore, we will simply call it the Game Input to Result Mapping Table.