Dear Pablo,
You asked earlier this week how game designers define 'game mechanic' and how you differentiate it from 'game system'. And this is an interesting question, for a number of different reasons, not least of which is historical.

'Game mechanic' and 'game system' are terms that have a history, and it is 'game system' that appears to be the older term, or at least, the term to have come into common currency sooner. Already, by 1974, Dungeons & Dragons talks about its "combat system", Frank Metzner's War Machine in 1984's Companion rules is a "mass combat system" – even Chainmail in 1971 talks of "The Move/Counter Move System", "two systems of movement" etc. In fact, the concept of a 'game system' is completely an artefact of the tabletop wargame scene that was driven forward to a huge degree by Avalon Hill, and that went onto influence videogames more than is usually acknowledged – not least of all via Dungeons & Dragons, the influence on videogames I've discussed many times, including in Imaginary Games.

Some time around the early 2000s, it became fashionable for videogame designers to start arguing about 'game mechanics', and for game studies academics to begin vaingloriously trying to define this term once and forever. Miguel's "Defining Game Mechanics" shows the problem exquisitely – he can explain at great (and beautifully precise) length what the problem is with 'game mechanics', but his solution is to propose yet another definition, a strategy with failure built-in. Also, neither Miguel nor anyone else has been able to show where the term 'game mechanic' came from, or how it became so widespread. However, I can find reference to 'game mechanics' in a 1973 edition of Simulation and Games, a 1979 edition of Games and Puzzles, and its successor The Gamer. In other words 'game mechanic' is also a tabletop game term.

And that's where and why it all goes wrong for everyone trying to 'fix' game mechanic as a term. Because both 'game mechanic' and 'game system' are concepts from tabletop game design where rules are explicated in written form turbovp安卓版. It is a 'game mechanic' in D&D that the D20 is used to resolve a percentile hit chance with 5 percentile increments, and this is part of the 'game system' for combat resolution. It is arguably a 'game mechanic' that pluses on weapons add to both to hit and damage – a mechanic consisting of a great many rules, not all of which appear along with the combat system in the rulebooks. In other words, for a tabletop game, everyone saying 'a game system' is made of 'game mechanics' (bonus points if you spot that 'game mechanics' are also made of 'rules') is continuing the practices of tabletop game design that flourished in the 1960s and reached a turning point in the 1970s – just in time for videogames to join the party and make everything much more confusing!

So the root problem with 'game mechanics' and 'game systems' applied to videogames is that we are applying these terms solely by analogy almost all of the time. Sometimes that analogy goes deeper – when I write a Game Design Document (GDD) for a client, it will be organised into chapters that are conceptually game systems, but nothing inside that design is something I would usually point out as a game mechanic in any formal sense. Conversely, Raph Koster is much happier using the concept 'game mechanic' in his design thinking, but he has a clear conceptual framework that guides his use of this term - and as comments at his blog repeatedly reveal, not one that transfers without friction to other designers! Historically, 'game mechanics' is shorthand for something akin to 'clusters of rules serving a single representative game purpose' in tabletop games. And while some videogames directly parallel tabletop designs, and therefore retain a meaningful sense for 'game system', few if any are specified in actual written rules, because this is not how videogame design proceeds.

So how does videogame design actually proceed? Well, as ever, there are multiple ways of describing what goes on, but I'm just going to focus on how I deal with this problem, as discussed in my DiGRA paper "No-one Plays Alone" (inspired by a brilliant argument I had with Dan Cook!) and explored further with the inestimable assistance of the good and excellent José Zagal in "Game Design Lineages: Minecraft's Inventory". My approach is to recognise that what anchors all the different game design processes are player practices – the things that players learn to do repeatedly. Many of our player practices began as rules, mechanics, or systems in tabletop games – the player practice that you grind for experience points to level up and gain in power, for instance, comes directly from the XP system of D&D. Many other player practices were built up and maintained by the specific design opportunities afforded by videogames. All these player practices form lineages that intersect but also proceed very conservatively… just look at that analysis of inventories in the second paper for a great example!

Most game designers and game studies academics seem to think player practices are an unnecessary abstraction. I don't. Player practices are the real habitual foundation of games and game design; it is 'game mechanic' and 'game system' that are largely abstractions of convenience. They are relevant and useful only as long as they can be applied – which is to say, only with complete confidence when there are written rules. This is always the case at the tabletop, and is sometimes the case with videogames, especially if the game designer has a background at the tabletop and therefore writes their GDDs in the style of a rulebook, or when a coherent conceptual framework allows the terms to be used with local precision. In all other cases, you can invent a set of rules as a mental model for what's going on… but it's always going to be a post-hoc justification for taking the analogies with tabletop design further than ought to be comfortable.

Videogames do not usually invent new 'rules' as such, although they are sometimes conceived of in terms of 'game systems', and 'game mechanics' are solely a way of picking out an arbitrary aspect of the game for discussion in isolation, usually held together by a common representational purpose, or else centred upon the player's choices (also a concept coming to us from the tabletop!). What videogames turbo Ⅴpn do, however, is iterate player practices. Watch the evolution of arrow keys to ASWD and mouse look between Dungeon Master and Half-Life via Quake and you're watching actual changes to actual player practices, reflected in the games being made and how they are being played, none of which involves a 'game mechanic' in the sense that this term was being used in tabletop design, let alone a 'game system' – even though I would have the greatest sympathy for anyone who said that the ASWD and mouse look scheme was a control system because, frankly, that analogy is easy to follow.

Every year, a horde of really interesting videogames die a commercial death because the people making them forgot that new players did not know anything about how their otherwise wonderful game worked. Instead of taking a set of existing player practices and putting a new twist upon them, they invent new player practices from whole cloth… and then few if any players put in the effort required to learn how to play. We don't even provide manuals ('rulebooks') any more to make the learning any easier! Players are dumped into a new videogame with just their prior habits to rely upon – which is why thinking in terms of player practices eliminates in one simple step myriad close-to-hopeless commercial paths in game development. If you don't know any of the player practices your eventual audience has already learned, your project is already in serious trouble! More likely, you know it so well you don't even think about it, precisely because player practices are turbo兔子官网.

The videogames that succeed combine and iterate player practices to create new experiences – nothing in Fortnite is 'new' except the specific combination of practices each season brings to bear, rooted on practices raided and inherited from elsewhere. Minecraft's core player practices, including its inventory, are inherited from a grand tradition of prior games that also participated in those practices. And all these player practices are sustained in videogames because code and assets were created by developers who had learned the player practices and could create new videogames that reproduced them. Sometimes they did so thinking about 'game mechanics' and 'game systems'… but regardless of how they described what they did – they took the existing player practices, and developed them into a new videogame.

That's the game we play as game designers – and it's a game with a long history.

Many thanks for kicking off this discussion,

Chris.

In response to Pablo J. Gorigoitia's tweet on Monday 29th June 2020.