Saturday, November 26, 2005
There are a few publications by the Game Design Patterns Project that are related to the work of Bernd Kreimeier, and he's noted as one of the group's associates. The works are more about the mechanics of gameplay than software.
Saturday, November 19, 2005
Raph Koster
So I spent yesterday afternoon, and some of the evening, arguing engaged in lively debate with Raph Koster. Basically I agreed with some of his ideas, and suggested some of my own, he said my ideas sucked, more or less -- he actually said my thinking was a mistake (three times!) and flawed, and even said I was just plain wrong about one thing in particular -- and so it was on, on like Donkey Kong.
Footnote: I'd included my last reply to Koster here whilst awaiting moderation, but it has since been published, see the above link.
Footnote: I'd included my last reply to Koster here whilst awaiting moderation, but it has since been published, see the above link.
Thursday, November 17, 2005
Bernd Kreimeier
The Case For Game Design Patterns
Bernd Kreimeier's Game Design Patterns are inspired by the work of Christopher Alexander and Gamma et al, about patterns in architecture and object-oriented software respectively. While recognising more specific applications of patterns to game design such as the work of Simpson, Kreiemier has opted to take a less software-specific approach and instead apply the design pattern methodology to gameplay of videogames instead of the code.
The pattern approach involves identifying a problem, and then coming up with, or recognising existing, solutions for that problem, discussing them, and giving them names. The main crux of patterns is giving a name to a commonly appearing concept so that designers can more efficiently communicate about it instead of having to repeatedly explain it. Patterns are named problem-solution pairs aimed at forming the basis of a design discourse for a given domain.
Kreiemier's game pattern template involves the following elements: name, problem, solution, consequences, examples and references. His work has attempted to translate the work of others, such as Crawford, Adams & Rollings, Barwood & Falstein and Church, into the pattern format. For example, in his "Paper-Rock-Scissors" pattern, he borrows Crawford's concept of "triangularity" and uses Adams & Rollings' warrior-barbarian-archer example to explain how the problem of avoiding a dominant strategy is solved by introducing non-transitive relationships. The name of the pattern is derived from the popular game of the same name in which Rock beats Scissors, Scissors beats Paper, and yet Paper beats Rock -- each strategy is equal, or at least no one strategy beats all others. Once game designers are aware of this pattern, such a structure within the design of a gameplay can thus be referred to by the name Scissor-Paper-Rock without having to be explained in detail as above.
Bernd Kreimeier's Game Design Patterns are inspired by the work of Christopher Alexander and Gamma et al, about patterns in architecture and object-oriented software respectively. While recognising more specific applications of patterns to game design such as the work of Simpson, Kreiemier has opted to take a less software-specific approach and instead apply the design pattern methodology to gameplay of videogames instead of the code.
The pattern approach involves identifying a problem, and then coming up with, or recognising existing, solutions for that problem, discussing them, and giving them names. The main crux of patterns is giving a name to a commonly appearing concept so that designers can more efficiently communicate about it instead of having to repeatedly explain it. Patterns are named problem-solution pairs aimed at forming the basis of a design discourse for a given domain.
Kreiemier's game pattern template involves the following elements: name, problem, solution, consequences, examples and references. His work has attempted to translate the work of others, such as Crawford, Adams & Rollings, Barwood & Falstein and Church, into the pattern format. For example, in his "Paper-Rock-Scissors" pattern, he borrows Crawford's concept of "triangularity" and uses Adams & Rollings' warrior-barbarian-archer example to explain how the problem of avoiding a dominant strategy is solved by introducing non-transitive relationships. The name of the pattern is derived from the popular game of the same name in which Rock beats Scissors, Scissors beats Paper, and yet Paper beats Rock -- each strategy is equal, or at least no one strategy beats all others. Once game designers are aware of this pattern, such a structure within the design of a gameplay can thus be referred to by the name Scissor-Paper-Rock without having to be explained in detail as above.
Wednesday, November 16, 2005
TeXToWebPublishing (ttwp)
I've found this great program called TeXToWebPublishing (ttwp) that converts LATEX to html/image pages. So I've started to create a draft of my thesis dissertation with various bits and pieces from this blog.
Friday, November 11, 2005
Zack Booth Simpson
Game Programming Patterns OR Design Pattern for Computer Games
Simpson thinks "an industry-wide shared vocabulary would be a very good thing". As such, he has taken the work of Gamma et. al., to do with Object-Oriented Software Design Patterns, and applied the idea to game programming. Inspired by Smalltalk's Model-View-Controller pattern (which corresponds to Gamma et. al's Observer pattern and combinations with Composite, Factory Method and Strategy patterns), Simspson has created 3 categories of patterns (or classes):
The three fundamental patterns, Model, View and Controller have the following properties:
Simpson thinks "an industry-wide shared vocabulary would be a very good thing". As such, he has taken the work of Gamma et. al., to do with Object-Oriented Software Design Patterns, and applied the idea to game programming. Inspired by Smalltalk's Model-View-Controller pattern (which corresponds to Gamma et. al's Observer pattern and combinations with Composite, Factory Method and Strategy patterns), Simspson has created 3 categories of patterns (or classes):
- Model
- Model Database
- Spatial Index
- Gateway
- Type Database
- View
- Render Delegation
- Appearance Map
- Controller
- Mini-kernel
- Double Buffered State
- Trigger
- Controller State Machine
- Usecode
The three fundamental patterns, Model, View and Controller have the following properties:
- Model
- maintains state of game world
- read-only by Views
- read-write by Controllers
- View
- knows how to render Models
- invisible to Models
- invisible to Controllers
- Controller
- process, changes state of Models
- created by Models
- (yet) invisible to Models
- invisible to Views
- Also Known As -- other names for the pattern
- Intent -- what the pattern does
- Motivation -- why the pattern is needed
- Implementation -- issues to do with coding
- Related Patterns -- similar patterns and suggested combinations
- Thanks to -- acknowledging expert advice
Thursday, November 10, 2005
Ben Cousins
Low Level Game Design: Atoms, Measurement and Hierarchies
Ben Cousins suggests some approaches to augment current game design:
Cousins suggests that the lowest level of design, corresponding to player input at the level of gameplay action, could serve as the basis for an "atomic model". This atomic model could be useful for analysis of games in terms of measuring. Cousins is very big on using measurement techniques when designing a game, and argues that "sweet spots" for various games can be found for the following:
The four main points of Cousins' work -- low-level game design, an atomic model, measurement techniques and hierarchies -- can be thought of as a single approach. The environment of a game and its associated gameplay, along with the representation of these, can all be viewed as composite structures, with low-level components being suitable for measurement and possible adjustment in order to improve the overall design of the game.
Ben Cousins suggests some approaches to augment current game design:
- low-level game design
- an atomic model
- measurement techniques
- hierarchies
Cousins suggests that the lowest level of design, corresponding to player input at the level of gameplay action, could serve as the basis for an "atomic model". This atomic model could be useful for analysis of games in terms of measuring. Cousins is very big on using measurement techniques when designing a game, and argues that "sweet spots" for various games can be found for the following:
- time, e.g. jumping time (of an avatar)
- distance, e.g. distance to a "choke point" in a map
- density, e.g. "atoms" or events "per primary element"
- area, e.g. 2D screen space (of an avatar's animation)
The four main points of Cousins' work -- low-level game design, an atomic model, measurement techniques and hierarchies -- can be thought of as a single approach. The environment of a game and its associated gameplay, along with the representation of these, can all be viewed as composite structures, with low-level components being suitable for measurement and possible adjustment in order to improve the overall design of the game.
Monday, November 07, 2005
State of the Art relevance
The Art of Computer Game Design - Chris Crawford
Game Theory: Interaction, Conflict and Safety.
Visualisation: Representation.
Patterns: Not really.
Low Level Game Design - Ben Cousins
Game Theory: Gameplay "atoms" are analogous to "moves" in Game Theory.
Visualisation: Spatial design of levels, positioning of avatars, etc.
Patterns: Composite?
Game Programming Patterns & Idioms - Chris Hecker & Zack Booth Simpson
Game Theory: Not really.
Visualisation: Model-View-Controller, and some graphics-specific patterns.
Patterns: Very much so, but perhaps too specific.
Game Design Patterns - Bernd Kreimeier et al
Game Theory: Sort of -- Scissor-Paper-Rock to avoid dominant strategy.
Visualisation: Not sure.
Patterns: Very much so, but perhaps too abstract.
The Designer’s Notebook - Ernest Adams
Game Theory: Explicitly mentions the field several times and explains concepts like dominant strategies. Often mentions "internal economy" of a game.
Visualisation: Cites the works of Edward Tufte, and has a good representation/visualisation article, "Cartographic Cartwheels".
Patterns: Sort of -- "internal economy" of the game is a kind of pattern.
Will Wright and Sid Meier
Game Theory: Not sure about Wright, but Meier's famous quote is "a game is a series of interesting choices".
Visualisation: Wright likes to wrap his "possibility space" in metaphors -- thematic visualisation? -- so that players develop a "mental map".
Patterns: Wright's "possibility space" a pattern?
I Have No Words & I Must Design - Greg Costikyan (extends Crawford)
Game Theory: Sort of -- similar to Crawford with definition of what a game is.
Visualisation: talks about things like Tokens and Colour, somewhat related.
Patterns: Not really.
A Grammar of Gameplay - Raph Koster (attempts to extend Cousins?)
Game Theory: again, like Cousins, the "atoms" or "ludemes" are "moves" in Game Theory.
Visualisation: There is a bit about visual representation of gameplay movement, but the visualisation in Koster's work is more about that of the game design rather than the graphics within the game.
Patterns: His attempted notation is a kind of pattern language.
MDA: Mechanics, Dynamics, Aesthetics - Marc LeBlanc (oft-mentioned)
Game Theory: Not really, but does talk about feedback (a la thermostat).
Visualisation: Not really.
Patterns: Each of the 3 levels, Mechanics, Dynamics and Aesthetics could be a pattern?
FADTs: Formal Abstract Design Tools - Doug Church (like patterns but not)
Game Theory: Not really, though some FADTs could qualify perhaps.
Visualisation: Not really, though some FADTs mention things like needing clear communication with the player.
Patterns: Like Game Design Patterns but not problem/solution pairs, just vocabulary.
The 400 Project - Hal Barwood & Noah Falstein (like patterns but really not)
Game Theory: Not really, though some rules could qualify perhaps (as with FADTs).
Visualisation: Not really, though some rules mention things like needing clear communication with the player (as with FADTs).
Patterns: Like Game Design Patterns but not problem/solution pairs, just laws.
Game Theory: Interaction, Conflict and Safety.
Visualisation: Representation.
Patterns: Not really.
Low Level Game Design - Ben Cousins
Game Theory: Gameplay "atoms" are analogous to "moves" in Game Theory.
Visualisation: Spatial design of levels, positioning of avatars, etc.
Patterns: Composite?
Game Programming Patterns & Idioms - Chris Hecker & Zack Booth Simpson
Game Theory: Not really.
Visualisation: Model-View-Controller, and some graphics-specific patterns.
Patterns: Very much so, but perhaps too specific.
Game Design Patterns - Bernd Kreimeier et al
Game Theory: Sort of -- Scissor-Paper-Rock to avoid dominant strategy.
Visualisation: Not sure.
Patterns: Very much so, but perhaps too abstract.
The Designer’s Notebook - Ernest Adams
Game Theory: Explicitly mentions the field several times and explains concepts like dominant strategies. Often mentions "internal economy" of a game.
Visualisation: Cites the works of Edward Tufte, and has a good representation/visualisation article, "Cartographic Cartwheels".
Patterns: Sort of -- "internal economy" of the game is a kind of pattern.
Will Wright and Sid Meier
Game Theory: Not sure about Wright, but Meier's famous quote is "a game is a series of interesting choices".
Visualisation: Wright likes to wrap his "possibility space" in metaphors -- thematic visualisation? -- so that players develop a "mental map".
Patterns: Wright's "possibility space" a pattern?
I Have No Words & I Must Design - Greg Costikyan (extends Crawford)
Game Theory: Sort of -- similar to Crawford with definition of what a game is.
Visualisation: talks about things like Tokens and Colour, somewhat related.
Patterns: Not really.
A Grammar of Gameplay - Raph Koster (attempts to extend Cousins?)
Game Theory: again, like Cousins, the "atoms" or "ludemes" are "moves" in Game Theory.
Visualisation: There is a bit about visual representation of gameplay movement, but the visualisation in Koster's work is more about that of the game design rather than the graphics within the game.
Patterns: His attempted notation is a kind of pattern language.
MDA: Mechanics, Dynamics, Aesthetics - Marc LeBlanc (oft-mentioned)
Game Theory: Not really, but does talk about feedback (a la thermostat).
Visualisation: Not really.
Patterns: Each of the 3 levels, Mechanics, Dynamics and Aesthetics could be a pattern?
FADTs: Formal Abstract Design Tools - Doug Church (like patterns but not)
Game Theory: Not really, though some FADTs could qualify perhaps.
Visualisation: Not really, though some FADTs mention things like needing clear communication with the player.
Patterns: Like Game Design Patterns but not problem/solution pairs, just vocabulary.
The 400 Project - Hal Barwood & Noah Falstein (like patterns but really not)
Game Theory: Not really, though some rules could qualify perhaps (as with FADTs).
Visualisation: Not really, though some rules mention things like needing clear communication with the player (as with FADTs).
Patterns: Like Game Design Patterns but not problem/solution pairs, just laws.
Sunday, November 06, 2005
State of the Art: Reloaded
I've reshuffled my State of the Art after some more reading.
These are the most relevant to my work:
Anyway that's that.
These are the most relevant to my work:
- The Art of Computer Game Design - Chris Crawford
- Low Level Game Design - Ben Cousins
- Game Programming Patterns & Idioms - Chris Hecker & Zack Booth Simpson
- Game Design Patterns - Bernd Kreimeier et al
- The Designer’s Notebook - Ernest Adams
- Will Wright and Sid Meier
- I Have No Words & I Must Design - Greg Costikyan (extends Crawford)
- A Grammar of Gameplay - Raph Koster (attempts to extend Cousins?)
- MDA: Mechanics, Dynamics, Aesthetics - Marc LeBlanc (oft-mentioned)
- FADTs: Formal Abstract Design Tools - Doug Church (like patterns but not)
- The 400 Project - Hal Barwood & Noah Falstein (like patterns but really not)
Anyway that's that.
Saturday, November 05, 2005
State of the Art notes
The Art of Computer Game Design - Chris Crawford
Chris Crawford says that all games have four main properties, namely: Representation, Interaction, Conflict and Safety. Representation means that a game is merely a representation of some kind of situation. Interaction means that the game involves input by players, and this input is reflected by output of the game, or other players involved in the game. Conflict doesn't mean violence, but means that the players of a game must have conflicting objectives and players must either win or lose. Safety means that a game is just a game, and the actions within a game do not spill out into the "real world" and have consequences beyond the bounds of the "game world".
Game Programming Patterns & Idioms - Chris Hecker & Zack Booth Simpson
Zack Booth Simpson and Chris Hecker co-authored a column for Game Developer magazine in which they identified patterns in game development. These patterns existed in both the process of game design, and the game design as artifact. The part that is relevant to my research is the patterns identified in a game's design. Simpson has attempted to create a set of patterns applicable to the domain of game design in terms of object-oriented software-engineering, a la Gamma et al. However, instead of creating a framework by adapting the existing object-oriented design patterns, Simpson has created a collection of his own game-specific patterns with the only exception being his use of the Model-View-Controller paradigm (exemplified by the Observer pattern, however this is not explicitly noted) as a foundation for his work. I liken some of the patterns to inventing a "four-point turn" when a "three-point turn" already exists, and while his attempt is worthy, it misses the mark with regards to the formulation of a framework which would ultimately rely on the existing patterns of Gamma et al.
The Designer’s Notebook - Ernest Adams
Adams is one of the few game designers who explicitly mentions mathematical game theory, and perhaps the only game designer to explicitly cite the information visualisation works of Edward Tufte. The topics of his many articles are varied, but one of the highlights is his talk about game design fundamentals in which he explains the "internal economy" of games. For example, a first-person-shooter involves resources such as ammo and health, and both of these have sources and sinks. Ammo has ammo pick-ups as a source, and shooting of weapons as a sink. Health has health pick-ups as a source, and being shot by weapons as a sink.
A Grammar of Gameplay - Raph Koster
Raph Koster's work is to do with creating a notation with which you can show gameplay. Akin to musical notation, his idea firstly involves identifying the base elements of gameplay, or "ludemes" (a term I believe he credits to Ben Cousins), and then creating a graphical representation of these. This is nothing to do with computer graphics, or the graphical display of game elements per se, however there does seem to be room in his possible notation for defining some kind of spatial or graphical elements of a game's design.
Low Level Game Design - Ben Cousins
Ben Cousins believes in designing games using a bottom-up approach. He likes to concentrate on what he calls game "atoms", as well as the measurements and hierarchies that exist within games. The atoms that Cousins refers to are the lowest-resolution elements of gameplay, such as jumping or firing a weapon. His idea of atoms is most likely very much like the idea of "moves" in mathematical game theory, however he doesn't explicitly say as much. His idea of hierarchies is related to his idea of atoms. Basically he takes a game, breaks that down into levels, then breaks those down into smaller sub-tasks, and then keeps breaking things down until he reaches the level of his game atom. As for measurements, Cousins believes that there is merit in recording both timing and spatial attributes of game design. For example, the size of a level and how long it takes a player to navigate to a particular location, or the amount of screenspace an avatar takes up, or even the amount of time a jump should take (he believes 0.7 seconds is the sweet spot, and suggested to Barwooed and Falstein that this should become one of their rules, however it was rejected as being too specific.
Will Wright and Sid Meier
Will Wright is very good at analogy and borrowing ideas not only from other entertainment media (such as CareBear cartoons) and traditional games (such as Go) but also from seemingly unrelated fields of knowledge (such as cellular automata and robotics). His games are, by his own admission, not games as such, but toys. He creates these artifacts and worlds and defines rules for their use, and thus he defines what inputs they can take, and what the resulting behaviours and outputs will be, but he doesn't explicitly define winning and losing states. Instead, he lets the player decide what they want to make as goals, and lets the toys accommodate these. One of the main ideas he has is that a game is just a bunch of numbers (think code) inside a computer, and to make this interesting to players he wraps this in a (graphical) metaphor. With regards to visualisation, he talks about the picture or structure of ideas that people have in their heads, and states that one of the main causes of conflict between people is that their mental pictures of what's going on differs from one another. What he emphasises is the externalising of this mental picture, as a model (which is actually predominantly visual, however the form of something is just the "wrapping" of the model).
Meier's contribution is short and sweet: "a game is a series of interesting choices". This is exactly what a game is in terms of mathematical game theory.
I Have No Words & I Must Design - Greg Costikyan
Greg's work basically repeats what Crawford says, but adds a few specific bits and pieces such as tokens, etc., which seem to stem from Costikyan's history as a board game designer. Nothing new here, however the structure of his work gives the discussion of games versus toys, puzzles, etc. more emphasis (in terms of the ratio of space it takes up in the article) than Crawford. As the title suggests, Costikyan desires a common vocabulary for game design.
FADTs: Formal Abstract Design Tools - Doug Church
The name is catchy, however Church's FADTs are not very formal, perhaps overly abstract, and have limited use as tools for design. He does identify a need for a common vocabulary in game design, however his collection of "tools" are more like patterns, and there's not any real method to follow.
The 400 Project - Hal Barwood & Noah Falstein
These are more like recipes for making games, howevere they are very abstract, and perhaps not applicable to all games, but more to specific classes of games. The idea that certain rules trump other rules and the lack of a hierarchial organisation of their rules collection makes it another collection of vague game design wisdom that's not directly implementable.
Game Design Patterns - Bernd Kreimeier et al
Kreimeier starts off well enough, espousing the virtues of patterns for games, which is akin to the work of Simpson and Hecker, however his patterns diverge from the realm of software to the realm of the 400 rules and FADTs in that they're not directly implemtable as code or any kind of framework. Design patterns should relate more closely to structure albeit at an abstract level, however the Game Design Patterns are too abstract.
MDA: Mechanics, Dynamics, Aesthetics - Marc LeBlanc
MDA is an approach to "reverse engineering fun". Mechanics are the rules of the game, dynamics is the gameplay or use of the rules by players, and aesthetics is the player's emotional response. LeBlanc surmises that if you want a particular player response you can work backwards and identify the kind of dynamics that can create these aesthetics, and in term determine the required mechanics and wa-lah, there's your game. His analogy of a thermostat mechanism for how a game should give feedback, i.e. it regulates difficulty of the game based on player performance and skill, is good, but is merely an aside within this work.
Chris Crawford says that all games have four main properties, namely: Representation, Interaction, Conflict and Safety. Representation means that a game is merely a representation of some kind of situation. Interaction means that the game involves input by players, and this input is reflected by output of the game, or other players involved in the game. Conflict doesn't mean violence, but means that the players of a game must have conflicting objectives and players must either win or lose. Safety means that a game is just a game, and the actions within a game do not spill out into the "real world" and have consequences beyond the bounds of the "game world".
Game Programming Patterns & Idioms - Chris Hecker & Zack Booth Simpson
Zack Booth Simpson and Chris Hecker co-authored a column for Game Developer magazine in which they identified patterns in game development. These patterns existed in both the process of game design, and the game design as artifact. The part that is relevant to my research is the patterns identified in a game's design. Simpson has attempted to create a set of patterns applicable to the domain of game design in terms of object-oriented software-engineering, a la Gamma et al. However, instead of creating a framework by adapting the existing object-oriented design patterns, Simpson has created a collection of his own game-specific patterns with the only exception being his use of the Model-View-Controller paradigm (exemplified by the Observer pattern, however this is not explicitly noted) as a foundation for his work. I liken some of the patterns to inventing a "four-point turn" when a "three-point turn" already exists, and while his attempt is worthy, it misses the mark with regards to the formulation of a framework which would ultimately rely on the existing patterns of Gamma et al.
The Designer’s Notebook - Ernest Adams
Adams is one of the few game designers who explicitly mentions mathematical game theory, and perhaps the only game designer to explicitly cite the information visualisation works of Edward Tufte. The topics of his many articles are varied, but one of the highlights is his talk about game design fundamentals in which he explains the "internal economy" of games. For example, a first-person-shooter involves resources such as ammo and health, and both of these have sources and sinks. Ammo has ammo pick-ups as a source, and shooting of weapons as a sink. Health has health pick-ups as a source, and being shot by weapons as a sink.
A Grammar of Gameplay - Raph Koster
Raph Koster's work is to do with creating a notation with which you can show gameplay. Akin to musical notation, his idea firstly involves identifying the base elements of gameplay, or "ludemes" (a term I believe he credits to Ben Cousins), and then creating a graphical representation of these. This is nothing to do with computer graphics, or the graphical display of game elements per se, however there does seem to be room in his possible notation for defining some kind of spatial or graphical elements of a game's design.
Low Level Game Design - Ben Cousins
Ben Cousins believes in designing games using a bottom-up approach. He likes to concentrate on what he calls game "atoms", as well as the measurements and hierarchies that exist within games. The atoms that Cousins refers to are the lowest-resolution elements of gameplay, such as jumping or firing a weapon. His idea of atoms is most likely very much like the idea of "moves" in mathematical game theory, however he doesn't explicitly say as much. His idea of hierarchies is related to his idea of atoms. Basically he takes a game, breaks that down into levels, then breaks those down into smaller sub-tasks, and then keeps breaking things down until he reaches the level of his game atom. As for measurements, Cousins believes that there is merit in recording both timing and spatial attributes of game design. For example, the size of a level and how long it takes a player to navigate to a particular location, or the amount of screenspace an avatar takes up, or even the amount of time a jump should take (he believes 0.7 seconds is the sweet spot, and suggested to Barwooed and Falstein that this should become one of their rules, however it was rejected as being too specific.
Will Wright and Sid Meier
Will Wright is very good at analogy and borrowing ideas not only from other entertainment media (such as CareBear cartoons) and traditional games (such as Go) but also from seemingly unrelated fields of knowledge (such as cellular automata and robotics). His games are, by his own admission, not games as such, but toys. He creates these artifacts and worlds and defines rules for their use, and thus he defines what inputs they can take, and what the resulting behaviours and outputs will be, but he doesn't explicitly define winning and losing states. Instead, he lets the player decide what they want to make as goals, and lets the toys accommodate these. One of the main ideas he has is that a game is just a bunch of numbers (think code) inside a computer, and to make this interesting to players he wraps this in a (graphical) metaphor. With regards to visualisation, he talks about the picture or structure of ideas that people have in their heads, and states that one of the main causes of conflict between people is that their mental pictures of what's going on differs from one another. What he emphasises is the externalising of this mental picture, as a model (which is actually predominantly visual, however the form of something is just the "wrapping" of the model).
Meier's contribution is short and sweet: "a game is a series of interesting choices". This is exactly what a game is in terms of mathematical game theory.
I Have No Words & I Must Design - Greg Costikyan
Greg's work basically repeats what Crawford says, but adds a few specific bits and pieces such as tokens, etc., which seem to stem from Costikyan's history as a board game designer. Nothing new here, however the structure of his work gives the discussion of games versus toys, puzzles, etc. more emphasis (in terms of the ratio of space it takes up in the article) than Crawford. As the title suggests, Costikyan desires a common vocabulary for game design.
FADTs: Formal Abstract Design Tools - Doug Church
The name is catchy, however Church's FADTs are not very formal, perhaps overly abstract, and have limited use as tools for design. He does identify a need for a common vocabulary in game design, however his collection of "tools" are more like patterns, and there's not any real method to follow.
The 400 Project - Hal Barwood & Noah Falstein
These are more like recipes for making games, howevere they are very abstract, and perhaps not applicable to all games, but more to specific classes of games. The idea that certain rules trump other rules and the lack of a hierarchial organisation of their rules collection makes it another collection of vague game design wisdom that's not directly implementable.
Game Design Patterns - Bernd Kreimeier et al
Kreimeier starts off well enough, espousing the virtues of patterns for games, which is akin to the work of Simpson and Hecker, however his patterns diverge from the realm of software to the realm of the 400 rules and FADTs in that they're not directly implemtable as code or any kind of framework. Design patterns should relate more closely to structure albeit at an abstract level, however the Game Design Patterns are too abstract.
MDA: Mechanics, Dynamics, Aesthetics - Marc LeBlanc
MDA is an approach to "reverse engineering fun". Mechanics are the rules of the game, dynamics is the gameplay or use of the rules by players, and aesthetics is the player's emotional response. LeBlanc surmises that if you want a particular player response you can work backwards and identify the kind of dynamics that can create these aesthetics, and in term determine the required mechanics and wa-lah, there's your game. His analogy of a thermostat mechanism for how a game should give feedback, i.e. it regulates difficulty of the game based on player performance and skill, is good, but is merely an aside within this work.