During a Microtalk at Concordia University’s Milieux institute, I mentioned that performing textual analysis upon videogame hacks poses some unique difficulties. I bemoaned how each hack was really two games, the game designed by the developer and the hack that was structured on top of it. This requires a researcher to familiarize themselves with the original title, so they could better identify the ways in which the hack was enacting changes upon it.
However, during the question-and-answer portion of the evening, an audience member smartly pointed out that it was perhaps even more complicated than I had imagined! Looking at each videogame hack as a homogenous whole was an error, as a each project is often comprised of dozens of smaller modifications. These hacks range from simple tweaks (perhaps adding a single feature or option to a game) to incredibly complex reworkings of algorithms or game assets. Hackers often layer features and patches atop one another, especially with large-scale projects.
That got me thinking… how would one even begin to distinguish who authored different elements of a videogame hack? It is rare for a hacking team to have a centralized credits page for their project, and it seems that game elements are often pulled from shared resources (archives, GitHubs, forums, etc…) when needed. Pairing this with the fact that many hacks keep their authorial information hidden – both on private websites and behind inconsistent pseudonyms – it can be very difficult to determine what elements of a videogame hack are new features and who created them.
On the other hand, does this differ all that much from professional game development projects? Very few commercial titles are developed by a single person, and the contributions from team members are often simplified immensely in the game’s credits. Smaller teams may work on very specific parts of a game – building textures, recording character voices, etc – before their work is incorporated into the finished product. When we, as academics, go to research these titles, we are rarely concerned with what part of the game has been created by individual team members. Instead, we analyse the game in its entirety, usually referencing the developer instead of any particular individual.
This brings to consideration of some methods we can use to counter this simplified view of game development as being completed by a homogenous entity. Although interviews are certainly not without their flaws (memory, honesty, access), I’ve found them to be a potent way to challenge this perspective. Speaking to individual team members allows you to break through the facade of unity and learn more about who really completed what work on a project and, perhaps more importantly, what the internal dynamics of the development really are.
An analysis of fan archives could be another useful method although, admittedly, this can be quite the daunting task. Many hacking communities utilize archives and messageboards to share information about their projects, including technical accomplishments and histories of development. However, these resources are not always formalized and are certainly not designed for easy access to the public. Although they hold a wealth of information – conversations about development, work-in-progress hacks, discussions about project direction – this knowledge is spread across thousands of pages of information. It is beyond the scope of many projects (and certainly beyond the scope of my master’s thesis) to meaningfully log and interpret this data.
As this blog is mostly about posing problems, not remedying them, I don’t really have a definite answer to this issue. Perhaps my biggest takeaway, however, is that presenting your research is a great way to identify potential holes in your methodology! Having these sorts of concerns in mind as I work through my research really helps me reflect on my methods and research.