Game Design Atoms
I went to an interesting talk by Raph Koster at GDC on "Game Design Atoms." Raph focused on the use of notation in music and choreography and discussed his attempts to create a rigorous notation for game design. He pointed out the advantages of notation -- reproducibility, error detection, rigorous definitions, content independence, and detection of bad game ideas -- and proceeded to diagram some of the game of checkers as a way to demonstrate the idea. An interesting, and intellectually appealing, endeavor.
However, I believe that it is making some fundamental mistakes about what games are. Are games more like music or more like the real world? While the design space of all music is certainly vast, it is vastly smaller than the design space and complexity available to games. As a result, in attempting to describe what games are, we should take a lesson from the real world. And for rigorous descriptions of reality, we turn to mathematics. Mathematics provide a formal description of the laws that govern the universe.
For games' universes, a similar formal description already exists: the code. Read on . . .
When building games, a common tactic is to create a "blue squares" demo. If your gameplay isn't fun with a bunch of blue squares running around, it isn't going to be fun with The Matrix license, Claudia Christian's voice work, or offset-mapped, trilinear-filtered, buzzword enabled graphics. While this lesson is regularly forgotten, most good games have a moment when they were fun long before all the other junk is grafted on.
Raph suggested that the audience create a better notation than he had chosen, so I offer the following notation for checkers:
// checkers.cpp
#include <iostream>
#include <vector>
#include <algorithm>
class CheckerSquare;
class CheckerPiece
{
public:
CheckerPiece(CheckerSquare *square, bool is_black)
: mSquare(square), mIsBlack(is_black), mIsKing(false)
{
}
~CheckerPiece() {}
void moveTo(CheckerSquare *square);
void king()
{
mIsKing = true;
}
friend std::ostream& operator<< (std::ostream& os, const CheckerPiece& p)
{
if (p.mIsBlack)
{
if (p.mIsKing)
{
return os << "\t\tB";
}
else
{
return os << "\t\tb";
}
}
else
{
if (p.mIsKing)
{
return os << "\t\tR";
}
else
{
return os << "\t\tr";
}
}
}
CheckerSquare *mSquare;
bool mIsBlack;
int mIsKing;
};
typedef enum e_square_connections
{
SC_FWD_LEFT,
SC_FWD_RIGHT,
SC_BACK_LEFT,
SC_BACK_RIGHT,
SC_MAX_CONNECTIONS
} SquareConnections;
class CheckerSquare
{
public:
CheckerSquare(int pos)
: mPiece(NULL), mBoardPosition(pos)
{
int i;
for (i = SC_FWD_LEFT; i < SC_MAX_CONNECTIONS; i++)
{
mConnections[i] = NULL;
}
}
~CheckerSquare()
{
delete mPiece;
}
friend std::ostream& operator<< (std::ostream& os, const CheckerSquare& s)
{
if (s.mPiece)
{
return os << *s.mPiece << "[" << s.mBoardPosition << "]";
}
else
{
return os << "\t\t[" << s.mBoardPosition << "]";
}
}
CheckerSquare *mConnections[SC_MAX_CONNECTIONS];
CheckerPiece *mPiece;
int mBoardPosition;
};
typedef std::vector<CheckerSquare *> squares_t;
const int gRows = 8;
const int gCollums = 4;
const int gSpaces = gRows * gCollums;
const int gNumberCheckerRows = 3;
const int gNumberCheckers = gNumberCheckerRows * gCollums;
typedef enum e_board_conditions
{
BC_NULL,
BC_BLACK_PIECES = 1,
BC_RED_PIECES = 2,
BC_BLACK_FORCE = 4,
BC_RED_FORCE = 8,
} BoardConditions;
struct DeletePointer
{
template<typename T> void operator()(T* ptr) const
{
delete ptr;
}
};
class CheckerBoard
{
public:
CheckerBoard()
: mBlackMove(true), mBoardCondition(0)
{
int i;
for (i = 0; i < gSpaces; i++)
{
mBoard.push_back(new CheckerSquare(i));
}
squares_t::const_iterator it = mBoard.begin();
squares_t::const_iterator base = it;
squares_t::const_iterator end = mBoard.end();
for(; it != end; ++it)
{
CheckerSquare *cs = (*it);
int position = cs->mBoardPosition;
int collum = position % gCollums;
int row = position / gCollums;
int oddrow = row % 2;
int left_edge = collum ? false : true;
int right_edge = collum == gCollums - 1 ? true : false;
int connect_left = !left_edge || !oddrow;
int connect_right = !right_edge || oddrow;
int fwd_left = position - gCollums - oddrow;
int fwd_right = fwd_left + 1;
int back_left = position + gCollums - oddrow;
int back_right = back_left + 1;
if (fwd_left >= 0 && connect_left)
{
cs->mConnections[SC_FWD_LEFT] = *(base + fwd_left);
}
if (fwd_right >= 0 && connect_right)
{
cs->mConnections[SC_FWD_RIGHT] = *(base + fwd_right);
}
if (back_left < gSpaces && connect_left)
{
cs->mConnections[SC_BACK_LEFT] = *(base + back_left);
}
if (back_right < gSpaces && connect_right)
{
cs->mConnections[SC_BACK_RIGHT] = *(base + back_right);
}
if (position < gNumberCheckers)
{
cs->mPiece = new CheckerPiece(cs, false);
}
else if (position >= gSpaces - gNumberCheckers)
{
cs->mPiece = new CheckerPiece(cs, true);
}
}
}
~CheckerBoard()
{
std::for_each(mBoard.begin(), mBoard.end(), DeletePointer());
}
void getOptions(CheckerPiece *piece, int &start, int &end)
{
if (piece->mIsKing)
{
start = SC_FWD_LEFT;
end = SC_BACK_RIGHT;
}
else if (piece->mIsBlack)
{
start = SC_FWD_LEFT;
end = SC_FWD_RIGHT;
}
else
{
start = SC_BACK_LEFT;
end = SC_BACK_RIGHT;
}
}
bool checkKing(CheckerPiece *piece)
{
if (piece->mIsBlack)
{
if (piece->mSquare->mBoardPosition < gCollums)
{
return true;
}
}
else
{
if (piece->mSquare->mBoardPosition >= gSpaces - gCollums)
{
return true;
}
}
return false;
}
bool checkForce(CheckerPiece *piece, bool check_destination = false, int destination = 0, bool move = false)
{
int start, end;
getOptions(piece, start, end);
for (int direction = start; direction <= end; direction++)
{
if (piece->mSquare->mConnections[direction])
{
if ( (piece->mSquare->mConnections[direction]->mPiece)
&&(piece->mSquare->mConnections[direction]->mPiece->mIsBlack != piece->mIsBlack))
{
if (piece->mSquare->mConnections[direction]->mConnections[direction])
{
if (!piece->mSquare->mConnections[direction]->mConnections[direction]->mPiece)
{
if (check_destination)
{
if (piece->mSquare->mConnections[direction]->mConnections[direction]->mBoardPosition == destination)
{
if (move)
{
delete piece->mSquare->mConnections[direction]->mPiece;
piece->mSquare->mConnections[direction]->mPiece = NULL;
piece->moveTo(piece->mSquare->mConnections[direction]->mConnections[direction]);
if (checkKing(piece))
{
piece->king();
}
}
}
}
return true;
}
}
}
}
}
return false;
}
bool doMove(CheckerPiece *piece, int destination)
{
int start, end;
getOptions(piece, start, end);
for (int direction = start; direction <= end; direction++)
{
if (piece->mSquare->mConnections[direction])
{
if ( (!piece->mSquare->mConnections[direction]->mPiece)
&&(piece->mSquare->mConnections[direction]->mBoardPosition == destination))
{
piece->moveTo(piece->mSquare->mConnections[direction]);
if (checkKing(piece))
{
piece->king();
}
return true;
}
}
}
return false;
}
bool doMove(int start, int end)
{
CheckerPiece *piece = mBoard[start]->mPiece;
if (!piece)
{
std::cout << "No piece found" << std::endl;
return false;
}
if (piece->mIsBlack != mBlackMove)
{
std::cout << "Not your piece!" << std::endl;
return false;
}
if (checkForce(piece, true, end, true))
{
checkBoard();
if (!checkForce(piece))
{
mBlackMove = !mBlackMove;
}
return true;
}
if (mBlackMove && (mBoardCondition & BC_BLACK_FORCE))
{
std::cout << "Black failed to take forced jump" << std::endl;
return false;
}
if (!mBlackMove && (mBoardCondition & BC_RED_FORCE))
{
std::cout << "Red failed to take forced jump" << std::endl;
return false;
}
if (doMove(piece, end))
{
mBlackMove = !mBlackMove;
return true;
}
std::cout << "Not a legal move!" << std::endl;
return false;
}
bool doTurn()
{
char temp[255];
int start, end;
if (mBlackMove)
{
std::cout << "Black to move" << std::endl;
if (mBoardCondition & BC_BLACK_FORCE)
{
std::cout << "Forced jump" << std::endl;
}
}
else
{
std::cout << "Red to move" << std::endl;
if (mBoardCondition & BC_RED_FORCE)
{
std::cout << "Forced jump" << std::endl;
}
}
std::cout << *this << std::endl;
std::cout << "Piece to move?" << std::endl;
std::cin >> temp;
start = atoi(temp);
std::cout << "Destination?" << std::endl;
std::cin >> temp;
end = atoi(temp);
doMove(start, end);
checkBoard();
if ((mBoardCondition & BC_RED_PIECES) && (mBoardCondition & BC_BLACK_PIECES))
return true;
else
return false;
}
void checkBoard()
{
mBoardCondition = 0;
squares_t::const_iterator it = mBoard.begin();
squares_t::const_iterator end = mBoard.end();
for(; it != end; ++it)
{
if ((*it)->mPiece)
{
if ((*it)->mPiece->mIsBlack)
{
mBoardCondition |= BC_BLACK_PIECES;
if (checkForce((*it)->mPiece))
{
mBoardCondition |= BC_BLACK_FORCE;
}
}
if (!(*it)->mPiece->mIsBlack)
{
mBoardCondition |= BC_RED_PIECES;
if (checkForce((*it)->mPiece))
{
mBoardCondition |= BC_RED_FORCE;
}
}
}
}
}
friend std::ostream& operator<< (std::ostream& os, const CheckerBoard& b)
{
squares_t::const_iterator it = b.mBoard.begin();
squares_t::const_iterator end = b.mBoard.end();
for(; it != end; ++it)
{
if ((*it)->mBoardPosition % 8 == 0)
{
os << "\t";
}
os << *(*it);
if ((*it)->mBoardPosition % 4 == 3)
{
os << "" << std::endl;
}
}
return os;
}
squares_t mBoard;
int mBoardCondition;
bool mBlackMove;
};
void CheckerPiece::moveTo(CheckerSquare *square)
{
mSquare->mPiece = NULL;
mSquare = square;
mSquare->mPiece = this;
}
int main(int argc, char* argv[])
{
CheckerBoard *cb = new CheckerBoard();
while(cb->doTurn())
;
if (cb->mBoardCondition & BC_BLACK_PIECES)
{
std::cout << "Black WINS!" << std::endl;
}
else
{
std::cout << "Red WINS!" << std::endl;
}
return(0);
}
So, the question that Raph is posing is whether some description is superior to just building the blue squares version. Code has all of the properties that Raph was looking for in notation, plus additional advantages. It would be easy to add AI to this, change the board shape or size, or experiment with other rules changes. You can also freely graft content onto it when you're happy with the gameplay. Sure, it was banged out in a hurry and isn't very clean, but just about any programmer could look at the code and understand the game of checkers. It probably has bugs, but testing will reveal these. More importantly, they could actually play checkers, which returns to the complexity issue.
A talented musician can "hear" music based on reading the score. After all, a primary function of our big, squishy, pattern matching and feedback laden brains is to simulate reality. However, the larger and more complex the simulation, the more likely that we're chunking away some useful piece and potentially missing something important. So being able to actually play the game is a vital part of analysis and critique. Even Richard Garfield, as brilliant a game designer as any, play tested Magic: the Gathering (and Lighting Bolt was still imbalanced!)
Of course, I'm a programmer, so I am undoubtedly biased. I am not, however, dismissing the value of other descriptive forms. Just as song, art and poetry all have their place in describing the world and the human condition, Raph's approach might be an important tool in our understanding of games. But for problems he wanted to solve with notation, I submit that code already serves us extremely well.
Posted by Cory Ondrejka on March 15, 2005 | Permalink
« Announcing: Command Lines | Main | Annotated Sword (Play) »
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/t/trackback/5074/2074361
Listed below are links to weblogs that reference Game Design Atoms:
» The Code Is The Law from Feet of Clay
In the past, I've argued that designers needed to know code. Not just know basic programming principles, but have worked on real projects as part of a team, understand what it's like to wrestle with a compiler bug at 3am. So I ought to line up with C... [Read More]
Tracked on Mar 16, 2005 12:16:22 AM
» Free Slots Guide Web Portal Relaunches with New Look and Expanded Services from has relaunched
Slots Guide, a slots-oriented web portal, has relaunched with an expanded list of services, and a significant increase in the number [Read More]
Tracked on Jun 9, 2006 1:41:04 PM
» POLITICS: Man/Walrus Enraged at UN from does not defend
blew a gasket after after a senior UN official accused the US of undermining the United Nations. Bolton demanded [Read More]
Tracked on Jun 12, 2006 9:51:54 PM
» Reid may move to Spurs from has prompted
interest in Blackburn midfielder Steven Reid has prompted Rovers manager Mark Hughes to plan talks with the player in [Read More]
Tracked on Jun 16, 2006 10:10:28 PM
» U.N. Envoy in Congo to Stay On from .N. Special Envoy
Special Envoy in Congo Will Stay on for Now to Handle Sex Abuse Claims [Read More]
Tracked on Jun 17, 2006 5:03:13 AM
» Teen's Addiction Leads Family To Unique Wilderness Therapy Program from straight-A student
12, straight-A student Jamesturned to methamphetamines to help him cope with his mother's near-fatalillness and to be accepted [Read More]
Tracked on Aug 7, 2006 7:00:11 PM
Comments
I think the problem with Code as Notation is that it is sort of like saying the Film is the Notation.
I could write checkers in the same language as you and end up with code that looks entirely different. Giving two different pieces of code, how can we tell if they are the same game?
By playing them? But then we are not using the code, we are using the game itself as the notation.
I can give chess a first person perspective, 3d graphics, and a gun to select the piece to move, but we'd still not classify it as a FPS.
A lot of mathematics revolves around trying to determine when things are the *same*. It's the ability to set aside a series of requiremnts and say: "Things that satisfy this are a "ring"" that allow us to then discover unexpected objects to be rings, and then deduce other properties about them.
When, as Raph Koster refers to in his book, we realize a game is all about vertices, we can then better analyse those graphs, and determine what changes would help or hinder the game.
For example, why is forced jump an important component of checkers? The code merely *has* forced jump as a game mechanic. It looks in the code form as a method to restrict the players potential actions. In fact, it is a method to *expand* player actions. Force jump gives the player the ability to control their opponents choices.
"On your turn, if you have a jump, you must take the longest jump available to you"
is different from
"On your turn, if you can set the board so the opponent has a potential jump, your opponent must take the longest jump available to them"
The reason why force-jump is a feature I think lies in the latter description. This is missed in most rule books of checkers, and one reason that I thought it was a stupid rule as a child.
- Brask Mumei
Posted Mar 15, 2005 9:23:21 PM | link
Brask,
I agree (and Raph and I chatted about this at GDC) that the non-uniqueness of code is definitely a problem, although since at this point you have the game, you can always play both pieces of code to compare.
I don't think that the film analogy holds up. Film captures a movie, code defines the game play. Also, your objects about forced jump are equally strong objections against notation.
Posted Mar 15, 2005 9:32:10 PM | link
Code
...
uniqueness
Probably need to qualify this with "C++" or "a general programming language" (Code)... Without knowing Raph's notation, I imagine its computable, for example.
Posted Mar 15, 2005 10:14:14 PM | link
I didn't get to the GDC, but notation is very appropriate for quests, particularly long ones, much as symphonies are broken up in "aBa".
For example: A typical "kill 10 rats quest" is "NKN", where N = narrative, K = kill. A "kill 10 rats and bring their tails to me" is "NKDN", where D = delivery.
If there's a choice in the quest then use something like BNF: "N(K|C)DN" means the player hears a narrative, can chose to attack or or chat with a NPC, gets an item, and delivers it back to the original, where there's more narrative.
This level of abstraction forces the designer to think about:
a) What the player does... the sub-games that are invoked by the quest.
b) What choices players must make.
Boiling quests down to such symbolic representations reveals that all MMORPG quests are essentially the same (which we already knew), that they are the same because there aren't enough sub-games, and MMORPG quests don't provide any choices for players to make other than which rat to kill first and what weapon to use.
I go into more detail on http://www.mxac.com.au/drt/Choice.htm and http://www.mxac.com.au/drt/Choice2.htm.
Posted Mar 15, 2005 11:24:40 PM | link
Good point, Nate. Raph's notation was very cool and very visual. Were it complete, one could certainly generate code from it (a la Visual Basic, perhaps?) but, as he pointed out several times, it isn't complete at this point.
Mike, Raph was trying to break things down *much* farther than that, down to very specific actions by the player (drag weapon from inventory, choose attack, smite rat, etc).
Posted Mar 16, 2005 12:10:17 AM | link
Interesting analogy, but I'm not sure code is really the thing to use as 'notation', or even that musical notation is the best way to understand music 'design'.
For instance, "The Simpsons" frequently changes its end title theme to mimic some other musical style that relates to the program that just ended. There's been the 'salsa end title', the 'Australian didgeridoo end title', the 'Vegas lounge lizard end title', and many others. While they use the same underlying musical themes, they don't use the same underlying notation, nor is such a change simply a question of, "OK, instead of a snare drum on this part we'll have maracas and 'boom', instant salsa." The process of changing musical genres is far more akin to the process of porting a computer game to a different platform or language - you want to keep the same 'themes', but you need to change the underlying notation so that the result plays like a medieval romance or runs in Red Hat 9.
I'd argue that the 'themes' are far more important for understanding games than the notation is. Even more significantly, you can take classes in music appreciation, and even in music criticism, without ever having to take a course in music theory or learn to play an instrument. Similarly, there are people who are very good at analyzing/understanding games who can't code their way out of a wet paper bag because they're able to grasp the themes of game design, even if it's hard to put those themes into a language that others can always understand. (The Forge suffers from this a lot, which is why it's so intimidating for a would-be newbie Forger to get started learning everything she has to know to really understand what people are talking about there.)
Musicians tend not to like critics who don't play, because they think the critics are missing an important aspect of performance. But the critic's job isn't to decide how closely the orchestra followed the composer's notation - it's to analyze the themes in the music and decide if that implementation works. Orchestras can play exactly the same notated music either very well or very badly, depending on skill, the difficulty of the piece, and other factors. Likewise, a game critic can bring a great deal of insight to the implementation of games even if he doesn't know the first thing about coding them, because he's dealing with the themes and the implementation - for instance, does "The Sims" work as a console game? People who code won't like this, of course, because their view is that the whole world should learn code. And perhaps you do need to code to be able to create great games rather than simply recognize when a game is great, just as a composer needs to be able to write musical notation and 'hear' how it plays to be able to write a great symphony. But the musical notation itself is just detail - there's something else there, inherent in the question of 'theme', that makes a piece of music or a game what it is.
Posted Mar 16, 2005 1:11:47 AM | link
Corey wrote - Mike, Raph was trying to break things down *much* farther than that, down to very specific actions by the player (drag weapon from inventory, choose attack, smite rat, etc).
Interesting. Has anyone written up the details? Raph doesn't seem to have posted anything on his web site.
Posted Mar 16, 2005 1:21:15 AM | link
I did not see Raph’s talk so I don’t really get some of the goals that he is trying to achieve. It reminds me of concerns that Greg Costikyan raised in his talk “I Have No Words & I Must Design” (www.costik.com/nowords.html) from a bunch of years ago.
The issues that I have with code as a design language:
1) Most of the game team would not understand it. I assume that a higher level notation would be easier to understand than C or Java, or even a basic variant.
2) Many forms of code are too flexible. This is a tricky one, as one wants a vocabulary that is not liming on design, but where one can say anything then understating becomes very hard as code becomes a meta-language meaning that one has to understand the language of each piece of code
Also I think that its instructive that in IT there area number of levels of system notation before one gets to code. Including ‘formal methods’ Certainly things like system state diagrams show a lot in a single picture – and in a way are similar to the dance notation that I’ve seen.
Maybe what is needed is something that has a generic noun / verb structure then has a set of more specific sub-languages for genre.
Posted Mar 16, 2005 3:39:37 AM | link
Mike Rozak> If there's a choice in the quest then use something like BNF: "N(K|C)DN" means the player hears a narrative [...]
Regular expressions can be used to capture the dynamics in OO analysis and design. => it is more generic than games design. ;)
Posted Mar 16, 2005 4:03:40 AM | link
ren>1) Most of the game team would not understand it. I assume that a higher level notation would be easier to understand than C or Java, or even a basic variant.
Yes, obviously. The funny thing is... C is based on Algol, which was indeed created as a language to be used for communicating ideas about algorithms (AFAIK: not implementation).
Java/C++ are based on Simula, which is based on Algol. Simula was designed to make explicit simulations of systems easy. E.g. modelling. Simula also have a successor Beta, which is based on work with the modelling language Delta (IIRC, I've never looked at that one, but I know Beta)
2) Many forms of code are too flexible.
Nono, code is way too inflexible and painfully pedantic! That's why starting with code is usually wrong, but you need to "imagine how the design maps to code" when designing at the higher level. Furthermore, design will also take place during implementation (usually rendering the design docs useless). Unfortunately, the UML crowd are rather pedantic too => leading to bloat and a syntax that is IMHO lacking elegance. You can't possible say anything useful about a game design by looking at UML chaos, can you? Maybe some can. I don't think I could.
Discussing design as code is of course a rather nutty idea... which is why you need the more flexible and less precise "notation" (whatever the design team is comfortable with, rich pictures, UML, pseudocode or whatever).
Posted Mar 16, 2005 5:28:22 AM | link
A notation for communicating game designs would definitely be useful. At their worst natural language design documents are incomplete, ambiguous and misleading. At their best they are verbose and require significant effort from the reader. Having been both a producer and consumer of design documents I'd like a better language to communicate.
A useful first step would be a recognised lexicon of game design terms, so that concepts could be communicated quickly and unambigiously at a higher level. Much like software design patterns. I've seen references to people putting together pattern languages for game design, so I know that other people have thought about this too.
I could see how graphical notations would be useful too as games are systems of interconnected objects and so lend themselves to the same kind of blobs and arrows diagrams that are often useful for describing computer systems. The UML springs to mind as a formal blobs and arrows language, but I'm still undecided as to whether I like it or not.
Another question is what the goal of the notation is. Musical notation is largely designed to allow real-time reading and performance (something I'm still not very good at), rather than conveying nuance, which is added by the performer, or intent, which is lost in the translation to notation, but can be guessed at by analysing the notation later.
A game design notation should be quicker to interpret than an equivalent natural language description and also less ambiguous, but should probably also preserve meta-information like intent and reasoning. My design documents have often ended up as a (hopefully) terse and unambigious desription of the game and an accompanying FAQ describing why the game ended up as it did.
Capturing reasoning would be invaluable during development when the design inevitably has to be mauled repeatedly due to time pressures, but would also be important when communicating designs to students and other designers who want to know why a game design ended up as it did.
Given these goals I don't think code is a particularly good design notation either. It is complex, verbose (do you need to know about C++ streaming mechanisms?), doesn't communicate in high level design abstractions and doesn't communicate intent or other meta-information.
I agree that while developing a game design sitting round a PC hacking code and iterating blue square demos is the way to go. However, once the game design needs to be communicated to a team of hundreds or a world wide community of game designers, critics and students, code isn't enough.
Posted Mar 16, 2005 7:43:28 AM | link
Brask Mumei: I could write checkers in the same language as you and end up with code that looks entirely different. Giving two different pieces of code, how can we tell if they are the same game?
You can in theory construct a language L which only allow experientially different games to be expressed.
Sketch of proof:
1. Only allow programs of length N or shorter.
2. Generate all possible programs and rate them against each other.
3. Only keep the programs that are rated as different and call the set of them L.
Is this doable in practice? No, but it proves that such a language exists. (unless I made a mistake somewhere).
Posted Mar 16, 2005 7:56:14 AM | link
Let me forget Raph's intent for a moment and follow Mike's tangent, which seems a lot more promising to me.
BNF could tell us something about the structure of quests, but as the earlier poster said many of them look much the same. More interesting to me is the idea of a notation that would try to express the dynamics of quests, or the interrelationships between them. For example, in Lionheart there were multiple quests that dealt with the moneylender Shylock. How players interacted with him in the matter of Cortez influenced how he'd deal with them in the matter of Shakespeare. Just handling this in BNF gives us a huge set of alternatives where anything other than the simplest of branching structures will be either unclear or unwritable.
There are richer notations than BNF from the concurrent programming research community, intended to capture dependencies between independent processes - like CSP and CCS. Or maybe we should just use something more Bison-like, where every branch in the BNF can have conditionals and every event in the BNF can set variables?
If you really want to get out there, express the relationships between quests and world features in a way that allows reasoning about them. (Is this starting to sound like Prolog?)
My thought experiment for that is the Elysium region of Anarchy Online. The "Gardens" are faction-based quick-transport systems (as well as having a resurrection bind point/XP save point and special vendors). Players can get a permanent key to their garden by taking a long quest that wanders about the entire region, meeting NPC members of the player's faction and spying on NPCs in the enemy faction. In its early days, this ensured that people knew half of the "content" before they had quick transport. However, players can get temporary access to the quick-transport system very easily. Combined with online guides, this means that the permakey quests can be completed much more quickly and at a much lower level than the designers apparently intended, since using the temporary garden keys one can skip over lots of unknown (and highly dangerous) territory.
Could a notation (of course built into a quest authoring system) that automated formal reasoning warn designers of this kind of unintended interaction?
Posted Mar 16, 2005 8:15:27 AM | link
As a game designer and programmer, I find the idea that one can express everything in notation as idealistic but unrealistic. Consider that a modern game is defined at several levels. There is the User Interface, handling screen updating, mouse clicking, UI logic, etc. There will be code for the game play logic, perhaps implemented in a scripting language, code to control music playing, combat etc etc.
The complexity of all this should not be underestimated- it is immense. Back 12 years ago when I was a designer for Microprose UK- the game design notes were 240 pages long.
As with battle plans, game designs do not long survive contact with the enemy- or in this case programmers etc. No tool I think can possibly capture the breadth and depth of any non trivial game. And I do not believe that it is possible to design a complete game in advance and then make no further changes. Its even worse with games as the User experience has to be taken into account. I tried this recently with a mobile phone game that I'm working on and despite all my efforts (wearing my designer hat), some changes had to be made to the design when I programmed it.
In the mid 90s, much was made of CASE (Computer Aided Software Engineering) tools that would do all this- we're still waiting!
Posted Mar 16, 2005 9:02:09 AM | link
Tom Hudson> Could a notation (of course built into a quest authoring system) that automated formal reasoning warn designers of this kind of unintended interaction?
IFF it only allows programs which it could prove correctness for, yes. But it probably would spam you with lots of warnings you didn't want for any complex MMO design. ;-) And it means that you would have to limit your MMO design to constructs which the prover could reason about. So, now you don't only need to prove that the quests are unbreakable, you have to prove that all changes to the rest of the game doesn't break the conditions you have set up for all content in the game. At some point you might not be able to change anything! ;-D => can you have a MMO that provides longterm non-exploitable fun? I doubt it, believing that you can go beyond the known is a key component to MUD fun.
Anyway, a language should be able to communicate the core ideas in simple games like tic-tac-toe and a cellular automata effectively. Surely you can model it in UML, but will the resulting diagrams be legible compared to alternative ways of expressing the ideas? I don't think a cellular automata described in UML would be particularly enlightening...?
Posted Mar 16, 2005 9:09:20 AM | link
If your gameplay isn't fun with a bunch of blue squares running around, it isn't going to be fun with The Matrix license, Claudia Christian's voice work, or offset-mapped, trilinear-filtered, buzzword enabled graphics.
I think the reason people forget this is because it simply isn't true. Halo, Devil May Cry, Grand Theft Auto, and World of Warcraft would not be fun if all the characters were blue squares. (Or even cubes.) The real power of a Blue Squares demo is this: if your Blue Squares demo actually IS fun, then God Damn, once you get trilinear-filtered graphics in there it's going to be AWESOME.
Posted Mar 16, 2005 9:31:47 AM | link
Notation in music and dance is always shorthand to express the underlying ideas. A good notation allows you to express them concisely in a way that they can be reproduced, but the final piece is up to the performer. No piece of music is ever going to sound exactly the same when two different performers play it. No piece of dance is ever going to look the same when two different performers dance it.
Code, on the other hand, is not about underlying ideas - it is about specifying something in the most minute detail possible. It is about making things exactly the same.
So, if you want to reproduce games, code is a good idea - but if you want to talk about new games, it carries way too much information, IMHO. And when we're studying games, we do want to look at the ideas behind them - so again, code is not concise enough.
Posted Mar 16, 2005 9:50:47 AM | link
Is there anywhere to read Raph Koster’s presentation on his proposed system of notation?
Posted Mar 16, 2005 10:08:49 AM | link
Running with Mike and Jim's comments, you could claim that something akin to Unreal Engine 3's graphical scripting framework is an intersting starting point (or Visual Basic, for that matter). Of course, you are once again writing code (just in a graphical format) and it can suffer from the "well, these are the types of games you can easily do in graphical editor foo"-problem.
Jamie, I disagree. The mechanics of the games you describe are fun without the fluff (well, I can't speak for Devil as I haven't played that one). Also, "blue squares" shouldn't be taken too literally :-). Sometimes they can be red. Or circles. Or even 3D objects.
Robert> Code, on the other hand, is not about underlying ideas
That is such an interesting assertion, and not one that I would agree with. However, I agree that code can go well beyond the underlying ideas -- hence the simple form of checkers.
Rich, I'm sure Raph will eventually read TN and tell us where he's posting the notes ;-)!
Posted Mar 16, 2005 12:36:20 PM | link
I agree: code is too low-level to be the right locus for usefully describing a game's design. But the same criticism also applies to notation-as-design. For a notation to have expressive value, you have to have higher-level rules that define how to use that notation. (Apologies to Raph if in what follows I'm just repeating things he's already said.)
I wonder if being able to communicate effectively about the creation of art (which includes computer games) requires three key levels of expression: notation, grammar, and language patterns. In other words, you have to have the fundamental symbolic building blocks (A, B, C, ... Z; 1, 2, ... N; +, -, /, *; etc.); you need a set of rules for specifying how those basic symbols can be organized into chunks; and you need a collection of meta-rules for grouping those chunks in ways that convey deep meaning.
In writing, these correspond to letters, words/sentences, and themes. If all you have are letters unconstrained by organizational rules, you can't communicate. If you add a grammar that allows you to form regular words and sentences (i.e., a language), you become capable of uttering valid simple statements, but those statements may not say anything interesting or useful. To say something that matters -- to express deep meaning -- you need to know ways of grouping words and sentences that will communicate rich concepts and feelings to your audience. (I think this is what David Wintheiser meant in suggesting that game designers can't neglect "theme.")
Just having a notation gives you monkeys banging on typewriters. Having a grammar enables gossip. Having patterns of meaning allows Shakespeare.
Architecture offers similar examples. Having concrete, wood, and nails will let you build some kind of structure; knowing how to pour foundations and frame walls and roofs lets you build a house; understanding the patterns in which human beings live in buildings meant that Frank Lloyd Wright could create the beautiful "Fallingwater" home in Pennsylvania.
So to have a notation for game design would be interesting, but it's not enough. To have productive design conversations, we also need a grammar that defines useful patterns of player action. If the notation is how we describe the fundamental statements of what's possible in the game world, the grammar defines how these actions may be organized to establish the basic game systems (movement, combat, quests, economy, etc.).
You could probably design a game using just these two levels, but I don't know how much fun it would be to play unless it's trivally simple. Just being able to define basic game systems doesn't let you create a game with any kind of *flavor*; you have no way to describe how the game systems should be assembled to achieve a coherent high-level effect.
So in addition to a grammar, you need another level of organization beyond grammar. Jim Purbrick nailed what I'm thinking of here when he mentioned "design patterns" -- in a game design context, these would be specific ways that basic game features could be grouped to achieve specific impressions in players. In other words, having access to a collection of game design patterns would support the need of designers to achieve the overall vision for their game.
To return to the example of architecture, Will Wright mentioned the book _A Pattern Language_ by Alexander, Ishikawa, and Silverstein (http://www.patternlanguage.com/) as one of his reference works for The Sims. This book is a collection of architectural design patterns for buildings, homes, communities, and cities -- it lists high-level patterns for achieving (what are in the view of the Berkeley-based authors) successful living spaces for individuals and groups.
Where is an equivalent listing of high-level patterns for designing successful gaming spaces?
--Flatfingers
Posted Mar 16, 2005 1:49:02 PM | link
Design patterns will never produce revolutionary art. It is so-so ok for _engineering_ solutions to common problems, or to establish a common vocabulary. It isn't obvious that using patterns will lead to better solutions although using OO-design patterns might make for more effective communication.
I don't really think most of the patterns of Alexander et al are high level at all, they are pretty down to earth, and for a reason: they don't inform professional designers as much as they let people design their own living spaces...
Posted Mar 16, 2005 2:19:43 PM | link
I would say they are high-level compared to lists of materials (notation) and construction methods (grammar).
And I'm not sure "revolutionary" art is required -- just great art. Having design patterns won't guarantee that; they just increase the odds.
--Flatfingers
Posted Mar 16, 2005 3:12:10 PM | link
Of course, the language you use depends upon what you think games are fundamentally about. Music notation assumes that music is about notes (segments of constant pitch and timing). It doesn't, for example, work well to describe yodelling, or what theramins can do.
If you think that games are about a series of interesting choices, then the notation needs to show what potentially-interesting choices the player has, and the interesting events that results from those choices, as well as what the player expects from the choices... which is why some sort of CFG is handy.
If games are about recognizing patterns, then the language should include information about the real pattern, what pattern the user thinks is there at the stage, etc.
Posted Mar 16, 2005 5:19:22 PM | link
Yes, they are higher-level than the actual implementation, but they still primarly address parts and not how the parts interact in the whole.
Ok, the way I see it you have at least three types of design patterns:
1. IDEAS/INTERVENTION: Alexander et al: inspirational, empowering "users" so they can get involved in the local community and create unique high quality living spaces. Their work seem to be driven to a large extent by a desire to intervene in society, could even be called a political and philosphical project. Their approach is interesting, a product of their time, but not very neutral. The authors' personal tastes shine through... ;)
2. VOCABULARY/QUICK FIXES: Gamma et al: putting names on a set of structures that arise naturally when you solve OO design problems in common OO languages. I believe I had used most of their patterns before I read their book. More low level than the Alexander ones. This is all about engineering. Quite neutral. They push OO-design, but that's about it. And many of their patterns should probably have been supported on the language-level. I.e. some address deficiencies in OO-programming language designs.
3. Pure best practice type of patterns. (I don't care much for these.)
I would expect talented game designers to know the key patterns already, and maybe they need names on them, but my gut feeling is that the net outcome of a pattern driven approach would be game engineering rather than game design. The games industry seems to master game-engineering already, it is the art and design part that is "in the teens"?
What makes game design special, and patterns very problematic, is that you don't only design the solution to a problem, you also design the problem you solve... Thus, to get good coverage you are likely to end up with a large and ever-growing set of different design-patterns (500+?). The book Patterns in game design apparently contains 200+ patterns... (haven't read it)
Gamma et al which is actively used contains only 23.
Posted Mar 16, 2005 5:45:12 PM | link
Ola, I think your taxonomy is right on the mark. I just differ slightly with you on whether they all truly deserve to be called "design" patterns (and thus rise to the level of supporting Literature or Architecture, etc.).
The "pure practice" and Gamma patterns aren't really about design; they're about implementation. I think of them as "application patterns." Such mid-level, grammar-centric patterns can afford to be highly objective because they don't go as far as a true design pattern to speaking to deep meaning, to concepts and emotions and the other very human capabilities and responses you might want to evoke with a great game.
The Alexander et al. work does, I think, rise to the level of design patterns. For all of its political biases (most of which I don't share, I might add), it does offer high-level patterns that are explicitly intended to trigger deep human responses. It's provocative in the depth and variety of its patterns, and that's a Good Thing.
I'd argue that the Alexander book actually goes too far down this road, that it's a better political work than architectural, and that this emphasis on social engineering causes the set of patterns offered to be less rich than could have been the case. But that this particular book isn't a perfect collection of patterns doesn't imply that no such collection of useful high-level patterns can exist.
I'm also reminded of Georges Polti's "36 Dramatic Situations" -- Polti's argument was that there are ultimately only 36 plots. Of course picking a number is an invitation to argument, but even if you decide that some of the plots are duplicates, you're still looking at some 20-25 basic patterns that recur throughout thousands of years of literature.
If a collection of high-level patterns for architecture and literature can exist, why not high-level patterns for game design? Of course "high-level" implies some amount of subjectivity, which means that not everyone will agree on which patterns are real and which aren't. But if most designers agree on enough patterns, wouldn't that be useful knowledge for would-be game designers (or Lead Programmers) to have so that we can speak a common language?
Why should the Sid Meiers, Raph Kosters and Warren Spectors have all the fun? Patterns for the masses! ;-)
--Flatfingers
(Note: I haven't read _Patterns in Game Design_ either, but that Greg Costikyan thought it was worth endorsing is a point in its favor. At 200+ patterns, though, I do wonder whether it's really about *design* patterns or application patterns.)
Posted Mar 16, 2005 6:30:16 PM | link
As some people have mentioned here, a CASE tool like UML might be a better starting point. I chatted with Brian Green about this, as well after the GDC. The diagrams at the end of the talk did look closer to UML than to music to me.
I think that UML is good at creating classes and their interactions, which is essentially showing how nouns are created and interact with each other. We want something where we describe the system in terms of verbs.
UML also has use cases and sequences that show how the system actually runs (describes the verbs). So perhaps what we might want is a dual of UML where the core objects are verbs, and the use cases and sequences describe how the nouns perform the verbs or use the verbs? Maybe we want to link the verbs together with the nouns that let you do things instead of linking the nouns together with the verbs?
Posted Mar 16, 2005 6:31:34 PM | link
Interesting discussion. While I absorb it more thoroughly, a thought:
Back in my acting/stage combat choreographer days, I designed a notation system for designing stage fights. It was fairly simple: P for parry, P1 for parry in prime, P2 for parry in seconde', AT6 for Attack Thrust in sixte and so on. The players were noted as prefixed and suffixed numbers, 1 through N for a fresh design, or an acronym for a known character, such as PAR for Paris, MER for Mercutio, et al. So, Paris thrusting at Mercutio in prime with a successful parry would read PAR-AT1-MER-P1.
I worried that it was too simple, but that turned out to be its true utility. Experienced combatants could take my simple notation, work through the fight on their own and get it down pat. Then, when the sets were available, we could work the fight into the sets, making changes as we went.
That last is the key; the sets could change everything. Do the stairway railings have enough stability to allow someone to lean their weight on it, after all? Hey, this window is actually big enough to crawl through! Great! Let's work them into the fight. The set, in other words, worked like a prototype, and every developer knows that the prototype will show you things about your design you didn't expect.
My point, then, is that you don't want to go overboard on the notation system. I think it is a great idea, but leave enough slack in the system that you can make changes to the annotated design easily.
Posted Mar 16, 2005 7:25:58 PM | link
Flatfingers, I totally agreet that the provocative aspects actually are a good thing about Alexander et al. If for no other reason, it is better to have patterns that make you think than patterns that people accept without asking questions. Some are rather good, one of my favourites is the one about paths: widen the path in the middle and put a bench there.
Regarding Gamma et al, I think what makes it work as a pattern _language_ is the rather low level and limited number of patterns.
Here's the TOC for the Game pattern book which lists all the patterns. Judge for yourself, I'm getting dizzy:
http://www.charlesriver.com/resrcs/tocs/1584503548_TOC.pdf
Posted Mar 16, 2005 8:34:12 PM | link
http://www.theoryoffun.com/grammar/gdc2005.htm now has the presentation, minus all the animation and sound.
Posted Mar 16, 2005 10:52:56 PM | link
I hate to be a nit-picker, but UML is not a CASE tool. Its quite capable of being used without a computer. Its equally capable of describing systems that aren't software at all. UML is a design and analysis tool, and a fairly versatile one.
A good notation really shouldn't be too detailed, because you end up obscuring concepts you wanted to communicate. The checkers code sample is a good bad example. The time to learn and understand the notation is long. The time to understand the game notated is significantly longer than even a plain language description. The description is implementation specific. There is no easy way to seperate the implementation details from the design details. If I didn't already know how to play checkers it could probably take upwards of an hour to figure out.
I find the act of crowning the king in real checkers to have significant symbolism and that is totally lost in the code description and probably lost in most other notations. It feels like notation gives us improved detail about the mechanics, but loses the meaning and nuance behind them.
Posted Mar 17, 2005 12:40:46 PM | link
Thabor> I hate to be a nit-picker, but UML is not a CASE tool.
The reasoning behind having UML head where it is heading is to enable CASE tools, code-level precision, specifing constraints, keeping code and diagrams in sync etc... This affects the syntax => an impenetrable forest of boxes and non-graphical syntax. It doesn't take advantage of the medium, and you basically need the CASE tool to efficiently produce diagrams and browse them..
Its equally capable of describing systems that aren't software at all.
OO analysis doesn't describe software, so that's a given. OOA aims at describing the real world... That doesn't mean it is particularly well suited for describing game mechanics.
You should be able to represent the core gamplay on a single sheet in a reasonably intuitive way so that a design team can discuss changes to it. UML doesn't sound like a good candidate.
Posted Mar 17, 2005 10:00:14 PM | link
"The reasoning behind having UML head where it is heading is to enable CASE tools"
Sure, because people are trying to use the notation to build something concrete, instead of using it to communicate about what they are building. When UML is detailed to the code level, then it ends up being less effective than the actual source for communicating.
Sorry, but I'll keep my UML use to where I find it useful. On pencil and paper, and use for focused communication about system design/analysis. Neither computer aided nor software engineering.
"You should be able to represent the core gamplay on a single sheet in a reasonably intuitive way so that a design team can discuss changes to it. UML doesn't sound like a good candidate.."
Well I would agree if you are talking about core gameplay. Why make it more complicated than you have to.. The core gameplay of a significant portion of games reads like this:
Enter an area where objects and characters have a minor power deficit in relation to the player. Destroy / defeat those objects / characters in order to accrue direct and indirect power increases. Once the power deficit is too large have the player proceed to a new area where they can repeat the process.
It could probably be more generalized into recognizing and mastering patterns, but thats basically it. The only real changes that get made are to the specific numbers in the equation. How many areas, how quickly power is accumulated and in what way, and what constitutes a significant deficit. I don't see the actual core changing much regardless of how much it gets talked about. I see details changing.
What are we actually trying to do with our notation? Are we trying to communicate abstract concepts? Describe mathematical details? Perform the actual construction of the game? Talk about artistic elements? You will end up with a different notation depending on what you decide.
Posted Mar 18, 2005 3:40:32 AM | link
Ola Fosheim Grøstad>C is based on Algol
Well, C is based on B, which was based on BCPL, which was based on CPL, which was based on Algol 60, which was based on Algol 58.
>which was indeed created as a language to be used for communicating ideas about algorithms (AFAIK: not implementation).
I've written numerous programs in C, BCPL and Algol 60. It was definitely an implementation language. It did have 3 syntaxes, though, so could be used to express algorithms that weren't run. See Wikipedia.
Richard
Posted Mar 18, 2005 4:22:33 AM | link
Yes, I wasn't particularly precise and perhaps wrong, but I thought the initial work on Algol was driven by a desire to find something better than Fortran to express algorithms in. I.e. legibility and expressiveness. Algol 58 was used in CACM for expressing algorithms, but I don't think it was implemented even though there were some efforts.
(I knew that later versions of Algol have been used for implementation purposes)
Posted Mar 18, 2005 2:49:12 PM | link
I haven't gotten around to reading the presentation yet. Tonight, probably.
Music does leave some interpretation to the performer. Frankly, I think this would be an advantage in a "game design" notation.
Much of what the notes themselves don't say can be added with very few words. For instance, I played a tympani solo once that said at the beginning of the 4th movement: "As fast as possible, with barbaric ferocity." Yeah, it still leaves some interpretation up to the performer, but you get a pretty good idea of how the author intended it to be played... Likewise, one of my favorite guitar songs says, "From here to the end there are many wrong notes. If you play them well, it will not sound bad." Which is also a good description and, though it is not quite as obvious without listening to the piece, it lets you know alot about how the author intended it to be played (and after at least one translation and a few hundred years).
The problem with most notations is that they're often just as complex as the thing itself, rather than an accessible shorthand. Laws of Form comes to mind... If you want notation to be useful, you have to leave some information out.
This is why I wouldn't use source code. It's a more complete notation, but much less useful. In fact, it's not at all useful to a non-programmer, and game designers aren't all programmers these days.
Besides, a game notation would work on all games, regardless of the medium. Computer games already have source code, but board and card games often do not. Writing source code for a game just to analyze it seems inelegant.
Posted Mar 18, 2005 4:11:33 PM | link
AFFA>a game notation would work on all games
There are some games that couldn't be coded, for example Nomic. I suspect a notation for such self-referentiality of the rule set could be devised, but it would only describe the game at the start, not after several turns.
Richard
Posted Mar 19, 2005 7:28:18 AM | link
Richard: There are some games that couldn't be coded, for example Nomic.
***
Ah, and this is why I continue to read TN -- for these moments in which I am surprised, delighted, and confirmed.
Nomic's Rule 213.
http://www.earlham.edu/~peters/writing/nomic.htm#213
"If the rules are changed so that further play is impossible, or if the legality of a move cannot be determined with finality, or if by the Judge's best reasoning, not overruled, a move appears equally legal and illegal, then the first player unable to complete a turn is the winner.
This rule takes precedence over every other rule determining the winner."
***
Now, what if Nomic were not the exception but indeed the rule? What if all games -- all play -- reduced to Rule 213? Then some things fall out:
a. You can't code play; you can only refer to it.
b. You can't know that you can't code play unless you can code play.
So struggle on, bros.
Posted Mar 19, 2005 10:15:05 AM | link
Nomic can be described. Whether it can be described in a particular notation depends on the notation.
I'm not a fan of the Emperor's New Mind school, so I'm not convinced that programming Nomic is impossible. I can even think of a way to approach the problem ("equation prover" with a NL parser that converts new rules to logical statements). It wouldn't be easy, and the medium would limit the game at least as much as the initial rules all Nomic games start with. But I think a version of Nomic could be coded. It wouldn't be "pure" Nomic with our current AI, but I think that will eventually be possible, too. Color me optimistic.
Posted Mar 19, 2005 12:47:03 PM | link
Code is certainly a practical form of notation, and one thing worth discussing here is, how can we take advantage of all the knowledge that the computer science and software engineering disciplines have spent decades generating, and put that knowledge to work for us?
There have been a few objections to code as notation because of language issues and non-uniqueness, and this is a problem when discussing CS problems. But I also think that computer scientists have grappled with this and have some thoughts about it that we can pull in here. For example, Knuth periodically invents his own machine and language for that machine in order to write his books, and uses that notation in a standard way when expressing his ideas. The point here is that it's possible to choose a language and create standards and conventions that will go a long way. It's not perfect, but I don't think we're going to get a perfect notation system any time soon, and in the meantime we'd benefit from a flawed but usable system.
You'd probably want something less technical than Knuth's language, of course, but the point I'm trying to make is that computer scientists have already thought about this problem a lot, so we should take advantage of that.
Posted Mar 19, 2005 3:58:17 PM | link
Computer scientists have thought a lot about turing machines... No language can fit all games equally well, unless one believes in the optimal language for describing human challenges. One might find a language for describing those games that are sold in stores though.
Posted Mar 19, 2005 5:57:49 PM | link
Computer scientists have thought a lot about turing machines...
I take it you aren't a computer science person then, if you are willing to make such willfully ignorant sweeping statements to try to dismiss the potential contributions of the field.
CS is about a hell of a lot more than Turing machines, and if you read the specific example I cited you'd be able to see that instantly.
No language can fit all games equally well, unless one believes in the optimal language for describing human challenges.
I don't know if anyone here believes that this is the goal. As I said specifically before, notation systems we come up with right now are *not* going to be perfect, but a system and language that helps us express ideas more effectively and succintly will help advance the field of game development. Rejecting potentially useful sources of ideas because they are imperfect doesn't really advance the discussion.
Posted Mar 19, 2005 6:12:14 PM | link
It is really up to you to point at frameworks in CS which have some potential. That current languages are so full of annoyances that one feel inclined to invent new variations for pedagocical reasons isn't really a good indicator, I think. I don't see much progress in computer language design the past 20 years. Maybe petri-nets are useful, but I doubt they are intuitive enough.
Very little of the CS body concerns itself with human beings. That's a problem in relation to game design.
Posted Mar 19, 2005 7:05:47 PM | link
That current languages are so full of annoyances that one feel inclined to invent new variations for pedagocical reasons isn't really a good indicator, I think.
And yet, the whole motivation for this discussion is that game people don't have an adequate language to discuss our work.
Besides which, that's yet another misleading statement which you seem to be making for argument's sake. Knuth didn't invent MIX because other languages were "full of annoyances" so much as other languages were designed for different tasks and so were not necessarily the best for *his* task, which was clarity of expression rather than ease of practical implementation. Which is why I cited it in the first place -- it was one answer to a problem that is parallel to the objections made about code-as-notation.
Very little of the CS body concerns itself with human beings. That's a problem in relation to game design.
Video games are intimately tied to the technical details thereof; ignoring that fact, or ignoring the knowledge that other people have accumulated because it isn't "human" enough, is to blind yourself to the truth.
(See, I can play this game too!)
Posted Mar 19, 2005 10:04:49 PM | link
OK, time for me to post something pertinent to the main discussion. ;)
Jim Purbrick asked what the goal of the notation is, and he suggests that it should be a terse, unambiguous language with which to describe game designs while preserving meta-information. In addition to all those benefits of having a notation, I think that once people start using a common notation system you can start doing even more meta-operations, like analyzing the notations for patterns, commonalities, etc. You can explore this in two ways. You can use this sort of analysis to gain a deeper insight into games, for example by doing statistical analysis on a set of designs expressed in notation. You can also use this in a way that Tom Hudson suggested -- error checking by looking for bad patterns in the notational "source code" for a design. You can also use it to find things which aren't errors but which might be "optimizable", i.e. made more fun somehow, once you abstract the design to a notation.
The inspiration for my thinking here is compiler research and static analysis. Specifically I used to work for a company which does this sort of thing for C/C++ code, and their work is based on the stuff we did as grad students. Clearly it's not 100% transferrable, but based on the kinds of stuff we were able to do with source code analysis, I can see a lot of potential, and that's why the idea of code as notation appeals to me. We can apply all this analysis understanding once we get there.
Stepping back a bit: I agree with Cory's original statement that code already makes for decent notation. What is source code, after all, besides a formal expression of some designed behavior on the part of the thing being programmed?
That said, as everyone's already pointed out, code has many shortcomings as notation. So how to address those shortcomings?
Many of the objections stem from the amount of specificity in source code that is unnecessary to expressing a game design, and that's definitely a problem. Perhaps one way to address this is to, instead of thinking of low level code, think in terms of a higher level API. We have APIs and middleware for physics, sound, rendering, and so on; why not for game design concepts? Although perhaps this is confusing the matter -- you sort of need a notation to develop such an API, so I guess my suggestion is that thinking in terms of creating this API may give some guidance to how to think about creating a notation.
This doesn't fully speak to Jim's need for preserving meta-information; I'm not sure if even a high level programming API or language which overcomes the other objections will be rich enough to preserve the reasoning he's looking for. I think programmers have mechanisms for coping with this, since software development has a lot of similarities to game development (not so coincidental!), but I am not sure right now if they'll be enough for the task here.
Posted Mar 19, 2005 10:05:48 PM | link
yph: Besides which, that's yet another misleading statement which you seem to be making for argument's sake.
Actually, it isn't. The core problem in finding a language for designing games isn't finding the right syntax, but finding the appropriate semantics. Which is a much more deep rooted issue. The code analogy is therefore the mislading one. It kinda like describing what it like to be a human being by describing DNA.
Posted Mar 20, 2005 8:15:15 AM | link
PS2 really sucks stick with Game cube^-^
Posted Mar 21, 2005 3:33:53 PM | link
Do not argue with the powers of Darkness it is far superior to the other consoles out there.
Posted Mar 21, 2005 3:38:14 PM | link
First, I believe all this talk of Alexander's A Pattern Language completely misinterprets his work. Certainly, his Patterns are quite user-friendly, but they are most definitely meant for and used by professional architects. A Pattern Language, written around 20 years ago, and especially The Nature of Order series, a recent work, confront contemporary architectural practices and theories in a most controversial way, and particularly oppose the Modernist and Postmodernist rationales which current architecture is founded upon. Rather than flailing about in the reactionary manner typical of artistic styles, however, Alexander has approached the mystery of what makes "good" architecture from an empirical (if decidely unmechanical) standpoint and ended up with revolutionary, if somewhat controversial, conclusions about the process of creation itself.
I won't go into details on his methods, since that would take me completely off tangent, but I will talk a bit about his conclusions (or at least, those that I have read so far, as I haven't yet gotten to finish his recent works). First, through analysis of relatively simple patterns, he has come up with roughly 15 principles present in all good (or "living," as he puts it) patterns. Off the top of my head, these include distinct scales (a factor between 2 and 4, often being the natural log in the natural world), contrast, boundaries, gradients (such as when approaching a boundary), and possibly the most important, an emphasis on local symmetries rather than global symmetries. These principles will appear recursively in the "centers" that make up a good pattern, in such a way to enhance the effect of the same principles in other centers that make up the whole pattern. Moreover, Alexander argues that such geometric organization will not only enliven the visual aspect of the design, it is often also the very best configuration for a functional foundation.
I believe it may have been that part of his work (which appeared in a rougher form in an earlier article written by Alexander), in conjunction with A Pattern Language, that caused so many software engineers and object-oriented programmers to latch onto his work as a possible bible for software design as well. Could his patterns also lay the very best foundation for code? I am personally not so sure that the meaning of Alexander's geometries can be translated into a form more akin to code logic. But then, I've read of people more knowledgeable than myself on both sides of the fence who see it as a definite possibility. Certainly, there are now popular works on "patterns" for object-oriented programming, and I've heard Alexander was consulted in their theory. How much of his work actually went into it, though, I don't know.
Of course, in the work that I am now reading, Alexander begins describing how, due to the recursive nature of living patterns, none but the simplest end products may be produced as a static form by a "designer". Rather, just as in nature, living complexity requires a process by which to grow. This, I think, [i]is[/i] directly applicable to discussion of notation for a virtual world. Virtual worlds are certainly complex patterns, and I think we can agree their quality, good or bad, can be summed up by the particular degree of "life"(*) that they possess. While you still get into some translation issues in the implementation, a virtual world nevertheless can be far more easily conceived of as geometrical than can the code from which it is constructed. And perhaps I should be saying "games" rather than just "virtual worlds."
A notation system for [i]good[/i] games may need to be structured such that its grammar is a process that inherently encourages the recursive appearance of good design principles (possibly Alexander's 15 principles) throughout the whole. If this is so, then simply giving a mechanical description of the player's options, no matter how easy to read and construct, is going to be relatively little help in creating good games.
*As a sidenote, Alexander has an experiment where he simply shows a person two different images of patterns, buildings, whatever, and asks them which they find to have the greatest degree of life. (He did this in a very controlled form using very simple patterns. I am uncertain how controlled his experiments with photographs of real buildings and such were.) He claims that in all his experiments, a vast majority of people agree on which image has the greatest degree of "life." He also claims that these findings correlate another question he often asks: that is, which image best reflects your own "self"? (That is badly paraphrased, I'm afraid, but that's the gist of it anyway.) This may have implications on subjects concerning identity construction and primary motivations of virtual world players.
Posted Mar 23, 2005 9:11:10 PM | link
yph wrote:
>Code is certainly a practical form of notation, and one thing worth discussing here is, how can we take advantage of all the knowledge that the computer science and software engineering disciplines have spent decades generating, and put that knowledge to work for us?>
Code is *not* the best way to notate a game, if simply because of the learning curve. The time to learn the sytnax and then skillful use of it is very high. There are people whose job is to put the game into code; there's no reason to require the entire team to have that skill.
Saying "the question is not whether to use code as notation but how we can use the knowledge of the field" only makes the issue worse. Do you have to be a computer expert to be a game expert? And yes, I am a computer science person, but haven't always been. Does that mean in the past I didn't have the ability to design games? I was designing games at age 6, so the answer there is no.
In reality, perhaps we currently do have to be computer experts to be game experts. That shouldn't be the case though. There are a large number of people with great ideas and skill to put into game design, but they lack either the knowledge or ability to be computer experts. Bridging the gap would only open the field to more people, which is good.
What is the best use of notation? It's to bridge the gap between the code and regular human language. Neither code nor regular language is qualified for efficient communication about things like game mechanics or layout, both being either too much work or too vague and extended.
Notation may not be capable of communicating everything that code does, but why should it? As pointed out already, code can express the same things in different ways. All this illustrates in relation to game design is that the code specifics don't matter at all. Code is, after all, not the game but rather how we get the game to appear on a computer. What does that have to do with communicating ideas about the game itself?
The problem with notation that I can detect is that it would be limited to fairly specific areas of the game. For example, notation to describe what the skills and spells on a MUD did would be useful until you wanted to notate how specific quests or item stats worked. Changing between genres of games would be even worse.
Still, creating a notation for every game wouldn't have to be much work, and would still provide efficient communication.
Posted Mar 25, 2005 6:55:38 PM | link