User Stories, Being Able To Do, and Philosophy

I just encountered something so delightful that I wanted to share it. As I thought about who else would enjoy this, I realized that it may just me. I decided to share it here on the blog in hopes that I forget it, search for it, and find it again later. (It wouldn't be the first time that has happened.)

I guide students through a lot of user story analysis, including but not limited to games-related courses. Years ago, I noticed a tendency for them to write a user story statement like, "I want Mario to be able to jump." I am pretty sure I also used to write them this way, too. At some point, it dawned on me that players don't want Mario to be able to jump: players want Mario to jump. Once I realized that, I saw the strangely passive "to be able to" in practically all of my students' stories. I've been on the lookout for this structure ever since, finding it akin to passive voice in prose: best to be eliminated.

This morning, I found myself reading a part of the Summa Theologiae as part of research into classical definitions of vice and virtue. In it, Aquinas tackles the question of whether a vice is worse than a vicious act. His response, in Sum I-II, 71, iii, co., includes the following.

For it is better to do well than to be able to do well, and in like manner, it is more blameworthy to do evil than to be able to do evil.

There you have it: a classical argument against the passive "to be able to" in user stories. 

Notes from Cal Newport's Deep Work

Some time ago, I had two people recommend Cal Newport's Deep Work to me in the space of one week. In fact, one of the two people assumed I had already read it. This was enough for me to put it on my reading list, and I got to it this past summer.

One of the delightful surprises early in the book is that Newport is a Computer Science Professor at Georgetown. Knowing nothing about him nor the book before getting into it, this was fun to come across. Although I haven't met him, I am happy that he's been able to find success in both technical research work and mass-market work like Deep Work. That said, I find myself wishing that Deep Work was written with more academic convention, including specific references at the points they are needed. Instead, references are given as notes in an appendix, but I don't know what that gains. By contrast, I am currently reading Edward Castronova's Life is a Game, which is very accessible but does not shy away from being specific about its citations. (More on that book another time.)

The premise of the book is that real value comes from deep work, the kind of work that requires focused attention and time to make progress. Newport pulls in a foundation from performance psychology to support this, pointing to Ericsson's deliberate practice as critical scholarship in that area. Deep work requires expertise and insight that is idiosyncratic and cannot be automated nor replaced. Newport acknowledges the value and role of shallow work as well, but he recommends establishing a shallow work budget so that it does not eat into deep work time. He recommends 30-50% as a reasonable budget, especially since the research indicates one cannot get more than four or so deep hours in a workday.

Newport cites Hoffman and Baumeister's Willpower, which reports on their finding that people have a finite amount of willpower that is depleted as they fight desires throughout the day. They point to routines and rituals as methods of sustaining or automatizing willpower in the face of desire. This section of the book has stuck in my mind, and I find myself ruminating on willpower as a diminishing resource in my family life, my work life, and as a game designer. 

I am intrigued by Newport's discussion of David Dewane's architectural conception of an office space that maximizes deep work potential, which he calls the Eudaimonia Machine. Details can be found once you search for those terms. The idea is that the space is a progression of depth, including intentional movement through inspirational spaces, from communal toward individual. I am not surprised at its monastic qualities, but I do not know if Dewane has discussed this connection or not.

Newport bookends his own work days with startup and shutdown routines. The last few work days, I have tried his startup routine: blocking out the day's hours, populating regions from my task list, updating the schedule to deal with unexpected twists in the day, and annotating blocks where deep work has happened. So far, so good. I've been doing informal estimations like this for years, and so my days have worked out pretty much as intended. Doing this deliberately has made me consider prioritization more explicitly than I would otherwise. 

What I have not done, and what I have never done well, is have a shutdown routine. Newport's involves a final email check, managing the task list, making rough plans for the next few days, and then stepping away until the next day. Deep Work gives me a name for a problem I am sure we all regularly face: the Zeigarnik effect. This states that incomplete tasks dominate our attention. They sure do. Even in the few days I've been trying the startup routine, I have had more than one case where I "check my email" only to find messages that then impose a drain on my attention. (I need to take my own medicine here. I regularly tell my students never to check email, only to process it.) This leads to my most significant Achilles Heel: a unified inbox. I decided decades ago to manage one inbox for all my messages so that I could always find what I needed. The problem is that personal and business messages both end up in the same place. When I'm looking for an update on a Kickstarter board game, I don't want to find a request to serve on a committee. The other side of the coin, though, is that if I'm looking for information about that board game and one of my students has problem that I can mentor them through in two or three sentences, I don't mind helping them out. Unfortunately, there's no way to eat this cake and have it too. It is an experiment I wouldn't mind running, but changes in provider interfaces would mean there is no going back.

Several concepts in the book had me reflecting on the weirdness of higher education, particularly public higher education. (Newport is surprisingly mum about the problems of academia, something that must have taken great restraint.) One such concept is the Principle of Least Resistance: "In a business setting, without clear feedback on the impact of various behaviors to the bottom line, we tend toward behaviors that are easiest in the moment." The bottom line at a state university is so far removed from faculty's daily activity that it is rarely discussed. Newport also has a lot to say about the dangers of "network tools," which seems to mean any electronic communication medium but is especially focused at social media. Here, he describes the Any-Benefit Approach to Network Tool Selection, which argues for using any network tool if it will provide any benefit at all, regardless of cost. This is another trap where academia is particularly prone to capture and for similar reasons. 

Regarding network tools, it is an oversight when he lumps blogging in with the likes of Facebook and Twitter. He treats blogging as if it is to build an audience, but there are many of us who do it for ourselves. Someone told me years ago, and I have found it to be true, that doing writing work in public encourages quality and clarity that could otherwise be illusory. (Indeed, it took me a few minutes to get that very sentence how I wanted it.)

Newport mentions Covey's The 4 Disciplines of Execution, a book that addresses how execution is harder that strategizing. The titular disciplines are: focus on the wildly important; act on lead measures; keep a compelling scoreboard; create a cadence of accountability. ("Lead measures" are in contrast to "lag measures." An example of the latter is customer satisfaction, while of the former, free samples given out. You control the lead measures directly and the lag measures follow.) It is no surprise that these align with agile software development practices, but I should keep this in mind should I end up in conversation with someone from the College of Business and we're looking for common ground.

The author's "Law of the Vital Few" is his spin on the 80/20 Rule or the Pareto Principle. His advice regarding it is surprisingly practical: if you are working toward a goal, and you're not in the effective 20%, then you should consider choosing a different goal. There's a business orientation here that may be valuable, but as with the discussion of network tools and blogging, it is also dangerously reductionist. It may just be my strange position as an academic, but it seems to me that one ought to consider one's intrinsic motivation, satisfaction, and sense of purpose in addition to measuring external factors. Some of my best academic works have zero or few citations and won't move the needle on any discussions, but I am a better person for having written them.

The last nugget I would like to share is Newport's heuristic for distinguishing between deep and shallow work. It surprised me that this came so late in the book. Yet, he presents it as a self-test, and I struggled to find the right answers, so there must be a wisdom to his placement. His heuristic (spoiler ahead) is, "How long would it take (in months) to train a smart recent college graduate with no specialized training in my field to complete this task?" Knowing that experts can only maintain about four hours a day of deep work, this heuristic can be useful in scheduling to ensure enough deep work gets done.

These are my notes and not a review, but everyone I've talked to about the book has asked, "Is it worth reading?" I think that if one is looking for tips on improving personal efficiency, then it is worth it. The book is breezy, and this comes with the necessary caveat that complex ideas are treated superficially: one has to recognize that to really understand, say, willpower as a diminishing resource, one would need to take a deeper dive into it. Newport's motivating principle is true: that deep work is necessary and valuable, and that one can learn to do it better. I think it would be worthwhile to combine a reading of Deep Work with something to remind ourselves that joy will never be found in the pursuit of success.

Mulberry Mead

It's time again for What is Paul Drinking? Today's notes are from my latest batch of mulberry mead, which I mentioned in my notes about making lattes. I think this is my second batch, with my first having been made in 2022. I found a bottle of 2022 in my cabinet, and if I've made other batches, they are lost to time. 

I put about a quart of mulberries into a saucepan with enough water to cover them. I cooked them a while to soften them, then gently muddled the berries, turning the water into beautiful purple. What I should have done (and what my wife recommended I do) is get as much juice out of the berries as possible then just use that in primary. Instead, I had the idea that I wanted the whole berries in the fermentation. I put all the solids into a mesh bag and dropped it into my usual mix of three pounds of honey and D47 yeast.

Unfortunately, the bubbling action of the fermentation lifted the bag right up and out of the water. In retrospect, that is predictable. I would have needed to use some weights to keep the bag submerged. However, I only wanted to keep the fruit in the fermenter a few days, and if I submerged it, it would have to stay until racking. In short, I had made a problem for myself.

Next time, just smash the juice out the berries and use that. 

In any case, the result is a lovely color. It has a subtle berry flavor, which I understand to come from the fact that the fruit was added in primary. It's quite different from when I infuse a mead with fruit, which picks up the fruit flavor more intensely. It also came out quite dry. Sometimes that is what I want, and sometimes I add just a splash of simple syrup to the glass before drinking. That's much simpler than formal backsweetening with no danger of exploding bottles from restarted fermentation.

Summer course revisions 2024: CS222 Advanced Programming

I made a few significant structural changes to CS222 for the Fall semester. The course plan has just been uploaded, so feel free to read it for the implementation details. The motivation for all the changes was the same: reduce friction. The course has always had a lot of stuff going on in it, and students seem less able to manage this than they could in the past. For example, it used to be that I could explain triage grading such that most of the students understood it, but students become more brainwashed into the LMS way of running a class, they become less able to conceive of alternatives.

I decided to use the same grading scheme in this class as I am trying in Game Programming. Each assignment will be graded on the scale Successful, Minor Revisions Needed, New Attempt Required, or Incomplete, following Bowman's case study. The EMRF approach that I tried last year did not work, and I am hopeful that this alternative alternative will patch some of the leaks. I considered breaking down the CS222 assignments into individual goals, as Bowman does in his math courses and as I have done in Game Programming, but I found it to be unnecessarily complicated to do so. Instead, I have taken each day's work and consolidated it into a single assignment with multiple graded parts. I hope that this, too, simplifies the students' experiences.

I am still using achievements, but I have changed how they are assigned and assessed. For many years, I have had an open submission policy, where students can complete achievements at any time, and their final grade is based on the quantity and quality submitted. This gave students one more thing to manage, and it was something that could not easily be represented in Canvas. My wishing that students didn't delegate or subjugate their planning to Canvas won't change the fact that they do. Hence, I'm just asking students to do three achievements during the semester. It will be like choosing an assignment from a menu. Since they are otherwise a normal kind of assignment, I don't need special policies for resubmission, either. Maintaining this parallel structure between achievements and assignments also made me remove the star system evaluations. Previously, students could claim one star through self evaluation, two through peer evaluation, and three through expert evaluation. I love the idea of having students review each others' work in this way, but in the name of streamlining, I have removed it. Since I don't have this kind of peer evaluation on other assignments, I am going to remove it here as well.

From the beginnings of CS222, I have used Google Docs to manage submissions so that students can see and comment on each others work. I used to spend time in class doing more peer review in this way, but this got cut out as new "content" was added to the course. Google Docs stayed as a convenient way for me to see student work and especially for students to do the peer reviews required for achievements. Taking those away means there's no real good reason to make students go through the process of submitting through Google Docs. As students' general computing literacy has declined, I have had more and more trouble with students understanding how to use Google Docs and the browser according to the instructions. Now there's no reason besides tradition to keep it, so out goes Google Docs.

I still want to keep my course plans online and publicly available rather than having them stashed away on Canvas. However, my old approach to managing the course site as an SPA made it impossible for me to link directly to specific parts of a document. Somewhere between .htaccess configurations and shadow DOM, I could just not make it work. This was especially frustrating since this is so simple in vanilla HTML: just link to a named anchor. With the change in how I am assigning and evaluating work, I decided it was time to make this work. I have spent about two work days fighting with web development and finally ended up with the solution you can find on the course plan. I have kept lit html and Web Components because of the powerful automation tools they provide: I can define the data of an achievement, for example, and use Javascript and HTML templates to generate the code that displays it. I have stopped using the open-wc generators and npm. I looked into trying to use the open-wc generator and rollup without the SPA configuration, but it turns out that the instructions for doing this are not up to date: they produce a conflicting dependency error. Hence, I just went with a simple deployment solution that copies my source files and a minified JS lit-html library to the web server. Even though I already wrote about my frustrations with maintaining my Game Programming site, and how they led me to migrate the site to GitHub, I am thinking about revisiting that decision based on the work I've done to get the CS222 page working properly.

O teach me

I recently read Romeo & Juliet for the first time since the early 1990s. I was struck by this particular line by Romeo in Act 1, Scene 1:

    O teach me how I should forget to think

At the time, he is smitten by unrequited love, yearning for a woman who he has convinced himself will bring him complete joy. It inspired me to make this.

UPDATE: A friend's commentary on this idea was too brilliant not to pursue, so here are a few more for the album. Maybe I will make up some T-shirts next semester.

I wonder if one even needs Benny on there? It would probably work just as well without. Here's a set you can use for your own satirical ends.

Thoughts on Koenitz's "Understanding Interactive Digital Narrative"

Harmut Koenitz's latest book, Understanding Interactive Digital Narrative, quickly establishes itself as being postmodern and political. I am grateful for his overt framing, although significant portions of the book contradict the tenets of moral relativism and subjective truth, as I will discuss below. Whether populism truly is a "cancer" that only leads to violence and trouble does not come up again in the text beyond the introduction.

A primary contribution of the book is Koenitz's System-Process-Product (SPP) model for analyzing interactive digital narrative (IDN). SPP recognizes that the system is created by the developers, that it is reified through a process of user interaction, and that this results in a product, which can be the discourse about the experience or a recording thereof. SPP includes a "triple hermeneutic" that users would bring to the experience, recognizing the interpretation of possibilities for interaction, the interpretation of instantiated narrative, and the reflection on prior traversals, which entails using memory from prior traversals. The explanation of SPP draws explicitly on familiar concepts from object-oriented software development, describing how IDN systems are instantiated through interaction as being like how objects are instantiated from classes. I remain surprised that this model would be considered revolutionary since it is exactly how any reasonable game developer would think of their work: design ideas are captured in code and assets; the player interacts with the dynamic system; and as a result of that experience, players can talk about it or share their playthrough.

Koenitz brings up the cautionary tale of Microsoft's Tay, the chatbot that was taken down after only 16 hours due to its absorbing and then repeating racist content. In a book that is otherwise about the boundless potential of IDN, the author here exhorts the reader that there must be protections in place to prevent IDN from exhibiting such behavior. This reveals a significant gap in his analytical model. SPP has no affordance to talk about morals and ethics outside of a participant's or scholar's subjective interpretations. The analytical framework in the text lacks the epistemological power to claim that any player activity is ethical or unethical. The claim that some interactions are universally unethical reveals that the author is using a different interpretive lens than the one he describes.

I appreciate his lengthy treatment of the narratology vs. ludology wars and its numerous references. I transitioned into games scholarship when this conversation was cooling. Koenitz's claims that the ludologists' primary mistake was narrative fundamentalism. Because they believe in only one kind of narrative, they misunderstood the narratologists, who had special knowledge of the avant-garde and multiplicity of narrative forms. I am not conversant enough in this literature to support nor critique his arguments, but the unyielding insistence that the opposition has no merit leaves me wanting to hear a bit more from the other side.

The book includes a discussion of the interpretation of Bandersnatch. He explains how interactors have created different mappings of this IDN's formal structure based on their experience, pointing out that none of them are "the structure of Bandersnatch" but rather are each "an interpretation of the structure of Bandersnatch." He also claims, however, that "unless the original design documentation is released, we cannot be sure, and therefore different interpretations of the underlying structure exist." 

Two things struck me about this claim. The first is that he presumes the existence of an authoritative and correct "original design documentation." This seems like the same fallacy that desires design bibles in games and BDUF in software development. My experience is that there may be some original design documentation but that the design-as-such is only definitively manifested in the system. Anything that specifies the possible player experiences at the fidelity matching actual player experience is homologous to the system itself. (Incidentally, one of the reasons most of my projects are released as open source is to allow the curious to study the actual system and not just interpretations of it.)

Second, there is a contradiction inherent in defending the recognition that Bandersnatch has a structure and that all interpretations are valid. He states that the differences in mappings "do not mean that any of these interpretations are wrong in absolute terms, but rather that we need to be aware of their epistemological status as post-factum interpretations." How can the interpretations not be wrong and yet the difference in interpretations be contingent upon the original design documentation not being released? That is, there is an implicit acknowledgement that there is an absolute and authoritative structure, and that these interpretations are approximations of it, such that if one had the former, some of the latter could be shown to be wrong. It is possible that a commitment to postmodernism requires one to admit the viability of demonstrably-wrong structural interpretations, but if that's the argument here, it's awfully subtle. If there is a difference between someone's structural analysis of Bandersnatch and its actual structure, then that means that it can be demonstrated with formal analysis or automated tests. I would call that interpretation of the structure "wrong." Aside from this engineering-design perspective, one can see the problem from the lens of constructivism: the interpretation yields a non-viable mental model because it makes incorrect observations about the world. It reminds me of Koster's point about Monopoly: you can use house rules all you want, but you have to acknowledge that you're playing a different game with the same pieces. If someone's model of Bandersnatch leads to contradictions against the actual thing, then it's either wrong or it's a model of something that doesn't exist.

Koenitz uses a cooking analogy to distinguishing between the prescription of a recipe (a specification) and the description of food (a product of the experience). It's a reasonable metaphor, but here is where also writes, "Far too long have we tried to learn how to cook from descriptions of finished meals." There is no referent for "we," but I don't consider myself included. When I decided I wanted to get better at making games, I didn't turn to descriptions of games: I turned to the writings of people who talk about why and how to make games. Indeed, it's hard to imagine how one could expect to get better at any art form by only looking at descriptions of experiences of that art form. Who is "we" then? He must mean "my community of IDN designers."

The penultimate section of the book provides advice on how to design IDNs. It is what any seasoned designer would expect, and it repeats what has been documented in countless books on video game design: specify goals, create prototypes of increasing fidelity, produce the software, and test. This is the conventional production process that has been talked about in games since at least Cerny's Method talk in 2002 and well before that in user-centered design. The approach is so well established that it allows scholars like me to interrogate it to determine where agile software development methods can improve it.

Reading Understanding Interactive Digital Narratives helped me understand both IDN and the community of IDN scholars. I learned some new ideas from it that will certainly be helpful in my thinking and writing, including narrative fundamentalism, narrative ambivalence, and the cognitive turn in narratology. I applaud Koenitz for his insistence that precise definitions of words like "story" and "narrative" are necessary and that lazy or colloquial use holds back progress. Indeed, I respect that he doesn't insist that people use his definitions necessarily, but that one has to define their terms in order to ensure that they are understood. I believe the SPP model will provide a useful starting point for learners who wish to analyze IDNs, including games, especially those learners who don't have a background in systems design. However, for my students who want to get better at writing for games, I will continue to recommend Bateman's collection.

Representing character damage through loss of skills and equipment

I was surprised to come across two recent tabletop RPGs that both eschew "hit points" as a means of representing character damage: Lester Burton's Grok?! and Runehammer's Crown and Skull. Neither cites the other nor any common inspiration, which makes me think that there's an interesting games history project hiding in here: is there a common ancestor or is it convergent evolution?

In Grok?!, the player has seven resource slots that can hold items. When a character suffers duress, there are a few possible outcomes. The player may choose to create, remove, or change one of their items, or they may take a condition that uses up a resource slot. These are intended to be temporary, but if a character has no more slots, then the character is incapacitated and the condition instead becomes a permanent trait. A player may also voluntarily add conditions to their character in order to roll additional dice after failing a check. Grok?! is clearly a story-focused game, using an elegant universal resolution system that invites creativity and narration.

Crown and Skull has an intricate point-based character-creation system in which players determine a character's skills and gear. Taking damage involves crossing off skills and gear, which is temporary, and sometimes destroying gear, which is permanent. Damage is classified by whether it targets skills, equipment, or both, and it is further classified by whether it is a random target or whether players choose. Runehammer describes this as an attrition system, and it's easy to see how it invites more interesting narration than "You lose five hit points." Crown and Skull is presented as a game that the players themselves get better at, learning more about it by playing it. Part of the challenge of the game is learning to create and manage a versatile, robust, survivable character.

I have played a lot of CRPGs, but I don't remember ever seeing a system like this—one where damage is exclusively represented by the temporary or permanent loss of gear or skills. It makes me wonder how well such a design could be adapted into a video game. Could such a system be adapted into a satisfying video game experience, or are these formal systems too strongly coupled with the improvisational storytelling of tabletop games?