The Tale of %PDF-1.4
Appropriately, as I first attempted to open Preserving.exe, the webpage loaded as follows:
%PDF-1.4 %âãÏÓ 3 0 obj <>stream hÞœVÛŽÛ6_}×Wð‘ VŒx_©Çv³_R_iš5Ò_A__YÞUëËV’7Íß÷ )ÉÞÆiš®5-r†gæÌœÑó—·ŠÝ
And so on, for a number of pages.
A script on my computer had malfunctioned, the PDF containing the report for the Preserving.exe summit had not loaded correctly in Safari. As a frequent user of the internet, Microsoft Word, and Safari, I knew there were a number of ways to remedy this situation: I right-clicked on the link in the word document, used my mouse to hover over “Hyperlink > Edit Hyperlink…” copied (pressing Command-C) the text from there, opened a Safari window, and in the URL textbox, pasted (pressing command-P) the text into the URL text box at the top of the window.
The PDF appeared, and I had just used several dozen bits of knowledge, techniques, and tools that are implicit in the software for Safari, Microsoft Word, and OS X El Capitan. These, as Henry Lowood describes in his discussion of the “Lure of the Executable,” are things that should be considered and documented when we archive software materials, because even if the software systems are executable, it does not mean that they are understandable.
Let’s Think About the User
A common thread through the works of Lowood and Chan/Cope is the focus on the ways in which the user interacts with the collection/software. Sebastian Chan and Aaron Cope’s acquisition of the iPad app Planetary was for the Cooper-Hewitt, and the Hewitt sisters who began the collection envisioned it as an educational resource for designers. Eleanor Hewitt went so far as to write that she was not particularly concerned with the destruction of the materials due to overuse, as long as design traditions were passed down. Chan and Cope seem to focus on the present: they even have a fairly temporary system in place where the creator of Planetary checking on the derivative works made from the source code they made available through the collection. They are mapping out the original vision for the collection, ensuring that design traditions are passed along today.
This seems to be a rather unique perspective amongst collectors; many worry much more about the longevity of the collection, including Lowood. However, he still is concerned with the users, but his focus more centered on use cases far in the future: what are we gaining and losing in our preservation of software, and how will they particularly affect future users? We return to screen essentialism; sometimes, the data you do not see could be far more important than that you do.
Lowood also has some pretty strong critiques of attempting to create an authentic experience using hardware.
“While I do not have a crystal ball at hand, my guess is that for most researchers documentation of historical use of software is a more valid source than a personal experience somehow deemed authentic.”
This rings true to me as someone who has done ethnographic fieldwork on past events. While an “authentic” simulation of a protest might put me in the moment in ways that I could not get from recordings, I would value a video of the protest much more than that. Similarly, even if an archive took the time and money to maintain an NES system with an old television, shag carpet, and mustard-yellow vinyl couch, the experience would not be the same as a home movie of children playing the NES, and interviews with them. after all, we see the NES today through the lens of the XBoxOne and PS4; even an authentic experience with it now does not erase those memories.
What Did I Just Acquire?
The underlying story beyond all of these articles is that the supporting documents matter, and it is rare for them not to be useful. The question considered by Alice Allen and Peter Teuben, posed by Doug Reside: “What are the things we can safely say no to archiving?” rings out, and the answer is that there are a lot of things that are necessary to support the longevity of the collection and the variety of users who may be interested in it.
Both the Planetary and Prom Week case studies demonstrate how having additional materials beyond a video game itself can aid in the understanding of the video game. The bug reports, the decisions made during the development process, revision history of the code, and other supporting materials all can contribute to popular and scholarly knowledge, to future software designers, and to our knowledge of the history of video games. As Matt Kirschenbaum notes:
“Software is thus best understood as an artifact: not some abstract ephemeral essence, not even just as lines of written instructions or code, but as something that builds up layers of tangible history through the years.”
Whether or not later programmers have access to the code of earlier games, by understanding how each piece of software was built, we can better connect one to another.
Documentation Beyond the Code: My Hatred of Clippy
This image of a paper clip with eyes, seemingly benign, highlights one of the other things noted by Kirschenbaum and our other authors: software is not simply a tool, but it has become ingrained in our popular culture at a number of levels. An image of Clippy stirs in me a wrath of a thousand papers interrupted by a little animated paper clip. Software is just as culturally significant as film is today, arguably more so.
Should a ethnographer hear a reference made to a video game, they do not necessarily need to play the game, they need some material to help them understand what that experience was like in its time. This means documenting nostalgia as this Buzzfeed article does, to a certain extent, for those classic 1990s educational video games. At the end of the day, an executable file is simply not enough.
(I think what was so infuriating about Clippy was that it never advanced. It was always at level 1; it sees, “Dear Mr. Smith” at the top of the page and determines that you’re writing a letter because most letters begin with ‘dear.’ Clippy’s fatal flaw was that it had no additional information to share. Once I knew how to write a letter or an essay, my need for Clippy was at an end and since Clippy had no new information, what I needed Clippy for most was turning off Clippy.)
As to the documentation of a video game, I agree that an archival packet should include more that just the executable file; contextualizing materials are vital to understanding as I think we’ve established, but how do we apply this same conservation initiative to the indie gaming trend that was presented to us as being so vital in the PBS video? These are the less than 10 person teams and I assume that one of these people is not a corporate archivist. Where in their business model is the place where they make the archival copy of their bug log for posterity? One of the upshots of major commercial releases is that a lot of people play the game, it is talked and written about, there are copies to be had. With the indie releases, truly phenomenal work might be done and never widely published and so go unappreciated. If no one knows about it, did it matter? If a tree falls in a forest and no one is around to hear it…? – How much does release and popular acceptance matter when determining influence and determination in collecting materials?
(I think perhaps the most annoying thing about Clippy was that it was essentially a pop-up window; it would interrupt you as you started working, rather than creating helpful tips that could be referenced or not without distracting you from the task at hand. Clippy did, after all, exist in the world where pop-up advertisements were aplenty on the internet; I think he was somewhat built on that model).
These are definitely important questions, although I have to say, I think the indie gaming scene is such that most games that are of remarkable quality do find their way into fairly wide circulation. For instance, the game I’m considering for our project, Undertale was made almost entirely by one person (apart from some art), and yet it has been downloaded by over one million people on Steam. That isn’t to say all indie games are like that, but a lot of indie games are played at the very least by thousands of people, who often start reddit forums and document a good bit about the games (the longevity of the reddit forums would then be the issue).
To your point, though, I think that the distributors, Steam, Kickstarter, and Indiegogo, likely all have the overhead space to think about posterity, and to give creators some incentive or space to create archival forms of their works. That would be ideal. Otherwise, like most things in the indie gaming community, I think crowd-sourcing such activities might be doable. If enough people bugged Toby Fox for more documentation, I think he would give it out, primarily because most indie games are not dependent on the sizable proprietary gaming engines that more mainstream companies are.
(I always thought that if Clippy could learn, it would have been more helpful and people would have used it, instead of promptly turning it off.)
While I never worked in the gaming industry, I did work on TV commercials and films. There was never any thought of preserving any part of the work for any reason other than to promote the company. I saw several behind-the-scenes documentaries being made, but the point was always to promote the company, its work, and the people it employed. They were always saying, “Look at the cool thing we did. You want us to make something even cooler for you next”.
Never once was there the thought that someone may want to study the work in the future. And if there was, I think that all the legal agreements, such as confidentiality and exclusivity, needed to develop and sell a game, movie, commercial, or whatever else, would prevent them from handing out almost everything created that went into making the thing, except that which was produced to be distributed, the final product, videos, screenshots, and documentaries.
The legal aspect is a really interesting one; I think that is what would make preserving/working with indie games much easier, because there are far fewer people working on the games, and while there’s a lot at stake, they just typically do not have the overhead that other larger gaming companies do (evident in the prices of the games: a PS4 game will run around $60, whereas most indie games seem to cost between $5-$15).
I think a big difference between video games and film is the fact that people interact with your product in a different way, and you’re expected to fix mistakes that people find. So, if there’s a bug in a game you’re playing, everyone emails the company and asks about it (particularly true as new operating systems come out– most game creators have to make sure their games continue to work for each new OS). The company needs to have documentation for their games so they can address these issues; they cannot just throw out the source code the second that they have the final compiled binary version.
I would imagine a TV show or commercial, though the creator might decide to or need to do some editing after their air-date, probably has to make few adjustments.
Regarding your conversation on the preservation of small indie games – would this be a case where Kirschenbaum’s suggestion for a National Software Registry might come into play? Would a game like Undertale that was downloaded by over a million people on Steam find a place on this registry? I think his idea is an interesting one and seems especially important to put into action while these developers are still around.
I would imagine so– one of Kirschenbaum’s principless for such a registry is a selective process: software would be stored that had a significant cultural impact in some way (page 20 of the final report). I think perhaps the greater challenge would be to document/preserve/archive indie games as a whole, or derivative games. So, for instance, Undertale would easily make it into a software registry, but derivative games like Undertale Red would not perhaps be as “culturally significant,” and therefore not included, although it depends on who is doing the considering.
(Clippy was like the kind of adorable yet socially awkward friend that keeps getting invited to parties out of guilt even though no one really wants him there. Someone should preserve him since he clearly evokes a passionate response through the years.)
Regarding Lowood’s statement about authenticity and your ethnographic example, I understand the argument but I also have reservations. As a social historian, I won’t pretend as though I don’t desire to step back into the world of those I research. I do seek out opportunities that will put me as close to the reality of those individuals as possible. While I will never be able to completely experience an “authentic” moment in the lives of my subjects, there’s value in placing oneself as close to the original moment as possible.
Obviously, it’s impossible to truly summon an authentic moment from the past. Much more to your point and Lowood’s, I agree that focusing the majority of preservation efforts on maintaining/recreating the illusion of authenticity is deeply flawed and ineffective on its own. There’s no question that there should be an emphasis on documentation of user experiences and description. However, I’m not ready to completely devalue and abandon the effort to touch and experience the past in some fashion.
Your point is well taken; I definitely feel there is value in having/maintaining historical hardware, so that researchers and scholars can have the experience of using a piece of software on its intended system. This has research implications that an emulator does not at a number of levels, and there is something in the materiality itself that provides a different experience.
I think the biggest issue that I have is with the discourse/rhetoric of authenticity: if you say one piece of historical hardware is authentic, you run the risk of discounting the experiences of others as inauthentic implicitly. When providing a piece of hardware to use a piece of software, I think we be sure to document
the relationship between the two: Was this the only hardware that would run this software originally? Was it the most common? Was it the easiest/cheapest to maintain? Were there bootleg copies of the software for other systems? These are questions that I think should be answered, and they help dispel illusions of authenticity while giving users a certain kind of original experience.
(Nobody likes Clippy.)
I agree with you about the limited ability to 100% reproduce the experience of interacting with games the way original players would have. I remember thinking while reading the articles that the only step left was to wipe the memories of the players, in order to really get the newness right. It reminds me a bit of film and trope-namers: those classic examples of cinema that seem so clichéd, until you realize all other examples of the trope are imitating this.
I think archiving the branching or exclusionary decisions are definitely some of the most important; the finished product can tell us what the software is capable of, but choices that were discarded can tell us what was envisioned that couldn’t be produced with the given technology.
I agree that the decision-making process is something that I wish we had more data on in current scholarship, and it would be worth it for collectors/archivists to find ways to document that a bit better. Something I really like about Kickstarter projects is that the creators of the game usually send regular/periodic email updates about the progress being made (mostly to make donors feel at ease about the deadlines). Depending on the creator, they can be sparse, just highlighting features, or provide deep insight into the creative/design process of the creator– the latter is far more interesting, and I believe Kickstarter encourages detailed updates… so hopefully that will provide some more information about the creation process of games in the future!