Archaeogaming

Last weekend I attended the TriBeCa Games Festival, and wrote about it here. One of the major takeaways that followed me home was the fact that objects tend to drive narratives in a lot of games. Don’t take my word for it. Ian Dallas, writer of What Remains of Edith Finch, reflected on his game’s development: “We have a 90-yo woman living in this house. How do we communicate this? We integrated a chair-assist.” It’s show-don’t-tell. The artifact gives the player clues to unlock the story.

Dallas also talked about the overlapping of the real world and the game world during the development cycle: “We redesigned completely all of the rooms at least three times. We made the rooms feel like accretions, a history to these spaces. There actually was because of the layers of previous game development. Things carried through from each design iteration. Stories threaded into each other through the stuff in each room. Every thing in the room ultimately had their own purposes because of the intertwining the stories.” In this instance, each thing has a purpose in the game, and the shingling of items in the room are themselves artifacts of previous iterations of game development. The artifacts tell the story of the game’s narrative, and also tell the story of the game’s development. With games, there are always two levels of archaeology at work, and the above is case-in point.

Later in the day, Jonathan Morin of Ubisoft spoke about the development of the Watchdogs series. For him the cities (Chicago and then the San Francisco Bay Area) set the stage for the narratives to unfold. Morin’s main what-if question that drove the game’s development was, “how do we interact with our cities? The city is a story forged by its inhabitants.” Creating the urban environment and then populating it with hundreds of NPCs all of whom came with algorithmically-generated identities and backstories (even income) led to the creation of unanticipated narratives. Why was an NPC earning $300,000/year found hanging out with other NPCs under a bridge?

Regarding objects in the game, these also helped drive various narratives, some intended, and others accidental. Morin said that “just because you have a gun in the game, doesn’t mean you have to use it.” Morin and his team played a lot with agency v. narrative in Watchdogs 2 especially. Players can follow a set narrative, or they can make up their own based on what they choose to do in the open world of the game.

Letting objects tell their stories is a very archaeological way of looking at the world. Here is a chair-lift. What can we infer from it? A lot of quest-based games contain item-retrieval tasks that when completed allow the story to continue. For example, in Fallout 4, if a player wants to travel to the Institute to begin the endgame scenarios, a teleporter must be built. This device requires the collection of materials from around the Commonwealth. The narrative depends on the collection and assembly of things to make a giant thing that then becomes a plot point for the narrative of the Sole Survivor finding a lost child, Shawn.

Certainly not all games derive their story from the manipulation of objects, but many do. This leads me to thinking about computer programming. The title of this post is a pun on “object-oriented.” Object-oriented programming (OOP) is organized around “objects” rather than “actions” and data rather than logic. In programming, “objects” are bits of code that share certain attributes that are then made to interact with other objects when a program is run. And object on its own might not do something meaningful, but when combined with other objects, a functionality emerges. OOP allows the programmer to break a complex project down into simpler parts to make the coding simpler. OOP deals with data and functions that are gathered together within each coded object. OOP languages include Python, Ruby, and C++. Taken together the objects create the narrative, which appears when the program is run, much like how objects when collected in a game drive the story.

The opposite of OOP is procedural programming. Procedural programming is more linear than OOP in that it involves coded procedures that interact with and change data to create some kind of output. Pascal and C are examples of procedural programming languages. With games, you might consider the logic of how things work—the game mechanic—to be procedural, facilitating the object-oriented action that moves the narrative along. Procedural programming does not tell the narrative, but allows the narrative to be told.

Archaeology is both object-oriented and procedural. Think of the procedural in archaeology as being the method, the “how” of doing archaeology. The artifacts we encounter during excavation or survey can be viewed alone as well as in their archaeological context (their findspots, and their relationship to other artifacts within the same deposit/stratum). Like games, archaeology is predominantly object-oriented; it’s about what we can learn from the stuff that we find. Each artifact tells a story and contributes to a larger narrative, framed by the procedures of methodology.

Archaeology goes one step further in being object-oriented. In OOP, the goal is to create code that solves a problem. One does not program simply to program. When reading recent books on excavation method by archaeologists such as Steve Roskams and Martin Carver, one realizes that questions lie at the heart of what drives the digging. It gives excavation a purpose. And for most games, one can say the same. To be a game by definition, one plays towards a resolution via a given set of rules. Archaeology, then, is a game by definition, object-oriented, and governed by procedures.

—Andrew Reinhard, Archaeogaming