I get the same question every time. When I mention I pursued both an English and Computer Science undergraduate degree to most people, it starts with a head tilt. Then comes the frown. And, finally, the question “What do they have to do with each other?”

The answer, to me, is pretty simple: “it’s all code.” From written to printed texts, it’s all code of a sort. It’s the distillation of ideas into a form our brains can process. Encoded symbols that represent complex thoughts that, in turn, have a relationship to other ideas. The connection comes from their context and execution, how we makes sense of what we see and hear.

The jump to thinking about programming languages the same way, then, comes pretty easy to me. Yes, of course, since they are a way of expressing thoughts, they consist of a systemic representation of the culture that created them.  Like all other artifacts, they contains the thoughts of their creators. The worldview of the person who created that language is written into  it.

And while that understanding might be fairly straightforward, trying to unravel it is anything but. The problem occurs not in trying to pick out the ideologies within a particular programming language, something that can be quite difficult all on its own, but in how they are used. That is, seeing them in practice to reverse-engineer how that language shapes the thought of those who use it.

Because that is the real key. Programming languages, for the most part, have gotten very abstract.  And nearly all meta. Most interpreted languages don’t have a direct correspondence to an idea as we might think of it for a written language. They represent an interface to a simulation of an object that is written in another language. Even writing assembly code means a translation at some point into binary signals. Code is always being interpreted and re-interpreted constantly.

It is this connection to game studies that interests me. When it comes to game studies, we rarely treat a game as a configured object. It is nearly always about the player and her response. The sensation or mechanics. The feedback loop between input and output. The game as run. As a single unit.

Yet, and here is where I would really like to see Robert Yang’s upcoming talk, that is just the beginning of how games can be studied. Instead of viewing a game as an experience, as a collection of bits to be configured during runtime to form a unique story for the player, they can be viewed as compiled texts. Hundreds if not hundreds of thousands of lines of written language — with patches and changes. An investigative cornucopia of marginalia and versioning edits.

Especially true of most AAA games, they represent not just the encoded ideas of a few people, then, but potentially that of entire organizations. The community practices of a team in how they think through a language or engine. Not just what they use, but how they name things and construct patterns. Not just in execution, but in planning too.

The exclusion of women and queer content that Yang notes is even more problematic than many initially realize. It might very well be that a team does not have the “time and resources” to include this (basic) content. However, that is not the true reason for not having such material in a game. It is not that the fictional world cannot support it, but that the systems behind it can’t. They were designed around and for certain people — purposefully ignoring others.

Exclusionary tactics, even subconsciously, were set into play quite early. Be it in the planning, the writing, or even the core objects or modules of the game, it was built into system. The meta-language, often the application programming interfaces themselves, were set up to privilege certain player expressions and outcomes.

Rolling forward, all these design decisions become The Game as a whole. All the little ideas and thoughts of the programmers are committed and merge together. The designer’s work on the layouts and flow of areas fill out. The artist’s renders and animations are attached. They are all though based on some initial assumptions: the deeply embedded hard-coded values of the simulation.

Having this skill — and I take up Yang’s call to educate too — becomes a powerful tool in analyzing games. Asking questions of the code itself. Not just how the systems feel to play, but combining that with the ability to parse its structures as well. Is it that the writers were not willing to include queer content, or that the system was not able to understand it? Does “takes too much time to include women” mean extra work for the modelers, or that such exclusion was rooted in the very planning itself? How does the code work exactly?