Fixing the student progress report system

It turns out that the approach I described in an earlier post simply does not work. I didn’t mention in that post that I developed it with the help of an interaction with ChatGPT. Turns out, trusting ChatGPT led me astray: it is technically impossible to use Google Sheets and Apps Script in the way I thought I could. Mea culpa.

Today, I stood up a new solution. Now, each student gets a UUID which is sent as a custom parameter to my script, and this returns for them a view of their row of the grading sheet. This variation was also developed in concert with ChatGPT, but one major difference is that this one verifiably works. The AI interaction was helpful in quickly identifying how to use Apps Script to generate UUIds and read http parameters.

In this post, I am going to try to reconstruct the steps I followed to get all the pieces working. It assumes I already have a grading spreadsheet set up that has all the students’ university emails in it.

1. Create a function in the Apps Script to generate a UUID. It looks like this: function UUID() { return Utilities.getUuid(); }
2. In the sheet, call this function for each student to give each a UUID. Then, copy and paste those values back in as plain text values.
3. Create another column to construct the URL from that UUID. For example, have the stub URL in a cell, then concatenate “&code=” with the UUID after it.
4. Export the sheet in .xlsx.
5. From Word, start a new document, then from the “Mailings” menu, start a new mail merge. Note that this cannot be done in Office online: it requires running Word locally.
6. Use “Select Recipients” to link the Excel file as a data source.
7. Type the message, using the “Insert Merge Field” tool to put the student’s URL in place. “Preview results” is a toggle button (surprise!) that can be used to check that it is merging as expected.
8. Choose “Finish and Merge” to generate all the emails, which will not actually send yet.
9. Open Outlook, which will step through and send each email.

Incidentally, this is my first blog post that I have written in Markdown and then turned into HTML with pandoc ( pandoc post.md -o post.html). It has worked great and is a much better writing experience for this kind of post.

Notes from Spring 2026 CS390 "Final Exam" meeting

Back in April, I mentioned that the "final exam" for my game preproduction class was primarily a discussion. Cleaning up my office, I found my voluminous notes from that meeting. The four questions I asked of the students were, in order, the following:

1. What do you think is missing from your preproduction work?
2. What is something you know now about preproduction that was unclear before?
3. What advice would you give yourself or to someone starting preproduction?
4. What questions do you have?

One of the major themes in my notes is that the students recognized, maybe only in retrospect, that they had lost sight of the players. They were building things they wanted to build but not conceptualizing the player experience. Curiously, a student pointed to the final presentation as the first time he recognized and understood the omission. One of the students made a clever suggestion: early in the semester, when experimenting with different constraints around ideation and prototyping, I should challenge the students to make something for someone else. 

Another theme was how challenging it was for them to understand and articulate design goals. After having struggled to maintain a vision and a direction, they came to understand why these are necessary, and all wished they had spent more time agreeing on such goals at the start of the project.

When it comes to the second question, the students came to much better understand the role of playtesting, what it means to answer questions with prototypes, the dangers of analysis paralysis, and the importance of planning in order to understand scope. 

These are my notes about the advice that they would give to new students. I am leaving out a few that were very specific to this group or repetitive. I don't know yet if I will share these verbatim with my next cohort, but I also didn't want to lose them.

• Think of game design as gift-giving, not as tinkering
• Fast prototypes to articulate ideas are good
• Don't spend too long trying to solve a problem
• Take prototyping and playtesting seriously—don't make something just to have it
• Set deadlines, use a calendar
• Write game ideas down
• Take feedback and write it down
• Prototype instead of just thinking it will be fun
• Mess it up
• Don't be afraid to fail
• Learn your scope (explore, but know strengths) and know when to move on

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.

[EDIT: The following few paragraphs describe an approach that does not work but I have left them here for historical purposes. See the later post for notes on a working replacement.]

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 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.

Reflecting on CS215, Spring 2026 edition

Introduction

It was a delight to teach CS215 Introduction to Game Design this past semester. I had not taught the class since Fall 2022, and I didn't realize how much I missed it. I had a really wonderful cohort of students, as good as I could ask for. They were eager with questions and comments. More than once, I was just warming up a story, and hands would go up with thoughts and reactions, before I even got to the good stuff. I am glad to have these students in the program and look forward to watching them over the next few years.

The class was overall a great success. I followed my tried-and-true approach, using the first half of the semester to go through readings and exercises that helped lay out what is known about game design and the second half to work on final projects. 

Course Structure

As in the past, I still feel like there are missed opportunities to help students deploy the ideas from the first half into the second half. One complication is that, because students design their own projects, there's no way to know which ideas from the first half will be salient to their work. I would like to get them thinking more about this, but at the same time, I don't want to add more load without a good reason.

The one universal is the iterative design process. This came up in informal meetings among the faculty who teach in the CS GDD concentration, and we agreed that it is the most important objective for students to meet. Currently, my final project structure recommends a particular sequence, but I do not mandate it. I wonder if it would help the students learn the importance of playtesting earlier if I required them to do it earlier, the way that I require acceptance testing in CS222 for example.

Player Logs

I asked the students to complete five player logs during the semester. These logs involved briefly describing a game they played and reflecting on what they learned from it. Because we were working in the analog game design space, I required that at least half be analog games or digital interpretations thereof. My hope is that they would be playing games anyway and that this would help integrate their personal and academic experiences. Judging from their selections, I think many chose games for this exercise, although curiously not the ones I suggested as good starting points. I did not ask them to explain why they chose the games they did, but I might ask that in the future. No one should be choosing a knock-off of Uno over a brilliant design like Carcassonne.

The player logs were evenly spaced throughout the semester. This had the advantage of appearing elegant on the calendar but the disadvantage of colliding with other deadlines. Of course, many students did the work right before the deadline, but this meant it competed for attention with other work rather than complementing a continuous practice of study. I may need to reframe the exercise as either formal assignments or as the building of a portfolio that is routinely verified.

I realized too late that there was an opportunity to tie the player logs into the final projects. Next time, for late-semester player logs, I should require that the game be related somehow (mechanically, thematically) to their final projects. A lot of the students admitted to having explored a genre in which they had little experience, and this could be a way to help them understand the design space they are in.

Design Logs

Once again, I required my students to maintain design logs during their final project. I love this idea, and I am sure it helps them think through their practice. However, I think I can make the progress a bit smoother. For example, I required them to follow a particular document structure, but many struggled to read and follow the instructions. Rather than be indignant about this, I could provide a template to remove some friction. Similarly, I gave them some latitude as to what specifics go into the design logs, but they probably lack the experience and wisdom to make this decision well. I have them read Dan Cook's article, where he appropriately provides some guidance but no rules. I think I should give them a few more rules in the spirit of shuhari.

Workshopping

We used six weeks of class for workshopping. I split the class into four groups, and since we met twice a week, each group had three days to focus on workshopping their games. Each presenter took a section of the room, and the rest of the class moved among the stations. For the first round, this was done ad hoc; I set a timer, but moving was a recommendation, not a requirement. We ran a little postmortem after that iteration, and the students liked the ad hoc groupings but not the optionality of rotation. Thereafter, groups had to move when the timer went off, and it went well.

I gave them a feedback structure that I learned from Lemarchand's Playful Production Process. Any feedback during workshopping had to be framed as, "I like..., I wish..., What if...?" The students who tried this loved it, but some were too eager to give advice without the framing. They desired some kind of accountability, so I decided that we needed a magic word that could be invoked: what better for a game design course than "xyzzy"? If anyone heard feedback without the format, they could say, "Xyzzy!" and the hearer would have to re-frame their discourse. I think I was the only one who actually used this, but it was a good reminder to have on the board.

Similar to the feedback structure, starting in the second iteration, I asked students to begin each workshopping session by giving their elevator pitch and stating their design question. This was not always followed, and a little more accountability could have helped here, akin to the magic word for feedback. Students also struggled to articulate a design question, but I did not give much guidance here either. Many students came in with questions like, "Is this fun?" despite our earlier conversations about the danger of the F-word. I think this is a place where I can help them develop better practices and tie together the two halves of the semester. For example, I could give them a template like, "What mechanic can I add or remove in order to improve [emotion] from playing my game?" or "What goal can I add for [player type]" These would require students to think about their games in the context of the theory we studied rather than falling back on colloquialisms like, "Is this better than that?" 

Along those lines, I wonder if it would help the students to articulate design goals, to be explicit about what their game is supposed to do. This is something my preproduction students have struggled mightily with, and I don't know if this means that it should be introduced earlier or that it requires more wisdom than many new game designers possess.

Rules

I was initially surprised when, reading their final submissions, that their rulebooks were low quality. Many were missing fundamental details so that it was clear that the rules articulations themselves were not tested. My evaluation rubric enthroned a clear rules articulation as being a requirement for a good grade on the final project. I reflected on the course and realized that most of the students had completed the semester without ever reading an actual rulebook. For their player logs, they either used a digital interpretation of a game such as Board Game Arena or they were taught a game by a friend. Digital adaptations are deceiving here because software prevents players from doing things that they ought not do whereas in a tabletop game, you are only beholden to the laws of nature and localized miracles.

The students had never worked with the genre of game rules, and so clearly I could not hold them accountable to that genre's standards. It still bothers me that the CS majors in particular did not deploy their programming knowledge to write clear rules anyway, since rulebooks are essentially programs run on people, but that doesn't change the fact that I did not scaffold a good learning experience to make them good at it.

Being able to articulate the rules should be part of the class. After all, I encouraged them to think about posting their work on itch.io or someplace similar, but if the work is unclear, then it may do more harm than good. Next time, I need to think about this particular deliverable the way that I handle other incremental development tasks: give them a scaffolded experience with deadlines for draft submissions and/or rules-based playtesting.

Paper prototyping, digital prototyping, and the DORA Metrics

My video game preproduction class formed teams and started work on their final projects a few weeks ago. Each group started working on digital prototypes before they had really settled on the core gameplay. I encouraged them to move toward paper prototyping so that they could make changes faster, even radical changes. I am pleased to report that they have embraced nondigital tools as part of their process, although I'm still concerned that they are not iterating fast enough. 

This was on my mind when I watched Steve Smith's latest video from the Modern Software Engineering YouTube channel, which reminded me how the DORA metrics can positively influence software development practice. It got me thinking about the metric change lead time, which measures how long it takes from a change to go from committed to deployed into production. I realized that this is essentially the same idea as I have been advocating for their prototypes, whether they are analog or digital: the less time it takes for an idea to go from implemented to tested, the better. It doesn't matter whether we are committing in the sense of version control or in the sense of having made a coherent change to a paper prototype. I suspect that the DORA metrics would still hold, that a team that reduces that time is going to be more productive.

In today's meeting, we talked about what this means for us as game developers. I borrowed part of Smith's analysis, discriminating between activity metrics, output metrics, and outcome metrics. The students got the idea that the outcome metric is most important, and that this could be something like profit or it could be something like delight. That is, if we are making a game that is designed to bring joy to people, then the amount of joy we bring the player is the intended outcome, so we should measure that. In fact, we often call that playtesting.

This led me to hypothesize that we can use change lead time metrics as a tool to determine when to switch between forms of prototyping. I have that students sometimes have difficulty understanding physical prototyping and other forms of lightweight prototyping when they are developing video games. The DORA metric points toward a solution: one should change modes of prototyping when it reduces change lead time. That is, given an intended change to the game system, one can ask which mode of prototyping allows us to go most quickly from implementation to playtesting. While that is paper, stay with paper. At some point, though, there will be more systems or crafted aesthetics than the low-fidelity form is accurately conveying, and so we use higher-fidelity prototyping instead. 

There are at least two potentially confounding factors within this hypothesis. The first is that it assumes that we can accurately assess whether a particular system can be accurately playtested in a given prototyping medium. Drawing a physical card feels different than tapping a depiction of a deck, for example. The second is that it may require an amortized analysis when getting started. Engineering a system that allows for rapidly changing design components requires some up-front work. The point remains, though, that one cannot build software that is infinitely malleable, and the low-fidelity prototyping ought to inform which parts of an implementation are expected to change and which are not. Like the first challenge, this deals with the inherent risks of software development: the only way to know exactly how to build it is to have already build it.

Amphibian-based grading

I have a friend, roughly my age, who studied architecture at Ball State as an undergraduate. He told me a story many years ago about his most formative interaction with the faculty. He asked his professor how he was doing in a class, expecting a quantitative answer. Instead, the professor drew a line: on one end, he drew an egg; on the other, a frog; in the middle, a tadpole. He pointed to a spot on the line and said, "You are here."

I tell that story to my students every semester when the question of grades come up. I recently shared the story with a faculty discussion group dedicated to improving teaching practices. Everyone who hears this story immediately understands that the professor has given the student valuable information—that this feedback is much more valuable than something like "86%" or "C+".

At the faculty discussion group, one of the participants asked us if we still had any marked-up papers from our own undergraduate years. I do not, though many did. She pointed out how modern undergraduates don't even have the opportunity to hold on to such things. All their interactions are mediated by technology; all their interactions have become transactions.

Yesterday, I recorded the podcast discussion around my essay for The Raised Hand. The other guest was the author of February's essay, which will be published in a few days. The moderator identified a theme between our essays: that there is an intrinsic danger to separating people with technology. Reflecting on the conversation, it strikes me that technology allows us to have a limited communication with people who are distant, but also limits our communication with those who are nearby.

Earlier this week, I graded my CS222 students' two-week project submissions. The explicit goal of this short project is to prepare students for the eight weeks of the final project. The short project integrates all the challenging ideas from the first four weeks, and so it is designed to help students figure out which of those things they really understand and which require more attention. How should such work be graded? I expect each team to miss some fundamental concepts in their project, often things like having clear names or following the Single Responsibility Principle. If a team misses one of these, should they get a low grade because the work is wrong or a high grade because they did what I expect? A low grade suggests that they have done badly, but they have done well, and a high grade means they have done well, but they actually misunderstand important concepts.

I end up giving them low grades because that feels like an honest assessment of where they are. What I really want is to show them how close they are to becoming a frog. Why am I giving them numeric grades despite having told them about amphibian-based grading?

After grading these projects, I always tell the students not to panic about the grades. I point out that in the course grading scheme, this grade will be dropped if they do better on the final project than they do on the short project. Everyone does better on the final project in part because the short project actually works: it shows them their weaknesses. But look at what I have done here: I have crafted a mathematical system, justified pedagogically, so that I can give grades to things. It's true that at the end of the semester, I need to have enough evidence to tell students where they are on the amphibian line. It is a line after all, and so letter grades can be interpolated over it. Yet, while a tadpole is in the pond, it is nonsense to say that it has failed to be a frog.

In my podcast discussion yesterday, my interlocutor described how an integral part of education is helping people develop well-ordered desires. The desire to quantify human formation is disordered. I did not become a professor so that I could make good Canvas experiences. I became a professor to kneel beside the pond and cheer on the tadpoles. 

I write this so that I will remember it.

Introducing students to Capture Go

I am enjoying teaching introduction to game design after my years-long hiatus. The class is very eager, the sort that I rarely have to wait for comments and instead have to urge to move on.

On Thursday, we discussed core mechanics. It's something we had talked about earlier in the semester as well, but now we returned to it so we could talk about primary systems, secondary systems, and so on—and how crucial it is for small teams to remove anything beyond secondary systems. One interesting aspect from the discussion was the question of what is "core" in Skyrim: is it combat? discussion? walking about? This allowed us to discuss a designer's perspective on elegance, how it is not the same as goodness of design, but that there are good reasons to strive for it.

I followed this by teaching them to play Capture Go. I don't often cover this in my class, but I was inspired to put it into Thursday's discussion of core mechanisms given that Go is practically all core. There's just not much else to it, which is part of why it's such a fascinating object of study.

I introduced the game, and we got into pairs to play. There was an odd number in attendance, so I got to join a student for a few rounds, which was a treat. She was having some trouble seeing the patterns, so I started pointing out when I was about to win, and this led to our having better games. Also, however, she also set up her own goals, such as covering the star points; this was more important to her than winning the match.

After playing for only about seven minutes, I polled the room to see if anyone had thoughts to share. Everyone seemed to have fun, and I didn't get the sense that anyone was confused by the rules. One student pointed out how there was a strategic element to hitting the edge of the board in such a way that they could entrap the opponent. What really struck me was a discussion from another pair, where they immediately recognized that there was "aggressive" and "defensive" play. They described how, at first, one of them was defensive to the others' aggression, but that aggression seemed to win out, so then they both played aggressively. It doesn't matter to me which is more strategic; what I want to point out is that they recognized that in this simple stone-placing game, there was something deeper than simply marking spaces: there was strategy, there was a feeling, there were patterns, even if they only scratched the surface.

This neatly tied up our discussion of cores and elegance, and I have marked my teaching notes to remind myself to use this combination again.

An Improvement in Brainstorming Game Ideas

I have used brainstorming exercises in my game design classes for many years. When I first started, the goal was to fill the board with ideas within one class period—and we did. But it wasn't that helpful. Brainstorming is recommended in Richard Lemarchand's Playful Production Process, and so I used it in my 2023 and 2024 game studio preproduction classes, following his helpful rules. These exercises can result in unexpected items, but it seems like every time, no matter my framing, the participants failed to grasp the point of the exercise: game ideation. Instead, what overwhelms the list is inspiration for theme, setting, or characters, but these are not game ideas.

I saw a different possibility when I watched Joe Baxter-Webb's video on ideation methods. The video recommends seven different approaches for ensuring that one is pursuing worthwhile game ideas. One of the approaches is to describe a game in terms of "Action Action Goal." An example he gives describes Into the Breach: destroy the kaiju and upgrade my mechs so that I can save the cities. It struck me that this simple formula might help my students stop listing things like "bacon" which everyone likes but which is not a game idea. 

I explained the structure and goals in class yesterday, and in twenty minutes, my small group of students came up with forty game ideas. The very first one was only a goal, but with a little prompting, it was revised into action-goal. The next was fully robust in its action-action-goal structure. A few of the entries were quick "Yes, and..." entries, where someone riffed off of another idea, but most were standalone ideas.

Forty is much less than previous teams have made, and that's a good thing. Everything on the list can be turned into a game, although many of the actions seem to describe narrative events rather than player actions. For example, one of the concepts was to "embarrass" someone else, but turning this into a player action would require some interpretation. 

Each student brought an original game idea to class, inspired by Baxter-Webb's video, and I hoped this would warm them up for the exercise. However, I am not sure that items on the list represent the games that the students actually want to make. I say this in part because, earlier in the week, I had them do a short analysis of a game they enjoy, but in the brainstorming list, I don't see elements of those games. In retrospect, I could have been more transparent, telling them that they should expect to be doing creative ideation in class. To me, this is clear from the preparatory exercise, but that's because I have the whole class plan in my head already.

As I was writing this, I looked at my blog for old brainstorming notes and came across my notes from Justin Gary's Think Like a Game Designer. My plan for Monday's class was to have my students start greyboxing, but I realized last night that we should some more time narrowing down what we want to make. I think I may review the notes from Gary's book more carefully and have those as a back-up plan to help the students figure out what they want to make. 

"What would you do instead?" An Idea for a Reflective Assignment

I have been thinking about how to get students to understand the impact of generative AI on their personal development. Yesterday, as part of a wide-ranging conversation about teaching with a trusted friend, I came up with an assignment format that might be useful.

The idea is to present the students with an assignment that is appropriate for the topic of the class, but they would not be asked to do that assignment. Instead, they would be asked to consider the obvious temptation to simply put that assignment text into ChatGPT and turn in what it spits out. The real assignment then is this: what would you do with the time you would have otherwise worked on the assignment?

The learning objective for this assignment is to reveal to students what they value and challenge them to consider whether that reflects their personal goals.

Why I am not using GitHub Classroom

As I mentioned the other day, I have turned my attention to preparing for Spring's courses. I am on deck to teach CS222 in the Spring. It's a fun and challenging course to teach, and I've been thinking about whether there are some ways to streamline the student experience. This morning, I spent some time investigating GitHub Classroom. It wasn't the first time, and that's why I'm writing this quick reminder to myself about why it's not the right fit for me.

There are two things that keep attracting me to GitHub Classroom. The first is that it reinforces the use of distributed version control. Anything that gets students into the habit of using version control and making small commits is good. The other is that it leverages the power of Markdown, where a writer can seamlessly integrate different kinds of text into one document: prose and code live happily together. This forms a synergy with the first point, since it gets students to start to think about version controlling all the things. 

What specifically got me looking again at GitHub Classroom though was its support for feedback via pull requests. This would allow me to comment on an individual line of student work as well as the work as a whole. The shortcoming is that the writer cannot do the same. 

I need a student to be able to do three kinds of writing:

• Traditional prose
• Source code
• Commentary on specific lines of the source code

The writing environment has to allow a student to say that a particular section of code manifests a particular property. This cannot be done in source code comments because those comments are part of the code itself. Rather, I'm talking about a kind of metadiscourse that is at a different level of abstraction than the code. It cannot easily be done in prose either. This requires either interrupting the code with commentary or using a referencing system, such as line numbers. The latter is not terrible, but it pales in comparison to the approach I have used for years: using Google Docs' comment feature to comment on different parts of the document. Using this approach, both the student writer and I can evaluate the text. In fact, I wish I had one more level of abstraction: I would like to comment on the students' comments, not in a thread, but at another level yet. 

These qualities describe a writing environment unlike any I have seen. It would be an interesting HCI exercise to explore how one might interact with such a thing. One might start by looking at Google Wave (RIP) or Code Bubbles. In the meantime, I will have to keep using word processors like Google Docs that allow for the metadata stream of comments.

Updated postscript:

I was thinking about switching from Google Docs to Office365, but after that experimentation, I don't think it is fit for purpose either. It seems like Word insists that we are preparing documents that will be printed on paper, whereas Google Docs has long allowed for continuous, non-paginated documents. 

Course revisions: CS390 Preproduction

I wanted to switch into writing mode this week, but I recently received my teaching assignment for Spring, and some relevant decisions were looming over my head. Of the three courses I'm teaching, I knew that my Game Studio Preproduction—the first in the three-semester game production sequence—needed the most attention. I have taught this course twice, both times closely following Lemarchand's Playful Production Process. It provided a useful framework for me and my students as we built our new curriculum.

The game production sequence has been on my mind as I have read other books over the last year, including Vasco Duarte's No Estimates and Tynan Sylvester's Designing Games, both of which I blogged about, as well as books like Mike Sellers' Advanced Game Design, which I did not. I have been particularly troubled by my agreement with Duarte about the distinction between scope-driven and value-driven software development. The former is based on a fixed scope, which unbinds budget and time, and the latter is based on fixed budget and time, which unbinds scope. I wrote a paper about this distinction that I will be presenting in two weeks at the Symposium on Games. To make a long story short, most of the published advice about games draws from AAA production patterns and takes a scope-driven approach, but my experience and learned intuition suspect that my teams will have much better luck with value-driven approaches. Sylvester was one who really helped me put a pin in this idea when he wrote about how much of game production borrows concepts from other fields rather than embracing the idea that software is different—which, of course, it is. He also introduced me to the phrase "therapeutic planning," which he cites to Nassim Taleb and which I find terrifyingly evocative. 

As a result, I have decided to forego my previous approach to preproduction and, if it goes well, the production sequence next year. The scope-driven methodology will be replaced by an agile, value-driven one. Preproduction has an agile bias no matter how you slice it, but where this change makes the most material impact on the course will be in the expected deliverables. In the past two offerings, I have followed Lemarchand's advice and had preproduction culminate in a macro document and production schedule. My experience is that these are always spectacularly wrong, but you cannot exactly blame the students for this: given their limited experience, of course these will be quite wrong. Laying them out feels like therapeutic planning to me. I will replace the macro document and schedule with the concept document format proposed by Sellers, peppering a few of my perspectives and additions. Sellers' is a three-part document that includes a high-level description, a business-oriented product description, and a lengthy detailed design that captures core loops and interactions. I hope that the production teams will be able to use these document as more appropriate starting points once production starts, compared to the compounded awkwardness I have witnessed of having teams attempt to base production plans on poorly composed progenitors. On the contrary, something from Lemarchand that I have seen teams make incredible use of is an articulation of experience goals and design goals, and that is something I want to weave into Sellers' recommendations for concept documentation.

My previous sections included an explicit element of learning how to learn from a book like Lemarchand's, and I have no regrets about that: the students who engaged with the reading did learn significantly from it. This included spending significant time at the beginning of preproduction talking about and practicing techniques of ideation. This was usually interesting, but I realized that the student projects rarely had any significant connection to this part of the class. It is more like pre-preproduction. In my plans for Spring, I have cut this down to two in-class exercises that are designed more to get people talking and thinking than to generate anything weighty.

This change allows me to move into a slightly more structured prototyping phase, for which I am borrowing ideas from my colleague Travis Faas. I am putting a little more structure into the prototyping weeks, including constraints that I hope will foster creative problem-solving. My sketch right now includes a short paper prototype, a short experience with greyboxing, and two two-week explorations. My plan is for students to get into teams and settled on a direction just before Spring Break.

I still have a few holes to fill in my plans. For example, I would like to incorporate a structured analysis of successful games, showing students how they might reverse-engineer a Sellers-style concept document from a game that they have played. I would like to have everyone play the same one or two games so that we can share our analyses. If you have ideas of freely available games that would fill the bill, let me know. I'm seriously thinking of Rogue, given the popularity of "roguelikes" and the dearth of knowledge about the original, but I want to make sure I'm not doing it only for my own nostalgia.

Notes from Tynan Sylvester's "Designing Games"

I just finished reading Tynan Sylvester's Designing Games. The book was published in 2013, but Sylvester is probably best known as the creator of Rimworld, which came out a few years later and is not mentioned in the book. I have read many game design books, but I still learned a lot from this one. This inspired me to share some of my notes here.

Sylvester's core conceit is that games are artificial systems for generating experiences. He presents a model early in the book that undergirds the rest of the text, that a game provides mechanics wrapped in fiction, which produces events with fictional meaning, which produces emotions, which leads to an experience. I am a collector of definitions for "game," and I think this may be the strongest formalized definition I have encountered. I appreciate that it highlights what makes games different from other media, which is a theme that also comes up frequently in the text.

An early chapter discusses emotions and their role in game design. He uses the term "human values" to refer to anything that is important to humans that can move through multiple states, such as life/death, victory/defeat, and friend/stranger/enemy. I am not keen on his terminology here since it sounds relevant to morals or ethics, but I like the hook for thinking about design. It reminds me of the binary opposites that are essential to imaginative education. Sylvester provides a catalog of emotional triggers that can be used here, each of which is given appropriate exposition in the text: learning, character arcs, challenge, social interaction, acquisition, music, spectacle, beauty, environment, newfangled technology, primal threats, and sexual signals. 

I have long been familiar with the idea that players cannot truly answer what caused different emotions, but that they will construct a narrative to explain the phenomenon to themselves. I was not previously aware of the technical explanation known as misattribution of arousal and the psychological studies around it. Sylvester focuses on the "bridge" studies, and a little searching online finds that this is a robust finding. A related psychological concept he draws upon is the two-factor theory of emotion, which explains that what we call "emotion" is a combination of physiological arousal and a cognitive label. This explains how the same physiological stress response could show up in Tetris and in Doom, but the latter's fiction is what leads us to call it "fear."

I would have preferred that Sylvester give more precise definitions around his use of "elegance" and "emergence" since he does not adequately address Kate Compton's 10,000 bowls of oatmeal problem. It's one of a few chapters where I wondered how Sylvester might approach a second edition. No Man's Sky came out a few years after the book was published, and Sylvester's own work on procedural storytelling undoubtedly gave him new insights into these ideas.

Sylvester uses apophenia to describe how humans find patterns in noise, but I wonder if he uses it a bit too broadly. Apophenia describes phenomena like "lucky streaks" in gambling. Seeing a face in the clouds strikes me as different because our visual cortex is programmed specifically to find faces. Similarly, anthropomorphising a non-human character seems like it appeals to our narrative sense, not to a matter of pattern-matching. I wanted to track this observation from my notebook because it's an area where I think precision matters, but I realize I am not completely confident in my own ability to describe the edges of these concepts.

The need for frequent playtesting also recurs throughout the book. I am glad that it does since it is such fundamental advice. In his discussion of balance, he points out that what we should be gathering from playtesting is experiences and not suggestions. Again, the essence of this advice is the same in any game design text, but Sylvester presents it with admirable clarity and succinctness, especially given that he is working within a specific and explicit definition for "experiences." He points out that each playtest is a story, but you need to playtest until you can see past the stories into the systems. This gives me an interesting heuristic that I plan to share with my game production students.

His chapter on multiplayer games includes a section on game theory. I am no expert in this area, and I appreciate his layman's covering of Nash equilibria. He points out that the structure of rock-paper-scissors is the only elegant symmetric game without pure Nash equilibria and matching pennies is the only elegant asymmetric game without pure Nash equilibria. All other (game theoretic) games add more entries to the decision matrix without fundamentally changing the structure and are therefore inelegant. I don't usually turn to game theory in my designs, but I enjoyed this section for its clarity and perspective.

I was a little surprised to see him adopt the term Yomi from David Sirlin to describe how players "read" each other—how they predict, deceive, and outwit each other in multiplayer games. I used to follow Sirlin more closely, and I recently uncovered my copy of Flash Duel. It was fun to see his name show up, and I see he's working on a second version of the eponymous Yomi.

I am guilty of colloquially referring to dopamine as a pleasure-causing drug, but Sylvester is more careful in the book to distinguish between motivation and pleasure. Dopamine causes motivation, not pleasure. Remove dopamine from rats, and they will do nothing, not even eat, even though they can still enjoy sugar syrup that is fed to them. It is an important distinction and one I should be careful not to blur since this biochemical understanding allows us to talk more clearly about how games can motivate us to play past the point of enjoyment.

The third and final part of the book is devoted to process. I expected a recommended series of steps to create a game as offered by other texts. Instead, Sylvester opens the section by pointing out that a lot of our terms around process and management are actually borrowed from other disciplines: director, preproduction/production/postproduction. Here, he applies a similar perspective to the process design problem as he does to the rest of game design. One needs to recognize assumptions and evaluate them, realistically but not cynically. Although he is right, also later uses terms like "production" as if we all know what they mean, and I found myself wishing he was more prescriptive here like he was in the section on emotions and experience.

His advice on process comes down to the same observation made by the signatories of the Manifesto for Agile Software Development: work in tight iterations with good feedback loops. This appeals to my sense of lean production, that we should only as much management as necessary. When it comes to sequencing, his advice is to figure out the dependencies among needs and then work upward from there. Here, I would augment his advice with some observations from story maps a la Jeff Patton, but I don't disagree with him. Sylvester is explicit about keeping the game as low fidelity (that is, grayboxing) as possible throughout so that time is not wasted re-creating assets. He mentions that working with an artist or level designer is important, but he is mum about what those other folks might be doing while this grayboxing is going on. I would have liked to know his thoughts about this, given that I mentor fixed-staff student teams.

The chapter on authority is beautiful, and I plan to use it as an assigned reading. Although he does not use these terms, what he describes is an approach to creative management rooted in natural law and subsidiarity. In particular, he talks about how a team member has natural authority over their work, and how it is a mistake to arrogate that. (Note: I learned the word "arrogate" from reading this book even though I've been battling arrogators in ISS Vanguard for some time without looking it up.) This chapter dovetails nicely with the next, which is on motivation. It is clear that he believes the only way a team can succeed is in an environment of trust and respect. Indeed, he goes so far as to say that one can only succeed by "getting people you can trust and then trust them." I used to recruit undergraduates for special community-engaged game development projects, but now, any student can elect into the game development track that puts them into the game production sequence; I am not sure what it implies for my teaching if Sylvester is right. 

Speaking of teaching, I am reminded of the essential challenges presented by the need to grade students in creative projects. Grades are an external reward, and we know that external rewards can kill intrinsic motivation. What then is a professor to do? 

One of the final points in the book is that the best way to motivate a creative person is to ensure that they have constant, small, visible progress. This is the progress principle. It turns my mind again toward considering physical task boards to replace the convenient digital ones my teams used the last two years.

I thoroughly enjoyed the book, and I am grateful for how much I learned from it. I will certainly return to my notes once I start pulling together my plans for the next game production sequence, assuming I get assigned to teach a section or two. The book inspires me to draw more from my own learning to build a process that I believe in, which will be easier after having stepped away from team-teaching for now. I am not sure how much of the book would resonate with beginning designers, who, in my experience, need more structured explanation and exercises to get them into the right mindset. I think it's a valuable reading for someone who has already moved beyond the amateur steps though, once one has come to tacitly understand iteration and the challenges of communciation and motivation.

Reading "Fifty Quick Ideas to Improve Your User Stories"

I recently finished Fifty Quick Ideas to Improve Your User Stories by Gojko Adzic and David Evans. The book was strongly recommended by Dave Farley on his Modern Software Engineering channel. I have been using user stories for many years as part of my teaching and practice with agile software development, and I hoped that the book might give me some new ideas and perspectives. I read it with a particular interest in helping students manage game development projects.

The book itself is laid out simply: every two-page spread presents one of their recommendations. Each has a narrative, a summary of benefits, and then practical recommendations for getting started. From the title, I expected the book to be short and punchy like The Pocket Universal Principles of Design, but it contains a lot more detail. The authors are clear that the book is not an introduction to user stories; they assume the reader is already familiar with user stories and the jargon of agile software development. This is good for a reader like me, except that I had earlier lent the book to a student who was just learning the fundamentals. I would use a different resource for that purpose if I could do it again.

Here are suggestions from the book that struck me as potentially helpful to my teaching and mentoring. I have included the page numbers for ease of future reference.

Describe a behavior change (p14)

This is the second time recently that I have come across Bill Wake's INVEST mnemonic for user stories—that stories should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. The other place was Vasco Duarte's No Estimates, which I wrote about earlier this year.

The idea behind this recommendation is to quantify change. For new capabilities, "start to..." or "stop..." are simple quantifiers. I feel like there's something useful in here for introducing students to user stories.

Approach stories as survivable experiments (p18)

This tip is all about the perspectives of what stories allow. I often see students mistake stories for traditional requirements, probably because traditional requirements look more like school. Framing the stories as experiments may help students see that this is more creative and exploratory.

Put a "Best Before..." date on stories (p24)

I wish I had thought of this one. I have mentored student teams where they have a story in the backlog that only makes sense to do by a certain date or milestone. It's an easy one to remember, and it falls into a common pattern in the book: make the stories your own.

Aside: It reminds me of the advice about managing my curriculum vita that I received from my colleague Mellisa Holtzman many years ago. She said that your vita is your own, and that you should use it to tell a story rather than slavishly follow a template. She was right, both philosophically and rhetorically. My university recently moved to using a one-size-fits-none digital solution, and I was disappointed that there has been no discussion about the impoverished epistemology of such a move. 

Set deadlines for addressing major risks (p28)

This is similar to the previous one, and it references it as a technique: one can use learning stories that have "Best Before..." dates.

The authors distinguish between learning stories and earning stories, referencing an old presentation by Alistair Cockburn. This is a nice distinction as well that I am sure I can use.

Use hierarchical backlogs (p30)

Having spent the last year mentoring three teams with flat backlogs, it made me miss story maps, and I look forward to going back to them. Story maps come up explicitly on page 36 under the recommendation Use User Story Maps, which is just after the recommendation on page 34 to Use Impact Maps. Gojko Adzic also wrote a book on impact mapping. I have read most of it and find it intriguing, and I can see how it could be useful in a business environment. It didn't strike me as immediately helpful for my needs teaching the game design and development or the basics of agile software development.

Set out global concerns at the start of a milestone (p40)

The authors acknowledge that user stories cannot and should not capture everything that a team has to do. Writing emails or reading applicant vitae are examples of crucial work that is not directly related to a user story. 

Cross-cutting concerns such as security, performance, and usability should still be discussed, but they should manifest as something like a checklist that accompanies the whole process—not embedded or wedged into a user story.

Use low-tech for story conversations (p54)

The recommendation for whiteboards and sticky notes comes as no surprise to me. What did surprise me was that they caution against using a room with a large central table. Such a configuration makes people sit and opine rather than converse, and what comes out of the conversation (what we often call the "user stories" themselves) are just markers of that conversation.

Diverge and merge (p58)

When user story analysis is being done by a large team, they recommend breaking the team into smaller groups. Each group comes up with examples of user stories, then the groups compare their results. They suggest 10-15 minutes of divergence. 

In last year's game production studio, one team was much larger than the others, and I recommended that they break down story analysis by feature domain. I wanted each group to have representatives from Computer Science and from Animation. It worked reasonably well, but it was slow, and there were still a lot of holes in the analysis: cross-cutting ideas were lost. (Also, most of the students didn't know anything about user stories, and some harbored significant misunderstandings.) Next time, I will keep this advice in mind and have them work on the same context rather than different ones. I regularly have students push back on this kind of activity as redundant but this is because they have not yet experienced the productivity drop that comes from realizing later that the requirements were wrong.

Measure alignment using feedback exercises (p62)

This one jumped out to me because it sounds like it came right from a book about active learning techniques for the classroom. 

During user story analysis, rather than ask if anyone has questions, give the discussants a sample edge case and ask them an open-ended question such as, "What happens next?" Each writes their response, and then the team compares them. This shows whether there is shared understanding or not.

Reading this gets me fired up to use it in all of my teaching from now on. That's awkward since I won't be teaching again until Spring 2026. That gives me all the more reason for this blog post.

Split learning from earning (p90)

As mentioned above, this separates two kinds of stories. Learning stories still need a concrete goal that is valuable to stakeholders. An interesting corollary to this advice is that every story should be either learning or earning; if not, it is not really a user story at all.

Don't push everything into stories (p98)

I foreshadowed this one earlier as well. They advise strongly against tracking non-story work with user stories. An example they give is insightful: if such work is tracked in the backlog, and the stakeholders sort the backlog, then they will deprioritize work that does not generate value. The non-story work won't get addressed, then, until it is a crisis, at which point it becomes the highest priority, so there was no value in having it in the backlog.

Avoid using numeric story sizes (p102)

The two-page spread summarizes some of the key arguments behind the No Estimates movement. Here, they recommend that if someone uses T-Shirt sizes, to only use at most three different sizes. Better, they prefer Goldilocks sizing: a story is either too big, too small, or just right. Their conclusion is similar to Duarte's: just count stories.

Estimate capacity based on analysis time (p106)

If we know that planning for an iteration takes 5%-10% of the iteration time, then we can timebox the actual planning and then only work on the things that could be covered in that planning meeting. That is, use the planning meeting's duration as a heuristic for the scope of an iteration. This is clever, and the authors acknowledge that the moderator needs to prevent the meeting from getting too far into the weeds.

Split UX improvements from consistency work

They recommend having UX changes explored by a "mini-team" that explores and prototypes. The output of this mini-team's work are the user stories for the whole team, not exhaustive design specifications. The work of this exploratory team is on the learning side of the learning/earning divide. The mini-team can slipstream back into the main team to help with implementation.

This interested me considering how often I see teams struggle with questions of gameplay and engagement. "Will this be more fun?" is a good design question that can be approached through prototyping. Unfortunately, my teams often want to do this work as if the answer is a fait accompli. I wonder if this recommendation, together with the learning/earning split, will help me frame better for them what it means to answer the design question with a prototype first. The outcome would be the stories for the whole team to actually engineer a solution. I suspect I will encounter much of the same resistance I mentioned previously, where teams assume working on the "product" is more efficient than working in prototypes because they have never seen a product fail under bad design or bad engineering. I think this is why I prefer working with students who have tried hard things and seen how mistakes have consequences beyond a scolding or a bad grade.

Check outcomes with real users (p116)

The authors proclaim this as potentially the most important thing a team does. The important corollary here is that this requires one to write user stories the way one approaches TDD, or even how one ought to design learning experiences: focus from the beginning on an assessment plan.

The outcomes of the 2024-2025 Game Production Studio

I have been working with a multidisciplinary cohort of students from Computer Science, Art, and Music in the Game Production Studio for the past three semesters, team-teaching the experience with Antonio Sanders from Animation. At the end of this process, we had three games released for free on itch.io:

• Food Truck Cartel
• Milky Way Market
• Weatherbreak: Climate Overdrive

I am proud of the work these students have done, but it was a very different experience from the previous cohort. Our third cohort of students in the Game Design & Development concentration are currently wrapping up preproduction, but I have not been involved in that course. I am out of the sequence for a year as Travis Faas steps up to lead the sequence, which frees me up for Fall's sabbatical that I mentioned yesterday.

One of the primary differences between last year's and this year's cohorts was scale. Mentoring a single team of six students is very different from mentoring 25 students on three teams. Some things I did intuitively needed to have been more structured. The clearest example is the asset pipeline. Both years, there was a studio policy that everyone needed to be able to open and edit assets and get them into the engine. It was easy to confirm this with my smaller team, and for the larger one, I took students' word for it. It became clearer to me late this Spring that a significant number of students could not, and never did, know how to do this: instead, they relied on manual hand-off procedures. The point here is that, with a small team, I could simply observe them in every step and know they had met expectations, but with the larger team, that did not scale. "Trust" and "verify" needed to be coupled, especially since it wasn't even clear that the students who had previously certified their compliance with the protocols understood what it was all about. Release engineering and quality assurance were two other areas, along with asset pipelines, where I know that I will need more formalized approval processes in the future. I don't know yet how much those processes will look like industrial ones, with some kind of threat of firing or demotion, or academic ones, wearing traditional pedagogic trappings.

Managing three simultaneous teams made it difficult to determine the timing of iterations. We ended up keeping all the students on the same schedule, which meant that there was one day when each team was doing review and retrospective meetings. One of the best decisions my co-teacher and I made was to have both of us sit in on the review meetings, and that's something I need to keep for next time. However, in reflecting on the semester, I think I should have also been there for the retrospective meetings, at least at the beginning of production. This would help me model the process for the students. Also, it made me reflect on how in my immersive learning classes, it was the retrospective—not the review—where I made a lot of my pedagogic insertions. Once a team identified a pain point, I could direct them toward an industry standard solution via just-in-time teaching. If I have another large section, I need to consider staggering their iterations so that I can be at both meetings.

We gave our students a short written final exam that was inspired by the questions we used during team retrospectives. I took notes about their responses to the final question, which was to identify something that they would do differently during production, knowing what they know now. I consider this one of the most important outcomes of the entire three semester process, and so I will summarize their responses here. I have clustered their responses and removed any identifying information, of course.

Work management. We used HacknPlan to manage work, but each team had slightly different stories about how this didn't go as well as they would have liked. Several students commented that using physical, visible task tracking was far preferable. It makes me want to bring in the same kind of task boards that I used in RB368 for my immersive learning classes. How to do this with equitably in a shared lab is an issue to figure out.

Scope management. Several students commented on how their scope was not well under control. I have been thinking about this as well, especially since I recently read Vasco Duarte's No Estimates book, in which he advocates for having proximal work in higher focus than distal work. This is somewhat contrary to the advice given by Lemarchand in Playful Production Process, which is our reference text for the studio. Lemarchand advocates for having a full production plan at the end of preproduction, but at the same time, he recommends breaking down a production phase into iterations—without really explaining how one might do that. I think Duarte's model is going to be more helpful here, and I'm thinking about abandoning the entire "macro chart" element of preproduction in favor of epic stories.

Code quality. A few students commented on how they needed to have better control over their technical implementations. Some mentioned a bad habit of pulling the first tutorial they could find into their production code, and how this would lead to an unmanageable mess of ideas. Others talked about how they should not have tried to reuse the preproduction code since it was too quick-and-dirty. A few recognized that introducing more automation would have saved them a lot of trouble, but also that their failure to refactor meant that their code was not amenable to testing. 

Iteration. Some students recognized that they needed more iteration on their core design loops and on their assets. Our students had a bad habit of taking an inspiration directly into production without low fidelity prototyping and experimentation. It was good to see them talk about how they should have done more sketching and playtesting. I do wish they had appended "as you instructed us to do" to their answer.

Vision management. One of the strangest things to me is that, despite my repeated suggestion and admonition, I don't think any team had a vision statement: they didn't articulate design goals or experience goals. This either caused or is a symptom of significant problems. Conversations about design alternatives became about force of personality rather than alignment with a vision. It was good to see that some of the students recognized this and highlighted the need to articulate vision as something they would do differently. It is the kind of thing that, in my producer hat, I can demand of future teams, and in my professor hat, stick a grade on so they know I am serious.

Marketing. Some students recognized that decisions made in preproduction lingered far longer than they should have. This is strongly related to the previous point about vision management. From my perspective, it looked like these students were on the road to recognize that they were rationalizing the past rather than being intentional about the future. I see this frequently with my students, that they will tell themselves a story about what their vision must have been because it aligns with what they already did. It's very human. It's also dangerous for collaborative creative work.

Specificity. This final pattern in the students' responses caught me by surprise, and I was delighted with how students articulated such an interesting problem. Many recognized that their discourse throughout the project was often at a level of abstractions but that the design and development work they needed to do was at the level of concretion. Again, I think the lack of clear design and experience goals contributed here, but it's also a case that makes me think about techniques like Stone Librande's one-page design documents. Looking back at the three projects my students made this year, each one of them could have been expressed in a one-page design and hung on the wall.

It was a trip working with these students for the past three semesters. They should all be proud of their accomplishments: making games is hard! Some of them really impressed me by learning new things, working through social and technical challenges, and devoting themselves to solving hard problems. I love teaching this kind of class, but it will also be good for me to take a little break. I look forward to what a sabbatical can do for my perspective on some of these ideas.