The funny thing about patterns is that I haven't even read A Pattern Language, the book which seems most often cited in regard to this, yet. But I have read The Timeless Way of Building, which introduces the conceptual framework which surrounds patterns.

I won't try to summarize here what the book *says*, but here are a few enduring tenets that I now hold after reading the book:

Read the book if you're interested. It's designed to be skimmable; I got through all 600 pages in two days and I probably read 50% of the text throughout (and skimmed over the other half).

- approach everything as an already-textured space, to be subdivided. design is not a process of creating; it is a process of dividing.

- a description of a project, even though it is made up of patterns with complex nested relationships, can be given linearly. if it does not work, this means the linear description is bad, not that it is impossible to describe.

- the linear description style described by the book roughly approximates a depth-first search, always starting from the largest overarching pattern and working your way down to the smallest, one at a time. but it's not exactly like that.

- a pattern describes a relationship between things, and the effect of that relationship.

- patterns are explicit/specific enough about the relationship and their purpose that they can be proven empirically wrong.

- patterns are the same at every scale. rather than having too much detail, a pattern contains other patterns.

- don't think about the details of a lower-order pattern until you're done answering the one above it.

- using a pattern language to describe an entire project is something you can do in your head, completely.

Coming from MDA, which breaks a game up into mechanics, dynamics, and aesthetics, patterns were a networked breath of fresh air. MDA separated a game apart into pieces in a way that didn't help me think about them much at all. If MDA is a "horizontal" separation, patterns are "vertical."

A pattern by definition contains all three components: mechanics, dynamics, aesthetics. So maybe I am still thinking in those terms, and I needed to study both in order to get to where I am now? MDA helps me understand individual patterns?

In any case, thinking in patterns allows me to break a game up into manageable pieces. Game genres, game promises, game systems, and individual game mechanics... these are all just patterns, or part of them.

Just off the cuff, at the top of a tower defence game's definition I might have a pattern like "BUILD TOWERS TO DEFEND FROM INCOMING ENEMIES". The details of how the towers work need to be defined, but only on a pattern language scale ("LIMITED RESOURCE FOR BUILDING TOWERS") and same goes for the enemies ("ENEMIES COME IN WAVES" and "ENEMIES FOLLOW A FIXED PATH"). These are really bad patterns, of course - they're just names that are thinly wrapped over my gut feeling about what makes these games tick.

But hopefully you can see how "BUILD TOWERS TO DEFEND FROM INCOMING ENEMIES" might describe an entire relationship between patterns (building, towers, enemies), and in-depth might also be seen through the MDA lens (towers can be placed -> tower strategy -> feeling smart for good strategy)

And then, beneath there we have "LIMITED RESOURCE FOR BUILDING TOWERS" which serves the pattern above it, filling in the space left by just 'towers can be built' with a deeper set of relationships (resources, towers) and a deeper MDA relationship (towers cost limited resources -> player chooses where to spend resources -> player feels stressed or confident, has the experience of making cost-analysis decisions)

I am trying to document my patterns and the processes I use for creating them in the Patterns forum here but to be honest 99% of it still happens in my head and stays there.

QuoteKirbyKid — Today at 1:27 PM
hmm
what do you think is missing with the way you used to go about things?
Droqen — Today at 1:29 PM
good question! i think what was missing was.. the feeling that i wanted to use any game design theory when actually making a whole game? i can list out a bunch of jumping mechanics, but that's really just analysis, not application, and certainly not application on a large scale
if i know how to design a platformer character controller that's one thing, but i didn't have any sort of conceptual framework that connected these individual pieces of knowledge into a 'big picture' i had any faith in