{"id":4982,"date":"2014-10-22T11:00:09","date_gmt":"2014-10-22T15:00:09","guid":{"rendered":"http:\/\/www.playthepast.org\/?p=4982"},"modified":"2014-10-22T10:58:19","modified_gmt":"2014-10-22T14:58:19","slug":"excavating-code-an-archaeological-record-of-software-development","status":"publish","type":"post","link":"http:\/\/www.playthepast.org\/?p=4982","title":{"rendered":"Excavating Code: An Archaeological Record of Software Development"},"content":{"rendered":"

Over the last few weeks, I’ve been in the process of relearning C++.\u00a0 Of course, saying that I am “relearning” is perhaps giving me too much credit, as it has been almost fifteen years since my first attempt at mastering the language.\u00a0 While it shares a good deal of syntax with other languages I’m more familiar with, I might as well be learning it for the first time.\u00a0 Although my previous programming experience has thus far been of very little use when suffering from linker errors or trying to track down memory leaks, it has given me an interesting perspective on my current endeavor.\u00a0 I’ve been programming (or attempting to) in one way or another since I was in elementary school.\u00a0 Starting with GW-BASIC, I slowly made my way to Visual Basic, C++, JavaScript, ActionScript 1, ActionScript 3, Haxe, and now back to C++ again.\u00a0 Most of these transitions, like my current one, largely involved starting from scratch.\u00a0 My fifth-grade self would probably be a bit sad to learn that the BEEP<\/code> command that he managed to overuse in every program he ever wrote wouldn’t be of much use by the time he got to high school.<\/p>\n

Learning a new programming language is generally not a purely iterative process.\u00a0 Even closely related languages have their own idiosyncrasies that don’t translate back and forth.\u00a0 This does not, however, mean that you can simply approach a new language as a blank slate.\u00a0 In fact, unlearning<\/em> your old approaches is often the most difficult part of picking up a new language (particularly if you’ve managed to pick up some bad coding habits along the way).\u00a0 As such, it should come as no surprise that code, like any text, can say a lot about the people, organizations, and technologies that were involved in its creation.<\/p>\n

Code is often a difficult object to approach from a humanistic perspective.\u00a0 In some cases, scholars have approached code as if it were simply a piece of literature<\/a>, generally coming to the conclusion that code makes for very poor literature (K\u00fccklich, 2003).\u00a0 More often, however, computer code is not seen as a text in the traditional sense of a completed manuscript, but rather as an assemblage of many culturally situated units of meaning, akin to how Michael McGee (1990) theorized text.\u00a0 To a much greater extent than most other texts, code requires technical expertise along with critical expertise in order to understand.\u00a0 There are numerous ways of approaching a piece of code, many of which have been discussed here on Play the Past<\/em>.\u00a0 One of the most useful ways of looking at code is from a functional, algorithmic perspective.\u00a0 By critiquing the way that code enables and constrains certain actions<\/a>, we can come to understand some of the underlying assumptions behind the a game.\u00a0 We can also come to understand a piece of software through the context provided by developer comments<\/a> written in the source files themselves.<\/p>\n

In this case, however, I’m interested in looking at code not as a way of understanding the piece of software of which it is a part, but rather as a way of understanding the history of those involved with its production.\u00a0 In this context, code provides an archaeological record of the goings on of programmers, computer hardware, and standards organizations.\u00a0 Some of the events that this record shows are easily discernible once you have access to the source code.\u00a0 For example, a quick comparison between the code for Wolfenstein 3D<\/em><\/a> and the code for Quake<\/em><\/a> shows a number of the changes that took place over the space of four or five years.\u00a0 Some of these merely reflect the way that both computer programming in general and Id’s own software had advanced over that space of time.\u00a0 For instance, the graphics code in Quake<\/em> lacks the large blocks of assembly code that are fairly common in Wolfenstein’s<\/em> rendering system.\u00a0 Other changes, such as the structuring of the code in Quake<\/em> around Doom<\/em>-style WAD files is more indicative of Id’s policy toward modding than any kind of technological advance.<\/p>\n

While there is a great deal of information that can be gathered from the general structure and syntax of a body of source code, there are also many important details that can only be learned through a closer reading of the code.\u00a0 Perhaps the best example of this kind of close reading is the book 10 PRINT CHR$(205.5+RND(1)); : GOTO 10<\/em><\/a> (Montfort et al, 2012), which looks at the history, cultural significance, and legacy of a single line of code.\u00a0 These same approaches can be used to uncover subtle, yet significant information about the creation of any codebase.<\/p>\n

\"Hungarian<\/a>
Hungarian notation was the standard coding convention for Microsoft programmers, though it was often difficult for other programmers to read.<\/figcaption><\/figure>\n

As someone who was writing software (though with varying degrees of success) for Windows in the early 2000s, I inevitably came into contact with Hungarian notation.\u00a0 Hungarian notation was the colloquial term for Microsoft’s variable naming conventions, which appended a number of letters to the front of every variable name in order to convey additional information about the kind of information the variable contained.\u00a0 The system was proposed by Charles Simonyi, Microsoft’s Chief Architect.\u00a0 This lead to long and impossible to pronounce variable names like hIcon<\/code>, lpfnWndProc<\/code>, and lpszClassName<\/code>.\u00a0 Although it all looked the same to me at the time, Hungarian notation actually refers to two different conventions that were used by two different groups within Microsoft.\u00a0 Those that worked on Microsoft Word<\/em> with Simonyi used a version known as Apps Hungarian<\/em>, while those that programmed Windows itself created their own dialect, Systems Hungarian<\/em> (Rosenberg, 2007).\u00a0 Thus, a programmer’s use of Hungarian notation not only shows his association with Microsoft, but what division within the company had the most influence on his coding practices.<\/p>\n

Most coding conventions are not quite as distinct as Hungarian notation.\u00a0 In all their forms, however, conventions demonstrate a lineage of programming knowledge that can often be traced back to a common source.\u00a0 Years after abandoning C++ for the first time (a choice that was influenced in no small part by my encounters with Systems Hungarian), I began teaching myself ActionSctipt 1.\u00a0 At this point in time, Flash (then still a part of Macromedia) was just beginning to be seen as a viable platform for creating actual games and a number of different communities focused on Flash game development were popping up on the Internet.\u00a0 I managed to teach myself ActionScript (and pick up a number of bad coding habits) by reading tutorials and demo code from programmers in Australia, Estonia, and Sweden and then combining them together into a cohesive program.\u00a0 When I finally decided to start taking actual programming classes, I noticed that one of the other students used some of the same strange naming conventions that I used.\u00a0 As it turns out, he had been following some of the same tutorials that I had used to teach myself.<\/p>\n

In addition to variable names, sometimes entire blocks of code are passed down from one generation of software to the next.\u00a0 For me, this meant that my collision detection contained poorly translated Estonian jokes for years to come.\u00a0 For companies that maintain large codebases, that code can preserve the work of programmers long after they’ve left the company.\u00a0 Such code is a record of these programmers’ assumptions, idiosyncrasies, and even mistakes, as in the case of the recently discovered Shellshock bug<\/a> that was dutifully reproduced in the open source Bash program for over twenty years.<\/p>\n

While the concept of code as an archaeological record certainly has implications for fields such as cybersecurity and software design, I am most interested in how it can inform the way we look at videogames and culture.\u00a0 In a recent article on Gamasutra<\/em>, Alex Wawro spoke with the designers of Civilization: Beyond Earth<\/em><\/a>, the latest game in the Civilization<\/em> franchise, set to be released this week.\u00a0 With around twenty different games and expansions in the series, Beyond Earth<\/em> is already a game with a lot of history behind it.\u00a0 For those who are familiar with Civilization V<\/em> and its expansions, the game should feel quite familiar.\u00a0 The interface is largely identical, apart from swapping its Art Deco aesthetic for a more futuristic look.\u00a0 The mechanics of unit movement, city growth, and combat mostly carry over as well.\u00a0 While these similarities in themselves are somewhat interesting, the more intriguing aspects, for me at least, aren’t entirely apparent until you go deeper…<\/p>\n

\"While<\/a>
While the visual similarities between Beyond Earth<\/em> and Civ V<\/em> are easy to spot, the legacy of their codebases goes all the way back to the original Civilization<\/em>.<\/figcaption><\/figure>\n

If we were to extend our archaeological metaphor to Beyond Earth<\/em>, the game would look less like the Temple of Karnak, preserved in the desert, and more like the city of Rome<\/a>, with its archaeological record buried beneath layer upon layer of new construction throughout millennia of constant occupation.\u00a0 As designer Will Miller notes, the code used for Beyond Earth<\/em> doesn’t just go back to Civ V<\/em>, but all the way back to the original Civilization<\/em> game.\u00a0 He describes the code base as being very “stratified,” with one successive game being built atop the previous title.\u00a0 As with my previous examples, the code that Miller and his team encounter doesn’t just tell them about previous Civ<\/em> titles, but about the people who helped to create them.<\/p>\n

It’s really fascinating to go back in the Perforce history and just kind of look and see ‘Oh, here’s where Soren [Johnson] started working on it, because all the APIs are camelCase.\u00a0 You can go back and back and see the geology, the layers of all these previous Civilization<\/em> designers’ hands in the codebase.<\/p><\/blockquote>\n

Miller’s co-lead designer, David McDonough, mentions that in addition to the code itself, Civilization’s<\/em> source files include include comments from the original developers.\u00a0 These comments not only shed light on the reasoning behind the design choices in earlier Civ<\/em> titles, but have also influenced the design choices for Beyond Earth<\/em>.\u00a0 This common codebase, along with numerous other prototypes and experiments comprise an incredible archive of the history of Firaxis as a company and (in the case of the code from Civ I<\/em> and II<\/em>) beyond.<\/p>\n

As impressive as the structural continuity of the Civilization<\/em> codebase is, it can be easy to write it off as a special case.\u00a0 There are very few games that I would place in the same class as Civilization<\/em>. To some extent, it might be expected that a game that has had so few changes to its core mechanic for over twenty years would have some amount of common code that runs through the series.\u00a0 What I find encouraging as a researcher is the fact that this kind of code longevity is not unique to huge franchises like Civ <\/em>and is probably a lot more common than we normally think.\u00a0 Most of the people I know who work for professional game studios will attest to (or quite frequently lament) the fact that they occasionally have to work with very old code.\u00a0 In some cases, studios working on games for the Xbox One and PlayStation 4 still have code in their engines that was originally written when the studio was working on Super Nintendo games.\u00a0 This is even the case in studios that have changed ownership multiple times over the years.\u00a0 Although there have been massive changes in graphics, processor speeds, and general programming conventions over the last twenty years, these relics of the past live on in low-level code that is reproduced again and again.<\/p>\n

There are two main reasons why ancient code lives on in software.\u00a0 In some cases, the code is just that good.\u00a0 A custom memory manager that was designed to squeeze every last bit of performance out of the limited hardware capacity of the Super Nintendo, in many cases, works just as well on modern consoles, even if not all of its cycle-saving tricks are strictly necessary.\u00a0 Old code can also be carried over into new software simply because there isn’t time to rework it properly.\u00a0 This is perhaps slightly more common in the crunch-prone world of videogame development than in other fields, though it certainly occurs in all large software projects.\u00a0 When deadlines are approaching, rewriting code that could<\/em> be better tends to be low on the priority list.\u00a0 Although some organizations will periodically reevaluate their codebase or simply “burn everything to the ground” and start over, large software developers often don’t stop to breathe between projects.<\/p>\n

\"Although<\/a>
Although we might not think of a codebase as an archive in the traditional sense, they are important methods of preserving game development history.<\/figcaption><\/figure>\n

In either case, this semi-intentional preservation of code provides a wealth of information to researchers.\u00a0 Unfortunately, the bigger issue from an academic perspective is the problem of access.\u00a0 Although I would love to be able to stand alongside Miller and McDonough as they look over bits of old code written by Sid Meier and Soren Johnson, the secretive nature of the videogame industry means that few, if any, people outside of Firaxis will ever get to see their impressive archives.\u00a0 This is one reason why it’s so exciting when companies like Id publicly release their old code<\/a> for developers, researchers, and anyone else to look at.\u00a0 It’s also one of the side-benefits of games with robust modding tools, like Minecraft<\/em> or Half-Life 2<\/em>.<\/p>\n

While this kind of development chronology is certainly not the only type of information that can be gathered through close readings of code, I believe it has the potential to give us a unique perspective on the games themselves.\u00a0 I would be curious to know how much, if any, of the code in Beyond Earth<\/em> is based on (or simply inspired by) code from Alpha Centauri<\/em>, which had a very different map system than most Civ<\/em> games.\u00a0 I would like to know how concepts like what constitutes nations, barbarians, and civilized people<\/a> has changed on an algorithmic level throughout the series.\u00a0 We don’t have access to that information today, but if companies like Firaxis continue to maintain their code archives, perhaps one day we will.<\/p>\n

References<\/h2>\n

Julian K\u00fccklich, (2003). Perspectives of Computer Game Philology<\/cite><\/a>
\nMichael McGee, (1990). Text, context, and the fragmentation of contemporary culture<\/cite>.
\nNick Montfort et al, (2012). 10 PRINT CHR$(205.5+RND(1)); : GOTO 10<\/cite><\/a>.
\nScott Rosenberg, (2007). Dreaming in Code.<\/cite><\/cite><\/p>\n","protected":false},"excerpt":{"rendered":"

Over the last few weeks, I’ve been in the process of relearning C++.\u00a0 Of course, saying that I am “relearning” is perhaps giving me too much credit, as it has been almost fifteen years since my first attempt at mastering the language.\u00a0 While it shares a good deal of syntaxContinue Reading<\/a><\/span><\/p>\n","protected":false},"author":20,"featured_media":4986,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[15],"tags":[45,413,412,44,199,141],"coauthors":[311],"class_list":["entry","author-christiansen","post-4982","post","type-post","status-publish","format-standard","has-post-thumbnail","category-articles","tag-archaeology","tag-archives","tag-beyond-earth","tag-civilization","tag-code","tag-critical-code-studies"],"jetpack_featured_media_url":"http:\/\/www.playthepast.org\/wp-content\/uploads\/2014\/10\/Old-Minecraft-Code.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/posts\/4982","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4982"}],"version-history":[{"count":12,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/posts\/4982\/revisions"}],"predecessor-version":[{"id":5011,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/posts\/4982\/revisions\/5011"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=\/wp\/v2\/media\/4986"}],"wp:attachment":[{"href":"http:\/\/www.playthepast.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4982"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4982"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4982"},{"taxonomy":"author","embeddable":true,"href":"http:\/\/www.playthepast.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcoauthors&post=4982"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}