« Announcing: Command Lines | Main | Annotated Sword (Play) »

Mar 15, 2005



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


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.



Probably need to qualify this with "C++" or "a general programming language" (Code)... Without knowing Raph's notation, I imagine its computable, for example.


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>http://www.mxac.com.au/drt/Choice.htm and http://www.mxac.com.au/drt/Choice2.htm>http://www.mxac.com.au/drt/Choice2.htm.


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).


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.


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.


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.


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. ;)


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).


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.


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).


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?


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!


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...?


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.


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.


Is there anywhere to read Raph Koster’s presentation on his proposed system of notation?


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 ;-)!


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?



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...


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.



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.


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.


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! ;-)


(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.)


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?


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.


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.theoryoffun.com/grammar/gdc2005.htm now has the presentation, minus all the animation and sound.


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.


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.


"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.


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.



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)


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.


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: 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.
"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.


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.


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.


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.


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.


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.


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!)


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.


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.


PS2 really sucks stick with Game cube^-^


Do not argue with the powers of Darkness it is far superior to the other consoles out there.


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.


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.


I think I love this thread. *g* This is good stuff.

WRT to Alexander, I wasn't proposing any kind of slavish one-to-one translation of _A Pattern Language_ to anything else (including a notation, grammar, or pattern system for game design). I mentioned it as an example of someone who was thinking beyond notation, the promotion of which was the point of my first post in this thread.

I think some of the suggestions in A Pattern Language are silly (for example, Pattern #94, Sleeping In Public, just doesn't seem like a terribly practical idea). But I also think that the authors' notion of trying to recognize mid- and high-level architectural patterns could be so useful that it's worth trying. Even if some of the results aren't particularly useful, others might be, and that's helpful.

So, given that designing a complex computer game bears a resemblance to architecture (both are concerned with organizing pieces to form a functional whole), I wondered if game designers might benefit from a game design analogue to _A Pattern Language_. I don't mean game designers need their own version of Alexander's patterns -- I mean that an attempt to identify high-level game design patterns could prove to have utility.

If a functional notation for game design can be developed, great. I just think there's a bigger payoff in developing a grammar or a set of high-level design patterns. Of course, if creating a notation could help make those things happen, then I'm all for it.

[Side note: it was only after I wrote my little "we need to talk about three levels: notation, grammar, and pattern" message that following a link in Raph's presentation reminded me of Mahk LeBlanc's "Mechanics, Dynamics, and Aesthetics" model. Sheesh. When Montaigne wrote, "There is nothing new under the sun," he was just echoing Ecclesiastes.]



Jarod Scott: 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.

There will always be a significant element of modernism in a pattern-approach, IMO... Anyway, the point was more this: 30-40 years ago the basic idea was to have more democracy and user-involvement in design and decision making processes. This taints their approach quite a bit IMO.

The book is almost explicit on the political goals: "The fact is, that we have written this book as a first step in a society-wide process by which people will gradually become conscious of their own pattern languages, and work to improve them". That's why it is called "a pattern language" and not "the pattern language".

What Alexander et al wanted or intended is perhaps not so interesting, but it is pretty clear that A Pattern Language isn't all that timeless and that it pretty much reflects the philosophies (taste) of the authors and their own time. And they are explicit about it too: "It is a language we have distilled from our own building and planning efforts over the last eight years" (the book is from 1977). That their long term goal was to describe the timeless is another issue, I think.

As inspiration and a startingpoint for like-minded people, sure. As THE foundation for architectural practice, I doubt it.


He is of course going even further in the first book in the series with what is very close to religious rhetorics (The Timeless Way of Building, page 8):

"Without the help of architects or planners, if you are working in a timeless way, a town will grow under your hands, as steady as flowers in your garden.

And there is no other way in which a building or a town which lives can possibly be made."

and on page 10 there are more postulates:

"There is a definable sequence of activities which are at the heart of all acts of building, and it is possible to specify, precisely, under what conditions these activities will generate a building which is alive. All this can be made explicit so anyone can do it."

and page 14:

"The power to make buildings beautiful lies in each of us already.

It is a core so simple, and so deep, that we are born with it. This is no metaphor. I mean it literally. Imagine the greatest possible beauty and harmony in the world -- the most beautiful place that you have ever seen or dreamt of. You have the power to create it, at this very moment, just as you are.
And this power we have is so firmly rooted and coherent in every one of use that once it is liberated, it will allow us, by our individual unconnected acts, to make a town, without the slightest need for plans, because, like every living process, it is a process which builds order out of nothing."

(all typos are mine)


Broadly speaking, I think there is an underlying grammar, and I think patterns are simply common sentence structures. Notation is a way of writing down expressions of the grammar (such as patterns).

Because of this, I was not focused on looking at patterns, but rather at the underlying grammar, except insofar as patterns help in determining the grammatical rules.


Flatfingers and Raph, I am getting confused when you use the term "grammar". For me a grammar just defines the set of legal sentences for a language, but only a subset of these are meaningful. Grammar doesn't really say anything about content. Are you suggesting an algebra for game design?


Ola, speaking for myself I'm probably responsible for a little of the confusion because I've been using the word "grammar" in two different (though related) senses.

At one point I used "grammar" in its loose, informal sense as meaning the rules by which a person forms sentences in a spoken language such as English. The concept I was trying to get across was how the letters in an alphabet, grammatical rules, and themes or plots that a writer uses to write a novel each might be considered analagous to the notation, grammar, and patterns that a game designer might use to design a computer game.

But I also used "grammar" in a stricter, more computer science sense of being a formal term of art for the set of production rules for how symbols can be combined to produce strings (the full set of which is a language). (More specifically, I mean a generative grammar, rather than an analytic grammar, since I'm not trying to suggest that we need a way to parse game design sentences for syntactic validity... although that's an interesting idea.)

So when I see Raph's proposed notations, my first thought (not necessarily a correct one) is, "That's excellent; a notation that identifies game action atoms would be a useful thing to have... but to actually build games we also need a way to specify how those notational symbols may be strung together in game-effective ways -- we need a grammar, too. Hmm... and I think we need a pattern system for the high-level thematic stuff, too."

Based on Raph's last comments, I now suspect I may have misunderstood what he meant by "notation." I thought he meant something like "alphabet", but it now looks like he means what I mean by "grammar" (in the stricter sense); that is, the rules for how to express statements about how a game works.

Either way, I guess I am entertaining the idea of an algebra for game design! I'm more interested in the idea of high-level game design patterns (arranging statements to create themes), but it's worth thinking whether we can get there by building on a notational system.


Meanwhile, here's something else that just struck me. There's been a lot of controversy over whether humans are "hard-wired" for language skills. Even though we learn different languages (English, Danish, Basque, Chinese, etc.), as humans we all seem to share the same *ability* to learn and use language.

So: Is there an innate "game design" language ability?

To put it another way: Are the kinds of games that each of us is capable of expressing conditioned (like spoken languages) on what we're taught while growing up? In other words, do game designers have "dialects?"

Or is there a Universal Game Design Language?



I, too, meant grammar in the stricter sense; I am referring to how symbols (which I called atoms) can be combined legally to create patterns (which are effectively molecules).

I got an email from Berndt Kremeier asking why I had dismissed the (useful and interesting) Game">http://www.gamedesignpatterns.org">Game Design Patterns work out of hand, and my answer was "I haven't--I just think that patterns are sentences, and I am looking for the rules to BUILD sentences." I do think having a notation system would then help move the game design patterns discussion away from largely verbal explanations and towards rigidly defined diagrams. The stuff that Doug Church, Noah Falstein, and Hal Barwood are doing is mostly verbal. The GDP guys do offer some diagrams, but they seem very... ad-hoc.

I also do not have the "alphabet"--that's what I mean when I say I do not have orthography. Actually, it's worse than that, I don't have the phonemes either, though I think we could probably start spitting out a pretty darn good list of phoneme-equivalents (verbs) off the top of our heads.


Flatfingers> Or is there a Universal Game Design Language?

There isn't. ;-) Take the set N of all possible languages and the set of fun games G, then find the most concise language for describing each game C. It is highly likely that the there is more than one language in C. Do you agree? So, any language will be biased. A fundamental problem when devising ontologies.


The idea of a completely unambiguous language to describe a game strikes me as, well, just another name for "gold copy code". Ultimately, that is the only version of the game which will probably ever be finalized (as much as I'm for epistemic proof of concept, rather than ad hoc approaches). In attempting to describe a game, you are essentially going through the motions of software engineering. That field is also full of different approaches, none more correct than another.

Practically speaking, not everyone can be expected to learn a new language. Very few, infact. If Raph's other work (the "theory of fun" stuff) applies here, then design documents, much like games, are systems to be interpreted, and especially in design doc's cases, we ought to aim to make that process as quick, accurate and intuitive as possible to anyone who needs to understand the game - from biz&marketing, to artists, to sound engineers, to coders, to hackers taking a sneaky look at your new designs (Ahh! Hackers are everywhere! AHH!).

The way we use Wikis at work, we've cut the verbosity of design documents down to incredibly workable degrees. For functional descriptions, we maintain natural language for the sake of non coders, but focus on a lack of ambiguity (writing out pseudo-code patches where necessary, but this is rare), and only occasionally have pages go over a hundred words.

The reason this works is because the wiki almost orders itself into the same kind of structure as the code which will eventually represent the game. When you're using a conceptually linked document to describe a game system, and you have a decent grasp of OO concepts, it's only natural that the description becomes an Object Oriented Document.

So, if I talk about a "Character" in the game, it can be as a genotype - used for any situation referring to a generic Character actor. Many Character types extend off the base character class - "TeamMate" "FactionMember" "RingLeader" etc. You never have to re-describe a "Character" where you use the word, since there is a wiki page associated with it every time you create a wiki link with the keyword "Character".

The other nice part of this is it allows you to associate descriptions of particle effects, models, animations, sounds, and HUD graphics & animation (assets in general) with specific pieces of functionality to be visualized. This really allows one to concentrate not just on game design issues, but intuitive feedback design (arguably requiring just as much thought as pure game mechanic design, since it's the only way to complete the interactive loop between player and game). It gives rise to excellent asset descriptions. The wiki is also peer reviewed and maintained, so constant discussion can go on, should descriptions be left unamibiguous. We encourage people to question the design, since sometimes, good design is not intuitive, and you don't want a coder with a grudge writing code he/she doesn't believe in.

Bearing in mind that there will never be a "right" way to notate design, that every approach has its pros and cons, I have to say that I enjoy the middle ground of the wiki. It makes artists feel at home, since the functional descriptions are easy to read. It allows a newcomer to jump between concepts in a very similar fashion to actual neuron structuring - you see a keyword and think "what's that?" and click on the link to find out!

The wiki still allows some creativity on the part of coders by not implying specific algorithms, but *still* provides a strict functional description so that coder's design arbitration does not occur. In fact, coders seem to feel very at home having a fully featured description to work from, without being forced to simply copy out a designer's overspecification.

The main con of a wiki is maintainance... while it's certainly easier to change, and update the relevant parties about changes, *everyone* can affect the wiki, and therefore, it requires the lead designer to have an eagle eye on the updates so that thousands of zombie sniper rifles don't slip through the net. Fear cooks ruining the broth.


Is the complete elimination of ambiguity required in order to have a usefully efficient design conversation?

If so, then Aubrey is right; we're talking about design == code. (Any representation of a thing automatically implies some ambiguity of description, otherwise it would be the thing itself.)

But that's not what's needed. It's not a matter of completely eliminating all ambiguity, but merely of reducing it. In which case it's not necessary to go all the way to code -- you just need a sufficiently comprehensible formalism for describing the action structure of a game to people as different as designers, coders, and artists.

Maybe that's a notation. Maybe it's a wiki. Maybe it's a hybrid -- a new content-specific kind of wiki whose concept linkages are permitted or required by the rules of a formal notation (rather than being ad hoc links). Or maybe it's a purely visual wiki, with graphic symbols standing for concepts. Or maybe it's something completely different.

Whatever it is, it won't be natural language (which is too ambiguous) or code (which is too rigid).



I'm not that knowledgeable about language, but it was my interpretation that although lanaguage can and often is ambiguous, it can be used to convey explicit ideas if enough care is used... especially when describing something like the nuts and bolts of functionality.

I really do not know if I am right about this, so stop me if I am:
Notation, if it is syntactically correct and well formed, cannot be ambiguous (save for a total interpretive breakdown on the part of the reader), but then, it is essentially just another kind of language with stricter grammar. Conventional language CAN be ambiguous, but not every sentance is necessarily, or practically* so.

I'm warey of unconventional, non-language based solutions. Don't get me wrong - if one turned up, I'd be the first to become fluent in it, and am certain we could carve ourselves the same ivory tower fate as the literary community. Hooray!

Unfortunately, part of my job is to communicate game mechanics and designs to people who make games as a day job. (I hate to be the harbinger of practicality. Sorry).

Case in point: I know UML, and have attempted game designs in it. All it really does is clarify my own understanding of the systems. I end up having to explain the game design to people through other means, regardless.

The problem is, what one person feels is an intuitively understandable flow diagram can be a complete maze to others. People have different interpretative strengths and weaknesses for different types of stimulus.

Because of this, a hybrid approach sounds like the right deal. As explained earlier, this is affordable in the wiki - when natural language *does* become too wishy washy, we switch to pseudo-code to get specific. We use other media to get ideas across... sound, pictures etc. A long standing rule in our wiki is that "a picture supports, but does not replace a description". Essentially, we're covering as many bases as possible - if someone can't understand what you mean from a description, maybe a picture will help?

If all else fails, they can just ask. You specify as hard as possible so that it does not come to this. If the people actually making the game have to ask a designer something every time, what's the point of a design document? Something to be weighed at a publisher's meeting?

*Some "reading between the lines" can be so obvious that it may as well be explicit given context. We're not explaining these things to robots, after all.


Pretty much all forms of notation I've ever learned either contain or convey ambiguity--usually marked as such via natural language. Even very rigid forms, such as musical notation, have a lot of flexibility in things such as how you play a given note legato or staccato. Plenty of room for interpretation.

As regards the Wiki, I agree it's a valuable tool, but it's somewhat orthogonal. The notation I proposed is specifically ONLY for systems. The Wiki sounds more like a specification document, which is not the same thing. My notation notion has huge areas of ambiguity because, for example, it ignores the question of presentation altogether. This makes it not useful for creating a full product spec, though IMHO it may make it MORE useful for analyzing games.


There seems to be a misapprehension in this thread that the grammar of a method of notation needs to mirror the organization of what it seeks to represent. But that's only the case if you want a notational system that serves not merely to represent its object but also to model it in some fashion.

I'm not entirely clear on what Raph requires of an adequate notation system for representing game designs (I was stuck home copyediting Smartbomb while Heather got to go to SF). But, if the aim is primarily to give designers a way to concisely represent their game designs in a manner that is amenable to critical analysis, the need to develop a notational system with its own 'generative' grammar that somehow mirrors the grammar of game design seems dubious--especially since it's not clear that any such grammar exists for game design in the first place.

Either way, one of the things that makes art successful is not how well it conforms to the 'grammar' and conventions of its production but how it exceeds them. If the point of game design notation is to make it easier to analyze whether a given game design is of any value and why, I'd wager that fidelity to the 'universal grammar' of game design is not going to be it's defining feature.


I am not clear on what I require from a notation system either. I suppose that in my ideal world it provides

- a syntactical structure or framework that clearly states how games work (in general, though as you point out, many specifics may violate assumed rules)

- a descriptive method that is more concise and less ambiguous than natural language

- a tool for analysis from both a self-editing point of view (i.e. designers sanity-checking and capturing their own work) and from a critical point of view (such as use by academics)

FWIW, through the exercise of preparing the presentation, I did become persuaded that such a grammar does exist.


Ah, I see, and apologize. This is more of a formal abstract design tool than the sort of silly adhoc production method I was suggesting.

I have far more time for it, in that case. I find myself trying to get immersed into my design - playing through the possibility space in your head. We've all seen the rookie mistake of a newcomer suggesting a system which is cool and awesome in just *one* situation, but breaks every other game mechanic in the game, and thus we must explore thoroughly the implications of every system we add in a game, in combination and recursion with other game systems.

FADTs such as the one you propose help to solidify your understand of the systems, and make for more accurate thought experiments. You can be playing the game in your head, all the time glancing at this design road map, watching for the leaks appearing. Good stuff. Erm. Sorry for the previous derailment. Now back on track: how to represent this thing?


Raph wrote:
- a syntactical structure or framework that clearly states how games work (in general, though as you point out, many specifics may violate assumed rules)
- a descriptive method that is more concise and less ambiguous than natural language
- a tool for analysis from both a self-editing point of view (i.e. designers sanity-checking and capturing their own work) and from a critical point of view (such as use by academics)

Thanks for posting the concise explanation, because IMHO this brings us right back to code. After all:
- Code clearly states how the game works, both via code inspection and by allowing you to play the game
- Code and the blue squares demo describe the game unambiguously
- What better way to analyze the game then by playing a version that is stripped bare?

From reading the comments, I am again drawn to the analogy between games and the real world. To understand a rock bouncing and rolling down the hill, you could choose mathematics and physics (the code) -- perhaps with simplified assumptions, ie a frictionless sphere bouncing on an incline in a vaccum -- build a simulation model to whatever level of detail you desire. While you might be able to create a notation for this, I'm not certain that it will lead to greater understanding than the classical methods.

One could also look at the software development itself as a process of similair levels of complexity as game development. Historically, many have cast about for processes and notations to help ensure that good code gets written. On the side, approaches like XP focus on building and refining code, asserting that the fastest complete design of code is generally the code itself. Given the expense of large scale development, it is easy to understand why intelligent and thoughtful people want to formalize the process, but isn't clear that formal development methodologies generate code that is better than XP/itterative methods. FWIW, my experience has been that the latter is far superior.


RUP is iterative and focus on documentation. XP focus on documentation as comments and use pair of programmers and unit testing to reduce some of the problems with having less documentation, BUT both XP and RUP ASSUMES that you start with a solid architecture. For a game, the core gameplay IS the architecture.

Btw, how did you arrive at the code? Clearly you need and SHOULD design before code. You do that if you follow XP too.

Come on, there is no silver bullet.


I'm in trouble now -- I actually agree with both Cory *and* Ola. :-)

In the nearly two decades I've been programming professionally, I've seen all kinds of supposed silver bullets for cranking out "perfect" code. I survived flowchating, and structured programming, and data flow diagrams, and I firmly expect that 5 to 10 years from now we'll look back on object-orientation as an antiquated fad on a par with phrenology.

This left in me a certain distaste for any theory of pre-programming or documentation that was supposedly going to enable me to write complex programs with no bugs. I feel the same way Cory appears to feel -- most methodologies actually impede effective programming by overformalizing it. They try to lock down a design before you start coding, but when you actually start coding, you always (in the real world) realize that there's something you didn't think of that changes the design... in which case, why have so formal a design?

On the other hand, it would be nuts to try to develop a complex application without some kind of design. One of the first real-world rules I learned (which wasn't a part of any formal CS curriculum, BTW) was that the greatest time- and effort-saving tool in any complex programming task was to design the core structure of the program using high-level pseudocode. Once you could see how the main systems had to fit together, and perhaps worked out the key structures of those systems, you could proceed to coding.

Perfect? No. But it was high-payoff because it did just enough design without wasting time overdesigning. Code got written, and while it wasn't perfect, it accomplished the overall goal.

It seems to me that this is the balance point any system for abstracting and representing a game's design ought to seek. Whether we're talking about a descriptive system that allows a game to be analyzed, or a prescriptive system that defines how a game will be constructed, the notation ought to be as formal as necessary to represent the game's structure and behavior at a high level... and no more.

So: Not natural language, which isn't precise enough, and not code, which is too precise, but something in between.

Does an atomic-level notation system go too far towards code? Possibly. How long would it take me to explain to you the essential function of a chair if I had to provide that explanation in terms of the behavior of the atoms that make up a chair? And when I was done, would you understand "chair-ness" or just that particular chair?

I think looking for ways to notate game design atoms is interesting and worth doing. But my hope is that the search for such an "atomic theory" is intended to lead to an effective high-level representation system, because that (I believe) is where the greatest descriptive payoff will be found.



Cory Ondreika wrote:

"Thanks [Raph]for posting the concise explanation, because IMHO this brings us right back to code. After all:
- Code clearly states how the game works, both via code inspection and by allowing you to play the game
- Code and the blue squares demo describe the game unambiguously
- What better way to analyze the game then by playing a version that is stripped bare?"

Here's why I think the adversion to code as a candidate notation for game design is a non-starter:

1. Code _doesn't_ describe how the *game* works. It describes the allowable state transitions of a machine intended to instantiate the game.

2. Blue squares demos are not descriptions at all. They are models.

3. It may be that playing a prototype (model) of a game is the best way to analyze a prospective game's design, but that is an entirely different project than that of notation.

Flatfingers wrote:

"So: Not natural language, which isn't precise enough, and not code, which is too precise, but something in between."

It's not that natural language isn't precise enough. It surely is. It's that natural language is not equipped to concisely refer to the 'atoms' of game design. And it's not that code is too precise, but rather, that it describes the wrong thing. It's referents are not elements of game design, they are elements of software design. (See your chair analogy.)

An atomic theory of game design would, by definition, be a high-level system of representation in the sense I think you desire, since the primitives of videogame design are not primitives of software design in any sense, imo.

Consider bidding (as in Bridge and many other games, for example). Bidding is a game design primitive in my view. But from a software design perspective bidding is clearly not 'atomic' at all. The same could be said about 'turns' in games. The notion of a turn is an atomic one to game design but not software design.


At that point we're surely talking about code patterns becoming the basis of game play atoms? Or would you want a higher level than that?

The problem is, if you don't delve deep enough you won't uproot the issues that you would otherwise make assumptions about - a key goal of the atomic notation.


In addition to what has already been said, it is obvious that two separate bodies of code, unlike two pieces of sheet music, cannot be compared and deterministically declared equivalent.

Stemming from basic theory of computation, whether two pieces of code are the same (ie, on every possible input, the output of each is the same) is reducible to the halting problem and is thus uncomputable. So using code as a mathematical or theoretical model for a game isn't really practical. Models, to be useful, generally need a test for equivalence of models that is computable, never mind efficient.

The comments to this entry are closed.