The (Harris) Matrix, Part II: Making the Software Stratigraphy Leap

 

leap

[Part I of this 3-part series introduced you to the concept of software stratigraphy. Part II explains how it’s done. Part III will provide a complete software Harris matrix for the game No Man’s Sky.]

In Part I, we learned about how the Laws of Stratigraphy as defined by Edward Harris apply not only to terrestrial sites, but also to software. So what does that actually look like, and how can one create a Harris matrix to visualize digital stratigraphy?

Commercial software is iterative, and each iteration comes with documentation in the form of patch notes. These notes detail what has changed in the software between versions. New versions (upgrades) add to the biography of the software, which is part of contemporary material culture. Taken together, the patch notes for a mature software application reads like a history of a city that was once a village.

The (media) archaeologist can imitate terrestrial archaeologists and excavate from the top down with the most recent (or final) version of a program. In the case of software, it makes more sense to begin at the beginning, and work up through the strata. The (media) archaeologist has the benefit of knowing how and when things began, and how they ended. The patches that happened in between can then be plugged in to get a complete sense of the growth of the software-site. We dig up instead of down.

This works with commercial software that ships with complete documentation of functionality, features, and changes, but things get tricky with earlier software applications, or more independent constructions. With these, one must be able to locate, install, and observe characteristics within every version of the program. When these programs ship on physical media, the difficulty of reading their stratigraphy becomes greater: one must find working copies and machines to run them on. Software released without a media package is marginally easier to study, but one must track down various versions, which may or may not be archived. And even when they are found, the chance that they will have attendant documentation is slim.

One can hope for some middle ground in lieu of patch notes: commented code. Some software engineers will add comments to the code as they write it, which can serve as a kind of road map to understanding how the code works. This commented code can be helpful in understanding stratigraphy, perhaps working in concert with actual (or accounts of actual) use-testing and patch notes.

I will provide an example of the above in creating a Harris matrix of the video game No Man’s Sky (Hello Games 2016). I chose this game for two reasons: 1) I have put hundreds of hours into playing this game, which includes playing it on every patch released so far, and 2) the No Man’s Sky patch notes are both detailed and complete. Because this is the first time I have attempted to create a video game/software Harris matrix, I wanted to use something well documented and familiar. Future attempts by me and hopefully others will not have as much to go on, and will require more higher-level archaeological thinking when analyzing the stratigraphy.

The (Harris) Matrix: Reloaded 

No Man’s Sky released on August 9, 2016 (US for PS4), August 10, 2016 (EU for PS4), and August 12, 2016 (worldwide for PC) as v1.0, and immediately required patching. The original game has been updated 13 times (1.03, 1.04, 1.05, 1.06, 1.07, 1.08, 1.09, 1.10, 1.12, 1.13, 1.20, 1.22, 1.23, 1.24). At the time of this writing (April 4, 2017), the game is up to v1.24. Hello Games designated the original game as “1” (before the decimal), and any major additions/changes as the first number immediately after the decimal (e.g., the “Path Finder Update” is v1.2x).

Reviewing the patch notes for this game yielded a lot of data that could be (and was) translated graphically for a visual understanding of the No Man’s Sky’s development and growth. To break the game down:

Between versions 1.0 and 1.24 (inclusive) there have been over 550 individual updates. Each of these updates is a stratigraphic unit that has a home in a numbered update, which is a stratum. The strata stack atop each other, the earlier updates below the more recent ones, therefore in superposition.

Most updates in No Man’s Sky included at least one change in one of three categories: Bugfix (F), Enhancement (E), and New Feature/Functionality (N). Bugfixes resolved (or attempted to resolve) issues in the game (e.g., crashes and other things that interrupted gameplay). Enhancements took existing features and functionality and either improved upon them (e.g., making rough textures smooth, making aiming easier) or “nerfed” them (reduced functionality to make things more fair during gameplay). New features and functionality added elements to the game that did not exist in prior versions (e.g., adding land vehicles, adding the ability to purchase freighters).

Each of the units in these three major types of game-changes fell into one of 15 sub-categories, which I was able to discern during my review of the patch notes: gameplay, visuals, OS/hardware, crashes, load/save, controllers, user interface (UI), audio, glitches, login, memory, languages, procedural content generation (PCG), game engine, and user-modifications (mods). Some software updates contained dozens of fixes in several categories, while other updates only fixed a few things. After reviewing the patch lists for each and every No Man’s Sky update, I felt that I was able to begin creating the software Harris matrix. I needed to write out the rules first, however.

Rules for Making a Software Harris Matrix

[NOTE: The following rules are subject to change based on usage in the field, and on peer review.]

According to Harris’s book, there are only three relationships between units of stratification (those little numbered boxes that exist within the matrix):

  1. Units have no stratigraphic connection.
  2. Units are in superposition.
  3. Units are correlated as parts of a once-whole deposit or feature interface.

For software then:

  1. Units are in the same patch/update, but without stratigraphic connection (i.e., fixes, enhancements, new features)
  2. Units are in superposition (i.e., enhancements of existing functionality/features)
  3. Units are correlated as parts of a once-whole deposit or feature interface (i.e., fixes, enhancements, or features of a similar type within the same patch)

Every box is a unit within a stratum. While the traditional Harris matrix uses mostly (or entirely) numbered rectangles, the software Harris matrix uses three shapes:

  • Squares: Bugfixes
  • Triangles: Enhancements
  • Circles: New features/functionality

composite.jpg

Each unit, no matter what shape (square, triangle, or circle), gets assigned a sequential number. The number corresponds to a text description of the bugfix, enhancement, or new feature/functionality, which is listed separately from the visual matrix. The numbering begins at 1 and starts with the first unit in the first numbered software update. Unit-numbering increases sequentially counting by ones, with higher-numbered units appearing in the upper strata, connected by lines (or not) as dictated by one of the three relationships as defined above.

The software Harris matrix has left, top, and bottom margins. Software version numbers appear at the left margin, the early versions at the bottom, and later versions above. Place the date of the update’s release underneath the version number. Versions are divided by a solid horizontal line, which designates the interface between any two strata (versions). If the size of an update is known (in kb, MB, or GB), that size translates to stratum thickness. Thicker strata indicate major updates (e.g., No Man’s Sky v1.2’s Path Finder Update), as opposed to thinner strata, which indicate minor patches (e.g., v1.24).

The top and bottom margins list each of the Sub-types for a given software application. The names are repeated at top and bottom for the sake of clarity. If the matrix is simple, omit either the top or bottom legend. Dotted vertical lines run from top to bottom of the matrix to separate the Sub-types.

When populating the software Harris matrix, units are placed in their appropriate strata (X-axis) and columns (Y-axis), grouped together by type. Vertical lines of superposition connect related units between various strata. Horizontal lines designate correlation between similar types of updates within a given stratum. Modest text can be added to define groups of units within a stratum.

There are two possible ways to create a software Harris matrix for an entire game: 1) the universal approach, and 2) the typological approach. The universal approach maps the entire software stratigraphy as a whole, which can be unwieldly. For my case study of No Man’s Sky, I am taking this approach just to illustrate what this kind of matrix looks like. The typological approach creates smaller matrixes based on either Type or Sub-type. Perhaps you create a software Harris matrix for just bugfixes, or just enhancements. You can go one step further to create matrixes that isolate certain subtypes. When finished, these typological matrixes can then be combined to form a master, universal matrix.

Taking the First Leap: A Simple Example

To conclude Part II, let’s build a simple software Harris matrix that is based on one of No Man’s Sky’s simpler patches, v1.24, which contains 4 bugfixes (F), 2 enhancements (E), and 1 new feature (N). Here are the patch notes, which I have numbered sequentially and grouped by type and sub-type:

F (1 glitch, 1 OS/hardware, 2 crashes)

555      Glitch              Fixed an issue that caused player’s bases not to appear

556      OS/hardware  Fixed some issues with Steam controller prompts

557      Crash              Fixed a game freeze/lock up that could occur when in space

558      Crash              Fixed some rare crashes & freezes

E (1 visuals, 1 OS/hardware)

559      Visuals            Improved frame rate when playing with unlocked frame rate, or vsync disabled

560      OS/hardware  Various minor performance optimisations

N (1 gameplay)

561      Gameplay        Optimised light shafts, allowing us to enable them on PS4

sampleharris3

Sample, simple software Harris matrix for a small No Man’s Sky patch.

The units drop into the so-labeled 1.24 stratum in their respective Sub-type columns. Units 557 and 558 share a continuity link (they are both crash-fixes).

Granted this example doesn’t look like much, but it’s simple, and it’s taken out of context/phase with the rest of the software updates that came before it. Remember that this is the first time I’m doing something like this, so if after reading you have some better ideas, I’d love to hear them, and can incorporate them into the workflow.

One thing I have been wondering is how to handle/differentiate the fixes/enhancements/new features for the same game on multiple platforms. Not all fixes in a given patch are applied across the platforms. There might be an additional way to illustrate those links, or perhaps to lightly shade the shapes of the effected units. Ideas welcome. It could be that we create a top-level matrix, one that shows the splits and illustrates where some patches were applied to one platform, but not to another. That might be the best way.

Part III will contain the complete software Harris matrix for No Man’s Sky, including the numbered patch notes. But first to sleep. Morpheus beckons.

neck3

—Andrew Reinhard, Archaeogaming

 

Advertisements

6 thoughts on “The (Harris) Matrix, Part II: Making the Software Stratigraphy Leap

  1. Maybe I missed something, but it seems like this assumes a linear sequence of development. If you look at a software repository, you’ll find branches and merges too. Does this imply that a more complex/general theoretical model is needed for software?

  2. Pingback: The (Harris) Matrix, Part I: Visualizing Software Stratigraphy | Archaeogaming

  3. Pingback: The (Harris) Matrix, Part III: Enter the Matrix | Archaeogaming

  4. Pingback: The (Harris) Matrix, Part IV: So What? | Archaeogaming

  5. As John said – also, as a kinda terminology thing – is this a matrix of the “software” itself or of the patch-notes? It seems like the latter to me as it stands?

  6. Pingback: Relics or rubbish? | archaeogamingblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s