So, I ended up having a pretty interesting conversation with Jeff about game design patterns. Jeff would like it known that he is still working all of this through in his mind and work was being a bit distracting durring the whole conversation, so if he sounds a bit scatter brained here, theere’s a reason. Anyway, here it is, for your edification.
Jeff: Hey… did you see this book?
Darius: I read the excerpt that was published on Gamasutra, and I forwarded it to Craig.
Jeff: What’s your all take on it?
Darius: I think pattern language is a very valid way of talking about game design, but I’m no expert, which is why I wanted Craig to take a look. So yeah: good idea, but I can’t comment on implementation.
Jeff: I’m all for game design patterns… but I don’t think that book is about game design patterns, honestly, from looking at the Table of Contents.
Darius: Did you read the excerpt? It’s really short. According to the introduction at least, it is. I’ll glance at the Table of Contents now.
Jeff: I skimmed, I’m afraid.
Darius: The ToC looks like it’s about game design patterns to me… what leads you to believe otherwise?
Jeff: I don’t feel things like boss monsters, deadly traps, tools, etc., are patterns. I think they’re concepts. They’re terms like “encapsulation” or “coupling.”
Darius: Well, most people who talk about design patterns believe that everything is a pattern.
Jeff: I take the approach from computer science, which says that a pattern is a reproducible solution to a recurring problem.
Darius: A boss monster is a reproducible solution to a recurring problem: it provides tension and narrative resolution, time and time again.
Jeff: Except that tension is considered a pattern.
Darius: Right, everything is a pattern: patterns within patterns.
Jeff: I’m just not sure.
Darius: Also, in the sample chapter, the author actually says, “patterns include well-known concepts such as Boss Monsters … but also more abstract concepts such as Hovering Closures and Trans-Game Information.” The author is acknowledging that Boss Monster is a concept, but is not excluding it from patternhood. I am not an expert on design patterns in CS. I know very little about it, which is why I really want Craig’s opinion.
Jeff: I haven’t had much time to really think about it much.
Darius: I just emailed Craig and asked him for his opinion. I’ll keep you in the loop
Jeff: Something doesn’t sit right with me considering a Boss Monster a pattern. It’s too specific.
Darius: Don’t get me wrong, I’m also worried that the “everything is a pattern” approach is possibly an oversimplification. I was just defending for the sake of argument :)
Jeff: I’m just not sure how it helps us. Patterns should exist so that you can look at a game and say “this is suffering from too much / too little *blank* and we can fix this by doing *blank*”. And I think that narrative patterns and solutions should be completely separate. Game design patterns should only concern game rules (and possibly space).
Darius: So let’s look at this from an MDA standpoint: you’re saying that patterns should concern… just Mechanics? Just Dynamics? Because Boss Monster is a Mechanic and an Aesthetic.
Jeff: Except Boss Monster is just an obstacle. Granted, it’s a more major obstacle than others.
Darius: So you’re saying that the game dynamics (i.e., flux of the game state) can manifest as patterns, and we can apply a pattern like Negative Feedback Loops to fix those problems, but the actual objects we put in the game world to create the Feedback Loop are not patterns?
Jeff: I’m not sure. I think I would want to think of patterns as relations between atoms that affect dynamics. I would think of most of these patterns as atoms. So it’s not that you have a boss monster that’s a pattern. I would be how the boss monster behaves relative to other situations, or to other mechanics. Also I think theorists jumped into patterns before really thinking about what they want to solve.
Darius: I agree wholeheartedly with your last statement.
Jeff: I think that patterns should be able to show problems in the mechanics that will negatively effect the dynamics and aesthetics. So for example… in CS you have this concept called coupling… meaning things rely on each other too much, and you have ways of spotting coupling using UML.
Darius: Okay, I see that.
Jeff: In a game… we don’t know the equivalent of “coupling.” 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?
Darius: Yeah. As you can probably tell, the only game design language that has really impressed me so far has been MDA. Were you at Raph‘s talk at GDC about his proposed game language? The one that sucked royally?
Jeff: I think Raph’s on the right track, though.
Darius: I do too! His concepts are right, but his implementation was flawed by tons of almost newbie mistakes.
Jeff: I think MDA helps you understand the relationship and flow of a game. I think Raph was aiming toward documenting the mechanics. You document the mechanics, you can start to see where dynamic / aesthetic problems might occur.
Darius: Right, like UML reveals patterns.
Jeff: Exactly.
…and Craig just posted his response to the sample chapter . Which I think is a very valid response.
{ 2 comments }
Valid, if exceptionally unhelpful…
I’m working on a post I think you’ll enjoy, Darius.
Its meaningless to argue whether things are patterns or aren’t patterns, because patterns only exist in our brains. The important thing is that people do percieve the world in terms of pattern recognition, its a physical fact, and the thoughts of a game designer and a gamer are no exception.
The wild card in terms of design and design patterns is the counter-point to pattern recognition, sequential logic. The way we order our perceptions into “concetps” and relations and most of all our perception of temporal causation has to do with logic. Hence my interest in the Phi phenomena.
From an MDA perspective, perhaps mechanics can be seen in terms of logical rules, dynamics can be seen as ranges of patterns along continuums, and aesthetics can be construed as the experience of the player in utilizing both there pattern recognition and logic to construct an experience. The confluence of pattern and logic in the brain is whats called subjunctive thought, the faculty that allows us to consider remote possiblities, our imagination.
This all adds up to a model where game design patterns, as well as instantative patterns within play, are the medium between the designers labor (writing and tuning the mechical encoding) and the user’s aesthetic experience. Its useful to talk of design patterns not because “everything is a pattern”, but because that is the langauge the author and audience have in common.
That said, the book seems to be either obvious or crap, as Craig said. I found this same flavor on reading the second half of 21st Century Game Design. The chapters on “structural game design” regarding different genres seemed like a bug catcher’s list of finds. The danger of talking about design patterns of “sturctures” is that they paint conviently static picture which discounts the creation of anything radically new.
Comments on this entry are closed.