Kernels Theory Interlude - Yehuda on Mechanics
From a recent post by Yehuda (itself a redux of a much older post on the same theme):
Another classification tool . . . is the “game mechanic“. By game mechanic, I don’t mean game components, such as dice, cards, or “running”. These are good and solid components within games and very useful for classification.
What I mean by game mechanics is the idea that a game fits a certain pattern of strategic thinking. Instances of game mechanics include such terms as “area control”, “auction”, “set collection”, and so on. You can see 43 game mechanics listed on BoardGameGeek here.
Unfortunately, few of these mechanics truly exist; the ones that do specify the game’s components, such as “hex and counter” or “singing”. The fact that these categories don’t exist is why so many people experience frustration when trying to use these terms to categorize games.
The post is insightfully written, and a bit of a reality check to designers and aspirants, such as myself, who spend a significant portion of their times thinking in those terms. It’s like going to the English department at your university and reminding all the literati that words don’t really exist, only patterns of thoughts. How can we think of games except in these terms?
Well, fortunately it is not so dire as that. Mechanics do exist, just not in the particular way we (designers) use them. As Yehuda argues, they are largely ineffective as a means of classification except in terms of theme or color, but this does not leave us impotent to interpret games. The irony is, many many games involve formal systems that tap a common thought process of pattern recognition and application. That games are systems of patterns is nothing new, naturally. However, I feel it may often be overlooked that the mental processes that occur when playing games are fairly universal to all games.
The same methods of systematizing and processing data — “chunking” — and of applying that data within the pattern of rules to form new patterns are the methods that every human brain brings to a formal system. That, in my opinion, is why the “mechanics” Yehuda describes overlap so noticeably. When he deconstructs El Grande and notes that the mechanics of “area control,” “auction,” and “set collection” are all equally applicable to that formal system, it is because the underlying pattern of thought and play for all three is essentially the same.
When I read the post I was put in mind of the Kernels paradigm I developed last quarter. The Kernels theory holds that single, self-contained “seeding ideas” — kernels — can be used in combination as the foundation and scaffolding of a game. I may have been a tad unclear in my earlier post, but the point I wish to emphasize most strongly about these kernels is that they are not mechanics in the classic sense: the sample kernelsI noted for Cowboy Cave were simplicity, speed, low-level persistence, rewarding player individuality, and tactical character construction. As you can see, these are not “mechanics” in the sense that Board Game Geek would define the term, but something akin to the core theme of a pattern — a pattern prototype, if you will. These same mechanics (excepting perhaps the last one) could easily be applied to the construction or deconstruction of El Grande, or indeed to any game. This flexibility and universality is the soul of the Kernels paradigm, and it’s the reason I believe in it. It’s a process of design that drills through the facade of a mechanic and into the pattern theory beneath it.
I haven’t had a chance to reply to Yehuda’s piece yet, but there are mechanics. What BoardGameGeek lists is patterns - combinations of mechanics that lead to behaviour such as set collection and the like. A mechanic is an individual thing - you use X in the lock to open it. That is but a part of a much larger pattern of adventuring.
This language thing… we’re still working it out.
BoardGameGeek may be defining a landscape for the non-digital crowd, but game designers on the digital side of the fence usual think in terms of discrete mechanics and not patterns.
Precisely! The difference is in the pattern, just as I say. I agree the BGG’s choice of wording is misleading—yet another excellent case for the need for a formalized language of design.