http://americancensorship.org/

In the window of a rare vinyl store in Hollywood Boulevard, on flickr, by Rich_Lem

In October I ventured to three locations in Mississippi with a coworker to deliver records management training to municipal clerks. My portion of the training addressed electronic records in the state. Here I discuss strategies I used and share some thoughts on teaching what is frequently dry material for an (often reluctant) audience.

A little context on government records in Mississippi: for local government, all electronic records are managed and maintained by the originating agency. If electronic records are scheduled as permanent, they’re kept with that agency forever — they don’t go to the state archives.

By contrast, there are two primary supporting resources for state agencies. The first is a tape backup service offered by us, as well as the ability to take their permanent electronic records into the state archives. The second is the counsel, services, and guidelines of the state IT department. Local government of course has our counsel with any of their records concerns, but we don’t offer any services to them.

Because few municipalities (if any) have the resources to employ a records manager, it’s not atypical for electronic records management to be distributed among all municipal employees in an ad-hoc and uncoordinated manner. Professional document or records management software is out of scope for most, since such packages are too expensive and the volume of electronic records produced is typically too low to consider the purchase. The same is true of email archiving services. Open source would appear to be ideal but those solutions really do require dedicated IT administration, which is limited for many municipal projects.

My portion of the workshop lasts an hour, and the goal was to give attendees the knowledge to manage their electronic records better than they do now. Outside of the constraint that all record management has to occur with the agency, there are a few other hurdles to teaching effectively in this hour:

• Little foreknowledge of each municipality’s specific tech setup or electronic records management strategy.
• Little foreknowledge of each attendees’ computer literacy.
• No foreknowledge of attendees’ specifics jobs or the records they regularly handle.

Unfortunately these constraints were outside of my control. However as I hope to share this doesn’t mean the hour can’t be successful.

I broke the material down into steps, such as setting public records apart from transitory or personal documents, basic storage strategies, security best practices, and so on. For the steps where it’s applicable, I made a list of computer skills one would need to execute that step. For example in setting public records apart from non-records, necessary skills are creating folders, naming and renaming folders, and moving files and folders, among others.

I didn’t create these skill lists until the second presentation, when it struck me that attendees may be overwhelmed or discouraged by a long hour of “you should do this” and “you need to do this.” Some of the skills I’ve listed may seem basic but I felt it was important to try to empower the audience, in this case by indicating the specific (as specific as I can be in this case) skill needed.

Records grow on trees, on flickr, by erikadotnet

When I asked for a show of hands on these I had anywhere from a handful of attendees confirming their ability to a majority affirming they knew how to perform the task. There’s a risk that those who don’t know how to do something will feel bad and decide to reject or tune out the material. I always state however that it’s okay if one doesn’t have these skills — they don’t just fall out of heaven and into your head, so it’s alright to ask someone.

Still, I’m actively reconsidering whether I should ask for a show of hands. I want to engage the audience but I don’t actually do anything with that information, so it’s not like any thing is hinging on the feedback.

After the first workshop I decided my goal was to have attendees feel like comprehensive and impressive electronic records management was within their grasp, with essentially all the knowledge and tools they already have right at hand. Even if they don’t have a listed computer skill (such as saving emails from their email client or service to a specific folder, or creating a shared drive or folder), they know specifically what they should learn in order to achieve records management. This leads to some presentation aspects.

This is dry subject matter for most, so keeping audience attention is really the top priority and the most difficult task, especially since I present in the third hour. On the final workshop I opened by saying “My goal this hour is to bore you to death with electronic records management.” It actually got some laughs.

Establishing some kind of rapport with the audience is critical, and something I’m still working on. I ask for stories of hard drives crashing, and I tell my own. I try to tell a good story about a failed security measure. For example, the (likely) Stuxnet attack on the Iranian Natanz nuclear facilities in 2010 is speculated to have been delivered by a USB drive. This emphasizes that basic measures like good passwords and ensuring appropriate physical access are invaluable in protecting data and systems. I’m still fishing around for something more local.

Amy Rudersdorf at NCDCR.gov, who I met at the Digital Preservation Outreach and Education (DPOE) beta workshop, mentioned passing around a bag of dead electronic media. We have an 8″ floppy we show, and I’d like to collect other media for the next round.

I also emphasize that a lot of the material covered, like creating a backup plan, basic data protection, etc., are just as applicable to their personal data as their work data — protecting their digital photos, their email and their documents. While there are different issues in managing electronic public records versus electronic personal data — especially when it comes to cloud storage — there is more alike than not in my opinion.

On that note, one activity may be to ask audience members who has the oldest media at home. Does anyone have music on audio cassette or vinyl? Store data on floppies or Zip disks? Video or print on any kind of film? None of that is bad of course, but it could help to get them to consider the how long that material can continue to be used, and if it’s at all possible to make a copy.

obsolete media, on flickr, by EssG

Another activity is to have the presentation laptop shared with a volunteer. Minimize the presentation software and have an example file or two on the desktop. Let the volunteer make a folder on the desktop and copy a file into the folder. Now, have the volunteer move a second file into the folder (thus maintaining only one copy of the file), then rename the folder, and finally then put the renamed folder in a new folder they create. On the face of it this seems awfully pedestrian but it allows someone to demonstrate their ability, and if there are others in the crowd who are unable to do these tasks, it will illustrate how they are done.

Just to emphasize, other audiences may be more technically advanced than what I’m covering here. They may have access to, or be able to consider, professional management software, or they may have access to a considerable IT force.

The intention for my audience is to have attendees know that organized use of basic computer abilities is all it takes to competently manage electronic records in full compliance of state law. That is, minimum requirements will be met. I do not go into hashes and I only touch briefly on audit trails (in the context of a legal hold, or in advising use of the author and organization fields in Word, Adobe, etc.). There is not enough time to cover more detailed topics, as this is a 101 session.

Conclusion

Electronic records training can be delivered to a novice audience, even if you don’t know as much about them as you would like. My two main strategies here were:

• Breaking down electronic records management into steps (setting records aside, creating a storage strategy, writing a policy, etc.).
• Providing specific computer skills for each step where applicable.
• Demonstrate these skills for the audience where you can.

The idea is to have a single, general purpose calendar that covers digital preservation workshops, talks, etc., across the country. If you’re giving a talk or workshop, no matter how small the audience, consider submitting it here. And of course you can check the calendar to attend events, whether online or local to your area.

A longer post on DPOE is still forthcoming.

The Digital Preservation Outreach and Education (DPOE) program is a recent initiative by LOC to “foster national outreach and education to encourage individuals and organizations to actively preserve their digital content.”

Since attendees are coming from a variety of institutions, it’s going to be really interesting to discuss the different contexts in which digital preservation can be introduced. Audiences and clients can make a big difference in how you articulate a subject – and identifying the core issues within those variations is a (perhaps lofty) goal of mine for this workshop.

That, as well as feedback on training and workshop execution, of which my position requires a good deal of, cannot be too welcome!

I hope to have a post or two on the workshop during or shortly after.

Lulu glares out at you from a sea of compression artifacts.

During my last two years of high school (c. 1998 to mid-2000), a friend and I began an “art website.” Our intention was to have a place to post our writings and visual work, and to solicit similar submissions from others around Internet. Our mascot was the enraged chimp pictured above, Lulu. The site received some modest interest from various users around the Web, and from a few of our friends at school. All in all, not an unsuccessful project.

However as high school came to a close, we grew tired of maintaining the site. We tossed around the idea of maintaining it while we went to our respective colleges, but eventually decided to shut it down. We would be too busy with better endeavors, and no one wanted to log into our hosting service to keep  the old high school art site afloat. We posted the EOL announcement on the site and applied a bullet wound to old Lulu with MS Paint. It was most certainly over.

Lost

Our site was hosted with the free service provided by Juno in conjunction with Homestead. This was like a much smaller version of the web hosting provided by Geocities. Readers may recall Geocities unexpectedly cropping up in the news when Yahoo decided to shutdown the service. Thanks in huge part to Jason Scott and the Archive Team’s tireless work and campaigning, an enormous amount of Geocities has been preserved in the Internet Archive as well as within numerous other archives.

In retrospect, that announcement of termination was a sort of a blessing: there wasn’t time to erect a perfect archiving project, but preservation did happen, and how.

I’m not aware of any similar announcement for Homestead or Juno, but I if anyone knows of such an announcement, or better yet, any archiving effort for those services, I would love to know. Homestead is still kicking, but the sites it now hosts appear to be commercial. Juno is around, though hosting doesn’t appear to be part of the package anymore.

(Partially) Found

So despite my friend and I doing nothing to save our old high school site, and despite no notice that it would be removed, it has miraculously weathered about a dozen years of benign neglect. Scratch that — not-so-benign neglect, given that Juno/Homestead actively pulled the plug on it upon the closure of my account with them – and the site was never resident on either of our computers. How could this have happened?

Well, the Internet Archive is how that happened.

Now, the Internet Archive does not yet provide full text searching of its archive – you need to know the URL. Through some Google sleuthing I was finally able to recover this through an old submitter’s profile page (from a different, unrelated website) who still had our own site (about eleven years in the grave at this point) listed as their homepage. This person had submitted a lot of work to our site so it makes sense that she might point to it as the best place to find her on the web of 1999.

I typed in that address from the Internet Archive and lo, the last year or so of the site had been collected several times by the Archive’s Heritrix crawler. At these points of capture we had already announced the site’s moratorium on submissions and updates, so none of the snapshots show any change in the site. All the same I nearly laughed out loud just from the delight and surprise of seeing our old site again.

Remnants

Despite those wonderful, wonderful snapshots, browsing the site now is like navigating a deeply decayed house that’s bordering on final collapse. The majority of the internal links are broken – for whatever reason, the crawler never got those destinations, or was unable to map those resources to the site. Most of the external links pointing out to the Web of 1999 have rotted, though that is not terribly surprising.

No submitted artwork remains — it’s all broken JPEGs as far as you can see. A few thumbnails from the art index page are what remains of the submitted visual content. Again, perhaps the crawler had access troubles or could not map those resources to the site. Maybe they’re resident in a WARC somewhere. Other site artifacts that relied on external resources, such as the numerous polls we conducted, are empty. Our Message Board remains intact but the Guestbook goes nowhere.

(Yes, sites used to have “guestbooks.” You would sign in and say what you think of the site, etc., like a guestbook in real life. So quaint, I know.)

For the time being I’m downloading the pages one by one. When Warrick has adjusted to the Internet Archive’s recent changes, I’ll try and avail myself of their services.

All said, and as impossibly painful as it is to read my (or anyone’s) high school poetry and prose, I’m happy to have what remains of this site back. This was my first web site after all. So, thank you Internet Archive.

And yet my takeaway here is that the Archive will not save you. As wonderful as it is to see this site again, the fact is that most of it is gone, and that’s a shame. The experience of browsing it is severely diminished. Getting what I have now was laborious, and to get anymore, I have to rely on a very slim chance afforded by a great tool, Warrick, which is nevertheless completely out of my control.

Compare this to my old student site, which I have preserved easily, just by moving the site directory from UT’s servers to my Dropbox account (and of course, on to my hard drive as well as a backup). This site has been retained almost perfectly within a few minutes, while my high school site is mostly destroyed. Preserving what’s left takes hours, with some considerable scrubbing to re-realize the original HTML.

Lesson the One: Preserving digital content earlier is much, much easier — and so much cheaper — than trying to come in after years of neglect and perform heroic acts of digital archeology.

Lesson the Two: Be careful of slowly fading services and resources. There wasn’t an announcement or notice that our site would go away. A lot of your digital content on hosted services are going to end with a whimper. I think this will get better — especially with major services like Facebook and Twitter, where the legacy of a deceased person’s data has come up notably several times, and for which policies and download services are in place. Still, I maintain that a great deal of digital data hosted by services is likely to quietly slink away from your reach.

Lesson the Three: Preserving web sites and the Web at large is really, really difficult. Arbitrary and dynamic content, multiple and unpredictable resource locations, many parts, many dependencies, and behavioral sophistication. It’s a tough list to say the least, so it can’t hurt to be a proactive about maintaining your content.

[Edit 07/22/2011] Lesson the Four: Digital objects are in danger of partial or damaged states just as physical objects are. This is something that has struck me as somewhat unintuitive for those unfamiliar with digital objects. A common experience is having a hard drive crash or accidentally deleting a file, and this can lead to the belief that digital objects are either preserved entirely or they’re gone entirely. This corresponds with the notion of digital machines, which work in discrete and discontinuous values.

But the reality is that preservation of anything but the most simple data can be partial and incomplete, just as my old web site here, or a video game, or a work of digital art, or a spreadsheet that lost the underlying formula, etc. Certain properties persist (with varying degrees of fidelity to the original) while others become lost. I think this is a particularly difficult component of digital preservation to explain to those outside the practice as all the logical or behavioral properties of an object are not apparent on first glance.

In any case, something to consider the next time you compose your elevator speech.

Before the week is out I wanted to post to the NYT interview with the Adams brothers, who design and build the incredible labor of love that is Dwarf Fortress.

I had the opportunity to interview Tarn Adams (audio and transcript available), who programs the game, for the game preservation project I worked on in school (all interviews are here at the Center for American History). Tarn is a standout guy, who is awfully generous with his time considering the colossal task ahead of he and his brother. He gave a great interview that illuminated important parts of their game-making, which is in kind with the idiosyncratic and singular quality of Dwarf Fortress.

Check out the NYT interview — Tarn has some thoughtful, provoking comments on playing games these days.

And, if you haven’t tried Dwarf Fortress, give it a go, eh? I played it for a year on and off – one day I’ll make a return to it. It’s not as hard as all that, really, especially when you jettison the ideas of “winning” … or “succeeding.”

Rosenthal however makes a convincing argument that this placement of effort is misguided, and is not providing the best ROI for the digital preservation community. I won’t repeat his arguments, except to say that Rosenthal places the format obsolescence issue in a historical context that suggests much has changed in computing since, and indicates other areas much overlooked (bit fixity, storage costs and hardware quality) that are shaping up as problematic indeed. Here’s a starter to his posts:

Format Obsolescence: Scenarios – April 27, 2007

Format Obsolescence: The Prostrate Cancer of Preservation – May 7, 2007

Format Obsolescence: Right Here Right Now? – January 3, 2008

Are Format Specifications Important for Preservation? – January 4, 2009

Postel’s Law – January 15, 2009

That should get one started although there are many, many posts on the subject. Given those dates, I’m pretty late to the party, but I feel this is required reading for digital preservationists, agreement or no aside.

After a few reads you may be running for the nearest self-healing, mirrored ZFS volume, waking up in cold sweats and mumbling on about silent data corruption. Scary.

But for anyone who has worked in IT at all ever, or just had to approach a problematic system and put out the fire may appreciate the elegance of this statement.

Systems that are both tightly coupled and highly complex, Perrow argues in Normal Accidents (1984), are inherently dangerous. Crudely put, high complexity in a system means that if something goes wrong it takes time to work out what has happened and to act appropriately. Tight coupling means that one doesn’t have that time. Moreover, he suggests, a tightly coupled system needs centralised management, but a highly complex system can’t be managed effectively in a centralised way because we simply don’t understand it well enough; therefore its organisation must be decentralised. Systems that combine tight coupling with high complexity are an organisational contradiction, Perrow argues: they are ‘a kind of Pushmepullyou out of the Doctor Dolittle stories (a beast with heads at both ends that wanted to go in both directions at once)’.

That is poetry. From Donald MacKenzie in the London Review of Books (link added). Itself from a post covering Amazon’s April 2011 cloud outage at David Rosenthal’s always-excellent digital preservation blog.

Below is a review of Derrida’s Archive Fever. The idea was to relate the lecture to practicing archivists and record managers. This was a really engaging read, and I think Derrida successfully articulates the archive impulse, with all its attendant richness and strangeness.

Archive Fever: A Freudian Impression. Jacques Derrida. Chicago: University of Chicago Press, 1998. Translated by Eric Prenowitz. 113 pages. ISBN 0-226-14367-8 paper. $14.98.

French philosopher Jacques Derrida (1930-2004) is most commonly known as the founder of deconstruction, an investigative thinking that identifies contradictions in a subject and demonstrates the essentialness of this contradiction to the meaning of the subject. For a thinker so adept at analyzing the valences of meaning in language, Derrida was unsurprisingly hesitant about the broad appeal and use of the deconstruction term, and no doubt would find fault with an overly mechanistic summation as perhaps written here. In Archive Fever, Derrida applies his intensely critical thought and evaluation to the notion of the archive as it is manifested in Sigmund Freud’s oeuvre.

Archive Fever: A Freudian Impression is a translation from the French of a published lecture Derrida delivered in 1994, and is divided into six parts: an opening note, an exergue, a preamble, foreword, theses and postscript. Derrida delivered this lecture to an international colloquium entitled “Memory: The Question of the Archives.” This leads to two caveats for the interested reader. Although blurbs on the paperback reference Derrida’s discussion of electronic media and more broadly the role of inscription technology in the psyche and in the archives, this is not the focus of his discussion, but is only part of a larger examination of the archive notion in Freud’s works. The reader should also know that this a later work of Derrida, and as such references ideas and investigations discussed in earlier works, particularly the essay Freud and the Scene of Writing (1972). This means some of Derrida’s passages can be disorienting if the reader is not familiar with the works of Derrida and Freud. Thankfully Derrida takes pains to convey his meaning through multiple expressions, so the reader has many opportunities to understand the ideas at play.

The opening note examines “archive,” from arkhē, wherein Derrida identifies dual principles in the primitiveness, or primariness, of the archive and in its centrality to the actualization of the law. From here Derrida deconstructs an act central to the archive, that of inscription, as it is treated by Freud. He first elaborates on printing. Relying on an exterior substrate, Derrida implicates the printing act in Freud’s conception of the “psychic archive distinct from spontaneous memory” (19). As described by Freud, this is an internal inscription in the mind, virtually housed and remote, but from which psychoanalysis may be able to gather “documents,” the products of a successful psychoanalytic session.

The private inscription is also examined. In Freud’s case, this is both a particular dedication given to him by his father Jakob, and his circumcision, which Derrida believes could constitute the original archive, a mark both exterior to the person but inscribed on the body and therefore always with the person.

After these short beginning sections, the reader reaches the foreword, which contains an extended discussion of Freud’s relationship both to the notion of the archive and to his Jewish identity. This is examined through Yosef Hayim Yerushalmi’s Freud’s Moses: Judaism Terminable and Interminable (1993). Yerushalmi (1932-2009) was an American scholar of Jewish culture and history, and in this particular text he attempts an analysis of Freud’s psychoanalysis with especial attention to the founder’s relationship to his Jewish heritage. Derrida’s interest is in this investigation as well as Yerushalmi’s own attempt to “archive” psychoanalysis through the recovery of a particular document, one he asserts as canonical to the history of psychoanalysis: Jakob Freud’s aforementioned dedication note to his son, given to Freud along with his childhood Bible on his thirty-fifth birthday which reminds Freud of his cultural or religious heritage and familial past.

Following this foreword, Derrida states his three theses, each pointing to a conflicted relationship Freud maintains with the archive notion. The first of these is that Freud successfully established a virtual archive of the mind, but favors original experience over the internal, technical prosthesis of this archive. The moment Freud savors is when archeology trumps the archive by recovering the original artifact, when “the arkhē appears in the nude, without the archive” (92). The second is that while the archive is only possible through the death drive and aggression, e.g. through the finite appropriation of certain points constituting original data or information, Freud does not acknowledge such a drive in the virtual archive found in his works. The third is that while Freud brilliantly deconstructed the archive principle by identifying its ties to law and authority (from the ancient archons of Greece), he nevertheless repeats this patriarchal logic through his theoretical compulsions as they concern the soundness of his work on psychoanalysis.

These are dense points, and any reader of Archive Fever will come to them with a clearer understanding than provided here. It cannot be stressed enough the richness and inclusiveness of Derrida’s archive considerations. Of particular interest to archivists and records managers is Derrida’s examination of inscription technology, from tablets to email. Here he is concerned with inscription technology’s relationship to both the psychic apparatus (as it is conceived and as it may function) and archives. Concerning the former relationship, Derrida questions if Freud’s conception of the psychic apparatus is still informed, if indeed archiving and reproduction technology affect the structures of the mind. Concerning the latter, Derrida asserts that “the technical structure of the archiving archive also determines the structure of the archivable content even in its very coming into existence and in its relationship to the future. The archivization produces as much as it records the event” (17). Thus archiving technology determines “the very institution of the archivable event,” (18) informing as well the conception of the future and possibly the future itself. Record managers and archivists may well accept this notion as it certainly lends the profession expansive power and responsibility.

Included in this notion however is the fluid relationship between the archive and what it archives. The archive, its structure, formulation and operation is informed by its contents along with any number of external bodies of knowledge. Derrida asserts then that the archive cannot remain outside what it memorializes. This removes some of the objectivity with which records and archival documents are typically treated. In the same way, Derrida believes Yerushalmi’s attempt to provide a definitive archive of Freud’s psychoanalysis is itself compromised by Yerushalmi’s exposure to psychoanalysis (deferred obedience in Freud’s terms). This is one aspect of the titular Freudian impression.

Noble attempts at archive building are not unfamiliar to the records and archive community either. Writers such as Luciani Duranti in The Odyssey of Records Managers (1993) or her “Archival Science” entry in the Encyclopedia of Library and Information Science (1996), and Frank Boles in Selecting and Appraising Archives and Manuscripts (2005) have similarly delivered histories of certain components of archives and records practice. Invariably such archive projects identify original documents of some sort, the first example, the first practitioner, canonical events marking divisions of eras and methodologies, etc. Just as the French First Republic attempted to establish a modern history of France through the National Archives, one can see the archive and records field establishing itself through the construction of these archives which always indicate canonical texts or occurrences.

For those in the field, these important efforts touch on the archive fever Derrida illuminates at various points in his lecture. “It is to have a compulsive, repetitive, and nostalgic desire for the archive, an irrepressible desire to return to the origin, a homesickness, a nostalgia for return to the most archaic place of absolute commencement” (91). Entwined in this desire is a repetitive force, the retention of a specific origin through repetition. As Derrida states, the One (in this case the archive) cannot distinguish itself from the Other without a constant reiteration of itself. In the ceaseless work to maintain one memory at the expense of another the archive not only maintains and curates memory, but buries it as well. Derrida argues that the archive as a public, prosthetic extension of memory cannot avoid this contradiction, which he emphasizes is not a negative contradiction, but a necessarily modulating one. Freud suffered from this archive fever, as did Yerushalmi. It is a compelling, fascinating argument and one with which this reader is inclined to agree.

What can this mean for a practicing records manager or archivist? Derrida is concerned with the conditions for truth, and archives (as well as Freud’s psychoanalysis) position themselves uniquely to truth and to evidence. Records managers are likely keenly aware of the socio-juridical systems that lend “truth” to the records they manage, as archivists are aware of the conditions under which their holdings may be considered authentic and properly evidential. It is worth then any practitioner’s consideration of the theoretical or epistemological presumptions behind these systems.

Practitioners may regard Derrida’s extended discussion of Freud’s treatment in Yerushalmi’s book besides the point, but these sections contain some of Derrida’s most poignant reflections on archives. Yerushalmi was a historian attempting to reform the memory of Freud through archival evidence, and Derrida’s analysis of this dynamic should pique the interest of anyone in the field.

In his postscript, Derrida analyzes the protagonist of Wilhem Jensen’s novella Gradiva: A Pompeiian Fancy (1918), itself analyzed by Freud. In it, archeologist Norbert Hanold seeks to find the original footfalls of a Pompeiian girl whose bas-relief portrayal he is fixated upon. Hanold attempts to discover the trace which at least psychologically if not literally would deliver him to the living girl. Derrida conceives the quest as a sort of archive fever that illuminates the constraints of inscription to deliver the truth or the original moment, of “the unique instant where they [the pressure and the trace] are not yet distinguished the one from the other” (99). Those in the field of managing inscription artifacts may ruminate on where, between the trace and the acts preceding it, the truth lies.

A PHP ingest interface we’ve set up is certainly the most developed of the our repository’s services, but there’s a strong need to relate one object to another as it is being ingested. To do this I want to provide the user with a drop down menu of objects in the repository which fulfill some criteria (say, the object represents a donator or creator). The user can select one during the ingest phase, relating the ingested object to this other object. That relationship would be recorded in the RELS-EXT datastream as RDF/XML, creating a triple. The predicate of that triple will come from either Fedora’s own ontology [RDF schema] or another appropriate namespace.

Below is PHP code using the cURL client library to call Fedora’s REST API and get this list of relevant objects. I encountered a few stumbling blocks putting this together, so I thought I’d share in case others were curious or looking at a similar problem.

The first step is to compose your query, and then initiate a cURL session with the query.

<?php
$request = "http://your.address.domain:port/fedora/objects?query=yourQuery&resultFormat=xml";
$session = curl_init($request);

curl_setopt($session, CURLOPT_RETURNTRANSFER, true);

$response = curl_exec($session);
$responseResult = simplexml_load_string($response);
$resultsArray = array();							
     
foreach ($responseResult->{'resultList'} as $result) {			
     foreach ($result->{'objectFields'} as $entry) {
          foreach ($entry as $value) {
               $resultsArray[] = $value;	
          }						
     }		
}
curl_close($session);

while (!empty($token)) {				
     $nextQuery = "http://your.address.domain:port/fedora/objects?sessionToken=" . urlencode($token) . "&query=yourQuery&resultFormat=xml";				
     $nextSession = curl_init($nextQuery);				

     curl_setopt($nextSession, CURLOPT_RETURNTRANSFER, true);

     $nextResponse = curl_exec($nextSession);
     $nextResponseResult = simplexml_load_string($nextResponse);		  		

     foreach ($nextResponseResult->{'resultList'} as $result) {			
          foreach ($result->{'objectFields'} as $entry) {				
               foreach ($entry as $value) {					
                    $resultsArray[] = $value;						
               }			
          }				
     $token = $nextResponseResult->{'listSession'}->{'token'};				
     print "$token<br />\n";

     curl_close($nextSession);

} //while
?>

On line 2 I’ve specified my query results to be returned as XML and not HTML (resultFormat=xml). This is because I don’t want a simple browser view of the results — I want to work with them some first, so XML is appropriate.

On line 5 the cURL option CURLOPT_RETURNTRANSFER to ‘true’. This directs cURL to deliver the return of its Fedora query as a string return value to the curl_exec() variable, in this case $response.

On line 8 $response, now an XML structure, is loaded into $responseResult as a PHP5 object. The object is a tree structure containing arrays for the result list, the entries, and the entries’ value arrays, all of which we can work through to get to the record values of interest. The specific contents will depend on your query. You can get a good look at the object with print_r():

print_r($responseResult);

The two Fedora REST commands used are findObjects and resumeFindObjects. We need both of these commands because findObjects will not return more than 100 results, regardless the value you set on maxResults.

Instead it returns the results along with a token. This token is a long-ish string you can then supply to resumeFindObjects, which will continue retrieving your results for you. Just like findObjects, resumeFindObjects will never return more than 100 results, instead giving you another unique token. Once again, you can supply that token to a new resumeFindObjects command to continue getting your results.

The two loops for each of these commands should fill resultsArray[] with all the results available in the repository.

You can use this array in a HTML drop down:

<?php
echo "<select name=\"donators\">";
foreach ($responseResult->{'resultList'} as $result) {
	foreach ($result->{'objectFields'} as $entry) {
		$pid    = (string) $entry->pid;
		$title  = (string) $entry->title;				
		echo "<option value=\"$pid\">$title</option>";
	}	
}
echo "</select>";
?>

Keep in mind that values like $entry->pid and $entry->title are only going to be in the results if those fields have been requested in your queries.

This approach has given me a good understanding of calling and manipulating objects in Fedora through PHP. I have found that setting maxResults to a smaller number (say 5, 10, or 20) is faster than setting it to its maximum 100. And of course, if you are going to be fetching hundreds or thousands of objects, it’s best not to dump them all in a drop down or to fetch them all at once.

Montfort, N., & Bogost, I. (2009). Racing the Beam: The Atari Video Computer System. Platform Studies. Cambridge, Massachusetts: MIT Press.

Racing the Beam: The Atari Video Computer System

Just want to give a brief rundown on a really great read I’ve come across. MIT has started a “Platform Studies” series of books where the idea is to examine a platform and its technologies to understand how this informs creative work done on the platform. Platforms could range from gaming consoles, to a programming language, to an operating system, or even the Web itself if this is the platform upon which creative work is being made. The platform in this case is the Atari Video Computer System, the first Atari home system, later referred to as the Atari 2600 in the wake of the newer Atari 5200.

The authors examine the Atari VCS as a computing system, and take care to elaborate the unique (really exceptionally odd) constraints found there. Six games are investigated in chronological order, giving the reader a sense of the programming community’s advancing skill and knowledge of the system: Combat (1977), Adventure (1980), Yar’s Revenge (1981), Pac-Man (1982), Pitfall! (1982), and Star Wars: The Empire Strikes Back (1982).

The most prominent technical details are explained in first few chapters, and they illuminate each game’s construction as an exceptional act of engineering and ingenuity. Just to give an idea of the unique affordances of the Atari VCS, here are a few of the most characteristic details:

• The custom sound and graphics chip, the Television Interface Adapter (TIA), is specifically designed to work with a TV’s CRT ray. The ray itself sprays the electrons onto the inside of a TV screen, left to right, one horizontal scan line at a time, taking a brief break at the end of each line (a “horizontal blank”) and a longer break at the bottom line, before resetting to the top and starting over again (a “vertical blank”). A programmer only has those tiny breaks to send any instructions to the TIA, and really only the vertical break provided enough time to send any game logic to the system.
• It was imperative that game logic be sent at these breaks because the Atari VCS had no room for a video buffer. This meant there was no way to store an image of the next frame of the game, all graphic instructions are written in real time (sound instructions had to be dropped in on one of the breaks). A designer or programmer could choose to restrict the visual field of the game in exchange for more time to send game logic instructions. Pitfall! is an example of this.
• This means there are no pixels on the Atari VCS. Pixels require horizontal and vertical planes, but for the Atari VCS, there is only horizontal scan lines. There is no logical vertical division at all for the computational system. As the beam goes across the screen, a programmer can send a signal to one of the TIA’s register to change the color. Thus, the “pixels” are really a measure of time (the clock counts of the processor) and not space.
• Sprites, such as they existed for the Atari VCS, were hard-coded into the ROM of the system. Programmers had five: two player sprites, two missiles, and one ball. Reworking that setup (clearly designed for Pong and the like) into something like Adventure, Pitfall!, or even the Pac-Man port is an amazing feet.

The book doesn’t refrain from the technical. I could have used even more elaboration than what is presented in the book, but after a certain point the book would turn into an academic or technical tome (not that there’s anything wrong with that), so I appreciate the fine line walked here. The authors succeed at illuminating technical constraints enough for the general reader to understand the quality of the engineering solutions being described. Moreover, the authors leave room to discuss the cultural significance of the platform, and to reflect on how the mechanics and aesthetics of these Atari titles have informed genres and gameplay presently.

Microsugeon

I’ve rediscovered an Intellivision game I played as a kid: Microsurgeon (1982). This was one of the great cooperative console games of my youth, along with General Chaos (Sega Genesis, 1994) and Contra (NES, 1987).

The Intellivision must have been my friend’s father’s — we had both grown up with the NES as the big prize. The console’s controllers each had an analogue directional disc, which struck us as impossibly weird and archaic (but still interesting after too many failed rounds of Sonic the Hedgehog).

The real-world weightiness of the this game made a mark on me. You control a micro-ship inside a human body, where you battle cancer. It was very hard. You could target certain parts of the patient’s body for healing: eyes, brain, lungs, etc. The tumor spread relentlessly and you would find yourself urgently manipulating your directional disc in an effort to hold back advancing grey blocks of cancer cells.

Microsurgeon Medical Chart

The challenge was always compelling: you wanted to save this patient.  My most vivid memory though is of the tumor overwhelming whatever organ I was engaged in and the patient dying. Despite the morbid conclusion, the idea of a triumphant heal kept us returning.

Microsurgeon took the mathematical progression of difficulty found in many early arcade games (Space Invaders, Centipede, etc.) and applied it to the body’s battle with disease. I would say it was tragic but my unfamiliarity with Aristotelian tragedy would advise against it. I will just say that it was really sad and a little bit scary to lose. Microsurgeon is still how I visualize cancer doing away with me.

My search phrase (intellivsion health game) also turned up an excerpt from the book Lucky Wander Boy by D.B. Weiss. It’s good read; I look forward to reading more.

The second part of this game I remember so well are the visuals, which were gorgeous and appealingly abstract. The banner graphic above and the medical chart display are taken from user Servo’s contributions to the stock of images at MobyGames. The banner graphic reminds me of Basquiat’s popular painting, Unknown (Skull) (1981):

Unknown (Skull)

There’s some resemblance, isn’t there? Sure the Intellivision’s representation of the skull is medical and diagrammatic, and Basquiat’s is expressive and descriptive. But both skulls are essentially tackled in pieces.

I’m happy to break the months-long silence here just to say I’ll be heading to the 6th International Digital Curation Conference in Chicago, Monday to Wednesday of this week. I’ll be manning the poster for the Dr. Winget’s Preserving Games research project, explaining to all willing passerby our findings regarding record creation in video game development and some key implications for curation of these records.

I’ll be able to catch a few talks on Tuesday and Wednesday before heading out. Just a few I’m interested in hearing:

• “Idiosyncrasy at Scale: Data Curation in the Humanities.” John Unsworth, Dean & Professor, Graduate School of Library and Information Science & Director Illinois Informatics Institute, University of Illinois at Urbana-Champaign.
• “Linking to Scientific Data: Identity Problems of Unruly and Poorly Bounded Digital Objects” Laura Wynholds, University of California, Los Angeles.
• “DataStaR: Using the Semantic Web approach for Data Curation” Huda Khan, Brian Caruso, Brian Lowe, Jon Corson-Rikert, Diane Dietrich & Gail Steinhart, Cornell University.
• “Dependency Analysis of Legacy Digital Materials to Support Emulation Based Preservation” Aaron Hsu & Geoffrey Brown, Indiana University.
• “What constitutes successful format conversion? Towards a formalisation of “intellectual content” C.M.Sperberg-McQueen, Black Mesa Technologies LLC.
• “Assessing the preservation condition of large and heterogeneous electronic records collections with visualizations” Maria Esteva, Weijia Xu, Suyog Dutt Jain & Jennifer Lee, University of Texas at Austin

DCC seems to be pretty serious about “amplifying” the conference to non-attendees and attendees alike. There’s a Twitter account (@idcc10) and a Netvibes dashboard, which will host all manner of media and feeds for the conference.

Here’s the ‘Minute Madness’ slide, which accompanies (appropriately enough) a one-minute rundown of the project:

IDCC '10 Minute Madness Slide

Here’s the PowerPoint slide.

Hutchison, A. (2008). Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom. Game Studies, 8(1). Retrieved from http://gamestudies.org/0801/articles/hutch

This 2008 Games Studies article examines the effect technology (or the “techno-historic” context of a game work) has on game aesthetics. The author defines the “game aesthetics” as “the combination of the audio-visual rendering aspects and gameplay and narrative/fictional aspects of a game experience.” It is important to note that audio-visual aspects are included in this definition along with the narrative/fictional components. This is because the author later argues that advancing audio-visual technology will play an important role in advancing the narrative aspect of games.

The article begins with a comparison of two iconic computer games of the mid 1990s: Myst and Doom. Specifically the design response in each game to the technological limitations of PCs at the time is examined. Very briefly, we see that Myst takes the “slow and high road” to rendering and first-person immersion, while Doom adopts the “fast and low road.” As the author explains, each response was prompted by the limitations of rendering that a personal computer could perform at the time. For its part, Myst’s design chooses to simply skip actual present-time 3D rendering and use only pre-rendered, impeccably crafted (at the time) images to move the player through the world. Minor exceptions exist when Quicktime video is cleverly overlaid onto these images to animate a butterfly, bug, moving wheel, etc. This overall effect very much informs the game’s aesthetic, as anyone who played the original can recall. Myst is a quiet, still, contemplative and mysterious world. Continuous and looping sound is crucial to the identity of the world and the player’s immersion. Nearly every visual element is important and serves a purpose. The designers could not afford to draw scenes extraneous to the gameplay. The player’s observation of the scenes available is key, and the player can generally be assured that all elements in the Myst world warrant some kind of attention. Hardware limitations of the time, such as the slow read time of most CD-ROM drives, serve to reinforce this slow, methodical gameplay and visual aesthetic.

Doom by contrast uses realtime rendering at the expense of visual nuance and detail. Doom achieves immersion through visceral and immediate responsiveness, and its aesthetic is one of quick action and relentlessly urgency. The low resolution of the art and characters is compensated by the quick passing of those textures and objects, and by the near-constant survival crisis at hand. Redundancy of visual elements and spaces is not an issue: the player can face down hordes of identical opponents in similar spaces (sometimes the exact same space) and not mind at all because the dynamism of the gameplay is engaging enough to allow such repetition. Pac-Man had the same strength.

From this comparison the author goes on to speculate how techno-historic limitations inform aesthetics in general, and whether the increasing capacity of personal computers to render audio-visual components in extreme and realtime detail will inform the narrative/fictional aspects of games as well. One only needs a passing familiarity with games to know that this aspect of games has been widely disparaged in the media and in some academic writing. Some quotes the author uses to characterize the degenerative trend of popular media and the game industry’s complicity in the coming intellectual apocalypse:

Perhaps lending strength to this phenomenon is a current popular culture stylistic trend which emphasises “spectacle” over narrative and gameplay. Peter Lunenfeld has identified this broad movement in popular culture generally:

Our culture has evacuated narrative from large swaths of mass media. Pornography, video games, and the dominant effects-driven, high concept Hollywood spectaculars are all essentially narrative-free: a succession of money shots, twitch reflex action, and visceral thrills strung together in time without ever being unified by classic story structure (Lunenfeld, 2000, p.141).

And more specifically dealing with games:

“It is a paradox that, despite the lavish and quite expensive graphics of these productions, the player’s creative options are still as primitive as they were in 1976” (Aarseth, 1997, p.103).

Most interesting is the observation that richer media capabilities does not necessarily translate to glossier, superficial renderings. Richer media can mean a more meaningful experience for the player. Nuance and subtlety can be introduced, more information-rich media can mean more powerfully conveyed characters and a more fully realized narrative.

On top of this, one can expand the definition of “story” and “narrative” as id developer Tom Willits argues in this Gamasutra report:

“If you wrote about your feelings, about your excitement, the excitement you felt when new areas were uncovered [in Doom] — if you wrote it well, it would be a great story,” Willits says. “People call it a ‘bad story,’ because the paper story is only one part of the game narrative — and people focus on the paper story too much when they talk about the story of a game.”

Information, he maintains, is learned through experiences, and the experience of playing a game is what forms a narrative, by its nature. Delivering a story through the game experience is the “cornerstone” of id Software’s game design, and the key when developing new technology.

Whatever your opinion on what constitutes story and narrative in media, the author of this piece has made a compelling argument that advancing technical capabilities could directly inform the narrative/fictional aspect of a game’s aesthetics, and certainly has done so in the past.

The place to be is UTA 1.208 (the large classroom) in the UTA building of the UT Austin campus, at 1616 Guadalupe, on Friday, October 8.

The presentations are open to all, so come have a seat if you can! There will be questions too. The agenda:

Disciplines Converge: Representing Videogames for Preservation and Cultural Access

1:00 PM Bonnie Nardi (University of California at Irvine)
The Many Lives of a Mod
The concept of “mod” (software modification) is deceptively simple. Starting with a thought in a player’s mind on how to improve a video game, the activity of modding ramifies to problems of power, law, culture, inequality, and technological evolution. Even an expansive concept such as participatory culture does not capture the lives of a mod which enter wider arenas of activity at corporate and national levels. As we write game history (the project of ethnography) and preserve digital artifacts (the project of preservationists) is there a way to move the two projects more closely together to provide future generations more theorized representations of video games?

2:00 PM Henry Lowood (Stanford University)
Video Capture: Machinima, Documentation, and the History of Virtual Worlds
The three primary methods for making machinima during its brief history—code, capture, and compositing—match up neatly with three ideas about how to document the history of virtual worlds. These linkages between machinima and documentation are provocative for thinking about what we can do to save and preserve the history of virtual worlds in their early days. As it turns out, they also suggest how we might begin to think about machinima as a documentary medium.

3:00 PM Jerome McDonough (University of Illinois at Urbana-Champaign)
Final Report of the Preserving Virtual Worlds Project
This presentation will provide a summary of the findings from the Preserving Virtual Worlds project, a collaborative investigation into the preservation of video games and interactive literature by the Rochester Institute of Technology, Stanford University Libraries, the University of Illinois and the University of Maryland.  This research was conducted as one of the Preserving Creative America projects sponsored by the Library of Congress’ NDIIPP program.  The summary will touch on issues of intellectual description and access of games, collection development, legal issues surrounding game preservation, the results of our evaluations of preservation strategies, and a discussion of possible further research agendas within this arena.

4:00 PM Megan Winget (University of Texas at Austin)
We Need A New Model: The Game Development Process and Traditional Archives
This presentation will relate findings from our IMLS project focused on the video game creation process. Data includes eleven qualitative interviews conducted with individuals involved in the game development, spanning a number of different roles and institution types. The most pressing findings relate to the nature of documentation in the video game industry: project interviews indicate that game development produces significant documentation as traditionally conceived by collecting institutions. This documentation ranges from game design documents to email correspondence and business reports. However, traditional documentation does not adequately, or even, at times, truthfully represent the project or the game creation process.

In order to accurately represent the development process, collecting institutions also need to seek out and procure versions of games and game assets. The term version here refers to formally produced editions of the game (the Xbox 360, Wii, Playstation 2, and Nintendo DS versions of the same game, for example), as well as versions that are natural byproducts of the design process, such as alpha and beta builds, vertical slices, or multiple iterations of game assets. In addition to addressing the specifics of the game design process, this presentation will make the case for developing new archive models that accurately represent the real work of game creation.

Y. Aoyama and H. Izushi, “Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of the Japanese video game industry,” Research Policy 32, no. 3 (2003): 423–444.

This 2002 article (written 2001) looks at the success of the Japanese video game industry and attempts to illuminate the unique factors behind its success. Japan’s video game industry is especially remarkable given the dominance of “English language-based exportable cultural products” and the origin of the video game industry, which began in the US with Steve Russell’s programming of Space War for the PDP-10 and Nolan Bushnell’s subsequent creation of Atari to market and sell such arcade games.

Mega Man, hero of the early NES platformers. His design has characteristics of the manga style.

The authors give a history of the industry and observe Nintendo’s very early interest and involvement with electronic toy games. This began as early as the 1960s with the emerging popularity of shooting games with optical sensors. Nintendo was able to recruit technical expertise from consumer electronics and provided them with early successes like Game and Watch and Color TV Game (totally cool old ad at gamepressure). But Nintendo’s historic rise in the console market with both the Famicon and NES was due in no small part to its attention to quality software; the company made sure to foster in-studio works (Donkey Kong, Super Mario Brothers) and hold alliances with outside game developers.

After the mid 90s Nintendo falters by retaining cartridges for their games rather than the CD-ROM; this among other factors allows Sony to rise in the market. The authors continue the brief history up to the approximate time of the article, but one main point can be drawn from the narrative: hardware and software are intricately linked and related; success frequently hinges on a deep synchronicity between the two engineering pursuits. The authors go on to elaborate this point, emphasizing Nintendo’s early collaboration with domestic electronic consumer goods firms.

The article describes three types of software publishers:

• in-house publishers of platform developers (e.g. Nintendo)
• comprehensive software publishers with in-house capability for most development (e.g. Square)
• publishers that act as producer/coordinator and outsource most functions (e.g. Enix)

The types are distinguished by varying levels of intimacy with the platform developers. Platform developers can provide all sorts of guidance and information to game-makers: early prototypes of the platform, guidance on formats, and provisioning of development tools and platform operating systems. It’s clear then that hardware naturally informs software and that game development projects can benefit immensely from an intimate knowledge of the hardware.

The authors next examine the cultural landscape of Japan and how this informed its massively successful video game industry. A robust cartoons and animation industry (manga) with broad acceptance allowed the game industry to draw artistic creativity from a domestic source. The authors note that it is Japan that introduced human and animal characters into video games, a dramatic break from the war (Space War) and ball (Pong) games in the US, and that it was a Shigern Miyamoto, influenced by the landmark cartoonist Osamu Tezuka (the “god of manga“), who was inspired to create characters like a rampant pet gorilla (Donkey Kong), a blue-collar construction worker (Mario), and a captured girlfriend (Princess Toadstool). The cultural legitimacy and artistic breadth of cartoons in Japan facilitated effective cultural crossover into the video game industry. This is compared to the comics and cartoons industries of the US, which could not claim such pervasive influence.

The authors conclude:

The developmental trajectory of the video games industry revealed a complex interplay between hardware and software technologies from its origin, and more recent trends represent a transition from hardware, engineering-driven to increasingly software-centered industry supported by artistic creativity drawn from cartoon and animation film industries.

I think this trajectory is accurate, but it’s important to note that the power balance between hardware and software is always subject to change. The iPhone has emerged as an extremely capable, popular and even innovative gaming platform, and Apple has chosen to retain full control over the game software available for it.

Regardless however of the power dynamic between the two disciplines, they are always and inextricably related. Any game should be understood with an understanding of the hardware it was developed for and on. Narrowing the scope from industry to a single game, I think it would be interesting to understand more about how specific projects were informed by the hardware constraints of the time.

I was specifically interested in Mr. Patrick’s thoughts on presenting software history. Hardware is a more intuitive museum subject in significant ways (its object-ness among them), but of course museums successfully convey subjects which have no direct corresponding object (e.g. touching the actual clothes of a Civil Rights victim) quite well. Still software remains especially difficult to present in an interesting way.

Mr. Patrick states that software’s workings are opaque to users, and suggests a multithreaded approach to software history that documents the different software types (applications, subroutines, operating systems, etc.) as they emerge, ascend or recede over time as separate threads.

Along with this, I am specifically interested in conveying to the museum goer the architecture, engineering, and writing of software. There is no better way to communicate the human labor, ingenuity, and yes, the toil, that goes into software making. Quoting industry numbers does not tell the museum goer that software is frequently an epic engineering project with considerable drama, not just externally (between departments, coders, and investors), but internally as well (in engineering problem solving). How to convey this drama?

Software is both an engineering and creative endeavor, and it exercises a rich figurative language that suggests physical play and work: variables are passed, object are created, something is trimmed, cleaned or scrubbed, a request is made, an exception is thrown, a thread stops and starts, etc.

I think this language indicates a way to illustrate the software engineering problem space abstracted away from specific commands and syntaxes. For example, museum visitors could manipulate some system (either a physical system or video game-type piece) with certain constraints emulating those of the coder. Come to think of it, puzzle games do a fine job of such demonstration already (perhaps more Portal than Braid). They could likely be much better demonstrations, of course, if they were directed toward this specific purpose.

I would love to see the day when some of the problems, solutions, tricks, etc. of software engineering are conveyed as well as those of medieval cathedrals or the Giza pyramids.

The project I worked on at MITH is up, MITH’s Vintage Computers. It’s a catalog and archive of the vintage computer systems and equipment at the center.

The goal is to demonstrate an intuitive and useful way to browse vintage systems. These are complex artifacts with numerous component pieces and software, each of various versions and iterations, with a wealth of important properties and functions, and all from many manufacturers and designers. No model yet exists for conveying this complexity in metadata records. Hopefully the site suggests the utility of such an endeavor, and is at least a little fun to browse.

I had an immense amount of help and support from all the folks at MITH, who shepherded the project start to finish. I can’t thank them enough for their support and expertise. But still: thanks everyone!

I really like these sorts of efforts. Agent information and contact profiles are fast becoming first-class entities on the web (see Mozilla Labs experimental Contacts add-on). Particularly for contact profiles, there may be backlash against formalizing such data as a resource, perhaps as impinging on the ideal of anonymous cyberspace so praised during the Internet’s early ascendance. It seems however that unless this data is formally handled and dealt with, privacy and control issues will continue to plague its use.

Fábio Petrillo et al., “What went wrong? A survey of problems in game development,” Computers in Entertainment 7, no. 1 (2, 2009): 1-22.

This February 2009 article from the Computer in Entertainment magazine of ACM takes a look at the game industry and compares its difficulties to the larger software industry. Specifically the authors analyze twenty postmortems from the archives of Gamasutra.com to characterize the problems that plague game development. I believe Gamasutra has discontinued this series but postmortems are still published by sister publication Game Developer.

A postmortem “designates a document that summarizes the project development experience, with a strong emphasis on the positive and negative aspects of the development cycle.” After reviewing the literature discussing problems present in the software industry, the authors begin to analyze the problems described in the postmortems. The games covered and the problems identified and quantified are in a table that describes the number of occurrences and overall frequency (click for larger image). Note: sometime in the future (the Web 3.0 future?) I would provide a link to the actual dataset rather than a .PNG  showing you a picture of the dataset.

Occurrence of Problems in the Projects

The authors’ categories provide a helpful navigation to the issues that arise in a game development project. As they note, this study sees the most cited problems as unreal or ambitious scope and features creep, both constituting 75% of all problems described. Notable for game archivists is a 40% frequency for the lack of documentation problem as well. The authors note low occurrences for crunch time and over budget (25%), both “said to be ‘universal.’” It’s difficult however to draw expansive conclusions from a small dataset. Moreover postmortems were not team projects or collaboratively written, rather a single participant is responsible for the postmortem. The authors usefully provide other limitations to put the data in context.

The authors conclude that the electronic games industry does indeed suffer from problems in the larger software industry (overly ambitious plans and poor requirements analysis) as well as woes peculiar to itself: the first to experiment with new technologies, tool problems, and collaboration between disparate professionals, among others.

On a final note, the postmortems are still available at Gamasutra, and they are really fascinating reads. It becomes clear just how young an engineering and creative discipline digital game-making is, and how much fluctuation there is in how a game turns out. There are some great examples and stories there; the authors of this article cite quite a few of them.