Review: "How Pac-Man Eats"

Noah Wardrip-Fruin has a great eye for identifying undercurrents in games and digital media. His previous book, Expressive Processing, was a great introduction to ideas such as the "Eliza effect": that familiar experience where computer users ascribe great intelligence to a system that doesn't actually have it, but behaves as if it did (an effect that's very familiar to all game AI developers) - along with comparisons to the "Tale-Spin effect", for systems that are intelligent and complex but fail to convey it, and to SimCity, where internal complexity and how it is communicated to the player match perfectly.

In his newest book, How Pac-Man Eats (MIT Press, 2020) he takes on another one of those ideas that feel very familiar, but also foreign: how do mechanics and systems communicate meaning to players? Can it be that some mechanics are better at some forms of communication than others - and if so, what is the interplay between what the game is trying to communicate, and the mechanics it uses?

These questions are familiar, but we don't typically talk about the details of how this happens. We don't have explicit techniques for analyzing interaction between mechanics and meaning, and yet they happen all the time, and as designers we just internalize them and how to make them work. But implicit knowledge is hard to talk about, explain to others, and teach to students. So the book opens up new doors for the game design practice: a new way of talking about an interesting and important aspect of game design.

This extended review describes the book, and what the author finds when he puts this aspect of game design under the microscope.

* * *

"How do games manage to communicate anything at all?" is a basic question that gets side-stepped in design practice. As designers we are very aware that our games are intensely meaningful to our players, that they make meaningful connections to their real world - and most of the time what they communicate is even intentional. But the question of what role mechanics play in this doesn't get as much attention.

Part of the problem is that we don't have a very good vocabulary for this in game design - not yet anyway. How do we talk about the fact that mechanics and systems work together with visuals and story to communicate something? How do we talk about mechanics having communicative affordances, or the aesthetics of engaging in interaction with a gameplay system?

In short: we tend not to. It's more common to talk about communicating through the narrative or through visual design. As we look at the story elements of something like, say, Call of Duty 4: Modern Warfare, or The Witcher 3 - or, for that matter, Stardew Valley - we know how to analyze those. It's easy to see what the narrative and the world-building communicate, and how the different characters, story, or visual elements reinforce (or subvert) the communication. And this happens not just in design practice, but also in academic work, which tends to concentrate mainly on the analysis of games as if they were film or stories.

But there's a problem: games communicate even when they don't have a story attached. They can't help but communicate. Just having mechanics and visuals is already enough for players to start understanding the game as a small, self-contained lifeworld, and map it to their own lived experience in the real world.

Some of these effects have been known for a long time. For an example of an extremely story-less game, SimCity 2000 / 3000 games have been well known for arguing for the benefits of "green" transit and energy sources, purely through mechanical and art design - for example, eco-friendly transportation options were pretty uniformly more beneficial, better looking, and negligibly more expensive, than the "dirty" alternatives. There is no eco-friendly storyline here, but it's not necessary - the meaning comes from systemic design, and it's clear to the player what those systems are trying to say about our decisions in the real world.

And sometimes this communication is harder to notice. The excellent Civilization series has been with us for a long time, but it's only recently that people started focusing on what its systems could be communicating. For example, the ideas that tech trees present human knowledge as following inevitable trajectories of improvement, or that the game's scoring system reinforces an all-consuming winner-takes-all approach to world politics: those are powerful subtexts being communicated by the game's systems. And if they were unintentional, as I expect was the case, it makes them that much more interesting.

Games clearly can and do communicate through mechanics and systems. But when we talk about game design practice, we rarely talk about this aspect of game design. We are very good at analyzing how systems behave: translating from mechanics into gameplay and into player experience. But we need a better way of talking about how systems communicate.

* * *

How Pac-Man Eats tackles this head on. It starts from a deceptively easy example: when we play Pac-Man, how is it that we perceive those few lit up pixels on the screen as someone who is eating? It's deceptive because it seems so obvious: Pac-Man looks like a giant mouth, opening in the direction of dots, which then disappear when they get in the mouth, so the eating metaphor is easy to see for everyone, even though the Pac-Man sprite itself is only a few pixels tall.

But at the same time, many things must go right for this metaphor to click: Pac-Man needs to read visually as a mouth, dots need to look like possible food, and the mechanics of colliding with dots and what happens afterwards need to be consistent with "eating".

Imagine what would happen if any of these were not there, for example, if Pac-Man looked like a walking Godzilla instead of a mouth, dots looked like buildings instead of pills, and the collision mechanic spawned explosions instead of removing the dot - with only slight changes, the game would no longer "read" as eating, it would read as a violent monster on a rampage.

Pac-Man is the author's core example, and the book explores many further cases from different games, to see how mechanics and systems end up communicate with the player, and succeed or fail in various ways. In short, several themes emerge throughout this process. Mechanics communicate with the help of other aspects of the game, most importantly visual design: Pac-Man must look like a mouth for the collision to read as eating. But the actual behavior of a mechanic is also crucial to communication. Removing the dot makes it look like it was eaten, and if instead it exploded with a bang, it would read as something else. And the connection of mechanics to other aspects is not arbitrary. Mechanics have communicative affordances, and various mechanics encourage some meanings but not others: Pac-Man removing the dot affords meanings like "eats" or "destroys" or "squishes", but it doesn't afford meanings like "creates", "nurtures", or "praises".

And so, the author proposes that we extend our notion of the building blocks of design. Mechanics and systems are usually discussed in terms of how they're built, and how they behave. But we need another aspect: how they communicate something to the player, both about the game world and about the real world.

To this end, the author introduces an interesting new abstraction: operational logics. At the risk of oversimplifying, an operational logic can be thought of as a combination of mechanics plus their communicative aspects: the mechanism that works in a certain way, plus what that communicates to the player. And while mechanics by themselves can be analyzed structurally, logics cannot - the meaning is tied to the larger aspects of who the player is and how they will understand the visuals and the behavior. Logics require cultural understanding alongside structural and behavioral analysis.

And this is the heart of this book - a new abstraction, a new tool for discussing something that we've always felt was there, but didn't have a good way to identify. This tool lets us broaden our conversations as we discuss game design: we can talk about mechanics and systems not just in terms of what they do, but also what they will mean to the player.

* * *

The book is structured in a very narrative way, introducing some historical elements of game design before getting to the crux of operational logics right in the middle of the book. The material is clearly written for multiple audiences - practicing game designers, game studies scholars, and students of game design, will all find relevant information there.

Consequently, the first part is focused on shared foundations and introducing the main elements. The book starts with the discussion of how mechanics and communication are linked together, and why we need to consider them together in terms of operational logics. Concrete examples are used throughout. A Tetris reskin with gruesome graphics, or a Bejeweled clone with gems themed as exploited workers that need to be moved around so they can be eliminated, underscore how much meaning can be changed purely with reskins, without mechanical modifications. On the other hand, discussion of games like Dys4ia and Papers, Please shows how much more we can get from building mechanics that work together with the communicative layer, and arranging them to reinforce each other.

Then in the second part, the author turns towards the nuts and bolts of the creation of logics. Those later chapters look at a number of pioneering games, their design trajectories, and what kinds of logics they ended up building - a good reminder that logics can be arrived at accidentally, for example the very early games like Space Invaders which set the tone for many arcade games that came after them. Finally this section ends with with more detailed discussion of how logics can carry metaphorical meaning, and how we can overload individual mechanics with several communicative options to produce specific rhetorical or metaphorical effects.

* * *

As the concluding chapter reminds us, games are rarely just games. They're usually games about something, they bring the real world into the game. As designers we may be used to treating them mechanically as just games, or narratively as just stories about something, but our intuitions keep telling us that these are really two sides of the same coin. Studies like this one help us see how to turn those intuitions into an explicit goal, so that we can start pursuing both together.