In Part I and Part II of this series, I wrote about the theory behind understanding software archaeologically and stratigraphically. Having dug myself a hole (pun very much intended), it was time to attempt to create a software “Harris” matrix for No Man’s Sky. Never one to shy away from a challenge, I realized that this project would have 14 levels of strata and 550+ stratigraphic units, plus various relationships between units and units (and units and strata), and that there would be a very good chance that I would fail (although the success is in being able to come close to realizing my thinking in practice). Part III shows the matrix I drew and pairs it with the data from which I worked. I describe my method of constructing the drawing and how it differed from my original plans/thoughts. Part IV will detail what I learned about No Man’s Sky from reading the matrix after I built it, and I will offer recommendations for future nerds. I mean (media) archaeologists.
Although I had the patch notes, they were organized initially only by version number. It took some time to determine how each unit was either an enhancement (E), new feature (N), or bugfix (F). Going one step beyond, I also needed to determine what kind of update each unit represented (e.g., gameplay, visual, audio, crash, etc.). I then dumped everything into a spreadsheet and color-coded it by patch number (colored cells), type (grays), and subtype (colored text). The data organized in this way were extremely helpful when it was time to establish the relationship links, which I will describe in a moment.
Scroll through the spreadsheet below (use the slider to see more of each description as well as the column of related links), or to get the Full Monty right away, click here.
One column still needed to be populated: “Links To.” In order to do this, I had to create an index of terms from the patch notes’ descriptive text. I used the resulting set of 200+ keywords to query against the descriptions in order to find out what things were tied to individual units (see below, or click here for the Full Monty).
I was then able to hand-check each term (and each unit tied to each term) to determine if there was a relationship shared between two or more units. Even though several units might share a term, it didn’t mean that all of the units had a relationship.
Enter the Matrix
Armed with data and a plan of attack (courtesy of modding Edward Harris), I grabbed my graph paper, pencils, and straightedge, and got to work. It took me a week of nights to finish, hand-drawing all of the levels, unit shapes, unit numbers, and finally links. As I drew, a number of niggling problems presented themselves, and I can only imagine Harris enduring the same kind of frustration during his experimentation. The good thing about drawing the first iteration of a software matrix by hand, is that it allowed me to slow down and think about what I was doing, and to think like an archaeologist. Drawing was very much a meditative act, and as tedious as it was, it was also helpful in forcing me to consider what I was doing, how, and why.
For my matrix, I decided to lump types together per each stratum. This meant that I drew triangles, then circles, then squares in each level. In hindsight, I should have grouped each type in their own rows; as it stands now, I might have two triangles and a circle on one row, topped by a row of all circles. I also realized that in some cases there were dozens of enhancements or fixes per level, so I had to stack the units within each stratum. Looking at the matrix now, I might have saved space taken up by the Subtype columns by using color-coding, a different color per Subtype, imitating the spreadsheet. In the future, this can be done easily with digital tools, but for the first experiment, I stuck with graphite only.
For the first pass, the tedium was a killer. Adding the relationship links was a whole other matter. As soon as I began to consider how to draw the links for v1.03 (the first patch), I knew I was stuck. With software, several fixes/enhancements work together and connect to several other fixes/enhancements. It’s not a simple, linear thing. On many occasions, there was a fix or enhancement that served like a hub connecting other units that may or may not be related to each other in a meaningful way (other than sharing the stratum). With not a little horror, I realized that instead of a matrix, maybe I should have done this as some kind of (neural) network, with hubs radiating units, instead of units stacked atop each other like blocks. These radiating hubs could still be locked into stacked strata, with arms reaching across levels as needed, to later hubs of fixes.
I did have at least one positive a-ha! moment, as I hunted high and low for units that crossed stratigraphic boundaries (or interfaces). I found a few. In these instances — always with fixes — an earlier fix in one version would lead to a better, more permanent fix in a later version. For example, unit 49 (v1.06) links to unit 59 (v1.07). Both units describe saving large numbers of waypoints. Unit 49 describes a bugfix for a crash caused by saving too many waypoints. Unit 50 describes a gameplay bugfix, which improves upon the waypoint-saving system. The two units are connected across the interface between versions, one unit building upon the other across time, stacked directly atop each other.
For the most part (especially in later updates), the enhancements, new features, and fixes kept to themselves, occasionally linking to one another within their stratum, but more often than not standing alone without linking to anything. I was able to analyze all of the minor patches for links, but did not do the two major updates of 1.1 and 1.2. There were going to be too many shared links, which would have made my drawing (more) unreadable. I could conceivably do it digitally using yEd or similar (thanks to Shawn Graham for introducing me to this open source diagramming tool).
Looking at the finished version, it is possible to recognize patterns and to see how the updates came to be, understanding formation processes of software updates for the game. It is also possible to see the limitations of this software “Harris” matrix as drawn for the first time. My supervisor at York asked me to think about the dangers of starting in the analog for understanding something digitally, and I can see now that I should have really been looking at the matrix not as a matrix per se, but as a helix, something 3D and in the round, with links to F, E, and N instead of ACTG, and other links anchoring the stratigraphic units from within the helix, passing through various labels. So while terrestrial stratigraphy can be visualized and mapped with a 2D Harris matrix and a companion top section, software stratigraphy must (I now think) be realized in three dimensions, with the element of time occupying the vertical Y axis. That will be the next iteration once I forget the pain and suffering I went through to create the 2D image below.
I had fully intended to turn the matrix sections below into image maps with mouseover text detailing the feature/fix represented by each numbered unit, but I cannot find a workable WordPress.com plugin that will do this. For the time being you get static images, but I hope to redo the whole thing as born-digital now that I’ve done it by hand. I have cut the matrix into sections for easier reading, and then I made a valiant attempt to stitch the things together in Photoshop CS5 to variable effect. The overall image is there just to show the whole thing:
Watch for the analysis in Part IV, coming soonish.
—Andrew Reinhard, Archaeogaming