Tapper
That describes how we get from the videogame itself—the code and content sitting on a computer or in a cartridge somewhere—to the dynamic results of the game actually being played, and ultimately to the aesthetic responses players have to that gameplay. But can we say anything more specific about that stuff that makes up the game, rather than treating it as an amorphous sea of mechanics?
This essay argues yes: videogames are made up of abstract mechanics, concrete representation, thematic elements, and input mappings.
I'll use the 1983 arcade game Tapper as a running example, because it's pretty simple yet clearly exhibits all four aspects. In Tapper, the player is a bartender who fills up mugs of beer, and serves customers by sliding the beers down one of several bars. The customers move along the bars towards the bartender; serving a customer pushes him back towards the door. The goal is to push the customers out of the bar without letting any reach the bartender.
Abstract mechanics
A game's abstract mechanics specify abstract game state and how that state evolves over time, both autonomously and in response to player interaction. In a typical arcade game, abstract state includes things such as time limits, health levels, powerup status, and so on: anything that is conceptually part of game state, but doesn't make concrete commitments to things like graphics engines, physics engines, on-screen display, etc. One way of thinking about how to strip a game down to its abstract mechanics is to think about what elements you'd put into a board-game or card-game version of the game.
In Tapper, the abstract mechanics are those of an order-fulfillment game: There are requesters (here, bar customers) who want certain items (beers) within certain time limits. There are sources for the player to get those items from (beer taps), and a way for the player to ferry the items between the sources and the requesters (sliding them down the bar). The abstract mechanics of an order-fulfillment game like Tapper are rules about requesters, sources, requested items, the progression of time, and the relationships between each. Changing the game at the abstract-mechanics level involves changing one of these aspects or their relationships; for example, we could make a Tapper variant with no time limits, or a variant where the sources run out of items after a certain number of retrievals, requiring the player to do something to restore the item source (tap runs out of beer, and player has to change the keg to get more beer).
Concrete representation
A game's concrete representation is how the game state actually is shown to the player, usually with audiovisual elements. A time limit, for example, might be represented with a literal clock on screen, or by the position of an object on screen, or even by the tempo of the music. The player's abstract position in a game world might be represented by telling them textually where they are (as in a text-adventure game); or by a sprite on a 2d, top-down-view map; or indirectly by showing the player their first-person view in a 3d game engine.
In Tapper, the abstract time limit within which an order request must be serviced is represented concretely by the customer's position along the bar: their distance from the player's end of the bar represents the time left to serve them. Serving a customer is represented by sliding a beer down the bar.
Concrete representations can have their own associated concrete mechanics: things like collision detection, movement trajectories, and so on. In Tapper, these are fairly minimal, but in a 3d first-person shooter the concrete mechanics specified by the physics engine might make up a fairly large part of the gameplay. Even in a game like Zelda, the concrete mechanics enforce things like which tiles the player can step onto, when something counts as having hit the player, and so on. The concrete and abstract mechanics interact: collisions in a concrete physics engine might cause the player's abstract health state to decrease; and abstract state like "can walk through walls" would in turn modify whether the physics engine enforces certain kinds of collision detection.
Thematic elements
Thematic elements are the real-world references a game makes. In Tapper, these are all clearly about being a bartender, filling up beer mugs from taps, and serving them to patrons sitting at bars. These elements have an effect because a player recognizes them as references to something they know from outside videogames. One way to think about what role thematic elements play is to imagine the same abstract mechanics, represented using the same concrete representation strategies, but with generic placeholder graphics: a version of Tapper where the player is a large oval, slinging triangles towards waiting squares that slowly move towards the player as their time limits count down.
Replacing a game's thematic elements without making significant changes to either its abstract mechanics or their concrete representations is called reskinning, and is a common way of modifying games, especially for user-made modifications. Adding references to recent events to an otherwise fairly standard game is also one way of making newsgames.
Input mappings
Finally, for a game to be a game, it needs player input. Input mappings (or control mappings) describe the relationships between the physical player input, such as button presses and joystick movement, and modification of game state.
In Tapper, pressing a button at the tap begins filling a mug; releasing the button stops filling it and, if the mug is full, automatically slides it down the bar. The game could be significantly changed just by making small changes to these mappings, without changing any of the other mechanics of the game. For example, if sliding the beer down the bar was initiated with a separate button press, instead of automatically happening when the player released the button after filling, the player could fill up a beer at one tap, then notice that another patron was getting too close, and walk over to serve them instead of the customer they were initially planning to serve. Nothing in the mechanics makes this impossible, but the input mappings make it so the player can't actually make that happen.
In simulation games, to choose another example, input mappings often fundamentally define what kind of gameplay is supported. A simulation with abstract mechanics, concrete representations, and thematic elements, but no input mappings, would be a non-game simulation, like those used for simulating weather or various engineering models. How exactly the player gets to intervene in the simulation defines what kind of game it is. Can they start clicking on elements of the simulation world arbitrarily and directly change them, SimCity style? Or do they click on and control characters within the simulation, which in turn change other elements, like Dungeon Keeper? Or does the player only control one character in the world and have to influence the simulation that way, like in some sports games?
* * *
Of course, it is not a requirement that all games equally emphasize all four aspects. In chess, the thematic content and concrete representation are of minimal importance; designing interesting chess variants would focus on the abstract game mechanics. A first-person shooter, on the other hand, puts large emphasis on the game's concrete representation and concrete mechanics (3d graphics and physics). A newsgame commenting on a recent event, or a political game designed to persuade you of a particular position, puts a large focus on the thematic elements. And, some arcade games put strong emphasis on the precise timing and cadence of the input mappings.
This analysis was co-written with Michael Mateas, and versions were published more formally as part of three papers: "Towards automated game design" (2007), "An interactive game-design assistant" (2008), and "Recombinable game mechanics for automated design support" (2008). Those papers also explain why we want this factoring in the first place: because we've been thinking about how to organize and structure mechanics in AI-based design tools, and in particular about the axes along which you can design game variants.
Responses and follow-ups:
In an intriguing comment attached to Ian Bogost's article "The Proceduralist Style" at Gamasutra, Adam Smith suggests that this four-part factoring could be used to think about four possible styles of art games, each of which would focus on one of these factors as the main way of making the designer's point.
In their talk at GDC 2010, the team behind the indie game Osmos factored game design into three components: audiovisual elements, input, and the underlying rule system. Tantalizingly similar! They don't discuss thematic elements, but it's clear they paid a good deal attention to them anyway, with Osmos's ambiguous space/cellular thematic elements setting much of its mood. The main difference is that they only classify pure "polish" type graphics under audiovisual elements, like particle-system effects and textures. They put concrete mechanics that affect gameplay, like physics, into the rule-system bucket along with abstract mechanics, while I prefer to separate mechanics that are closely tied to a particular visual representation (like collisions and movement) from more abstract mechanics (like order-fulfillment or health levels). But in their case, Osmos's physics system pretty much is the rule system, so separating them may not make much sense.