In this chapter I have talked about the perspectives from which I look at processes — perspectives that are authorial, critical, and political.
So far, however, there’s been little mention of something quite important about digital media processes: the fact that they don’t operate on their own. From web-based knowledge repositories to console-based video games, the operations of digital media are, in important ways, only truly realized in contact with audiences. A wiki’s processes mean little if the audience doesn’t use them to add data, edit it, and follow the connections embedded in it. Similarly, many of a game’s processes never come into operation if the game has no player.
None of this is any surprise. But we generally understand this situation from the audience’s perspective, looking at both the audience’s actions and the work’s behavior as though the work is a proverbial “black box.” I believe it is also important to understand this situation more reciprocally: to think about the relationship between the audience’s experience and the system’s internal operations.
Throughout this book I look at this relationship in different ways. I discuss three “effects” that arise from differing relationships between the audience’s perception of a work’s processes and the actual internal operations. I consider the suitability of processes for the audience experiences they are meant to support — focusing on issues in the realm of story and character, but in other ways operating quite similarly to how Bogost looks at the suitability of processes for the rhetorical ends they are meant to serve. Finally, in a few cases I examine audience experiences that only make sense when we think of the surface of a work as part of a process-driven system.
First, however, I return to the diagram of digital media developed over the course of this chapter. Figure 1.4 adds a representation of interaction to figure 1.3. While “interaction” is certainly a contested term, for the purposes of this book I am defining it as a change to the state of the work, for which the work was designed, that comes from outside the work. Interaction takes place through the surface of the work, resulting in change to its internal data and/or processes. In many cases, some trace of interaction is immediately apparent on the surface (e.g., an audience member types and the letters appear as they are typed, or an audience member moves her hand and a video image of her hand moves simultaneously) but this is not required. Interaction, while it always changes the state of the work, can be approached with the primary goal of communication between audience members — as when communicating through a shared virtual world such as World of Warcraft or Second Life. Finally, given the definition of interaction that I am using, it also becomes clear that digital media works interact with more than audiences — which is why the revised diagram also notes the possibility of interaction with outside processes and data sources.
Figure 1.4: Adding interaction to the diagram of digital media.
It is my belief that being able to consider both internal operations and audience actions at the same time will give us a fuller understanding of digital works and audience experiences.
The primary goal of the model of digital media developed in this chapter is not found in its individual components. My main hope is not that readers will come away with an understanding of every nuance of what I mean by “data” or “surface.” Rather, my hope is that a basic understanding of these components will provide the foundation for a new approach to thinking about digital media (and computational systems more generally). I use the term “operational logics” to name a new type of element, specific to procedural systems, that this type of thinking can help identify and analyze.
When a work of digital media operates, this can be seen as an interplay between the elements of the model discussed so far: data, process, surface, interaction, author, and audience. Observing the specifics of this interplay can be very informative. Is the system actually doing what it is described as doing? What unspoken assumptions are built into the ways in which operations proceed?
At a higher level of abstraction, however, we can also notice patterns in this interplay. I call these patterns “operational logics.” In my first discussion of them (2005) I talked about common graphical logics, such as “collision detection.” This is a term for when a graphical system notes the virtual “touch” of two simulated objects. When the Pong ball bounces off the paddles and walls, this is collision detection. It is also collision detection when the Doom engine prevents players from walking through walls — and when it determines that a bullet (or chainsaw) has hit a target.11
From these examples it is probably clear that the same operational logic can be implemented in a wide variety of ways on a continually-expanding set of platforms. Once we have identified a logic it can be informative to make comparisons between different instances. These comparisons can delve deep, into the specifics of how the logic is implemented for different works, or operate at a higher level, looking at how the same logic can contribute quite differently to the experience of a set of works. This is true not only of graphical logics, but of many operational elements of systems. Later chapters will consider elements ranging from the quest logics implemented in many computer games to the assertion and inference logics implemented in many symbolic artificial intelligence systems.
However, while operational logics will, I hope, prove powerful for comparative studies, in this book they are primarily used within the examination of individual works. More specifically, while an operational logic can be seen as a pattern that arises in the interplay of the elements of a digital media system, I am interested in the examination of the interplay of a system’s operational logics — and in this as a starting point for critical interpretation. I pursue this method most explicitly in this book’s chapter on Tale-Spin, which identifies planbox-based planning as the work’s dominant logic, driving the others (a fact invisible when examining only the work’s surface). Though not as explicit in other chapters, this approach underlies much of this volume’s analysis — and it is my hope that these examples will encourage others to further develop their own versions of this method.
11The idea of “operational logics” is my attempt to find a way of talking about aspects of digital media with which other people are also concerned. Given this, should be no surprise that operational logics are related to some of the ideas others have proposed for thinking about digital media systems. Bogost’s Persuasive Games, for example, positions my notion of operational logics as the “tropes” of procedural rhetoric (which seems appropriate, at least for those logics that clearly structure audience experience). The concept of operational logics is also not unrelated to Bogost’s figure of the “unit operation” — though Bogost’s aim is in some ways more general, in that his work creates a foundation for “any medium — poetic, literary, cinematic, computational” to be “read as a configurative system, an arrangement of discrete, interlocking units of expressive meaning” (2006, ix). At the same time, Bogost’s aims are also more specific. For example, he writes, “Unit operations are modes of meaning-making that privilege discrete, disconnected actions over deterministic, progressive systems. . . . In software technology, object technology exploits unit operations; structured programming exhibits system operations” (3). In my current thinking, I use the concept of operational logics only in reference to computational systems (not, for example, traditional cinema) and in a manner than encompasses both what Bogost calls unit operations and system operations.
Game design, of course, is one area for which it is particularly important to consider the parts of a system that operate, and connect, and that can be combined and adjusted to create a successful audience experiences. One influential framework for thinking in these terms is called “MDA,” standing for Mechanics, Dynamics, and Aesthetics (Hunicke, LeBlanc, and Zubek, 2004). In the language of game design, particularly for those familiar with the MDA framework, what I call operational logics might often be called “mechanics” — except that MDA mechanics are framed as being limited to operational logics experienced by the audience. As Hunicke, LeBlanc, and Zubek write, “Mechanics are the various actions, behaviors and control mechanisms afforded to the player within a game context.”
Coming from a rather different direction, computer science has also thought quite a bit about the question of system operations. A general computer science term for a more abstract level of consideration of the operations of process and data is “algorithms.” This concept certainly shares the relatively implementation-independent nature of operational logics (an introduction to algorithms class may implement the “bubble sort” algorithm in many languages and on many platforms). However, an algorithm is usually thought of as an effective procedure for doing something (e.g., how to sort in a particular way) whereas my focus, with operational logics, is on a somewhat higher level: what is done (e.g., sorting of a particular type). Also, of course, there is little emphasis in computer science education on considering algorithms, and their relationships, critically or aesthetically — rather than in terms such as efficiency.
Powered by WordPress