What is a mechanic? (my pragmatic view)

This is a little piece about the meaning of the word 'mechanic' which I fired off on Twitter the other day. It's about why talking about mechanics does not need to be rigid or robotic and about the uses and limits of the concept of a 'mechanic'. It's not perfect and probably incomplete but I've been asked to post it on the blog for easier citation and I hope it does a job.

It was prompted by a question from @criticalbrit (now @utterlyhorrid) and a response from @xenobotanist. The original can be found here.

*

Most of the time, when people talk of 'mechanics', I think they mean one of two things:

With the s, plural, 'mechanics', it's a vague but serviceable gesture towards 'the underlying rules of the game', the gamey bits. X game is just the mechanics of Y game but with a different skin. Z game is mechanically innovative.

When you talk of a single 'mechanic', though that's a bit more defined, and tends to follow something like the MDA Framework. This is an analytical tool for looking at game structure. It separates 'Mechanics' from 'Dynamics' from 'Aesthetics' and most formal definitions of 'a mechanic' are vaguely similar.

Let's use Metal Gear Solid as an example:

The fact that you leave footprints in the snow is a 'mechanic' - it's a rule, an individual building block of the game. Another linked mechanic is the rule that if you crawl on snow then you won't leave any marks.

'Dynamics' are the phenomena that arise from these. For example, the dynamic of guards following you even if you're not in their sight when you run past. Also, the dynamic of being able to lead them astray, or in circles. Then there's the difficulty trade-off, which is that if you run past a guard in the snow, you'll be faster but they will follow you. If you crawl, you'll be out in the open, in their sight, for a lot longer, so you're incurring immediate extra danger to gain more long-term security. That's a dynamic too.

In MDA framework 'aesthetics' would be stuff like the experience of surprise when a player realises that these mechanics even exist, or shock when the player is caught unawares. Tension when a guard is following you, or schadenfreude when you use the footstep mechanic against them. But this is a bit confusing because I and many others tend to use 'aesthetics' to mean, basically, 'graphics and sound' - ie, the various ways stuff in the game is represented to the player. Still, we can ignore the 'A' in MDA and still get a workable definition of 'mechanic'.

Nevertheless, there are also a few things which make this framework difficult to apply.

For one thing, individual 'mechanics' can't function in isolation. The footprint mechanics above also depend on the mechanic that 'guards can see things'. And that links to mechanics governing how guards follow and investigate areas. In Half-Life, I guess you'd call it a 'mechanic' that marines can throw grenades, another mechanic that grenades have modeled ballistics and physics, and yet another mechanic that grenades hurt entities to different degrees depending on proximity.

And all this gets us into optical illusion territory. How big is a 'mechanic'? Is the mere fact of a guard seeing something one mechanic, and the fact of investigating another? Is it a bit like Zeno's paradox where you cut something in half and then you can cut that in half and then you can cut that in half and so on forever...? This is one reason why, practically speaking, critics don't tend to talk about AI behaviour in terms of mechanics. All the little nitty-gritty rules of how an NPC in a game reacts to stuff are opaque to the player and very complicated. By contrast, stuff surrounding player verbs is a bit more easy to get a grip on.

Moreover, there are many cases where MDA doesn't really function. In Twine games, as Raymond Neilson pointed out earlier today, the basic mechanic is 'click' (or rather, in the backend, 'move' from one tile to another). But the way Twine games are made basically means that this mechanic has an infinite number of possible meanings and significances. Sure, it's identifiable as a mechanic, you can pin it down and see how it works. But unlike with other games, doing so tells you nothing about player experience or meaning. So it's a bit pointless.

This is why @Xenobotanist's approach is probably the best when it comes to actually designing things. If you think about everything from the level of player experience downwards then you'll always have a baseline from which everything gains its significance. Probably 'what happens in player's minds when they play' is the baseline most game developers are working from.

Also arguably, Twine games and text adventures completely blow our ideas about 'how games work' out of the water. For example, a big part of the 'interactivity' of Christine Love's Analogue: A Hate Story is remembering stuff you read in one part and applying it to a decision later. The same is true in Twine games: one of the player's actions is to read meaning from passages of text and carry it with them until it informs their decisions or reading of another. This is a basic unit - a 'mechanic' - of linguistics and literature, but not of games, because we don't think about them that way. And yet, isn't it just as large a part of games? When you see an enemy for the first time in a game, don't you, to exactly the same extent, 'read' their appearance on the screen, 'read' the signals about your HP and their HP that you get, and carry that knowledge forward?

Okay, so let's define 'mechanic' as 'a rule in the computer system'. The reading happens in our brains and the mechanic happens in the computer. But wait! Isn't it all maths that are happening in the computer? When we speak of footprints in the snow aren't we just talking about our impression, our image, of the complex and pernickety system of programming rules which led to that effect? Is the only mechanic, ultimately, a switch from 1 to 0?!?

Obviously, now we're in useless la-la land. Most definitions of 'mechanic' are trying to arrive at an atomic theory of games. "Here, finally, I have discovered What Games Are! And the smallest possible unit of a game is a Mechanic!" Or it's a Play Atom, or a Ludeme, or whatever. Ultimately I think these theories tend to end up faltering on their own hurdles. There will always be exceptions that break their rules, or otherwise the problems above will surface. To be fair to MDA, I don't think it's an attempt to come up with The Final Theory of All Games Ever. It's just a tool, with its own acknowledged uses and limitations.

Recent discussions about 'formalism' have thrust the question of frameworks and definitions into sudden and explosive prominence. Like Andrew Vanden Bossche, I think that dogmatic definition schemes tend to have glaring theoretical problems even if you completely ignore their politics. For me, the word 'mechanic' is just useful when I need a word to describe 'a piece of rule'; I keep one eye on MDA while using it so that it doesn't end up being a polymorphous word which can mean anything. I'd call the fact that you can jump higher and longer by holding down the jump button in Mario a mechanic, and call the more general characteristics of jumping over stuff 'dynamics' just so that I don't get confused and can separate things out.

I do think a critic should be able to make these distinctions and drill down into the fabric of games because it unlocks important insights. For example, one reason Robot Unicorn Attack feels so happy and free is because it tweaks the aforementioned Mario jumping-length mechanic to have a very long jump arc. When you combine this with the dash mechanic, and the mechanic of being able to jump again immediately after a dash, you get a game which produces a dynamic of constant lift and a feeling of near-infinite flight as you charge your way ever upwards and upwards and up! And now we know how it did it, specifically - or at least I think we do (my theory is open to challenge).

By the same token, though, a critic must also understand that all separations, and all unities, are provisional and temporary. These are useful distinctions to make only when and if you need them. And, obviously, they're useless on their own.