Experienced programmers know that data can often be substituted for process. Many algorithms can be replaced by tables of data. This is a common trick for expending RAM to speed up processing. Because of this, many programmers see process and data as interchangeable. This misconception arises from applying low-level considerations to the higher levels of software design. Sure, you can cook up a table of sine values with little trouble — but can you imagine a table specifying every possible behavioral result in a complex game such as Balance of Power?

Of course, what you’re talking about is really more like procedural content, rather than saving a table of numbers as a shortcut for calculations. Personally, I think of procedural content as a good example of process intensity. Costikyan makes a similar point, in discussing Spore, in his post on the subject.

But this doesn’t entirely put the matter to rest. For example, we might ask the same question about a system that uses n-grams. The raw data could be analyzed for its n-grams each time that the information is needed, or each time that the system starts up, or by a different system beforehand (and then stored as data). This could result in very different levels of “process intensity” for the system, but in each case the system would be operating based on the results of running the same n-gram process on the same body of data. We’re really just talking about programming efficiency here, and it doesn’t seem to me that the different system designs really have different behavioral process intensity.

As you can probably tell, I think it might be interesting to write an essay some time about these sorts of “edge cases” for process intensity. But my hope is that, for this book, just laying out the broad outlines of the idea will suffice.

If we go back a bit, we can actually find examples of process being used to generate content. I am thinking of the original Elite in particular. It had a universe of several thousand planets for the player to explore, but said universe was not stored as static assets. It was rather generated on the fly through mathematical algorithms that were always seeded with the same constants, thus leading to the same environment always being calculated, transparently to the player. This was the only method that could allow such a huge field of exploration in a game that ran in 32K of RAM.

Crazy stuff those 8-bit pioneers got up to…

Gilbert, I agree entirely. It doesn’t make sense to think that we can judge the value of a work based on its process intensity. Resident Evil is a nice graphics-centric example. Also, an e-book fiction, email narrative, or blog novel with strong text would have very low process intensity — but it could make for a great, innovative audience experience (just like we can still have with print books). In fact, this is probably easier than making a successful audience experience via high process intensity. We’re just starting to learn how to author media processes, whereas we have millennia of experience authoring media data. But authoring media processes is also, from my perspective, the great promise of digital media. So that’s why it’s the focus of the book.

As for separating graphics processing from behavior processing, you’re right that they’re not totally separable and that graphics processing is not by definition superfluous. I don’t mean to say graphics processing is bad — only that my book is more about things like rules for character behavior than things like ray tracing (or complex database operations, or…).

All that said, don’t worry about bringing up difficult questions at this point in the writing. If I’m leading people astray conceptually it’s definitely better to know now than later.

This seems like more of a crystalized idea and explanation of process intensity than when I posted on here before about it. I’m really excited to see your explanation the data/process distinction, since this seemed the weakest point of the process intensity idea before.

I largely agree with graphics bashing, because truly insignificant graphics are often over-emphasized. However, I’m not so hot on creating a divide between graphics processing and behavioral processing. I think it’s really useful to try to cull out superfluous processing, but I don’t think graphics = superfluous. As examples, both low-data high-process graphics and vice-versa have been essential to the experience of playing some games. In particular I’d think of Mario 64 as an example of a high-process low-data game, (although low-data is debatable, in comparison to many 3d games now it’s arguably low-data) and Resident Evil as an example of a low-process high-data one. As I see it, Mario 64 was huge in that it introduced conventions and vocabulary for 3d platformers, subsequently providing a base for many other 3d game vocabularies and new forms of game interaction. Resident Evil, however was successful for creating the experience of horror in players, to which the graphics choice of fixed perspective and detailed static renderings (data or pre-process?) contributed enourmously. That you couldn’t always see where the zombies were coming from and that the environments are detailed enough to convey the atmosphere considerably aided the horror aim. If Resident Evil should be considered a low process intensity game, then it could be an example of where low process intensity dictated conditions that (perhaps inadvertently) furthered the game’s aims. In both cases the graphics might be such that they fall under categories that are considered superfluous and ornamental, but I don’t think that would be accurate for the graphics in these games.

Anyways, It looks really good. I hope bringing up contentions isn’t too distracting at this point in your writing process.

Looking forward to more.

Aaron, I agree that graphics are much more marketing-friendly than processes. We can evaluate graphical improvements by looking at a magazine or television ad — we don’t need a copy of the game — whereas any touted process improvement is likely to be treated with some skepticism (or even confusion as to its potential impact) until players experience it themselves.

Luke, I think you’re right that the spinning recipe cards may be the wrong example. I’m meaning to point out that processes can be used for a variety of things, from AI behavior to real-time lighting effects. But being able to freely spin the recipe cards is actually a new type of behavior. So I’ll rework that passage. Also, I agree it might be good to include an illustration that shows how far people are willing to turn down their graphics in return for increased system responsiveness.

Matt, you’re of course correct that graphics can be complex and interesting. So can text. But I think the thing I’ve failed to make clear here is that this book is about processing. From this viewpoint, graphics and text can be interesting output from processes, and they can be the (structured or unstructured) data on which processes operate, but they’re not central to the discussion. Still, you’re probably right that I will want to make it clear, somewhere in the discussion, that I have a somewhat more nuanced view of data than “that pile of stuff over there.”

Overall, my sense from the discussion so far is that the best excerpt to present next might be the one that precedes this — where I introduce my focus on processes and establish my version of the process/data vocabulary. I’ll plan to post that in the near future.

This is good stuff and I (for one) want to see more! My quick take–from this brief excerpt–is that it would be useful to balance the introduction of process intensity by also giving graphics their due, via some of the more successful theoretical accounts of images in various strains of visual studies. I’m thinking here of Johanna Drucker’s work, for example. I totally get what you’re after here, but graphics can’t just be a foil for behavior.

Secondly, you might want to detail a little more about the lo-res graphic option that hardcore gamers use. Some readers might not be familiar with the extremely low level of detail that counterstrike, unreal, etc players are willing to live with for that extra framerate that gives them an edge ingame.

The original GTA was designed by developers that deliberately chose dated, top down 2d graphics over the awkward 3d translations currently saturating the market. Again, like the Sims, this graphic tradeoff allowed for a more fully formed world that responded intelligently to the player. Nintendo is another example of a company that has deliberately forsaken developer years crafting artwork and cramming consoles with graphical power in favour of a focus on gameplay, WiiSports, WarioWare, Mario series, etc. Although for your book I’m assuming you’ll want to delve more into deeper AI strategies used in games like The Sims, Civ, etc.

Making simple choices is also something the public seems to understand more readily than interacting with a complex system. Whenever I try to explain IF to people, they almost invariably compare it to “Choose-Your-Own-Adventures,” but even Zork is more complicated than that, simulating states and tracking variables. In my own work, I try to use lots of under-the-hood process intensity to increase the player’s ability to affect the story and environment, but many people just assume they’re reading a static block of text, unless they take the time to delve deeper. I gather with Facade there were similar problems with people’s perceptions of the facial animation system.

Interesting excerpt, Noah. As you continue work I’d love to see more bits and pieces posted.