This post comes after seeing the Gamasutra post of the first chapter of Game Design Patterns, a subsequent conversation with Darius, and after reading two posts from Craig on the subject. I still can’t say that I have a firm grasp on anything about the book, but I am now willing to offer my opinions on the subject a bit more freely.

As I said to Darius, I’m not a fan of the “patterns” as I assume they are expressed in this new book (I have not read it as I said to Darius). I will fully back up and elaborate on something I said to Darius though:

I think theorists jumped into patterns before really thinking about what they want to solve. I think that patterns should be able to show problems in the mechanics that will negatively affect the dynamics and aesthetics… In a game, we don’t know the equivalent of [the base concepts we find in computer science]. Maybe “frustration,” but frustration usually comes from feeling lost or cheated; and those things stem from other more meaningful problems which we have yet to fully understand. So how can we move to making patterns?

In computer science, a design pattern is a “general repeatable solution to a commonly-occurring problem in software design. … Object-Oriented design patterns typically show relationships and interactions between classes or objects without specifying the final application classes or objects that are involved. ” [Wikipedia] I think this is the solution we should be going after, and I’m not sure that this is what is being done in current solutions. As I stated to Darius, I just can’t see the mechanic / dynamic problem that a boss monster “pattern” really solves, save those that are more story driven than game driven.

Furthermore, computer science design pattern grew out of a need to solve conceptual problems. Problems like (I’m sorry to use it so much but it’s currently near and dear to my heart) coupling. Students of CS know (or should know) that certain patterns will reduce the reliance of some objects on other objects, thus allowing whole sections of code to be pulled out and replaced without affecting other systems. What problems do we aim to solve with the design patterns offered in the book? What fundamental concept of game design do we seek to improve? Since we don’t know these concepts, it might be very hard to identify them.

I’d also like to jump on the large notation bandwagon for a minute here and offer up the fact that my thesis made a short mention of the topic near the end of it’s life which I still stand behind. When I was first working on my thesis, an interactivity / interactive narrative notation was what I wanted to be the end result. This wasn’t going to happen for an undergrad, but I still wanted to make mention of it, as well as several concepts that I felt were important to creating a usable game design notation. So you don’t have to read the whole thesis, here are the relevant conclusions.

A good game design notation should:

• Avoid using the branch or choice as its key interactive element. Instead, it should be able to notate fuzzy concepts cleanly and efficiently.
• The notation should be easy to read so that a simple glance will suffice to be able to interpret all but the most complex interactive systems.
• It should work on systems of dependency and universality instead of branching.

I would also include that because most interactive systems can (and usually are) made of much smaller interactive systems, the notation should have a way of defining and reusing smaller interactive loops in a variety of places. A simple example of this would be most game buttons that have rollovers. A hover over the button brings up a highlighted graphic or animation, which is one interactive loop. Pressing the button also causes a simple action, another interactive loop. That button may set into motion a series of steps that will end in an affect on the game world, which may in turn be part of set of steps required to do something like build a stronger tank. More loops. I’m not suggesting that you would notate the rollover or button press itself, but you would certainly notate the last two steps as separate loops, one dependent on the other.

The problem I see with most notations is that they first assume the linear interaction and causality. They end up notating things that would be better left up to narrative theory and notation, instead of actual game theory. In my opinion, the flow of levels and tension in a game has more to do with stories than mechanics, semiology and interactivity. I don’t think we need to understand this any better. The problems we have are understanding why certain interactive loops work great, and why others completely end up sucking, and way certain combinations of interactive loops work, but others end up frustrating the user.

A notation that is able to show loops easily would have immediate value. Patterns would emerge from good and bad notations, and we could start understanding just what loops work, and what loops don’t, then actually decide why and create more solutions from those. Armed with such a tool “designers [would] be able to start developing patterns for interactive systems, common ways of structuring interactive works that increase agency, reduce frustration, and enhance the willing suspension of freedom” [Thesis].

I have to agree with Raph’s comment that eventually there will probably be levels of notation, and people will use whatever levels they need and are most useful. I think working at too high a level, especially with notations that inherently portray linear and causal systems, will prevent you from seeing the full potential of interactive systems.

Alright I think I’m done for the night…