If you haven’t seen the news, BGG has launched a major change to the game database. The mechanisms/mechanics descriptors for game entries has been greatly expanded in alignment with a recently published book on game mechanisms, Building Blocks of Tabletop Game Design (2019) by Geoffrey Engelstein and Isaac Shalev.
The synopsis is that we’ve gone from 51 terms for mechanisms to 186 terms. The new set is, by virtue of the sheer number of them, considerably more detailed. Instead of a singular “worker placement” we now have seven different mechanical nuances defined for worker placement games.
Before digging into an initial critique of this change, I do want to acknowledge the work that was done in creating Building Blocks of Tabletop Game Design (2019). As a game designer myself, I’m always interested in thoroughly developed texts that dig into the minutiae of game systems and mechanisms and (most importantly) how those shape play experience. Having 186 well-described mechanisms is a trove of useful ideas.
But as a classification system used in a crowd-sourced database? Well, I have a few lines of critique on this decision to change the BGG database in this manner..
(1) To get a basic one out of the way, understanding the nuances and distinctions between these 186 mechanisms requires attentiveness and study. It also requires purchasing the book, which happens to have a list price of $80 and is new on Amazon for $75. I have a principled objection to utilizing a classification system for a community-driven database that’s behind a steep paywall. It’s a matter of equity, as those who control the knowledge can better wield power and authority. We don’t need this on BGG.
Truncated definitions are listed under the new mechanism entries, but I think these need to be greatly expanded with text from the book by the authors. Discussions will inevitably descend into the mire linguistic arguments (as they often do on BGG), and it will be hard to use these terms correctly unless they are made more accessible.
(2) The purpose of BGG classification system (specifically the “category” and “mechanism” fields) in my mind is to help users find and identity games subject to their interests. Any classification system will invariably brush up against questions about the appropriate level of detail that is needed. And while I have plenty of critique about how the categories and mechanisms of old were assigned, the overall numbers felt about right. 186 is way, WAY too many. In practical terms, a simple search for “worker placement” games now requires selecting from among seven different sub-flavors. How many of the casual BGG users (that make up the majority) are going to wade through this?
From a database maintenance standpoint, the difficulty in comprehensively and accurately assigning mechanisms to games has gone up tremendously. It is one thing if we had dedicated librarians cataloging and maintaining the database, but it is up the collective community to do it. I’ve focused extensively on game classification and taxonomy in my work on BGG and in my writings, and I’m thoroughly overwhelmed at the prospect of trying to manage this number of mechanisms. People are already discussing the need to have a "poll" to determine major versus minor mechanics in the game. This, right here, indicates to me that the scope is off if this is to be a usable classification tool.
(3) The Building Block taxonomy itself is not “complete.” I fully recognize that it will likely never be complete, as there are always going to be greater levels of detail to drill into and new ideas or mechanisms that could be included. But there are, I feel, some basic omissions. Where are mechanisms related to creative or performance activities (hallmarks of many party games)? Where are the mechanism related to dexterity type games?
The set of mechanisms on offer, while quite detailed and nuanced, are also fairly myopic in the picture they paint of the hobby and related design spaces. The chosen mechanisms lean heavy towards modern eurogame sensibilities. I found it not at all ironic that Worker Placement, a cornerstone of modern eurogaming, has it’s own category for example. As an insider design resource, this is more understandable. But when applied to public database meant to capture the breadth of the hobby, the bias is noticeable.
(4) The biggest issue with the old BGG classification system is that the category and mechanism fields were a hodgepodge of stuff. Categories kinda-sorta related to what we would think of as “genres” in other fields (e.g. music), but also contains all sorts of thematic references. Theme should really be its own field definition. The mechanisms of old likewise contained stuff that was probably better suited to defining a genre of game (i.e. I want to play a “trick-taking game” or a “press your luck game”). So it wasn’t without its share of problems.
Selwyth’s Alternative Classification Scheme remains one of the most insightful and effective approaches to sorting out the critical distinction between game “genres” (aka category) and game “mechanisms”. Selwyth spoke eloquently about the need to find the appropriate “scope” or “zoom” for a system, so things are differentiated enough to be meaningfully useful, but also not so detailed they are overwhelming and unwieldy.
Unfortunately, these latest changes do nothing to rectify this problem. In fact it probably makes it worse. Many of the old mechanism categories - which ideally should be re-coded as “genres” under Selwythe’s scheme - have been reassigned into one of the 186 detailed mechanism categories. Sorting those out and pulling them, if needed, back to a genre field is far more difficult now.
Perhaps more significantly, this change reflects a tonal change in value. By rebuilding the database around such a detailed taxonomy - likely unwieldy to both users and maintainers - while ignoring the higher orders of taxonomy and the critical distinction between “mechanism” (as a purely mechanical thing) and genre (as a primarily “experiential” thing), we are thus further fetishizing game design intricacies over the player-centered shared experience of “gaming.”
The above is a mouthful. And I say that as a game designer who is very much interested in “game design intricacies” (and which the Building Blocks books is a great reference). But I don’t think basing a crowd-maintained database on such a detailed system is sending the right message about our community, never mind the practical problems we’re likely to run into along the way.
Geoff and Issac's work is awesome (from what I've gleaned from Amazon's "look inside" feature), and will be a great resource for designers. But I'm having a hard time understanding why the decision was made to use this system as a database classification tool, and more importantly, why all that effort was expended when even bigger issues affecting the database classification scheme (i.e. the messy category field) were ignored.
No comments:
Post a Comment