Closed captioning available at YouTube
Hi everyone. My name’s Darius Kazemi. I’m speaking to you from my home in Boston but at this exact moment I’m probably on my way to Logan Airport to come to San Francisco and I’m really jealous of all of you who are actually at Critical Proximity. Anyway, you might know me as the “Fuck Videogames” guy but I’m actually here in my capacity as the author of a forthcoming book about the 1999 turn-based strategy game Jagged Alliance 2 published by Boss Fight Books.
My book attempts to illuminate interesting things about one of my favorite games by focusing on the material realities of development. It’s heavily based on interviews with the developers and also my reading of the game’s source code.
Now one might ask: why even bother to look at source code at all? It’s a valid question, especially when technological determinism and the reductionism it brings has been such a pervasive, negative force in a couple of decades of dialogue about videogames. So I’m absolutely not saying that source code is the only important factor when looking at a game. What I am saying is that it’s ridiculous to not look at it if you are lucky enough to have it at your disposal.
What IS source code?
This may seem self-evident but there are many layers to what can be considered a game’s source. For example, for an Atari VCS game there’s one layer of code: the game programmer is providing instructions directly to the hardware. I’ve highlighted the code part in red, in case that wasn’t clear.
A modern game, and by this I mean probably any game made after 1995, looks a lot more like this. This is actually a huge simplification, but you get the gist. And when we study a game, it’s not 100% clear what we should be looking at here. There’s core game code, which obviously is worth looking at, but then there’s also gameplay stuff often implemented in a scripting language separate from the game code. There’s the third party game engine like Unreal or Unity — do we want to spend our time digging into how the Unreal engine works? Maybe we do. What about the limitations of the operating system? Are we getting too abstract now? Does the choice of OpenGL versus DirectX really matter? What about the maps? They often contain code and logic embedded in them: triggers for “if the player walks into this room, then do XYZ.” That’s code too, even though it was laid out visually by a map designer.
It’s not cut and dry what “the code” is anymore.
The reason I bring this all up is that it may only be possible to find ONE of these things, and that’s okay. I believe that the modding tools released with Skyrim, which are cleaned up versions of their internal tools, might as well be considered source code, as they reveal things about the inner workings of Skyrim’s data structures and logic paths.
So how do you find a game’s source code?
Aside from the obvious “google for it”, the main thing you need to look for is a modding community. If a game has a dedicated modding community, then the modders need to be able to work somehow! I ended up finding the source code for Jagged Alliance 2 by going to the main JA2 modding community message board and searching it. It took me about 30 minutes and a lot of dead free file hosting URLs, but eventually I did find it.
Go to the mod community. Reach out. Do the work.
So what do we do when we get our hands on the source code? The first thing that I try to do is get a sense for how it’s organized.
I’m going to show you the source code from a few different classic games as examples here.
Here’s the source code for Spear of Destiny, a mini-sequel to Wolfenstein 3D released in late 1992. All of the code is in a single directory. If you look at the files, they’re organized by prepending strings to their names. Audio files begin with “AUDIO”, graphics files begin with “GFX”, the core utility files start with “ID” for “Id”, and the actual game files begin “WL”.
At this point you survey the code — if you don’t have anything better to go on, use your intuition. Worst case, just scan over every file. At this stage it’s not worth reading things in detail: you’re trying to understand the lay of the land, so just read. And honestly, just skim.
In Wolfenstein, we might start by looking at this file, WL_MAIN.C. Seems promising. Let’s scroll all the way to the bottom here: there’s a note here saying “Beta testing is over, sorry.” And what it’s doing here is it looks to see if today’s date is beyond a given date, not specified here. Well, let’s search for the string “year” in the code…
Hey, what do you know. We now know that beta testing for Spear of Destiny ended on September 30, 1992. That’s pretty cool.
And a brief note on reading source code: you don’t need to be an expert programmer to read source code. You probably need some programming background, to get something out of it, but to give you an example, this game is written in the C programming language. I am not a C programmer. It doesn’t matter, I can still read what’s going on!
Now we’re looking at the source code for Jagged Alliance 2, because I want to show you examples of the kind of things you can find in the source code. For those unfamiliar with Jagged Alliance, this is a kind of XCOM style game where there is an overworld map that lets you plan strategy, and tactical maps where squad based battles happen.
I want to show you something that I found in the source code of the Strategic layer, specifically in a file called “Strategic AI” — it seemed important so it was the first one that I opened. What we have here is a three hundred word essay penned by one of the game developers, laying out the overall philosophy behind the design of the strategic AI. It’s a beautiful piece of writing about game design, and I think it’s even more beautiful because it was inserted directly into the source code as a way to guide what people working on the strategic AI for the game were doing on a day to day basis.
So this is an extreme example of comments, which are really just plain language texts embedded in code. I don’t have access to any of the design documents for Jagged Alliance 2, but I do have this, and I think it’s incredible that by looking at the source, something like this could be dug up and exposed to the world. It tells us something about the game that we didn’t know before.
There are also examples of aesthetic beauty to be found in the source code. I’m going to switch over to something from the tactical battle code, where squads of soldiers are doing turn based battles. This table sticks out and is kind of incredible. It’s a kind of estimation table that says “If I’m looking south and someone is to the north of me, then they’re behind me. If I’m looking west and someone is to the north of me, then they’re to my side.” It’s an elegant piece of code that’s not only pretty to look at, but also shows that the developers were not concerned with simulationist realism: they were fine with estimating angles rather than calculating them explicitly every time.
Anyway, that’s all the time I have right now, but I encourage every one of you to look at source code: web games, twine games, old games, new games — you’d be surprised by what’s out there and by what you can find.
4 thoughts on “Looking at source code”