Mixed Initiatives

2026-02-13T22:23:40+00:00

I’m currently kicking around some ideas about trying to articulate the difference between form, function, and process.¹ I’m using these terms in an idiosyncratic way, but the basic thing I’m trying to convey is:

We have constructed much of our society around particular forms of output; the student’s essay is the form. Often the form is the only thing we formally identify (Seeing-like-a-state metrics: the forest we can measure is the only forest we care about; the student essay we can grade is the form and stands in the place of the learning we can’t measure).

However, the thing we actually want is the function that the output performs; we want the student to learn (or to be more employable) and often the reason a particular form has been settled on is that the form and the process of creating the form happens to bundle together multiple functions in a way that serves many of our needs simultaneously. One particular example: bargains between labor and management hinge on the coincidence of several competing needs in one common process. Another: laws are constructed so that the various side effects that the passage of the law and the enactment of the law bundle together.

Often the thing that actually performs that function is the process by which the form is created. Rather than the fixed artifact (which is easy to view and measure and remember) the thing that gets us what we really want (or think we want, or truly want) is the enactment of creation rather than the result at the end.,

The thing that we’re observing today is that, as the sea-change happens and we have new ways of creating particular forms, the generation of the forms may only serve a subset of the functions that the original form gave us, because the process was the valuable bundling of our negotiated needs. Today, we’re seeing a delamination, as the various substrates that were bundled together peel apart. We’ve unbundled the cable channels, and now what we get and the way that our collective cost works has unraveled.

This affects different people and groups differently, causing skewed outcomes. It advantages the people who are pushing hardest for the delamination, at least at first, because they’re actively choosing which of the side effects to keep while discarding the others. It also means that the bargains struck for prior configurations of functions are no longer balanced. This is a significant thing when the current form+process is the result of negotiation (implicit or explicit). One party can continue to hold up their end of the letter of the law (providing the form), but the functions have changed because it was the process that really dictated what the actual functions were.

This can founder when the reason you believed the form worked turns out to not be related to the actual function you wanted. It also means that you may end up jettisoning side-effects that you actually wanted, or ones that were keeping the status quo in place. Any delamination is going to require a reexamination of prior negotiations.

I feel like I’m repeating some concepts that have other expression elsewhere (alienation? post-commodification as the no-longer-marketable product decomposes?) but this framing has been useful for my thinking, particularly when I have to talk about generative AI and how it is good at reproducing the form of something in exactly the way that elides the function that we actually wanted the process of creating that form to perform.

I’m not convinced that these categories are complete or exhaustive, but they do give me a way to talk about this effect. ↩

The Garden of Forking Paths

2026-01-14T00:00:00+00:00

I think there’s a misunderstanding about Borges’ short story that is mirrored in some of the fundamental misunderstandings people have about interactive narrative (and emergent systems in general). The popular gloss I most frequently encounter when I ask someone what The Garden of Forking Paths is about is that people will say it is about branching. Similarly, when you ask someone about interactive stories, the first thing that comes to mind it a kind of Time Cave¹ branching structure, where branch leads on to branch.

These days, there’s much more awareness of other possible approaches to interactivity and emergence, but I think it’s worth reiterating that Borges’ point in 1941 was precisely that branching was merely the walls of the labyrinth. The novel in question is specifically described as contradictory; “he read with slow precision two versions of the same epic chapter. In the first, an army marches into battle across a lonely mountain; the horror of the rocks makes the men undervalue their lives and they gain an easy victory. In the second, the same army traverses a palace where a great festival is taking place; the resplendent battle seems to them a continuation of the celebration and they win the victory.” The point is explicitly that the branching is contradictory but both exist simultaneously in the same book; branching is one method of constructing the labyrinth but the hyperobject that the story volume² describes holds both branches to be true in a certain timeline and reconciles them to end with the same outcome.

The short story is obsessed with the idea of branching timelines, a kind of multiversal understanding of possible futures. But it hinges precisely on the question of considering all timelines to be part of the same story volume.

[…] This network of times which approached one another, forked, broke off, or were unaware of one another for centuries, embraces all possibilities of time. We do not exist in the majority of these times; in some you exist; in others I and not you; in others both of us. In the present one, which a favorable fate has granted me, you have arrived at my house; in another, while crossing the garden, you found me dead; in still another, I utter these words, but I am a mistake, a ghost.

“In every one,” I pronounced, not without a tremble to my voice, “I am grateful to you and revere you for your recreation of the garden of Ts’ui Pên.”

“Not in all,” he murmured with a smile. “Time forks perpetually toward innumerable futures. In one of them I am your enemy.”

This is making the argument that the branching is the thing of significance, yes? The endless, mutually incompatible futures. Except, wait: all of those times that he describes are, in this story, the same time. Or can be read as such, because in this timeline the protagonist is his enemy and his friend; he will be found dead soon; he has been presented as ghost-like oracle: “His face, within the vivid circle of the lamplight, was unquestionably that of an old man, but with something unalterable about it, even immortal.”

“…In the work of Ts’ui Pên, all possible outcomes occur; each one is the point of departure for other forkings. Sometimes, the paths of this labyrinth converge: for example, you arrive at this house, but in one of the possible pasts you are my enemy, in another, my friend.”

Earlier the protagonist sees himself as already dead, his course irrevocable, inevitable:

I foresee that man will resign himself each day to more atrocious undertakings; soon there will be no one but warriors and brigands; I give them this counsel: The author of an atrocious undertaking ought imagine that he has already accomplished it, out to impose upon himself a future as irrevocable as the past. Thus I proceeded as my eyes of a man already dead registered the elapsing of the day, which was perhaps the last, and the diffusion of the night.

The narrator of “The Garden of Forking Paths” tries to convince himself that the eventual outcome is inevitable; the story leaves it ambiguous because it is precisely hinged on the question of how inevitable the outcome actually was. The protagonist is simultaneously both enemy and friend. The hyperobject contains both possibilities without contradiction, because branching is just one of the structural elements that makes up the labyrinth.

This, I think, applies to many of our attempts to grapple with generative systems, story volumes, and related emergent phenomenon. The fixed points and the ways that the hyperobject converges are often just as important as the divergence points where it branches. The emergent system is precisely the thing that can be observed from the outside, seeing all possible times simultaneously.

Time Cave, as in The Cave of Time the first novel in the original CYOA series. The Cave of Time is very focused on branching; it does include some merging but has become a shorthand for interactive narrative that relies on constant branching. Here’s a diagram; Sam Kabo Ashwell’s blogpost about the book also has a diagram, and contains some further discussion that informed my post. The Cave of Time is really a large number of barely-related stories that don’t connect with each other much in either structure or narrative; Ashwell compares it to episodic television. ↩
The concept of a story volume is the recognition that interactive narratives are made of many different but congruent stories; story volumes are particularly helpful when we try to understand emergent narratives. ↩

It Can't Say Everything

2025-11-24T00:00:00+00:00

The one thing that I think that people are misunderstanding about a language model is this idea that it knows everything and can say anything.

Knowing everything is a deep topic we can get into another time, but other people have talked about it and I’m fascinated by how many people overlook that there are things that a given language model is categorically incapable of saying.

It helps to be able to look at the logits as it is generating. For each token we can observe what options it has to choose from. I can tweak the inference parameters to change the weighting and cutoffs for token selection, but even without that I can see that some tokens are much more likely than others. And some are either effectively zero or actually zero, and will never be chosen. There exist patterns of text that a given model will never output on its own.¹

A view of generated text, with one token highlighted, showing the other possible token choices. This was generated with a relatively high temperature so the spread of possibilities for this particular token is fairly wide but still trails off after the top possibilities. Different sampling settings for inference would create a different curve here, but you can see that there are a lot of grammatically correct words the model isn't even considering here. It also doesn't guarantee that any of the tokens are actually correct.

You can train a model to produce that text, if you know it. You can manipulate the context until it is more likely that a particular sequence appears. But those are going to be at the expense of other tokens, other patterns.

So when I interact with an LLM it mostly makes me acutely aware of how unlikely it is for it to spontaneously reproduce the particular words that I was going to say. This goes doubly for if I’m training a model: the word choices I show it are inevitably going to enrich its vocabulary. The space of possible English utterances is larger than the model ever tries to reproduce.²

This goes beyond word choice, of course: larger patterns are often very biased in LLMs. There’s a deliberate bias in trying to make them helpful and harmless, which has led to sycophancy, a lot of bad prose, a failure to criticize the user, and being a terrible game master.³ Even unintentionally, we have problems with only repeating a few preferred names when asked to name a person, the tendency to repeat cliché phrases and cliché plots, and general unoriginality. It gets worse when we look across people because the people interacting with the model tend to fall into similar patterns while being unaware of just how many other people got the exact same response: this is known as the homogenization effect.⁴

You can overcome some of this through engineering the context and retraining the model, but there’s always going to be some pattern bias in there. That’s how they managed to learn language in the first place; heck that’s how life overcomes entropy in the first place.

Being deliberate about engineering the bias certainly helps in figuring out to overcome it, but I think just being aware that the bias exists in the first place is a big leg up.

For a given model, we can measure the perplexity of a token, which tells us how likely it is that token would be chosen by that model in that context. This gives us a way to tell if a given text was written by a particular model–though AI detection has a lot more layers to it. ↩
Which makes sense, because we trained it with the idea that false positives in terms of vocabulary and grammar are much worse than false negatives. There’s no way to train it on producing every possible valid sentence in the language, after all, so we settle for a subset of them. ↩
Though there has been work done on training models intended to be game masters to be more even-handed or hostile. ↩
Which is a major problem if you were hoping to strike it rich by prompting your way to the next Great American Novel. That won’t get you any new ideas unless you bring them yourself. You’ll have a bunch of ideas that seem new to you but that every other self-published AI author has already generated before you got here… ↩

Respect the Zebra: Vibe Scripting

2025-11-19T00:00:00+00:00

Today I needed a parser for a source file for dynamically composed text.¹ In other words, I had a text file that described a bunch of variations in a one-off format that was particular to this text file. I could write a parser for it by hand, but it seemed like the kind of thing I might be able to hand off to AI. After all, parsers are pretty well-known programming patterns, I could describe the problem pretty well, and I didn’t expect this to become a foundational format that I’d want to keep a robust parser around for. I just needed to translate the source file into a minimal number of permutations. If I could get other things done in the meantime, that’s a win, right?²

I ran it and it promptly filled my laptop’s memory multiple times over, thrashing the disk and causing the whole thing to lock up. First thought: running AI code without reviewing it comes with risks. In this case it might very well have shortened the SSD’s lifespan–they only get so many writes after all. Don’t ship it to production just yet.

Now, I was specifically having it do this in an isolated chat; doing it in an agentic loop where it could see its own output would have simplified the editing process of writing the actual files. The problem was, however, pretty far upstream of the individual token choices: it had picked an algorithm that worked perfectly well on petty test cases and fell over completely when I fed it a text file of appreciable size.

I backed up and rewrote the specifications with some additional bullet points. Letting it pick the algorithm clearly didn’t work. I had a pretty good idea of what I wanted it to be doing under the hood anyway, so being more specific about that might have been a good idea from the beginning. Though it helped to see what the actual problem was in its interpretation of my instructions.

Backing up and taking the conversation in a different direction is, in my experience, usually preferable to trying to tell LLM-based editors to edit things in place; unless you’ve got an actual feedback loop where it can see the evaluation of its own output you gain a lot more by just completely rerolling it from the start. Particularly with models that jump the gun on writing code. That’s why I favor a function composition approach rather than letting the AI write an entire module without architectural guidance.³

Sometimes, of course, you do want to make a minor edit. In that case chatting about the change can be worthwhile. Editing by chatting is a pretty powerful way to iterate and clarify an idea, but in general I prefer to separate the design phase from the implementation phase. Carefully engineering the context before the generation happens is usually the better (and shorter) way to express your needs. Unless the editing-feedback interaction loop is very fast, in which case you are still chewing through context but are more likely to be able to rapidly give effective feedback. For an image that has an immediate sense of what is working and can suggest minor tweaks, that works fine. For programming, where just running the program once is unlikely to test all of the edge cases, your going to want to have tighter control over the architectural design of the thing being generated.

Five rounds of rewriting and regenerating later, I had a script that crashed my computer, a script that said it handled nested dynamic test but didn’t, a script that had a bunch of lies in the readme (and didn’t work), a script that worked but made me realize that my requirements for the distribution were wrong, a script that actually worked until I tried to run it on real data, and a script that actually worked.

I think my takeaway from all this is that it is still all about the ideas that you bring to a project. If you’ve got vague ideas it won’t save you from them (but might help reveal that they’re weak ideas, if you are willing to listen). If you’ve got a clear sense of what you want, or enough knowledge of the topic to see where it went off the rails, then you can steer it successfully.

If you can’t describe what you really want, it is going to give you what you really asked for.

You can think of it as something like Aaron Reed’s dynamically composed text except far less sophisticated, given that it was a one-off format for a side-element in a different project. ↩
Having done this kind of thing before, I did not actually expect to get a lot done in the meantime, though it did reduce the context switching that I was doing. ↩
Again, this is somewhat different if you’ve got an actual agentic code editor set up, but this whole thing was intended to be a one-off script and I already had too many other windows open. But it does highlight how treating the context as a conversation is something of an illusion; I prefer treating the context as a context, which is a rather different animal. Trying to treat a zebra like a horse will just end with you getting kicked in the head. Respect the zebra. ↩

Moravec's Paradox

2025-06-01T00:00:00+00:00

There’s a curious thing about AI that we’ve known for a long time. It’s sometimes called Moravec’s Paradox, after Hans Moravec, though a number of other computer scientists in the 1980s also espoused the idea.

Moravec was writing about the problem of the intelligent robot, “a machine that can think and act as a human, however inhuman it may be in physical or mental detail.” (Moravec 1988, p. 2) One of the things that Moravec discusses (in his book Mind Children and elsewhere) is curious phenomenon that, despite building expert systems that could solve complex calculus problems and chess-playing programs that could, even then, defeat chess masters, their robots struggled to do something as simple as building with children’s blocks or apply common-sense reasoning that would tell it that a bicycle can’t be fixed with antibiotics (Moravec 1994). Researchers had managed to make a computer that could do many tasks that are hard for humans, but had repeatedly been defeated by toddlers at things that seemed trivial. In the artificial intelligence world, hard things are easy, and easy things are hard.

Moravec’s answer was to build robots that needed to see and move in the physical world, and thereby learn intelligence from the bottom up. He predicted a sequence of development of universal robots, starting dumb robots, then introducing learning, then giving them the ability to simulate their surroundings, which give you “neatly organized data about the robot and its world that can be married to a reasoning program to produce a machine with most of the abilities of a human being” sometime around 2040. We’ve made some progress in robotics and the physical world, but the neatly organized progression Moravec describes has been rather upended by the unexpected success of neural networks in the 2010s, back from the dead. We now have something that is a little like the messy bottom-up evolved common-sense understanding that Moravec anticipated, but rather than being based on the directness of the real world, it is instead learned from language and imagery itself.

With enough interaction with this latest incarnation of artificial intelligence, it quickly becomes apparent that the paradox is still with us. The language models are capable of astonishing task generalization but in a way that is often quite spiky: we’ve invented models that can explain calculus but can’t multiply (or spell) and that can (sometimes) play chess at a high level but completely fail to grasp how tic-tac-toe works ¹. The neural net models are spiky, often in ways that are highly counterintuitive. We’re used to being able to predict that if someone is good at one thing, they’re also good at related thing. That intuition is going to betray you. Hard things are easy, easy things are hard.

My original interest in generativity is in neither the easy things nor the hard things. We can already do the easy things (even if the AI can’t). We can already do the hard things (they’re just more effort). But the impossible things that generativity enables: that’s the really interesting place to be.

Biblography:

Moravec, Hans. Mind children: The future of robot and human intelligence. Harvard University Press, 1988.

Moravec, Hans. “The universal robot.” Interdisciplinary Science and Engineering in the Era of Cyberspace (1993): 35.

Structured prompting makes them better, but in general they’re terrible at recognizing what a win condition is in the game, or how to lose gracefully, or really anything we expect a five-year-old child to learn about the game. Language models may, of course, get better at this in the future, but it’s a useful illustration of the spiky nature of the models does not have a linear correspondence to the human experience of difficult tasks. ↩

The Generative Dimension of Existence

2025-05-28T00:00:00+00:00

I’ve been thinking more about the ideas I wrote about in designing the generative dimension and walking through the generative dimension. One of the major things I’m interested in is the shape of this space of possible things: every rule system describes a space of existence, in opposition to the void of non-existence.

Which is basically a bunch of big words to say that some things are possible and some things are not, but I think a lot of the rhetoric of procedural generation–and generative processes more broadly–still misses this point. Practitioners are less likely to make this mistake, of course. I’ve been excited about the academic discussion on information theory, Kolmogorov Complexity, and Dearth of the Author, for example. But I think that it’s worth thinking about how generative design is often about making choices about what should be left out.

A generator can’t make everything; even the big language models that have overrun everything have word orderings that are impossible for them to ever construct. It’s invisible to us, because we can see how the language allows us to say this thing or paint that picture or do this sequence of actions, but the generative process might very well have a gap there that’s invisible to us. Perlin noise is never going to have a straight line carved down the middle.

You can try to go Library of Babel and construct an exhaustive space of every possible configuration of letters–but that becomes its own problem. Yes, technically there exists a book in the Library that, when properly decoded, results in the exact information you were looking for. But the decoding method itself contains information.

A generator, therefore, is a statement of existence. This thing should exist. That thing should not. The rules describe a shape of existence. Researching generativity is an investigation into the rhetoric of existence.

Catboxes and Umineko

2024-09-02T00:00:00+00:00

A while back I co-wrote a paper on Umineko no Naku Koro ni.

The ultimate origin was that I had a lot of time during the pandemic to play an eighty-hour visual novel while simultaneously trying to solve the murder mystery with my housemates, but the point of the paper was that we saw a connection between the concepts of the game and the discussion of story volumes that had been happening around the same time.

You might already be familiar with a story volume even if you didn’t have a name for it. A story volume is “a family of emergent stories, all of which are begotten by a set of carefully curated system parameters” or, in other words you’re playing a game and there are many possible storylines that could happen, but there are also storylines that could not happen. The rules that create the emergent stories exclude as much as they include.

More importantly, we want it to be the case. The shape of the story volume is as much a part of the experience as any of the individual storylines. Some things are impossible and never happen in any storyline, some things always occur in every storyline. Discussion of interactivity often centers on what changes in response to the player, but often the most impactful moments are precisely the ones that don’t change. And some of that impact is because other things do change.

Umineko has a lot to say about this, but one useful bit of terminology inspired the paper: the idea of the catbox. Schrödinger’s cat is both alive and dead, and all of the storylines in the story volume are both alive and dead.

Related to this, one aspect of Umineko that I particularly like is that the catbox nature of the narrative means that we can see the characters from many points of view–I feel like I knew the characters more intimately because I’ve seen what it takes for them to change. And, moreover, what part of their character is immutable, unchanging in every circumstance.

Texture

2024-09-01T00:00:00+00:00

There’s a phrase from Mandelbrot about fractals that stuck with me: fractals are about roughness.

I’ve been trying to figure out how to explain something about the dimensions of generativity that I think is under-explained. Effective procgen isn’t about producing as much content as possible, it’s about producing content with the right texture.

By texture, I mean to invoke the sensation of running your hand across the rough fabric of the generated output. Texture isn’t a formal term (yet) and there might be a better term to use to describe the variation of roughness, but that variation is one of my primary interests.

When people first do something with procgen, they sometimes err on the side of trying to show off as much of what their generator can do as they possibly can. An example: you’ve got a series of things that the player is going to experience with (combat encounters, trees, vfx particle systems). You made a lot of them by hand, but you want to randomize the player’s experience of them while avoiding repeats.

First move that many designers make is to treat it like a bag of marbles or a deck of cards: put the content-marbles into the bag, draw marbles at random, replace the marbles when the bag is empty. This guarantees that the player experiences everything at least once, without being able to predict the order, and without repeats (except at the transition between bags). Where’s the problem?

If you’re familiar with Tetris randomizers you might be thinking of the issues with the human perception of randomness, but in my experience that’s less of a problem with very unique content. No, the more immediate problem is twofold: the first time through, the player will have no idea that the content is randomized (how can they? they’ve never seen it before!).¹ Then, the second time through, the order is unpredictable, but they’ve seen everything already.

You’d hope that the unpredictable order would make it more interesting, but it can end up feeling very flat; just one thing after another. You can make it less flat by having some of the content marbles be uniquely different, but that works by creating texture along another dimension. The result can devolve into waiting around for the spiky landmark result.

Sometimes a flat pacing is fine; Annals of the Parrigue’s principle of mushroom emphasizes that there’s nothing wrong with repeating slightly-varying content. Sometimes it is perfectly fine to have expected-but-random content. But you can also go for more interesting textures. Weighting the marbles in the bag to make some outcomes rare enough that you won’t encounter them for a while can keep the experience fresh. Repeating low-importance events can make the bigger shocking ones really stand out, while paradoxically making the repetitive events seem like they’re just a natural part of the landscape. Grouping content into related bundles is another way of adding meaningful texture, this time through constraints. In either case, the texture is rougher and more interesting than the smooth, frictionless experience that tries to over every possibility fairly.

The tree/forest/orchard distinction that I’ve talked about is related to this; is your focus the uniqueness of the individual artifact, the slight variations between similar artifacts, or the overall experience of the gestalt across all of the artifacts.

There’s a lot more that could be said about how to use texture for more interesting procgen.

There are ways to have people realize they’re interacting with a procgen result the first time around, but that takes some deliberate design. Or explicitly telling them up-front. The easy way is just to have a short enough content loop that it is obvious that things are different this time, which is one of the many reasons why procgen is so effective in roguelikes. ↩

Games with Friction

2021-04-07T00:00:00+00:00

Some games work better with more friction. As part of my investigation of very-long-form mechanics in roleplaying games, I’ve been playing Pathfinder Kingmaker, and as a side effect I’ve been contemplating whether the kingdom management part of the game would be as engaging if it was in a game by itself.¹ On a practical level, could you use a paper prototype to accurately judge how fun the pacing would be when implemented in the full game. I wonder if the degree to which energy mechanics tended to be just roadbumps to generate revenue at the height of the mobile free to play boom has caused me to overlook the many times making a game slower and with more friction makes it more interesting.

A game being too slow is a pretty common probably in early development, because there’s a lot of ways to create roadblocks. But flow is also hurt by things being too fast or too frictionless. You need time to slow down and actually get attached to a particular element. A fire hose of content is going to wash all the meaning out of the individual drops.

Which leads me to the thing I’m curious about right now: how can you prototype something that has a long gap between moves and still get a sense for how it will feel? There’s presumably some paper prototyping practices that can help with this, but I wonder what approaches slow games have used to test their designs. If you are designing a game like VESPER.5 or The Longing, how do you get a feel for the pacing?

–

Yes, I am aware that it’s based on some of the supplements for the tabletop RPG. In completely unrelated questions, why has no one made a computer RPG for The Great Pendragon Campaign? ↩

Concrete Interaction Visibility in Game Interaction

2021-03-23T00:00:00+00:00

One of the key aspects of the immersion in the original Thief was that the visible geometry matched what you could interact with more or less directly. This was, admittedly, easier when the average level seldom went over 400 polygons on screen. But the things that the player can interact with are visibly delineated: you can see exactly which surfaces the rope arrow can be anchored to as a feature of the world properties, not as something the level designer had to customize or call out.

Which is not to say that collision volumes are bad–far from it! But the further that a virtual world gets from that one-to-one relationship, the more that an expert player will filter out. Watching me play Atelier Ryza, my friends can distinguish what is allegedly real (the sparkly collectable ingredients) from what isn’t (the non-sparkly decorative plants that you can’t interact with). I can ignore things that aren’t sparkly, and therefore I stop looking at what things look like and start concentrating on the interact-with-me glows.

Nier: Automata carefully positions its interactions to be as real as possible, within its limitations. Although its horizontal collision volumes are sometimes larger than the ruined building, its vertical collision planes are very precisely aligned so that the visible appearance of most jumps is completely honest about where you need to land to make the jump.

So each physical interaction in a game exists on a spectrum from more concrete to less concrete. Though the players’ perception of the interactions is shaped by the density of the concreteness of the surrounding interactions: a resource-bearing tree in Atelier Ryza is quite concrete, but since the other trees in the forest are only there to be immutable collision volumes it stands out. Minecraft on the other hand, has a world that is almost completely composed of concrete interactions.

Participation in Imagination

2021-03-20T00:00:00+00:00

One consequence of the focus on the ‘game’ part of videogames has been an identification of game with game that allows the player to exhibit strategy. This extends to board games: even though roll-and-move games have a very long history, they’re often looked down on by strategy gameplayers¹.

Every game means something to someone. This is doubly true for popular games. It makes it very hard for me to dismiss something as an unalloyed bad game, because the people who are playing it and enjoying it are getting something from it. Sometimes the gap between your experience of the game and those who enjoy it is a demographic appeal; in a sense the game isn’t for you because you don’t have the need that it is fulfilling (or don’t have the grounding to feel the appeal of that fantasy). Mismatches in fantasies are common, because fantasies often require some groundwork. One function of the current commercial consumption system is to introduce new fantasies to sell products to fulfill; many fantasies that survive from the past are similar amalgamations of folk fantasies, commercial appeals, and social propaganda, often with their origins forgotten².

But for the moment I want to focus on the other half of the equation: what pleasures and means does the game use to fulfill that fantasy? One approach is to simulate the thing in question in obsessive detail—that’s a pretty common design approach. But there are other ways.

Theresa Tanenbaum has long observed that one thing that games offer is participation.

It is common within the interactive narrative research community to conflate interaction with changing the outcome of a story. In this paper we argue that reimagining interaction as participation in a story opens up an important new design space for digital narratives. “Being in the Story: Readerly Pleasure, Acting Theory, and Performing a Role”, Tess Tenenbaum, 2009.

A game’s fulfilment of its fantasy is often presented as if you, the player, are transported into the game world and are thereafter living your second person life, a la the Choose-Your-Own-Adventure series. You are both the player character and providing the story’s prime mover.³ But, as we can see through many other narrative media, people can enjoy themselves perfectly well by merely enacting (or observing others enact!) the experience of the story. (Or, contrariwise, by being the author but not the protagonist.)

In Playing at the World, one of Jon Peterson’s arguments is that Dungeons & Dragons was ripe for rapid popularity precisely because there were already existing communities of fantasy fans enacting their participatory fantasies through collective writing projects and world building zines. Dungeons & Dragons offered a more intense participation through enactment.

There’s been a recent popular Twitter thread about the history of Candyland. The connection between the game and polio makes sense when you consider that it was designed for three-to-five-year-olds who couldn’t read (but could recognize cards with colors) but were confined to a polio ward by disability, or confined to the house out of fear of the disease. In contrast, the fantasy that the game enacts is the ability to walk.

There is a common misconception that agency requires branching or choices. Agency is about being able to enact the promised fantasy. While games often require a fairly complex computational model to do this for many fantasies, complexity and branching are not strict requirements.

Agency is not simply “free will” or “being able to do anything.” It is interacting with a system that suggests possibilities through the representation of a fictional world and the presentation of a set of materials for action. “Agency Reconsidered”, Noah Wardrip-Fruin, Michael Mateas, Steven Dow, Serdar Sali

Candyland, then does exhibit agency: the fantasy that it fulfils is a straightforward walk through a more appealing world, and the affordances it offers allow the players to enact the fantasy. Tanenbaum refers to this as bounded agency and stresses that it is dependent on communicative competence: the player and the game both need to be able to communicate their intent to each other.

Which brings us back to the beginning: why do people enjoy playing roll-and-move games? They defy a ludic-centered notion of strategic play.⁴ But countless people have played and enjoyed them.

One way to think about this is through the lens of games descended from e-sugoroku, which Nathan Altice and Jared Pettitt have been investigating, particularly by examining how Bandai’s hundreds of Sugoroku games build on this basic model in a variety of ways. One interesting aspect of this is the inclusion of rules that go outside the strict game and pull in the social relationships and player involvement in ways that the mechanics can’t immediately “read”⁵.

A roll-and move game is another way to experience the fantasy the game presents. While strategy games let the player experience the fantasy of a protagonist making decisions, we can equally make games where the player experiences the fantasy as an outside author, an audience member, a performer, and so on. While a roll-and-move game doesn’t have as much detail as a novel, it can be more engaging in some ways (because the interactivity engages more of the senses).⁶

To tie this into the D&D thread, tabletop roleplaying games have been rediscovering the power of going outside the strict rules, on the theoretical level with concepts like Vincent Baker’s fruitful void and on a practical level with what I’ve been calling “open circuit” rules, such as The Quiet Year’s Contempt tokens. I’ve seen reviewers be confused by what the Contempt tokens are supposed to do, since they don’t seem to have a firm connection to the rest of the rules, but the point is that the players complete the circuit, running the game through the entire social context that players bring to the game. The players themselves are a part of the mechanics.

Kawash, Samira. “Polio Comes Home: Pleasure and Paralysis in Candy Land.” American Journal of Play 3, no. 2 (2010): 186-220.

Peterson, Jon. Playing at the World: A History of Simulating Wars, People and Fantastic Adventures, from Chess to Role-playing Games. Unreason Press. 2012.

Tanenbaum, Theresa. 2011. Being in the story: readerly pleasure, acting theory, and performing a role. In Proceedings of the 4th international conference on Interactive Digital Storytelling (ICIDS’11). Springer-Verlag, Berlin, Heidelberg, 55-66. DOI:https://doi.org/10.1007/978-3-642-25289-1_7

Wardrip-Fruin, Noah, Michael Mateas, Steven Dow, and Serdar Sali. “Agency Reconsidered.” In DiGRA Conference. 2009.

There is, admittedly, something understandable about being annoyed when you are repeatedly asked to play something that doesn’t match the pleasures that you are actually interested in, somewhat akin to the feeling of being continually gifted tchotchkes with cats on them because you liked a cat that one time. ↩
Which is a whole other topic, and overlaps with a long-running discussion we’ve been having about historical city builders, ontologies, and the problems with doing research in the children’s section of the library. ↩
I tend to connect this player/character identification to my (possibly naïve) understanding of the development of the novel, with early writers having to justify how these characters are able to communicate to the reader (through e.g. letters in an epistolary novel) and later writers feeling comfortable dispensing with the framing device as an outmoded metaphor, no longer required for audiences to sustain their disbelief. We begin from assuming the protagonist is a player avatar and continue from there, but there are many games that demonstrate that the player/character identification is not required, just as there are novels that demonstrate that the narrator/author identification is not required. (And in both cases admittedly introduce a timeline that complicates the simple just-so linear story I’ve just summarized.) ↩
I suppose to be completionist I should gesture to Roger Caillois’s mimicry, but Caillois casts different kinds of cultures and play on a kind of great chain of gamers, with civilized European people engaging in ludus that exhibits agon, in contrast to primitive societies wallowing in paidea with mimicry and ilinx, so he’s arguably one of the major causes of the blind spot we’re discussing. ↩
Which also complicates Caillois’s supposed distinctions between paidea and ludus. ↩
I wonder if the different ways that people engage with media is partially governed by factors like aphantasia, and that some people have their imaginations more strongly inspired by interactively performing a fantasy while other people are more strongly moved by reading about it or watching a film. ↩

Software Instruments - Research Debt

2021-02-12T00:00:00+00:00

Last week, we talked about practice and performance in a computational medium, using instruments to navigate an artifact space. This week, we use our instruments to play in another sense - to ‘think the unthinkable’, by embedding skill into our representations of and operations on difficult problems.

Next week, we will have our first case study of a software instrument (The Sims 3 Create-A-Sim). In two weeks, the second (a reading of The Wisdom and Madness of Crowds, as if we were porting it to D3.js). After that, we will take a break for revisions.

Research debt, and its counters

At first glance, it isn’t obvious that we have any skill transfer problems in science or engineering. Maybe the problem with math teaching, what makes people afraid of math, is just a problem with math.

Olah and Carter write [1]:

Often, some individuals have a much more developed version of an idea than is publicly shared. There are a lot of reasons for not sharing it (in particular, they’re often not traditionally publishable).

Mathematics is extreme in this regard, because mathematicians have a lot of explanations that only make sense to other mathematicians, and only if that person takes a lot of time to find the background that makes the explanation make sense. (Surprisingly, mathematicians just do this. They aren’t busy with other things, and they can’t be.)

Mathematics has a lot of research debt, in other words.

A community of practice has research debt when its students and researchers know they need to learn some topic X, but the public exposition on topic X is very dense and requires a few years to digest.

This becomes a problem when people keep re-inventing knowledge about topic X, but using a different terminology that is less inscrutable to them. Usually it is specialized to their use case, which angers people who are using the otherwise inscrutable terminology, if they realize it is the same thing at all.

Any topic can be and will be a topic X, but the more abstraction it contains, the worse this situation gets. I’m going to assert that science and engineering contain a large and increasing amount of abstraction, in the present historical moment.

Grounding

Interactive articles are unreasonably effective at cutting through research debt. They are both demonstration, and instructions for a computer to reproduce that demonstration. They are more portable than other forms of software, because they can run in a browser or in a computational notebook environment.

Conrad Wolfram has talked about [2] using interactive articles to tackle mathematics pedagogy, a kind of research debt that every schoolchild runs into, using rich visual output and parameter sweeps.

When Wolfram focuses on the pupil and their notebook of calculations, and how much faster a computer is than a page for this usage, he resides in the parts of the interaction loop. When Bret Victor expands on [3] the idea of representation and direct manipulation of the parameters, he resides in the arcs of the interaction loop.

Nielsen’s notes on Victor continue [4] to discuss the data visualization operations of linked brushing and drilling down. But he is getting at the building blocks of them now, the operational logics* of an interactive article.

The operation of “tying” two quantities together, to form a single linked entity.

The operation of scrubbing a number.

The operation of “searching” over the graph.

See Joe Osborn’s catalog [5] from his dissertation. Note ‘linking’ the scrubbing slider to the parameter, ‘controlling’ that slider with the mouse, and ‘spatial matching’ over the parameteerized space of graphs.

Reproducibility

Many computational notebooks are not articles themselves, but distributed alongside papers, providing a reproducible computational component. It is better to share notebooks than to share scripts because a notebook can encapsulate more of its own environment configuration, and is therefore more likely to run on someone else’s computer. Some scripts (and other scientific softwares) are distributed in Docker containers for this reason.

It is typical to share both software and libraries through a package-management system, such as Python’s pip, Javascript’s npm, or Scala’s sbt (to name a few). Because scientific software written in Python often has non-Python dependencies (such as the Math Kernel Library, or other C++ and Fortran code), the Anaconda distribution of Python has a specialized package manager that can handle such dependencies.

This is one of the software ecologies that makes it possible to share software instruments (including interactive articles) between computers via the internet. The development of HTML5 is another such story. Two decades ago, most portable software depended on Java (in the scientific use case) or Flash (in the explorables use case), neither of which runs in browsers anymore.

Addressing research debt isn’t just a question of software distribution, but also one of computational literacy. The full value of a computational notebook cannot be realized without the skill to rewrite its score (its code) without breaking the data pipeline it describes. Whereas a poorly written article is difficult to understand, a poorly written notebook is difficult to build on.

Olivia Guest describes [6] bad instruments in the professional practice of mathematical modelling, such as a programming language that teaches users to poorly encapsulate their abstractions, and whose entire statefulness leaks immediately into the interaction loop (to my immense dismay as a functional programmer).

[1] https://distill.pub/2017/research-debt/
[2] https://www.computerbasedmath.org/resources/reforming-math-curriculum-with-computers.php
[3] http://worrydream.com/LadderOfAbstraction/
[4] http://mnielsen.github.io/notes/kill_math/kill_math.html
[5] https://eis.ucsc.edu/analyses-and-approaches/operational-logics/
[6] https://neuroplausible.com/matlab

Instrument design

What does it mean to design a ‘good instrument’ which actually reduces research debt, instead of creating it?

We claim that programming skill alone is insufficient to make a software instrument. The shape of its data must be amenable to representation, and there must be a set of actions defined on data of that shape which are sensible. In other words, domain expertise is required.

For instance, an avatar creator instrument such as Create-A-Sim must implement actions in a ‘face space’ of all faces that Sims can have. But it is more sensible to ‘place the eyes’ or to ‘tweak their shape’ than to (e.g.) change the position of one vertex comprising part of the eyelid. Our first case study will consider face spaces and Create-A-Sim in greater depth.

In the case of a scientific instrument, most actions are typical of data science, such as ‘filter for events matching this condition’ or ‘show me a timeline of the remaining events’. However, as an example, nonlinear dynamical systems are a kind of model requiring more specialized actions. These systems consist of a ‘set of rate equations’, which describe the change in a state vector over time. Every combination of parameters and initial conditions may produce a very different traces (i.e. sequences of states taken on by the system).

For instance, one may ‘draw a phase portrait’, which is the plot of one trace of the system. ‘Performing a parameter sweep’ means to step one (or more) parameters by a fixed amount several times, yielding several conditions. The traces produced by the system in each condition are plotted together (usually in layers). To ‘draw a bifurcation diagram’ is similar, except instead of the trace, the steady-state solutions of the system (i.e. a description of the phase space) are plotted together (usually along an axis). These ‘higher abstraction’ visualizations help us to understand the effect of the parameters and their co-dependence with each other, or with certain conditions of the system.

Bret Victor’s interactive articles about dynamical systems visualization not only describe and demonstrate these operations, but they also articulate a vehement criticism of the research debt that has piled up in the terminology of nonlinear dynamical systems. I have just now described some simple tasks in this area of research using a volley of complicated terms.

(It is beyond the scope of this document to consider games with ‘simulation’ or ‘idle game’ mechanics as research instruments themselves. Consider Dwarf Fortress, Crusader Kings III, or Universal Paperclips. In these cases, the artifact is a simulated life-world, and the research debt lies in an ontology of that life-world that may be shared by only one person. See Kreminski on narrative instruments, and Ryan on simulated life-worlds.)

Community-led discovery

Are instruments self-documenting? How does a community of practice remember?

Interactive articles and video games are both generally meant to be widely accessible, functioning as casual creator support tools. [Cite dissertation zine of Kate Compton.] Other software instruments are not only expected to take years to learn, but they may not even be usable without expert instruction.

For instance, it is unreasonable to expect to learn how to play a guitar without ever receiving instruction from a guitar player. At the same time, many expert guitar players are largely self-taught, because they are highly motivated to play with the instrument, and have discovered many features of its expressive range in that time.

In the course of their practice, a guitar player has presumably also discovered many more action sequences that produce noise than produce songs. Where a beginner’s action space may include verbs like ‘press down this string at that fret’ and ‘ready my pick above this string’, an expert will have encapsulated the action sequences they have executed on hundreds of times, resulting in verbs like ‘strum this chord’ and ‘arpeggiate this scale’.

Application programming interfaces (APIs)

Programming languages are software instruments that programmers can use to create software. In practice, it is script libraries (like NumPy and matplotlib) and game engines (like the HTML5 document object model) that are the instruments used to create software instruments.

A script library always consists of methods - certain action sequences that have been encapsulated as their own verbs, - and objects, which are the data shapes those action sequences expect to operate on. Together, these comprise the API of the library.

Through this ‘high-level’ interface, the library functions as a programming instrument. But let’s define what it means to be ‘high-level’, rather than ‘close to the machine’. If a well-chosen library is used in a program, then the score of that program has a lower dimensionality (# free parameters, approximated by # lines of code) than the same program written without those encapsulated library methods. [Cite Kolmogorov complexity here.]

This score is now more useful as a control surface for a programming practice, because it is harder to explore the space of all possible programs when you are busy doing code maintenance.

APIs are as difficult to design as any other instrument, which is why we will consider Data-Driven Documents (D3.js) as an exemplar in the second case study.

Software Instruments - Performance

2021-02-05T00:00:00+00:00

This week is about design space, and its navigation via software instruments. This is the second background section of the series. Next week, we will have the first background section on research debt, which wasn’t meant to be self-demonstrating in its indefinite deferral.

Pens and turtles

Students are often introduced to imperative programming using the Logo language introduced by Papert, which provides a software instrument called a ‘turtle’.

A turtle carries a pen, which traces its movement on the canvas. The turtle can be directed to move forward, or to turn by a certain amount, and to repeat a block of such instructions a given number of times.

It turns out that many remarkable figures can be produced by stringing together these instructions and varying their parameterization. Logo is a prototypical example of a ‘generative system’.

The Logo environment converts a sequence of instructions into a turtle-made drawing on the screen. The programmer converts this drawing into a modified set of instructions, because they are trying to make or discover another form. This execution-evaluation loop (per Norman) comprises an exploration of the artifact space (see Compton on expressive range) of Logo.

Practicing with the turtle

All instruments participate in an execution-evaluation loop, as exemplified in 1963 by Sketchpad (cite Sutherland). The loop is the functional unit in a cybernetic system, which consists of a set of subjects, and a set of arcs of interaction between them. For example, a programmer and their Logo environment together comprise a cybernetic system, because the environment executes the programmer’s expression of their intent (in terms of Logo affordances), and the programmer evaluates whether the thing they intended really happened or if their instructions went awry somehow.

A (cybernetic) performance comprises of an inner ‘practice’ loop, involving the player and their instrument, and an outer ‘presentation’ loop, involving the practice and its audience.

Practices may be improvised (by the player selecting their next action based on the response they anticipate), based on a score (the player selects their next action by consulting a script), or typically combining the two (when the script underspecifies the next action). Performances inherit this property of the practice. In these cases, the player is likely to account for the audience in both their action selection (at the moment-to-moment level of improvisation) and their choice of scores (if they are aware of such choices).

In Reveal Codes, Rita Raley characterizes the navigation of hypertext as a practice with a complex system, one that “functions to separate the digital from the analog”, which is echoed in our distinction between the model (whose instance is an artifact) in a software instrument, and its referent which cannot be represented as data.

(Raley describes ‘performance’ as sequences of actions with a hypertextual instrument but not necessarily an audience, so we will call this sense practice. She also describes ‘practice’ as a form of reading and writing hypertext, implying a long-form conversation within a hypertext community, so we will call this sense performance.)

We can substitute any artifact for Raley’s hypertext, only if it is the object of a software instrument. We will find that this instrument’s expressive range is a complex meaning-making system, as she has described.

Performing with the turtle

What is so surprising about practices - that is, action sequences taken in an interaction loop with the artifact that they describe, - is that they illuminate the ‘grain of the medium’ (cite Barthes), i.e. an attractor structure on the artifact space.

This is most clearly demonstrated by the anecdote about ‘failing quickly’ as a pedagogical method. Those students who were instructed to create one hundred pots over a semester, were creating higher-quality pots by the end of it than students who had focused their entire energies that semester on one pot.

Recall that generative systems, including Logo and similarly ‘rich output’ programming environments, describe artifacts in terms of action sequences written in a domain-specific language (e.g. the turtle’s vocabulary of ‘move forward this far’, ‘turn by this many degrees’, ‘set pen up or down’). We call these descriptions ‘scores’, after the scripts that musicians consult to help them learn a given song.

Musical scores are incomplete, because many inflections and dynamics in the song as it is played are not written down and must be learned ‘by ear’, i.e. imitation of a presently-existing instance of the song, which is transient. Also, scores are partially transferrable between instruments, as it is possible to play a score written for one instrument on a related instrument, but only by skillfully modifying the score to not make it unrecognizable.

We will discover these properties in software instruments later. For now, imagine the difficulty of learning Photoshop without seeing someone’s demo, or of re-writing a Python script into Javascript.

Analysis of turtle-like systems

Emily Short’s characterization of the generative meta-medium (and specifically, her own hypertextual machine collaborator), in the appendix to Annals of the Parrigues, breaks it into the following five complementary lenses (‘aspects’):

Salt, which governs structured processes like crystal growth and tilings.
Mushroom, which governs branching processes like rhizomic growth and Markov chains.
Venom, which governs spiky distributions of semantic weight, like when ‘distribution’ and ‘semantics’ appear in a sentence together.
Beeswax, which governs mass-curated processes and crowdsourced collections.
Egg, which governs singly-curated processes and moments of authorship.

These lenses of analysis apply to instruments, which impose on generative processes enacted with them in related ways. For instace, salt implies structure, mushroom implies self-propulsive energy, and venom implies standout moments. Now think of a generative text which continuously produces utterances that use the same grammatical structure, but which vary in their payload, from ‘blossom petals’ to ‘nuclear runoff’.

By combining aspects and a medium, we have just described a Twitterbot, a kind of artifact described (along with its accompanying creative scene in the 2010s) by Veales and Cook at length. Beeswax seems to describe the ‘like’ count of a generated tweet, while egg describes the choice by someone to retweet it. Salt, then, also describes the predictable layout of the bot’s Twitter page.

We should not be surprised that a characterization of the ‘practice’ (i.e. bot-making) is equally applicable to the ‘performance’ (i.e. Twitter presence), which is another interaction loop inside which practice is nested.

It is not possible to circumscribe the possible action sequences with a given instrument in the abstract. Although practice and theory (which we will discuss next section!) together indicate ‘rules of design’ (goals and constraints on action sequences) that make good artifacts easier to find, these rules are almost never hard and fast.

For example, one affordance of a guitar is to play semitones on the fretboard. Because it sounds dissonant if you play notes together that do not share a scale (a patterned subset of semitones, characterized as a sequence of intervals), so players learn to move within e.g. the blues scale. As long as the key of the song doesn’t change, the player can “improvise freely” over the matching blues scale, meaning that they can choose arbitrarily between next actions that follow the rule without making any mistake. But it is equally important that this rule can be learned, and that it can be unlearned - because it would be very boring to play only one blues scale all the time, and besides, you might want to play in a different key.

With our intuition pump primed in this way, we hope to have motivated a future research project of describing software instruments, whose operational logics serve to navigate the ‘rugged landscape’ of artifact space.

Software Instruments - Definition

2021-01-26T00:00:00+00:00

What is a software instrument?

I am revisiting the definition of software instruments today. I intend to return to the question of research debt next Tuesday, and the remainder of last week’s outline subsequently.

Examples of software instruments

Here are some typical examples of software instruments, starting with instruments for static media (i.e. specifying state):

social media applications with built-in image filters
dedicated tools for 2D content creation, such as raster-based, brush-based, and vector-based image editors
character creators in videogames, especially in games where you ‘build and test’ and/or ‘play as’ the resulting character(s)
text editors

Of instruments for durational media (i.e. specifying state over time):

digital audio workstations, a kind of development environment for audio content
multimedia capture and editing tools, such as Open Broadcast Studio and After Effects
3D software suites oriented toward content creation, such as Maya and Houdini
computer-aided design suites, oriented toward 3D design of physical objects

Of instruments for interactive media (i.e. specifying state and its behavior):

read-evaluate-print loops (REPLs), a kind of software development environment
software development environments built around computational notebooks
creative coding environments with first-class grpahical output, such as Processing and its forebearer, Logo
editors for videogame engines, such as Unity Technologies’ Unity (for their Unity engine), or Bethesda’s Creation Kit (for their Creation Engine), or Bitsy (for Bitsy games)

Of instruments for organizing media (i.e. managing collections of information):

digital index cards, such as Scrivener and Anki
essay-editing software, such as Word and TeX Studio (as specialized text editors)
communal discovery platforms such as Pinterest, Pinboard, Are.na, and Reddit
citation management software such as Zotero, browser built-in bookmarks managers, and the hypothetical Memex
nonfictional hypertexts, such as Wikipedia, certain Twitter threads, and personal Roam Research wikis
digital whiteboards and mind-mapping software (as specialized vector-based image editors, & may map out a hypertext)

Checklist for software instruments

What if your computer program is in zero or multiple of the genres listed above? This questionnaire will diagnose whether it is a software instrument.

Does this program couple a subject to an object in a feedback loop?

The subject must be capable of perception. There must be a data representation of the program input, such as keystrokes on a keyboard or midi controller, otherwise the instrument is not software.

The object must be modifiable by the subject, and this modification must be perceptible to the subject. There must be a data representation of the object’s state which contributes to the program’s output.

Does this program represent the object in a form the subject can perceive?

For example, does this program prefer to express an array of floating point numbers as the samples of an audible waveform, or as the pixels of an image? The correct answer isn’t obvious. Programs may use idiosyncratic formats, and it may not write all memory into its save files. However, the program must interact with some sound API and/or graphics API to drive its hardware outputs.

Programs can be studied at the level of their graphics buffers, as an in-game photographer (‘screenarcher’) might to understand a shader modification, or perhaps through a narrative constructed around a series of screenshots. The object may be a performance, an improvisation, an experience. But programs can also be studied at the level of their save files, which in the case of content creation tools, are likely to directly represent the object (a multimedia artifact).

Can the subject directly manipulate this representation through the program?

Some programs will allow the subject to manipulate the expression of the data representation of their object by clicking and dragging it. Other programs require the subject to manipulate something else (e.g. an array of sliders) and see their object recompiled in real time. Other programs require the subject to manipulate something else, and then press a button and wait to recompile their object. [Not sure whether to use ‘compilation’ from programming languages here, or stick to the generic but nonstandard ‘expression’.]

Indirect manipulation of objects is harder to understand the effect of. It may also be necessary if it is difficult to infer which property is being manipulated, i.e. when the property is emergent. It is easier to manipulate emergent properties indirectly when relevant high-level properties are exposed to direct manipulation.

A digression about hardware and data-bending

The object may, in addition to its data representation, also be physically present somewhere (e.g. a robot). However, physical objects can lose synchronization with their data representation (whether due to communications lag, inappropriate environment, or any other source of unrepresentable events), which degrades the quality of performance with the software instrument to an unpredictable degree.

An analogous state of ‘glitchiness’ occurs when the data representation can be understood as though it were physical in some states, but not others. When a frame becomes spliced into an unrelated sequence of action, or a vertex becomes displaced and weirdly stretches the surface it was part of, the human subject is likely to perceive a problem with the object (as a media artifact), even if the program is still able to operate on it happily.

Negative numbers (if regarded as quantities, but not as rate of change) and imaginary numbers (if regarded as rates or quantities, but not as rotations) are examples of data representations that may or may not be ‘glitchy’, depending on the object represented.

In general, representations of non-‘glitchy’ objects are expected to be points in a rugged manifold that sits in the higher-dimensional space of the data representation. An instrument is more effective in a typical sense if it is good at tracing this manifold, i.e. bad at sampling points that aren’t on it.

On the other hand, there is a wild unknown of possible artifacts located off-manifold that someone might be interested in reaching with other instruments. It is possible - even likely, in the case of scientific theories, - that the non-glitchy referents of such artifacts have simply not been discovered yet.

Software Instruments - Introduction

2021-01-19T00:00:00+00:00

This post begins an essay about software instruments, which will be serialized on Tuesday evenings for the next five weeks or so.

Introduction

We describe software instruments as a family of interactive computational mediums (i.e. game-like artifacts) spanning both toys and tools, which share a representation of an artifact (‘state’ or ‘canvas’ or…) and a set of affordances to manipulate that artifact (‘verbs’ or ‘brushes’ or…). Instruments are open-ended, whether they are used to discover or characterize artifacts and phenomena, as in ‘performance instruments’ and ‘analysis instruments’ respectively.

We observe that skilled practitioners use instruments to navigate design spaces in general. A sculptor may use various wire loops to manipulate their clay, or a pottery wheel. A painter may apply acrylic paint to canvas stretched on wooden boards, or they may daub a stylus against a pressure-sensitive tablet to manipulate a pixel grid shown on an LCD screen.

Software instruments must substitute data structures and modelling constraints for their referent artifact or phenomenon, in place of physical analogues or direct study. The substitution is trivial when a neural network, a simulated behavior, or another kind of artificial life is investigated. Yet objects ranging from portraits of humans, to undersea robots, to global climate systems are also represented in data as simulacra of themselves.

Like portraiture, characterization of a complex system does not demand a one-to-one mapping from, say, molecules to voxels. The intentional choice of brushstrokes, of simplified representation, is itself a source of insight. Both the interactor with a software instrument, and the designer of it, will have in part built the artifacts and phenomena they characterize in this way.

Far from being a lapse of objectivity, this is a fruitful way to build up ontologies that are useful to navigate complex sociotechnical domains. The next two sections of this essay draw on existing design practices, thoughts on the use of, and conversations with software instruments.

Our primary areas of research coverage will be data visualization (as a form of interaction design) and generative narrative design (as a form of worlding). These areas have been applied successfully to scientific communication, game design, and experimental essay formats including explorable explanations and computational notebooks.

Affordance and emergence

From the design standpoint, a software instrument can be said to implement a domain-specific language of interaction, through any combination of keybindings, draggable interface elements, conversational agents, file upload, structured text input, and so on. These inputs may be reframed by the model (as when a Sim paints an image from your files and hangs it in their house), or interpreted by it (as when you direct a Sim to hang up the painting, but they are interrupted by the phone ringing). They may replace other data in the model (e.g. applying a certain file), or act to perturb it (e.g. applying a certain keystroke).

From the interactor standpoint, these different affordances may be combined in ways the designer did not anticipate. The results of an analysis are the skillful result of playing with the instruments of analysis. Therefore, performance - whether from a score, or by improvisation, - is vital to how software instruments are made productive. Written scores and recipes let us understand and exercise the capabilities of a software instrument, in a way that recordings of results alone cannot. We call this capacity that of ‘emergence’ or ‘agency’ in a software instrument.

In the world of small generative models, it is typical for the interactor and designer to be the same person(s). In the world of scientific research, this may initially be true, but no longer after research dissemination or cross-disciplinary collaboration. Thus an issue of reproducibility arises, in the same way that having the same guitar and amplifier settings as a famous guitarist does not, by itself, help you to play like them.

Any expert using computers may find in this essay a discussion of the qualities in an software instrument which facilitate high-quality creative output, especially the suitability of its affordances and its representations to an open-ended set of domain-specific analyses.

Any artist using software mediums may find herein an attempt to describe the ‘conversation’ with a digital ‘canvas’, which we claim as vital not only to producing compelling artifacts, but also to engaging on shared ground with a community of fellow practitioners.

The first part of the background section of this essay will address the specific problem of ‘research debt’, coined in analogy to technical debt by Olah and Carter [1]. Along the way, we’ll critique mathematics pedagogy, learn to tune a platformer game in real time, and discover a better way to code interactive artifacts.

The second part of the background section concerns a case study in shared experiences of navigating (generative) design space, namely the Annals of the Parrigues, written by Emily Short [2]. We will read its appendix, which recounts designing a medium of expression whilst navigating the space it describes, against similar accounts by Vi Hart and Iannis Xenakis.

In the case studies section, we will explore an avatar creation tool from a videogame, and a web-based library for binding data to visual representations.

In the final, theoretical section of this essay, we will introduce terminology for practitioners who intend to develop novel or existing software instruments, and to communicate their results through landmarks, scores, and other methods of orientation in design space using software instruments.

[1] https://distill.pub/2017/research-debt/
[2] https://emshort.blog/2015/12/07/procjam-entries-nanogenmo-and-my-generated-generation-guidebook/

Apologia for Game Wikis

2021-01-15T00:00:00+00:00

Some folks in the community Discord for my roguelike Caves of Qud are heading an effort to write an expansive wiki for the game. As a game wiki apologist, this brings me an immense amount of joy. I recall my experiences with one of Qud’s biggest inspirations, the 90s roguelike Ancient Domains of Mystery (ADOM), and how it was (successfully) pitched to me as a game “so complicated you need a guidebook just to play it”. I spent hours scrolling through the pages of said guidebook, in parallel to my playthroughs but also in tangent to them — first searching for answers to my questions (why was I just crushed to death by my own luggage?) then later enchantedly browsing through catalogs of the game’s myriad secrets (if I put beeswax in my ears I’ll be protected from the banshee’s wail, but getting hit by a fireball trap will melt the wax and cause me to hear her again).

Amusingly, “so complicated you need a guidebook just to play it” reads as critique today; games are frequently judged by how self-contained they are, how effectively they encapsulate an experience inside the bounding box of their rules, how elegantly they unfurl their own secrets. The sort of game that does these things successfully will point to the gaps I, the player, am meant to fill: I might look at an Into the Breach map and not immediately know the solution to the tactical puzzle there, but I know what to solve and how to solve it. I know what the stakes are. Contrast this with an alternative tendency — what Jim Stormdancer called “games as ludic mystery” — where what is unknown is itself unknown. On the Qud team we talk often about a related idea, systems suspense, to describe the experience of maneuvering through game systems that do not make their boundaries immediately known. Instead of deriving theorems from their axioms, these games ask players to discover the axioms themselves.

The modern design ethos, of simple, elegant mechanics that can be internalized in seconds but then played for hours, stands in direct opposition to games as ludic mystery -- games where figuring out how to play them at all is a huge part of the fun. https://t.co/ulANOre6YN
— Jim Stormdancer (@mogwai_poet) January 17, 2019

ADOM and its older sibling Nethack, with their dedication to anticipating every imagined interaction, are both games made in the tradition of ludic mystery. This lineage was broken with the roguelike popularity explosion of the last decade, a phenomenon that saw the distillation of some of the genre’s mutually supportive design patterns (procedural generation, permadeath, player-monster parity) into ludicly unmysterious shells. I’m no purist — this new crop of games are interesting in their own right, and people should make them, play them, call them roguelikes, etc. I’m just taking a moment to mourn what could have been an alternate path to genre popularity based on the oft-neglected principle that feeling bewildered can be satisfying.

I said something earlier about games encapsulating experiences and bounding boxes. One thing games look to do is accentuate the dynamics of the real world by metaphorizing them into a set of knowable rules and learnable extrapolations. Grid-based combat approximates real-life combat. Conversation trees approximate real-life conversations. A “bounding box” game wants to get you fluent in its particular suite of system metaphors as quickly as possible so that you can experience what it’s like speak in them, i.e., to play the game. I imagine a physics-like system diagram of the forces in the game where all the arrows are pointing inward toward this experiential goal. Ludic mystery games, instead of rushing you to fluency, seek to reproduce an epistemological relationship we have with the real world, where knowing things is difficult, boundaries are fuzzy, and horizons are far off. They lean into the idea that knowing itself is protean, erratic, perpetual: a bouquet of arrows pointing in every direction.

How do we become knowledgeable in the vast and messy real world? We do so by a variety of means and tactics, stitching together familiarity and then wisdom from a diverse array of sources. This process is inherently discursive and nonlinear¹. Think of how we click through hyperlinks on a wikipedia page, walk through the citations of a research paper, chain together google search results. Ludic mystery invites us to import this methodology into our play, to melt the magic circle, just a little more than usual, and reach out to the encompassing world for context. Enter guidebooks, wikis, forums, chat rooms, and let’s plays; these are sites on the game’s periphery that enable understanding through discourse.²

You may know someone who, like me, admits to prefer reading about Dwarf Fortress to playing it. I say prefers reading to playing, but reading (or writing) is its own form of play, one that’s fundamentally social — through a series of page views and edits we shape the collective understanding of the game, and in turn the collective shapes each of our own. Wikis are the social stratosphere that surrounds the lithosphere of the game core. Like all cultural objects, the lithosphere itself only coheres into something meaningful through a system of references that necessarily point outward — regardless of whether there’s ludic mystery or not — and so it seems reasonable to think of cruising the stratosphere as play, too. In fact, doing so opens up some interesting design possibilities. Blaseball is a good example, with how it encourages creative interpretation in its stratosphere and then sublimates the results back down into its lithosphere. (Interestingly, the upcoming Neurocracy seems to take the converse approach to this ludic layering, isolating the discursive subject and packaging it back into a bounding box.)

Obviously there are play patterns here that are degenerate. If a game is forcing me to look up an answer on a wiki and then immediately enact it and move on, I’m not crawling the web of collective knowledge in a meaningful way, I’m just doing a chore. And ludic mystery games will flirt with this boundary, because by definition there’s less linearity, less curation, less greasing away the friction. Some of the arrows in the bouquet will point to dead ends. I may even experience what the bounding box designer dreads most: frustration. There’s also the time investment problem. As a 30-something new parent, I appreciate the efficiency of the experience-in-a-box and am increasingly drawn to the idea that games should respect my time. I find myself looking for the escape hatch when a game gives me what feels like a gratuitous amount or type of friction. Nonetheless, despite all the pitfalls, I still crave and relish these experiences of ludic mystery, of righting a bewildering world by gathering its far-flung pieces and fastidiously putting them back together.

Deleuze and Guattari’s rhizome comes to mind. See A Thousand Plateaus for the source, or Manuel DeLanda’s A Thousand Years of Nonlinear History for a more readable application of the theory. ↩
I don’t have the space to get into them here, but it’s worth noting that alternate reality games (ARGs) take this to an extreme, with the knowledge-gathering methodologies of the real world being their only affordances. ↩

The Sense of Scale in Software

2021-01-12T00:00:00+00:00

While videogames are the most obvious kinds of software to deploy aesthetic effect, my first strong impression of the size of a program was in 3D graphics. But it wasn’t because of the infinitely-sized space I could use as a canvas.

The interactive thing that gave me the strongest sense of the program being big was when I clicked a button I’d never interacted with before, despite being a user of the software for years. It opened a new window that I’d never seen, with functionality that I had never used before. This experience has lead me to conclude that the sense of scale we get from interacting with an interactive system is more related to the processes we perceive than in the size of the canvas.

I believe this has some relationship to the sense of scale in procgen. There, the perceived scale of the space of possible generated artifacts is related to the perceived complexity of the system that makes them. Though we don’t yet fully understand the relationship between perceived expressive range and system complexity.

The sense of scale also operates in reverse: sometimes you don’t want to make something that feels big. Sometimes you want small and cozy. Games that take place within a single screen feel smaller and cozier than ones that scroll around a map. Though there are plenty of single-screen games with complex reveals: Nethack by default fits nicely in a standard VT52 terminal.¹ and no one ever accused a Zachtronics game of lacking depth.

Nethack reveals new depths through new interactions and new levels, but doesn’t change the UI. Other games unfold new depth through visible changes to the UI. Like many idle games Universal Paperclips (2017) takes place on one screen, but opens new modes of interaction as the game continues. There’s a relationship here between perceived depth and modes that I’ve been trying to tease out for the past year or so.

Modes in user interfaces have been discussed for a long time in HCI, often in a negative sense.² But modes and other interface elements that unfold to display new information and new processes are one way to make a game feel bigger. That wasn’t a priority for business software, but software that does have an aesthetic goal can take advantage of things that affect the users’ sense of scale.

Crusader Kings 3 should bring back the window that lets me see what the characters think about other characters.

Because it is ported to every system under the sun, Nethack also includes code for scrolling on smaller screens. ↩
If you’ve ever seen a joke about how hard it is to quit vi, that hinges on switching between the different modes of vi being confusing in a way that makes it hard to enter the command to quit the program. ↩

An offer you can refuse

2021-01-07T00:00:00+00:00

I want to create computer programs that engage in meaningful two-way creative collaboration with human users. For this to take place, I think the notion of “offers” is going to need to become more widespread in human/computer co-creativity research.

In solo creative work, you don’t ever necessarily need to articulate what it is you’re trying to make. You can take action in the medium, see what happens in response, and iteratively refine the actions you’re taking in order to produce an artifact that more closely matches your intent. A classic creative feedback loop – and all without ever having to explain yourself.

When another person gets involved as a creative collaborator, though, things get tricky. You can’t just take action anymore – they’ll be taking action too, and if your actions aren’t coordinated, you’re likely to end up with a mess. Some creative forms (like improv) seem at first glance to operate on the premise that action is sufficient for creative coordination and you don’t need to explicitly metacommunicate with your collaborators about intent. But even improv performers do a lot of metacommunication about intent outside of individual scenes. And in most creative forms, effective collaboration involves a ton of dialogue and negotiation about what you want to accomplish, how you want to accomplish it, and why.

There’s something of a gap in existing co-creativity research around the question of how to handle creative metacommunication. In co-creative platformer level design, for instance, the state of the art involves action-level turn-taking between the human and computer system, but creative intent (on both the human and computer sides) is left almost totally implicit. Either you guess at what your collaborator is trying to achieve from their actions alone, or you just learn to treat them as inscrutable and alien. And if they’re doing something you don’t want, you often can’t even tell them not to do it – let alone tell them why you don’t want to do it in terms of the creative intent you’re trying to enact, as you would with a human collaborator. Negotiating creative intent with your machine collaborator (e.g. by deciding together which creative goals should take precedence over others in a situation where they can’t all be fully realized) is right out.

Where existing systems try to handle creative intent, they usually do so by trying to implement more and better ways for the machine to infer what the human intends from their actions alone. This is neat when it works, but not sufficient: insofar as actions speak, they always say simultaneously too little and too much. Not only do actions fail to reliably communicate their own motivations, they also hint at myriad other possible motivations that the person performing the action never even considered.

This is why I’m excited about the notion of explicit offers in creative collaboration. An offer, in essence, takes a tacit inference about intent and makes it explicit: “Based on what’s happened so far, it seems like we’re trying to achieve this overall goal. I could further advance that goal by doing X. What do you think?”

The term “offer” as I’m using it here originally comes from improv, where it refers to any action that somehow “advances” the scene. Generally improv actors are supposed to accept any offers they receive, since there’s no time to deliberate on whether the overall direction implied by an offer is good or not. But here I’m generalizing the concept a bit. A lot of co-creative systems already implicitly provide users with little details that they can either seize on and elaborate or choose to ignore. (Consider, for instance, “extrapolative narrativization” in simulation-driven emergent narrative games.) But crucially, I think an offer is not just a creative action – it’s a creative action accompanied by some explicit means of acceptance or rejection. The structure of an offer not only provides the recipient with something to react to, but also provides the giver with a way to determine whether the recipient is interested in taking the shared creative work in a particular direction. If the system makes an offer and the user rejects it, the system gains information from the rejection that it can incorporate into its understanding of what the user is trying to create.

In the co-creative storytelling game Why Are We Like This?, we’ve been implementing offers via the automatic detection and surfacing of what we call “situations”. First, we query the database for collections of interrelated characters and narrative events that match a certain specified pattern – let’s say the baseline minimum requirements for “love triangle”, or “escalating cycle of vengeance”. Then we present these matches to the user as potential situations, and give them the choice to take an action that reifies the situation in question. Once reified, new actions related to this particular kind of situation are unlocked between these characters: for instance, two characters engaged in an escalating cycle of revenge might unlock a set of actions relating to sworn enmity that enable these characters to act hostile toward one another without any other immediate motivation. But if you don’t want to tell a story that includes sworn enmity, you can also reject the offer and choose to develop some other storyline instead.

In practice, this can start to feel a bit like the palette negotiation that takes place in the tabletop story-making game Microscope. If everyone in your story is supposed to be uncomplicatedly polyamorous, you can reject the system’s offers to help you develop potential love triangle plotlines. But if you’re deliberately delving into the luridest corners of soap opera-space, the system can begin to recognize a pattern of accepted bids in that direction and offer increasingly enthusiastic support.

Note that offers aren’t enough to solve the problems outlined here on their own. The main issue is that they’re too local: they don’t help as much with longer-term or higher-level negotiation of creative intent. For that you need a proper intent language, which I hope to say more about in future posts. But a co-creative system that reasons in terms of offers still represents a big step up from a system that reasons in terms of actions alone.

Gameplay as Language

2021-01-05T00:00:00+00:00

In the opening moments of 2017’s Nier: Automata, the game smoothly transitions between a vertical shooter, a twin-stick shooter, a third-person melee action game, a side-scrolling platformer, and a few other modes. But more than just including a bunch of minigames, it deploys these modes of gameplay as language. Each use of a gameplay type is a statement, about the game, the world it inhabits, and the relation between the actions the player is performing and the ideas the game is communicating.

Minigames are common in videogames, particularly those in the genre valley that hybridizes a JRPG progression structure with third-person action. In the ’90s, one common development approach was to treat each minigame as a bespoke interaction. Final Fantasy 7, for example, frequently interrupts the JRPG exploration and active-time-battle combat modes with one-off minigames: one early one involves fleeing attackers with Aerith while pushing crates on their heads. These minigames either repurpose trigger-based exploration gameplay or have their own custom system (as in the tower-defense minigame). The minigames are largely departures from the main gameplay.

Some games were essentially composed entirely of minigames, with the over-arcing progression structure mostly confined to moving to the next self-contained level. This was also one of the design approaches some CD-ROM video-backdrop games used with games like Cyberia (1995) and Star Wars: Rebel Assault II - The Hidden Empire (1995) swapping between different flavors of rail-shooter levels, puzzle levels, etc. At the extreme end, each level might be its own bespoke minigame, possibly with little code shared between levels.

However, some designers had realized that they could reuse minigames, assembling a larger game out of individual parts. Action platformers such as Beyond Good & Evil (2003) took integrated boat driving, melee combat, and photography with the soup of the ur-videogame platforming and puzzle-solving. The different minigame-modes became verbs in themselves, with the camera being used for both its own wildlife photography minigame and as part of other puzzle-solving.

Alternately, the major gameplay mode can be coerced to create puzzles and minigames that exist within the primary game rules. Half-Life 2 (2004) has many straightforward examples: using the game’s guns and physics simulations, each level is a series of puzzles and encounters that ask the player to use their tools to interact with bespoke scenarios.

A separate strand is fixed-camera third-person games, such as Alone In The Dark (1992) and Resident Evil (1996). While fixed camera games typically retain the same gameplay between scenes, the use of different camera angles for each scene frequently necessitate reorienting to the new perspective. There are some similarities to the theatrical presentation of point-and-click adventure games, but retaining the more direct third-person-action input.

Minigames are a natural fit for the JRPG model: the design tradition inspired by Wizardry: Proving Grounds of the Mad Overlord (1980) separated the dungeon-crawling exploration from the separate turn-based combat mode. It’s a relatively small leap to the idea that any minigame could be used as a combat mode. But the JRPG exploration/combat progression structure wasn’t the only design. Many games incorporated a design of a game-made-up-of-games. A few interesting examples: Cinemaware’s B-movie inspired It Came From The Desert (1989), Sid Meier’s Pirates! (1987), and Danielle Bunten Berry’s M.U.L.E. (1983) and Seven Cities of Gold (1984).

It Came From The Desert is an interactive narrative, with the player travelling around on a map an encountering dialog-tree conversations and minigames that represent various activities. These fed into each other: getting injured in the knife-fight minigame or during an attack by giant ants took the player to the escape-the-hospital minigame (because waiting around to get discharged would take too long and doom the town). Pirates! combines sailing, ship-to-ship combat, sword duels, trading, and so on, expressing each pirate-y activity as a different minigame. One influence on the design of Pirates! was Seven Cities of Gold, which similarly deployed minigames to represent different activities in its Columbus/Cortez simulator. However, unlike the way that Pirates! changed UI paradigms between modes, Seven Cities of Gold often reused the same movement interface: making menu selections while preparing in Spain was represented by a character walking through town. M.U.L.E.’s one-button-joystick UI was an even purer form of this interface-unification between minigames: the players’ character was the interactor in almost every mode, including surveying land, placing the eponymous M.U.L.E.s, and buying and selling during the auction phase.

Because they use a unified interface, the different gameplay modes in M.U.L.E. speak with harmonized voices in a way that other games don’t attempt. Interfaces that would more normally be represented by directly inputting numbers take on new meaning when the player has to physically steer their character up and down the screen to state their buying or selling price.

Nier: Automata’s smooth transition between gameplay modes engenders a similar effect. A transition between over-the-shoulder third-person and side-scrolling interaction without cutting or interruption allows the game to make a diegetic statement about the space the player is moving through. A feeling of architecture and space that would take a great deal of work to feel natural in a free-camera environment is succinctly summarized through the use of a different camera perspective. But unlike fixed-camera horror games, the gameplay context also shifts: without changing the player’s verbs, switching to a side-view perspective also shifts the gameplay to a side-scrolling platformer.

Similarly to embrace of theatrical abstraction in Kentucky Route Zero (2013-2020), Nier: Automata makes the videogame-ness central to its language of interaction. The different modes are deployed consistently. Each gameplay mode is associated with a particular scenario or context: the flying top-down shooter mode requires specific equipment, allowing the player to anticipate it and associate it with its context. By acknowledging that it is a videogame, Nier: Automata can use the different minigame interaction modes as part of the language it uses to communicate with the player.

Departing from considerations of immersion and realism, it is freed to instead ask what each interaction can be used to express. This extends to the usually non-diegetic interface elements. Saving the game is explicitly tied to in-game-world objects (which act as body vending machines reiterating the themes of the self and the sometimes tenuous relationship between embodiment and identity). Characters talk about the system menus. Interface elements are tied to the character’s equipment loadout. By acknowledging that the game exists as a game, the design can incorporate the usually non-diegetic interface details into the player/machine communication channels.

Similar to cinematic language, we occasionally speak of a ludic language¹ or language of play. But this goes beyond a simple verb-action gameplay association and instead treats the modes of gameplay as language units in themselves. The meta-gameplay of switching to a side-scrolling perspective delimits the context for that section of the game: we must now engage with this part of the level through the lens of platformer mechanics, dynamics, and aesthetics.

Not to be confused with Ludic, a Finnic language in the Uralic family. Or with using language in a playful way–wordplay having been occasionally referred to as “the playful (or ‘ludic’) function of language”². ↩
Crystal, David. Language Play. 2001. University of Chicago Press. ISBN 0226122050, 9780226122052. ↩

Welcome to Mixed Initiatives!

2021-01-01T00:00:00+00:00

Welcome to Mixed Initiatives!

These are the notes of the Seabright Camerata, a loose working group of scholar-practitioners in expressive computation. Posts here might discuss anything within the remit of computational media, broadly construed; at minimum we expect that this will probably include such topics as generative methods, interactive narrative, computational creativity, videogames, human-computer interaction, and artificial intelligence.

Partly this is an experiment in group blogging akin to Grand Text Auto, where several of our intellectual ancestors used to post. Partly it’s a place to drop rough pieces of writing that are too long for a Twitter thread but too tentative for formal (academic) publication. And partly it’s just another website, because we like websites and want there to be more of them.

This website is deliberately scrappy and the writing on it is deliberately sketchy. Don’t take it too seriously.

Mixed Initiatives

The Garden of Forking Paths

It Can't Say Everything

Respect the Zebra: Vibe Scripting

Moravec's Paradox

Biblography:

The Generative Dimension of Existence

Catboxes and Umineko

Texture

Games with Friction

Concrete Interaction Visibility in Game Interaction

Participation in Imagination

Software Instruments - Research Debt

Research debt, and its counters

Grounding

Reproducibility

Instrument design

Community-led discovery

Application programming interfaces (APIs)

Software Instruments - Performance

Pens and turtles

Practicing with the turtle

Performing with the turtle

Analysis of turtle-like systems

Software Instruments - Definition

What is a software instrument?

Examples of software instruments

Checklist for software instruments

A digression about hardware and data-bending

Software Instruments - Introduction

Introduction

Affordance and emergence

Contents

Apologia for Game Wikis

The Sense of Scale in Software

An offer you can refuse

Gameplay as Language

Welcome to Mixed Initiatives!