I guess I’ve generally thought of textons and scriptons in the realm of electronic literature. In this realm I’m pretty comfortable calling the language reader/players see/hear “scriptons.” Everything else that is a representation of what they might see/hear (text, sound files) I think of as “textons.” The way things move from being textons to scriptons (e.g., algorithmic recombination) I think of as the “traversal function.” But then there are parts of any electronic literature experience that aren’t any of these things. There are likely parts of the electronic literature piece itself that are there for purposes such as allowing the reader/player to make input of some sort. That’s not texton, scripton, or traversal function. There are also likely pieces of application software, or support code, or operating system code, that are required for experiencing the piece. But these are not part of the piece, and for this reason I haven’t been thinking of them as texton, scriptons, or traversal functions.

I guess I’d say what you’re working on strikes me as an interesting attempt to expand in a new direction while borrowing some of Aarseth’s terminology — but I don’t remember anything in Cybertext or elsewhere that would make me think of this as an extension or clarification of Aarseth’s work.

On the other hand, what about things like generative algorithms? That, to me, seems like a direction from which we might want to push on Aarseth’s structure. Are there texts generated entirely, or mostly, from traversal functions rather than from textons?

Of course, I should probably go back and reread some of this before opening my mouth too much.

First, I find it charming that Nick (and others?) are studying the assembly code of Combat and other early computer games. I think they’re worthy of study because of their place in history, they have some elegant features, their necessary use of abstraction (as opposed to the ever-increasing realism of today’s games), their extremely constrained operating systems (so little memory, CPU speed, squeezing in computation in between drawing of frames when the raster gun was travelling back to pixel 1, etc.). I find it amusing because I’d bet the mindset of the folks making those games at the time was simply to get a dumb little tank to move around and shoot the other tank. It’s doubtful they could have appreciated at the time how their efforts would fit into the continuum of computer gaming and scholarship.

My initial reaction to idea of studying the code of today’s games, is that would be a hugely complex undertaking. There’s a lot of code to look at. These are huge, huge machines we’re talking about. For example, looking at any one page of code is kind of like standing in one small room of equipment in an aircraft carrier and trying to understand how it fits in to operation of the whole ship.

More productive than looking at source code itself perhaps would be studying the architectures of programs. Higher-level diagrams of the machine, all of its subsystems, then diving into particular subsystems, its data structures, API’s. Perhaps zooming on the code of a few key pieces, but even then I wonder if looking at raw source code would be that fruitful…

Also, reading detailed technical design specs might be a good thing. (But this gets back to the issue that it’s hard to capture the details of behavioral systems in descriptive texts.)

Then I thought, maybe studying the code of Combat and the like would be easier, since it’s so relatively smaller than the code of contemporary software. Although much of that code is probably about working around the quirks of that operating system, rather than about pure gaming algorithm.

What we almost need is to pull out the essential algorithms of a game’s architecture, that strips away all the mundane plumbing and wiring that isn’t terribly interesting, allowing scholars to focus on the core procedures of the game itself.

There’s got to be some good literature from the software engineering community, on the best ways to technically analyze and understand large complex software systems.

Take a look here

http://www.otal.umd.edu/~mgk/blog/archives/000758.html

and especially here

http://www.solasi.org/moin.cgi/CodedAndRecoded

I’d like to encourage GTA readers to contribute to the Wiki page, which was set up by a former student of mine, Matt Bowen. It has the potential to become a resource that would be widely used by many of us in our teaching and other situations.

Is there more info out there about the stuff of yours this connects with?

As a matter of fact you do.

> is this bit of terminological wrangling really the most interesting part of the post? If so, I must have done a pretty bad job.

It hits close to home for some of the stuff I’m working on.

Everyone certainly does have access to the Mystery House binary code – and to the Combat binary code, which I did some critical analysis of and which might be a better example – it’s just that we don’t have the source code on hand. In my paper on Combat, I argue against the idea that the source code is necessary for code-level analysis:

Critics have sometimes shied away from making comments on the code level because they do not have access to the source code of the game or because they lack programming expertise in the language the game was written in, but in such cases much can still be said about how programming practices, tools, and languages influence the development of a game.

We know that Combat was written in assembly language to fit into 2KB of ROM, the first phase of the work begin done by Joe Decuir (who worked on the Atari VCS hardware design) and the second phase by Larry Wagner, and that certain code and coding tricks were re-used later (which is why Air-Sea Battle and other carts also have games that last 2 minutes and 16 seconds). And we know all about the capabilities of the Atari VCS as a platform. And we have an annotated, complete disassembly of Combat.

We also know a lot about the Apple II and Mystery House, even that the drawings were input by with a VersaWriter tablet by Robert Williams, with Ken Williams writing the drivers for that new piece of hardware.

It’s certainly worthwhile to look at source code when it’s available, but to argue can we can’t do any code-level analysis is like saying we can’t speculate at all about how Cicero composed his texts because we don’t have his secretary Tyro available for interrogation. If you mean an analysis of source code specifically, you might just say “analysis of source code.” But even then, we could ask people about how well-commented the source code was and what variables were named and they could reply from memory, without the source code being available…

I take it I have your agreement on everything else in the body of my post?

I disagree ;-) But my basic point is that “analysis” should not be an actviity confined to the normative range of outcomes recognizable as critical hermeneutics (“readings”). Is reusing code “interesting code level analysis”? I certainly think so.

Perhaps you’re conflating outcomes with critical method here. If by “interesting” you mean some analytical enterprise whose outcome is a “reading” in a published essay or a monograph then the question becomes pointed in the way you intend it. But isn’t that a smaller (and more institutionally determined) sense of “interesting . . . analysis” than we need to accept? The work Nick and others are doing reverse engineering Mystery House is (from what I know of it) “interesting code-level analysis,” isn’t it?

Critics of their research have often focused on particular substantive positions that have seemed unreasonable, for example the frequent use of computer symbols such as REASON and DECIDE and GOAL whose relationship to the actual human phenomena that those words ordinarily name is suggestive at best.

(By the way, does anyone reading this know of a single example of interesting code-level analysis for code not written to be analyzed? I’ve heard the stories that people have read ideological assumptions in old AI systems from the fact that data structures were given names like “beliefs” when they could have been called “myTable” – but I’m not sure I ever got a reference for one of these readings. I think the only code I know of that’s been read critically is the code for software art and “codework.”)

Some of Phil Agre’s work might be useful to you there, particulary his paper “Toward a Critical Technical Practice: Lessons Learned in Trying to Reform AI”. He doesn’t step through any particular piece of AI code, but he offers an analysis of AI’s language (inside and outside of code), and shows how it works by being very precise and very vague at the same time.