Of Videogames and Visualisations

Saturday, November 26, 2005

Game Design Patterns

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.

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.

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):
  • Model
    • Model Database
    • Spatial Index
    • Gateway
    • Type Database
  • View
    • Render Delegation
    • Appearance Map
  • Controller
    • Mini-kernel
    • Double Buffered State
    • Trigger
    • Controller State Machine
    • Usecode
This list is very much programming-specific. It is not meant to be complete or apply to all types of games, but instead has a bias in favour of fixed-point-of-view real-time-strategy/adventure games due to the author's experience with them.

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
The format of this catalogue also borrows from the original, with sections:
  • 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
Some of the patterns defined by Simpson are possibly unrecognised combinations (or redefinitions) of patterns by Gamma et. al., however the listing for each new pattern at least references existing patterns it is related to. The collection of game programming patterns is, as the title suggests, specific to programming and is not necessarily applicable to design at the level of gameplay. Nonetheless they give valuable insight into the structure of a game from a game-as-code perspective.

Thursday, November 10, 2005

Ben Cousins

Low Level Game Design: Atoms, Measurement and Hierarchies

Ben Cousins suggests some approaches to augment current game design:
  • low-level game design
  • an atomic model
  • measurement techniques
  • hierarchies
A game involves an input and output loop. Players provide input and the game responds with output. This loop can be viewed at different resolutions. A high level example might define the input as simply "save the princess" while the output is the collection of all the game's enemies, levels or encounters. A medium level example might have "get to the end of level 1" as the input and the level design and enemy placement as the output. A low level example of input might be "shoot gun" with the output being gun fires, bullet hits, enemy dies -- each of which correspond to actual sounds and animations, game physics and changes in game state. Lower levels of design are nested within higher levels, with the lowest level involving the direct mapping of player input via a controller to game output via graphics and sound (and touch if using a vibrating controller).

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)
Lastly, instead of a bundle of gameplay concepts, e.g. running, missions, story, etc., Cousins believes in creating a hierarchy for a game's design. For example, running is part of missions and a sequence of missions makes a story.

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.

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:
These are somewhat relevant but either redundant due to the above or here only because they're often referenced by others (which I suppose doesn't lend any credibility per se, but let's just go with mob-rule for now):
I promoted Kreimeier's Game Design Patterns and demoted Koster's Grammar of Gameplay. The reasons are that Kreimeier's work, while a bit too abstract, is at least somewhat more formal than the "Formal" Abstract Design Tools or the 400 Project, and serves as a good contrast to Simpson's Game Programming Patterns. I'm trying to fit somewhere between Kreimeier and Simpson with regard to abstraction and application of design patterns. Koster's work is good, but it basically repeats Cousins' idea of atoms and breaking down gameplay to base elements or moves, and his notation is a bit unweildy. Notation for concepts such as state transitions and other things Koster mentions already exists, however he has attempted to invent a new kind of diagram. Adapting existing graphical notations to the domain of games might have been less bold and less prone to failure, as Koster concedes his attempt was unsuccessful.

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.