Some ways to get a McGuffin from the Goblin King

Cleaning my office this morning, I came across some design notes that struck me as too interesting to throw directly into the recycling bin. I don't quite remember the context, but I must have been thinking about Apocalypse World style "moves" (in-game action types) and generative storytelling. It's probably from when I first learned about Viv, which I still have yet to play with. The paper itself contains a list of the moves that will be included in the third edition of Apocalypse World, a few notes about what it would mean to randomize locations and their denizens, and then an exploration of the different ways one could get a McGuffin from a Goblin King. These are what I came up with as possible stories:

• Find him, kill him, take it
• Find him, convince him to give it to you
• Find him, steal it, escape
• Find someone else, convince them to steal it
• Find him, threaten him, he attacks (jump to another case)
• Find him, threaten him, he gives it
• Find him, beat him up, demand he gives it, get it
• Find him, offer something else in trade, trade for it
• Find him, observe him for leverage, deploy leverage as part of demand, receive it

There are certainly more, and clearly, some of these weave into each other. For example, convincing someone else to do it for you still requires that that character end up having to go through some other matrix of options.

Reading these simple statements starts stories forming in my mind. Each is a seed that could grow into something compelling, but they could also turn into something rather dull. Paying someone else to go questing is economically efficient but narratively unfulfilling.

It stands in contrast to my current project, which involves writing a lot of interactive fiction. This current work requires me to be very careful about branching since each alternative increases production costs. I am playing with the idea that you are a particular character, and so I do not feel like I have to expose all possible options to the player--only those that are reasonable to the character's situation and demeanor. 

I do hope to get back to exploring the kinds of narrative systems analysis that the McGuffin Acquisition represents, but in the mean time, I am finding more traditional gamebook-style interactive fiction to be a rewarding creative experience.

Now I can recycle this paper and get back to cleaning.

Summer Course Revisions: CS315 Game Programming

I had a break from teaching CS315 Game Programming last Fall while I was on sabbatical, and now I'm gearing up to get back into it. It's a fun course that has always had the same mission but has taken many different forms. I'm feeling pretty good now about my plans for Fall, and so I want to document some of the key points here. The draft course plan is already online. As with my CS222 course, there are still some areas where I want to rework the prose, and I have only posted activities for the first few weeks, but I feel like the structure is where I want it to be.

Grading

Three years ago was the last time I used checklist grading in CS315 in its original form. Two years ago, I switched to a different model inspired by a book I had read. I wrote about how it had some good qualities, but it caused friction with Canvas, and it also had me doing a lot of regrading. Thinking about my plans to kick Canvas to the curb, I figured I might get rid of the interface problems. Yet, the more I worked on my plans, the more I kept drifting back to checklist-based grading. I drafted the first four weeks of exercises this way while I tried to identify why I still felt unsettled.

At some point, it struck me that a completely different way to handle functional requirements articulation is through user stories. This is the way I do it in the prerequisite course (CS222), and it's also how I coach teams to do it in the CS315 final project. Why not deploy user stories in the weekly exercises as well, thereby also giving example of something I want students to do later? It seemed sensible, and so the only missing piece was to map this to grades. I decided to go with the same simple model I started using recently in some CS222 sections, where the grade is based on the number of completed stories.

I am happy with the articulations I have put up for Exercise 0 and the three increments of Exercise 1. The only piece that gives me some pause is that the grading scheme does make it seem like missing a story is punitive rather than that meeting stories is rewarded, but I think this is part of the systemic problems I have inherited. At least I don't think I'm reinforcing them, and I can explain to students that they still have the option to skip lower priority stories and earn a lower grade if their situation makes that prudent.

As part of my Canvas-kickery, I'll be using GitHub issues to give student feedback. This is a natural place to give feedback in the first half of the semester, when students are working individually on projects. I haven't thought much about the final project yet, but I suspect that once the semester is running, a path will open up for me. CS315 is not a course where we traditionally use Google Drive, but since I'm already collecting students' GitHub usernames, I can also collect Google Account names in order to set up a dashboard system like I described in my previous post.

Style

There are two major benefits to teaching students to have good style in this course. First, there is the intrinsic value to the student of learning to follow an established style guide. Second, it makes it much easier for me to read a lot of student projects if they follow the same structure. It is not so different from requiring a particular style in order to approve a pull request.

For some time, the exact style requirements have been distributed through the early semester exercises. This had the advantage that it allowed me to ramp up expectations as students became more comfortable with the game development ecosystem. The downside was that students had to build up knowledge piecemeal about the expectations, remember where to find reference material, and potentially build up bad habits until the right models were shown.

This year, I've done something I've wanted to do for several months: I constructed my own style guide. It has its own page on the course site, and all of it is required from the second week of the semester. It consolidates many aspects that previously were spread out across different grading levels in the checklists. It also puts almost everything in one place, which I hope will be useful. One place I could not easily bring into one site is the actual code style, for which I am simply having students follow Godot Engine's published conventions. For commit messages, I used to ask students to read Chris Beams' article on commit messages and follow his guidance, and this was frequently a source of frustration for students: some didn't understand version control well enough to follow his arguments, many skipped reading crucial parts of it, and some just had bad habits. Now, I have simply included his seven rules and linked to his article for more information. 

Accessibility

The course site is built from the same Astro configuration as the CS222 one I referenced earlier. Writing and revising in Markdown is quick, and component-oriented design can be useful. One of the main reasons I want to use Markdown is that I want to easily include source code in the exercises. Unfortunately, the default Astro formatter violates WCAG 2.1 AA requirements that are now being required for all teaching material.

It took several hours to sort out a solution, and I ended up using the github-light-high-contrast Shiki theme in order for my code to pass muster. It does not have the aesthetics that I wanted, but at least WAVE says that it passes all the requisite checks.

Summer Course Revisions: CS222 Advanced Programming

I always revisit my courses over the summer, but this year there are higher stakes than usual. Ball State has opted to change the calendar from 15 weeks of instruction to 14 weeks. There will be significant ramifications for curricula with long prerequisite chains such as my department has, but those problems will have to be tackled systematically later. For now, the immediate challenge involved shaving a week from an already packed semester. This coincides with two other major changes I have had in mind: reviewing the textbook and getting away from Canvas. I plan to give each a fair treatment in this post, although some details may be reserved for future writings or conversations.

My draft course plans are available online. Much of it is copied over from Spring for expediency. I would like to tighten up some of the lengthier sections, but for now, it will suffice. The projects will be posted when they are assigned, as usual. 

The Calendar

For many years, I used the first three weeks of CS222 to prepare students for the rest of the semester. This was followed by the two week project, leaving ten weeks for the final project. A few semesters ago, I expanded the introduction to four weeks, and this proved helpful, so I shaved a week off of the final project in order to keep two weeks for the warm-up project. To accommodate losing a week, I have decided to shave a week off of the final project. It will still be done in three iterations, and this means that the iterations themselves will be shorter. In turn, this means that we will spend a higher proportion of the final project on project administration (presentations, planning, retrospectives) rather than enrichment work.

It will have to be this enrichment work that is cut, and I have not yet made up my mind which two days will go. Most likely, it will be some of the practice exercises such as in-class code reviews or part of my week-long defensive programming exercise. I can move the "What We Learned" exercise back into the final exam slot, but then it becomes harder to use that exam as an objective measure of learning; it may turn out that I have to change the structure of the exam as well.

I am comfortable putting off some of these decisions. The second half of the semester is always more about my responding to the students' needs anyway, so I can wait until I meet them and see where their interests are.

The astute reader may notice that my draft course plans have no mention of achievements. I would not normally have one assigned until around the two-week project anyway, so for now I have left them off. Achievements are an engaging part of the class, and I love the idea of giving credit to activities that are normally out of the scope of a college course. However, it's also one of the easiest things to cut. Even though they use little class time, they occupy significant amounts of student attention. A week's worth? Perhaps. This is another decision that I am putting off until the last responsible moment, when I will have the most understanding of its implications.

A Book

The second edition of Robert C. Martin's Clean Code was released not long ago. It is twice the size of the first edition, and this alone had me concerned. The first edition is a classic, but it does show its age. Much of the criticism that is levied against it seems to forget to whom it was written twenty years ago. Still, not all the criticism is unwarranted, and this prompted me to look for alternatives.

One is The Pragmatic Programmer, which saw a refresh in 2019 with its 20th Anniversary Edition. I have always respected this book, and the new edition is strong. Re-reading it, though, I remembered how much it assumes of the reader. The tips are useful, but many of the details are left to the reader's experience-—and my readers lack experience! I noted a few particularly salient sections that I think my CS sophomores would benefit from, but I didn't see an easy way to use it the way I've used Clean Code.

The other alternative is Ousterhout's A Philosophy of Software Design. I got a copy of this book as soon as I heard about it, but I bounced off of it pretty quickly. The book presents itself as the sole source of design wisdom, which is already off-putting, but what really got me was Ousterhout's summary dismissal of Test-Driven Development coupled with an incorrect explanation of what it is. It's not hard to learn what TDD is, and if the author couldn't be bothered to cite a real source, then how much of the rest of the text should one take seriously?

Having put these two books aside, I decided to give a closer look to the new edition of Clean Code, starting with an inspectional reading. By golly, there's a 50-page appendix that recounts a conversation between Martin and Ousterhout! It was fascinating to read, especially since so much of it is criticism of the first edition. It inspired me to read the rest of the second edition, which does indeed address much of the criticism Ousterhout and others have levied against it. Martin is not explicit about why he devoted so much of the book to this conversation, and despite how much I enjoyed reading it, I wish he hadn't: the book could be more manageable and affordable without it.

The other primary reason for the book's being so large is that it now includes abbreviated versions of two of Martin's other books, The Clean Coder and Clean Architecture. There is some convenience to having this content here, especially since the three ideas are not orthogonal to each other, but again, I would have preferred a tighter volume. More books, I say, not bigger books. Doesn't that seem more modular?

The best improvement in the second edition is that Martin is more careful in his chapter about comments. Almost all of my students have misread his chapter as an admonition against all comments, even though that is not what he says. When I push students to re-read that chapter more carefully, they have always come out with better understanding. The new articulation tones down the rhetoric, and I think fewer students will need a re-reading in order to get the main ideas.

The section that I miss is the old chapter 17, which was a long collection of code smells and heuristics. There was a lot in there that was not in the rest of the book, and it was all bite-sized, small enough for a sophomore CS student to recognize and think about.

I look forward to seeing how students react to this new edition. Expect an end-of-semester report, as usual.

An Edupunk Reaction

I have long bemoaned the problems of Canvas, and it keeps getting worse. A full treatment of this may wait for another blog post or some kind of SIGCSE opinion piece. For now, suffice it to say that an experience last semester was the straw that broke the camel's back, and I'm going full edupunk.

The new course has been built using Astro, which allows me to compose large portions of the course plan in Markdown. This makes it much easier to edit code samples and assignment sequencing than my previous, lit-html-driven approach. This does not represent a major change since I have not bound my courses tightly to an LMS since experimenting with Moodle in the late 2000s. One of my lessons there was don't bind your course tightly to the LMS.

In the past, my students submitted work through Canvas even though it was usually created either on GitHub or on Google Drive. Now, I will be skipping the middle man entirely. I plan to collect assignments through a form, and I will track grades in my own Google Sheets document. I used Apps Script to create a simple web view of the data based on the authenticated user. I already have students register a Google Account with me so that they can access the shared drive, so there's no extra administration required here.

My sheet looks like this:

Sample sheet

That row of sample data is linked to my own email address for testing; the email address is redacted for public posting. When I go to the deployed app, I get this report.

Progress Report WebApp

The layout is a placeholder, but it already exhibits the strength of having been created intentionally for pedagogic purposes. There is no coloring, there is no "grade so far," and there is no confetti. It is a simple report that a student can review in order to make decisions about what to do next. My plan is to embed this as an iframe right in the course site, but I haven't done that yet.

Technical note: I was a bit confused about Apps Script and web deployment, so I want to keep a note here for later. After the first deployment, one needs to revise the existing deployment in order to maintain the URL, not create a new deployment. The interface here is very strange. First, select Manage Deployments from the Deploy dropdown, then use the pencil button to make the deployment editable, then use the Version dropdown to make a new version. The description then can be something like a commit comment. Upon saving, the latest version of the script will become the new live version.

As for grading, I will do this Google Drive or in GitHub. I already have a workflow on Google Drive in which I leave comments in students work. I had been then summarizing those comments on Canvas, but now I can simply do that in Drive and record the grade into my spreadsheet. Similarly, for projects, I would clone the project, evaluate it, and type the results in Canvas; now, I will instead do that on GitHub, posting my feedback as an Issue. Existing privacy options means that none of this leaks out to the public: I simply use the permissions features already baked into Google Drive and GitHub.

My approach separates the concerns of (1) presenting course details, (2) collecting submissions, (3) giving feedback, and (4) presenting a dashboard summary from which students can choose what to resubmit.

As mentioned above, expect a full report here on the blog at the end of Fall. I know, you're probably wondering, "When are you going to get back on the Small Web and host your own blog?" I think this would be fun to pursue, but I'm also weeks into a very exciting, non-course-related summer project. I look forward to returning to it, but I may ride this momentum into planning my Fall CS315 course as well.

One final logistical note, for my own future reference: Making these changes took me about four full-time days, not counting reading time. I had used Astro before, for my CS390 page last semester, and I had never used Apps Script. I wanted to track that here so I can come back to it, expecting critical discussion in Fall about purported vs. actual justification for calendar changes combined with the increased work required of faculty with respect to ADA requirements.

A few notes on branching, microbranching, and pants

I am wrapping up work on a preproduction build of a digital gamebook that has me writing a lot of interactive fiction. After exploring my options and spending a few days on a custom engine, I landed on using ink. I have enjoyed working with it, and after a short learning curve, I find that it really does help me focus on the writing. That is, although it has a formal syntax that one must deal with, it mostly stays out of the way.

Coincidentally, a friend recently pointed me to the Game Narrative Kaleidoscope podcast. I just finished listening to the sixth episode's interview with Kate Gray. Two bits caught my attention that I wanted to capture here on the blog so I don't forget them.

The first is just a simple turn of phrase that the interviewers and guest all knew but that was new to me: the distinction between planners and pantsers. Writers of interactive fiction seem to identify as one or the other, the former being those who plan out their story carefully before writing and the latter being those who go "by the seat of their pants." In my case, I had sketched a quest structure with a few important branches, but once I got into writing, I really found that I could pants a lot of it.

The other was a distinction Gray drew between conventional branches and microbranches. She pointed out that many use "branching" to refer to the big, game-changing decisions that a player makes during play. However, there are also lots of smaller decisions one can make, particularly in dialog, that can serve other purposes. Often, this purpose is merely performative, allowing the player to choose a voice for their character. Other times, it is used for subtle worldbuilding. The important thing is that they are not important things, and Gray discussed how much she enjoys attending to them.

This struck me since I spend a lot of time with my students talking about how, in game design, decisions should be meaningful. A decision that is not meaningful is a false choice. Of course, that's a sort of ludological perspective, and it's true in the cases where it applies. Gray's interview gave me a vocabulary to talk about those other kinds of choices, the ones that only matter to the player and not necessarily to the game.

I have been playing Heaven's Vault in part to try to see through the experience to the ink layer below. It presents a lot of microbranches, some of which seem to have long-term impact on the game but many others of which are decorative. The dialog is all brief and punchy, no more than one or two sentences before another choice is made. It has a good rhythm. I am trying to understand the game in the context of other playful narrative experiences. I have been enjoying my page-a-day adventure calendar more than I expected even though it has very few decisions and no significant branching; after all, the next day's page has already been printed. I also picked up The Raiders of the Dune Sea, a gamebook that, at first glance, seems to favor longer narrative passages.

In my preproduction prototype, I have some scenes with lengthy text passages and some with frequent microbranches. Once I pull it together, I need to get it in front of some different representative players to see which best carries the themes I am exploring.

A new way to start classes

Now listen! and before I start,
give me your hearing and your heart,
for words will quickly disappear,
if they aren't heard in heart and ear.
Some men will hear and then commend
things that they cannot comprehend.
Their sense of hearing lets them hear it,
but once the heart has lost the spirit,
the words will fall upon the ears
just like the wind that blows and veers.
The words don't linger there or stay;
in a short while they fly away,
if the unwary heart's asleep,
because the heart alone can keep
the words enclosed. The ears, they say,
are just the channel and the way
by which the voice comes to the heart.
But the heart's able to impart
the voice that enters through the ears
unto the breast of him who hears.
So he who would hear me must start
by giving me his ears and heart,
because, however it may seem,
it's not a lie, tall tale, nor dream.

Chrétien de Troyes, Yvain, the Knight of the Lion, translated by Ruth Harwood Cline (University of Georgia Press, 1975), lines 141–164.

I am thinking of reciting that passage as a way to start next semester's classes.

Reflecting on CS390, Spring 2026 edition

I taught CS390 Game Studio Preproduction after a year off, and it was to have been the beginning of a three-semester sequence. However, there was an administrative error: an overestimate of the number of students who would need the sequence meant that we had two sections of CS390 running but only enough students to justify one. The compromise with the administration was that we would collapse the two cohorts into one. For various good reasons, mine was the sequence that was cancelled, so my small number of students will be joining with another cohort for next year's production sequence. 

I open with this story because it cast the whole course in a strange light. My original plan for the course was that I would be preparing them to work under my supervision next year, and I had set up scaffolding to support that growth. When I found out that these students would go to another faculty member, I realized that this aspect of my plans were essentially moot: the other faculty member and I have different approaches. At one point, I laid out on the board a list of topics I had planned to introduce and enforce on the preproduction students, and I left it up to them to vote on which things they thought sounded interesting. In the end, the only one they voted for was a bootcamp on command-line git, but I don't even think that "stuck" since I didn't have any follow-ups or see students working through comprehension; many seemed hooked on WYSIAYG GUI tools instead.

It was a good group of students, and it was fun to work with them on the journey. The first several weeks, we explored ideation and prototyping. There were a few concepts left on the table here that I think are absolutely worth pursuing. They ended up settling on two designs to move forward through the formal preproduction process. These were presented to my Games Advisory Board, who generously volunteered their time to give feedback to the students. This pitch presentation was one of the three major deliverables of the course, the other two being a vertical slice and a concept document. All the details, of course, are in the course plan.

This was my third time teaching this course, and a major change is that I did not require reading Lemarchand's Playful Production Process as I have in the past. This was an experiment to see how the students would do with less structure. I am not sure I have a strong conclusion. Parts of it are really powerful, and I found myself missing them. I did not miss the niggling doubt of whether a student actually read and thought about the content. I feel like if I brought the book back, I would need to do it in the way I evolved my handling of Clean Code in CS222, incorporating more explicit instruction on how to take notes and how to transfer from the text to the task at hand. I will need to revisit this before Spring 2027, when I expect to teach CS390 again.

I invested a lot of time during my sabbatical trying to come up with a good concept document framework. I blended together some of my favorite aspects of the old Tim Ryan article, Lemarchand's book, and Sellers' Advanced Game Design. It mostly worked, but there were three pain points in students' documents that I think I can alleviate by improving the recommendations. 

The first relates to project goals. Lemarchand has a whole chapter on this topic where he distinguishes between experience goals and project goals. I abstracted that into what I called design goals, but I think I would do better to just adopt Lemarchand's approach (which he credits to Fullerton, I believe). My students obviously struggled with the idea of making goals for the player's experience. They kept listing their own goals instead. That is, they talked about means where the goals should be about ends. For example, a team mentioned drafting as a core mechanism because they wanted drafting, but they didn't talk about the question that drafting answers. Curiously, this should tie back to MDA, which I know we talk about a lot in CS215 as an analytical tool, but perhaps we need to emphasize it more as a generative tool. Curiously, even after I pointed the teams specifically to Lemarchand's examples from Uncharted 2 in his book, the teams still did not seem to get it. In fact, I realized that they didn't get it in the same way that my CS222 students kept wrapping up technical requirements as user stories instead of doing proper user story analysis. It makes me wonder whether this idea, of user-centeredness or player-centeredness, ought to be a program-level learning objective, at least of the GDD concentration. (I was tempted to put that previous sentence in bold, but that looked really aggressive. Do you think I'll remember this otherwise?)

The second pain point was that I did not have an equivalent of Lemarchand's macro chart. He puts it as part of his "game design macro," which is equivalent to my "concept document." Without such instruction, the students waved their hands around things like how many levels there would be and what powerups might be available. Both teams, loving them as I do, really dropped the ball here: they both described games with a scope that was essentially unbounded due to their lack of quantifiable analysis. A macro chart really would have helped them face the work to be done, especially if I had pushed them to include incidentals that they tend to forget, such as marketing materials and playtesting time. I don't think an entire schedule is necessary, but the macro chart makes one face facts.

The third is that I did not require them to go deeply into what Sellers calls the detailed design. I can see in my own documentation that I shifted toward narrative explanation of core loops using Chambers' approach, but I cannot recall why I stopped there. I don't want to go as far as Sellers' formal system modeling, but I think more documented details would have helped communicate the interactions among systems. During the pitches, one of the board recognized that a project had simple systems with multiplicative effects: that's the kind of observation I want my students to make about their own projects, not for a third party to point out about it.

Taking all that together, it points to something crucial that I need to remember next time I teach the course: push the students to make smaller games. I am not sure how to quantify or enforce that, but it has to be done. They just don't have the experience to interpret subtle or even overt feedback in this regard. Baxter-Webb brings this up in a helpful video, arguing that people making "indie games" need to be familiar with what small games are like. If my students are coming in inspired by large games, they will be thinking of making large games. There may be opportunities here to require a more structured research phase to help set expectations.

For the "final exam," we met and talked about the semester. After some open discussion, I gave them three questions to answer, one at a time, and we went around and shared answers to each. It was a wonderful conversation; I could write a whole blog post about how the students articulated what they learned. The final question I asked was what advice they would give to their past selves or to new students coming into preproduction. The answer that sticks in my memory is to think of game design as making a gift for someone else, not as tinkering for yourself. This wraps up a lot of the meaningful conversation the students and I had about design goals, experience goals, playtesting, humility, and risk-taking. 

That covers the major parts of what I learned from teaching the course this past semester. I am grateful to have had a small group that worked so well together; I look forward to watching their projects from afar during their senior year. In the meantime, I will put this train away, knowing that I will be able to dig it back out in late Fall, when I get ready for the next group.

Reflecting on CS222, Spring 2026 Edition

I had a fun cohort of students in CS222 this semester. Each team designed a final project of the "connect to a Web service and do something with the data" variety. In many ways, their foibles and experienced were akin to past students, but something that stood out to me was how well they asked each other questions. It is not clear whether I have done something different to foster this; one possible factor is that I have improved the requirement that teams give a technical lesson as part of their presentations.

We cover a lot of ground in CS222, and so I am concerned that next time, I will have only fourteen weeks of instruction rather than fifteen. The university is changing the academic calendar as of Fall 2026, and it will be hard to find a week's worth of work to remove. Also, students coming in will have two fewer weeks of classroom experience programming; given that many students do not do much independent practice, this will have a significant effect on downstream courses. Coincidentally, I just got out of a meeting this morning where we talked about how much more we want to teach within the undergraduate major, and yet we will have eight fewer weeks in which to do what we are already struggling to fit in.

My course requires students to read and evaluate "project code," which is a term I define but that a majority of students don't understand. Either they don't read the instructions or they lack the ability to distinguish between code-for-learning and code-to-do-something. As a result, many of them look back on their own code that was just purely pedagogic; others find code on GitHub, which I recognize is a leap of faith, but they look at code that is just someone else's classroom or tutorial project. This leaps out to me upon inspection, but because they have only ever read pedagogic code, I don't think they recognize it. Hence, rather than just refine by definition, I think I need to point them toward specific examples of projects that are appropriate. I hate to do this because there is so much code out there and I want them to find projects that are interesting to them. Yet, despite this encouragement, almost no one has ever done that, so maybe that's a dream not worth chasing. I would need to set up some guardrails to prevent two students from evaluating the same block of code, which is also something I am not keen on. Perhaps I need to set up some kind of draft.

I have had a note in my planning spreadsheet for some time to remind students that a good way to think about SRP is responsibility to whom. Also, though, there's a second edition of Clean Code out now that I haven't read yet. I need to see if the new edition is worth switching to, especially around explanations of OO principles that often trip students.

My final note is about the final exam. Many years ago, it comprised only reflective questions, and those gave me an insight into the student experience. A few semesters ago, I was concerned about students blowing steam, and so I added a content question as well, to make sure students could express some of the fundamental class topics. One of these questions has been perennially challenging to articulate correctly. Essentially, the question is trying to see if students understand that they should be able to make a list of unit tests they have yet to write and that these should be SMART. The trouble is that if I remind them that each step has to be SMART, then I have given them the answer. What happens is that students will say that their first step is to "write some tests," for example. That is not wrong, but it also doesn't illustrate what I'm trying to get at. Relevantly, I think many student teams continue to struggle with this idea throughout the semester, that they should always have a goal to work toward. TDD is supposed to push them in this way, but in practice, many fall back on old habits of just plowing forward without discipline. So, I think this points toward two other action items for me: first, to use more class time to have them practice articulating what their immediate next steps are, like Kent Beck does in Test-Driven Development By Example, and also then to use a similar framing to ensure that they can do this individually, as an outcome of the class.