Scholars have been studying written texts for centuries. If there’s one thing we’re good at, it’s seeing words on a page and saying something about them (and hopefully saying something smart). When it comes to computer programs, however, we aren’t quite so confident. Computer programs, in all their varied forms, make up a significant number of today’s cultural artifacts. Videogames, smart phone apps, word processors and even operating systems all have a significant influence on our day-to-day lives. Most people agree that they are an important part of our culture. The question is, how do we interpret them?
If we look hard enough, we can find things in these artifacts that at least resemble words. I, of course, am speaking of code – the lines of instructions that programmers use to create a program. For many scholars, this is the natural place to start. If code is at the core of what makes programs what they are, isn’t that what we should be reading and critiquing?
While the “code as text” stance has a certain familiarity about it for many scholars, it is also quite problematic. This issue can be particularly contentious in the realm of Videogame Theory, where debates over narrative and game logic raged for years. In this context “story” was often equated with “code,” usually bringing the author to the conclusion that videogames are severely lacking in the story department. Of course, code is not known for being a particularly good read, so many scholars took issue with this somewhat simplistic understanding of game narrative. In his article “Perspectives on Computer Game Philology,” Julian Kücklich addresses some of these concerns:
The basic problem of this view is the fact that the player does not interact with the code during gameplay, but solely with the interface. He or she might access the code at a different point in time, and might even glean some information from this activity, but it must necessarily remain outside the experience of playing the game. Usually, the only thing the player knows about the world of the game is what is displayed on the screen. However, the player is able to learn about the implicit rules of the game simply by interacting with it for a sufficient amount of time. Thus, without “knowing” the rules of the game – and usually without being able to formulate them, albeit heuristically – the player will find out how to react in a given gameplay situation.1
It’s pretty hard to make a direct correlation between the way we perceive a written story to the way that we perceive game code. As a general rule, readers are directly aware of the story in a written book. Game players, on the other hand, are usually only aware of the games code in a very indirect way. They know that attacking an enemy will do damage and that after so much damage, the enemy will die. They may also know that certain attacks are more effective, but most players haven’t memorized the actual damage values. Even those players with a non-diegetic style of play who prefer to run things “by the numbers” generally don’t learn the numbers from direct interaction with the underlying code, but by careful observation of the code’s in-game results.
So is there value in studying code from the perspective of a scholar in the humanities? I believe that there is. It just takes a different kind of literacy than your normal textual analysis, and I don’t just mean the ability to make sense of something that looks like “numArray[i] = Math.round(Math.random()*20);” although that is part of it. We need to look at code less like a finished novel and more like a collection of the author’s notes. Though all of it provides valuable insight, not all of it is directly reflected in the final piece.
One particularly interesting piece of code to look at from a critical perspective are the comments. Comments have no effect on the program itself. They are merely notes for the benefit of the developers. On one hand, they are irrelevant to the users of the program, while on the other hand, the fact that they are deliberately included and written in much more plain language can make them incredibly insightful.
In his most recent post on Play the Past, Mark Sample compares the practice of commenting code to the medieval use of marginalia – notes scribbled in the margins of manuscripts. These notes could serve a number of purposes. They could be simple aids for reading or pronunciation, or they could contribute to the interpretation of the text on a rhetorical or symbolic level. They could even be corrections or alterations to the original text. These are essentially the same reasons that programmers include comments as part of their code, whether for their own benefit or the benefit of others who might work on the project.
To illustrate this concept, Sample turns to the controversial documentary game JFK: Reloaded by Traffic Games. The game, which the developers promoted as a simulation to help people better understand how the actual events might have transpired, puts the player in the role of Lee Harvey Oswald in an attempt to reproduce the results that correspond to the findings of the Warren Commission. The gameplay emphasizes the difficulty in actually reproducing that version of events, as well as demonstrating many of the other possible versions of the assassination.
Although the developers promoted the game as a serious and respectful simulation of historical events, the comments in the code are filled with crude jokes and irreverent takes on the characters’ gruesome deaths. This suggests that the attitude of the developers toward the subject matter was far from serious. It also serves to justify many of their critics’ arguments concerning the legitimacy of the game’s supposed educational value.
While this article certainly showed a new perspective on JFK: Reloaded, the most interesting questions I got out of it have to do with the way that we look at code and comments, in particular. Since these comments don’t actually appear in the game, are they of any value when examining the game? Are they any more relevant than the unrecorded conversations that happened between developers? If we do use them, how should they fit in to our overall analysis?
It also gives me something to think about as a programmer. Be conscious of the comments you put in your code. You never know who might read them some day.
References
1. Perspectives on Computer Game Philology. Julian Kücklich. Game Studies.
Very smart observations, Pete. There might also be an analogy to the debate over DNA as “code” and our attempts to understand human behavior. The “code” is important, but it’s clearly not the only thing going on.
Or, you could also think about a videogame as a technological system rather than an individual artifact. Reducing a game to its code would be like reducing the Internet to TCP/IP. Sure, both are a key component, but understanding TCP/IP does not make for full understanding of the Internet, not even at a technical level, and certainly not when we factor in economics, culture, politics, etc. The same is true for videogames, no?
I definitely agree with the system view of videogames being more productive than the code view. The latter implies a simple mechanical interaction between the player and code, like pulling a lever. You perform an action and you get a result (though Winner would argue that even the lever has politics). Videogames, like the Internet, rarely exhibit that one-to-one model of interaction. Even players who are essentially giving the same input can interact on a number of levels. You could be interacting with the game on an immersive level or on a more “meta” level.
I think the same holds true for the ways in which people use the Internet, too. Some people are immersed in it, communicating with their friends in Facebook, unconscious of how Facebook is interacting with their computer and their information. Others take a step back and see the structure of such applications not as just a medium for facilitating their online goals, but as an object of interest in and of itself, to be learned about and manipulated.