Thursday, December 12, 2024

Reflecting on CS315, Fall 2024 Edition

As described in my course revision post in June, the overall structure of CS315 Game Programming was unchanged from previous semesters: half the semester was spent on weekly projects designed to build skills and confidence, and half the semester was spent on larger projects. 

The most significant change was in how those weekly assignments were evaluated. The past several years, I have used checklist-based evaluation, but I was hoping to find a fix for the problem of students doing the checklists wrong. This takes something simple and makes it into more work for me than if it was just a point-based rubric. Unfortunately, the strategy I used did not make things any simpler. Instead of checklists, I gave students a list of the criteria that needed to be met in order to be satisfactory. Their work then was assessed as Satisfactory, Needs Minor Revision (fix within 48 hours), or New Attempt Required. New attempts could be made at the rate of one per week, as I've done for years in most of my non-studio courses. I ran into a bit of the same problem as I wrote about yesterday, where Canvas' "Complete/Incomplete" assessment combined with no-credit assignments leads to a bad user experience, but it was not among the dominant frustrations. Those frustrations were two: students not submitting satisfactory work, and students not submitting work.

The first of those is the most disconcerting. As with checklist-based grading, I gave the students the precise criteria on which a submission would be graded. All they had to do was to meet those, and most of them did. Sometimes it took minor revisions or a new attempt or two, but these were no big deal: handling and correcting misconceptions is exactly what the system is supposed to do. The real problem came from students who submitted things that were wrong multiple times after I had told them what was wrong. In a strict reading of the evaluation scheme, this means the work was still simply unsatisfactory, whereas in other schemes (including checklist-based) they might have gotten a D or C for the work. I am still torn on this issue: was the system unfair to students of lower ability or was it the only fair thing to do with them? Put another way, is it better to give a student a C when they still have serious misunderstandings, or is it better to clearly tell them that they should not advance until they understand it? I don't interpret any of the criteria I gave as strictly "A"-level. That is, it did not require excellence to meet those criteria. What it required was rigor

The other problem, of students not resubmitting work that needed to be resubmitted, seems unrelated to the evaluation scheme chosen. Speaking with professors across campus and institutions, this seems to be part of a generational wave of challenges. I have a few hypotheses about root causes, but the point of this blog post is not to opine on that topic.

Some of my early-semester assignments take the form of multi-week projects. For example, the set of assignments involve creating an Angry Birds clone. It is submitted as a series of three assignments with increasing complexity, and the complexity is scaffolded so that someone who has never made a game before can follow along. I had a student in the class this semester who fell behind, and then he wondered if he could just submit the final iteration of that three-week project as long as it showed mastery of each week's content. I ended up declining the request. One of my reasons is that the assignments double as a sort of participation credit. It makes me wonder though if it's worth my separating these things. For example, something I've done in other courses in the past is make it so that the final iteration's grade supercedes earlier ones if it is higher. 

This was the first semester that a colleague offered a different section of CS315 during the same semester. Looking at his students' games, as well as some recent conversations in the game production studio, made me realize that I should probably emphasize the build process more in my section. Rather than simply running their games in the editor, I should ensure that they know how to create an executable or a web build. It's an important skill that's easy to miss, and there's a lot to be learned by seeing the differences between running in the editor and outside of it.

Now that we've grown the number of games-related faculty in my department, there's a chance I may not teach game programming again until 2026. I expect I will come back to these notes around that time. The biggest pedagogic design question I will need to consider is whether to return to checklist-based grading (with its concomitant frustrations) or move to something else, like a simple point distribution. 

Wednesday, December 11, 2024

Reflecting on CS222, Fall 2024 Edition

I had a little break from teaching CS222 last semester as I wrapped up work on STEM Career Paths. I have not blogged much about that project, but you can read all about it in my 2024 Meaningful Play paper, which I understand will be published soon. In any case, here I want to capture a few of the highlights and setbacks from the Fall 2024 class, and I promise, I'm trying not to rant about Canvas more than I have to.

Regular readers may recall that I tried a different evaluation scheme this semester, which I wrote about back in July. In September, I wrote a detailed post about some of my initial frustrations with the system as well as a shorter one about how I felt my attention being pecked away. I don't want to bury the lede, so I'll just mention here that to compute final grades, I went back to my 2022 approach, the tried and true, the elegant and clean system that I learned from Bill Rapaport at UB: triage grading. Between my failed experiment this semester and the similarly failed EMRF experiment from last year or so, I feel like I'm looking for a silver bullet that doesn't exist. It reinforces to me, yet again, that I should really be running some kind of workshops for local people here to learn about what makes triage grading superior.

I still want to track some of the specific problems of the semester, though, so that readers (including future self) won't walk into them. First, I tried to set up a simple labeling system in Canvas such that I could mark work as being satisfactory, needing a minor revision, or needing a new attempt. I made no headway here in part because of Canvas' intolerable insistence that courses are made up of points. I talked with a respected colleague who is willing to toil over Canvas more than I about his approach, and he mentioned that he encodes this information into orders of magnitude, something like 10 points for satisfactory, 1 point for minor revisions, and 0.1 points for new attempt required. Combining these together, students get a weird combination of numeric and symbolic feedback. He acknowledged that it wasn't perfect. 

What I tried to do instead was to use Canvas' built-in support for grading as "complete/incomplete." Because that was all I cared about, I set the assignments to be worth zero points. When I used SpeedGrader, sure enough, the work was labeled properly. It wasn't until midsemester that I downloaded all the grades as a spreadsheet and saw that it only gave me the zero points. That is, whether the work was complete or incomplete was stripped from the exported data set. There wasn't so much data that I couldn't eyeball it to give students midsemester grades, which was facilitated by my recent transition to only giving A, C, or D midsemester grades (which are epistemologically vacuous anyway). 

It wasn't until weeks later that it dawned on me that my students almost certainly had the same problem: Canvas was showing them zeroes instead of statuses. Of course, all my policies for the course were laid out in the course plan, and I do not have any qualms about considering those to be the responsibility of my students. However, when the university's mandated "learning management system" actively disrupts their ability to think about the course, it becomes more of a shared responsibility. About two weeks ago, I went in and re-graded all of the work to use triage grading instead, which allowed me to distinguish not only between complete and incomplete, but also between things that were submitted-but-incorrect and things that were not even attempted.

One positive change that I made this semester was counting achievements as regular assignments. This made processing them simpler for me, and I suspect it made thinking about them easier for the students too. While they have a different shape than the other assignments, they are "assigned" in the sense that I expect people to do them to demonstrate knowledge. I also set specific deadlines for them, spaced out through the semester. This reduced stress from the students by providing clear guidelines, since they could still miss one and resubmit it later by the usual one-resubmission-per-week policy. It also helped me communicate to them that the intention behind the achievements is that they give you a little side quest during the project-oriented portion of the course.

I had a really fun group of students this semester, as I mentioned in yesterday's post. There were still some mysteries around participation, though. I had several students withdraw a few weeks into the semester without ever having talked to me. It is not clear to me if they decided the course was not for them or if they were simply scared. By contrast, I know I had at least one student who was likewise scared early on, but who stuck with it, and ended up learning a lot. It is not clear to me if there is more I can do to help the timid students lean toward that mindset. Also, despite excellent in-meeting participation, I had many students who just didn't do a lot of the assigned work. I have some glimmers of insight here, but it still puzzles me: how many times do I need to say, "Remember to resubmit incomplete work?" I hope that some of the simplifications I have made to the course will help streamline students' imagination about it, but more than that, I am thinking about the role of the creative imagination. I am sure that a lot of students come into this required sophomore-level class without a good sense of what it means to study, to work, or to learn. My friends in the Biology department recently took their required senior-level professionalism course, in which students do things like make resumes, and made it a sophomore-level course. I wonder if we can do something similar to help the many students we have who are not well formed.

Tuesday, December 10, 2024

What we learned in CS222, Fall 2024 edition

My students are currently typing away, writing their responses to the final exam questions for CS222. As per tradition, the first step was to set a 20-minute timer and ask them the list off anything they learned this semester that was related to the course. This was an enthusiastic group with hardly a quiet moment. They listed 130 items in 20 minutes. I gave them each six votes, and these were the top six:

  • TDD (9 votes)
  • SRP (8 votes)
  • Code cleanliness (6 votes)
  • DRY (6 votes)
  • Git (6 votes)
  • GitHub (6 votes)
Here are all the items they listed, together with the number of votes each earned, if any. There some interesting items here that point to interesting stories of personal growth. It was really a fun group of students to work with, even though several of them exhibited some behaviors I still cannot quite explain, such as a failure to take advantage of assignment resubmission opportunities.
  • Flutter (1)
  • Code cleanliness (6)
  • TDD (9)
  • A new sense of pain
  • How to set up Flutter (1)
  • DRY (6)
  • SRP (8)
  • Mob programming (2)
  • Pair programming (1)
  • Git (6)
  • Version control (2)
  • Future builder
  • Setting up your environment
  • Asynchronous programming (1)
  • UI design (3)
  • GitHub (6)
  • Code review (1)
  • Defensive programming
  • Working with APIs (1)
  • Model-View Layers (2)
  • Teamwork (4)
  • Better testing (1)
  • What "testing" is (2)
  • Explaining code with code instead of with comments (1)
  • Understandable and readable code
  • Agile development (1)
  • Naming conventions
  • Functional vs Nonfunctional Requirements
  • User stories (2)
  • Paper prototypinig
  • CRC Cards
  • User acceptance testing
  • Programming paradigms
  • How to write a post-mortem
  • Resume writing
  • Knowing when something is done (3)
  • Debugger (1)
  • Time management (3)
  • Using breakpoints
  • Test coverage (1)
  • Modularization
  • Distribution of work (1)
  • Communication skills (1)
  • Discord
  • Dart
  • commits on git
  • pull using git
  • Flutter doctor
  • pub get
  • Configuring the dart SDK
  • Rolling back commits
  • Checking out commits
  • Going to office hours early
  • Commit conventions
  • CLI tools
  • Don't use strings for everything
  • Structuring essays
  • Enumerated types
  • Sealed classes
  • Better note-taking
  • Humans are creatures of habit
  • Parse JSON data
  • JSON
  • Refactoring (5)
  • How often wikipedia pages change
  • Data tables
  • OOP (2)
  • URL vs URI
  • One wrong letter can lead to the program not working
  • How data are handled in memory
  • FIXME comments (1)
  • Widgets
  • State management
  • Encapsulation (1)
  • Abstraction (2)
  • Presenting projects
  • Coming up with project ideas
  • Reflection (2)
  • pubspec management
  • .env files
  • Hiding files from GitHub
  • Serializing JSON
  • Personal strengths & weaknesses
  • Falling behind sucks
  • Software craftsmanship
  • Work fewer jobs
  • Finding internships
  • Remember to email about accommodations
  • Accepting criticism on resubmissions (1)
  • Procedural programming
  • You don't have to take three finals on one day
  • Painting miniatures
  • GitHub has a comic book
  • Being flexible
  • Dead code
  • Holding each other to standards
  • Bad and good comments
  • Aliasing
  • Reading a textbook thoroughly
  • Rereading
  • No nested loops (no multiple levels of abstraction)
  • Using classes is not the same as OOP (1)
  • SMART
  • A bit about the Gestwicki family
  • Places to eat in NY
  • Getting ink to the front of an Expo marker
  • How to clean a whiteboard properly
  • New York Politics
  • Data structures vs DTOs vs Objects (1)
  • Conditions of satisfaction
  • Setting up ShowAlertDialog
  • Handiling network errors
  • Handling exceptions
  • Build context warnings
  • CORS errors
  • Semantic versioning
  • Dealing with Flutter error reporting
  • Test isolation (1)
  • Don't make multiple network calls when testing
  • Improving test speed
  • Always run all the tests
  • You can test a UI
  • Writing 'expect' statements
  • Running tests on commit
  • Autoformatting in Android Studio
  • Testing in clean environments
  • Creating dart files
  • Hard vs soft warnings
  • Functioning on 0-3 hours of sleep
  • Configuring git committer names

Top Five Videogames of 2024

Over on the Indiana Gamedevs Discord, one of the organizers encouraged members to share their Top 5 (or Top 10) games of 2024. I am fascinated by the fact that most of the other developers' top games are things I have never heard of. A friend pointed out that games were becoming like music, where each person has an individual taste that might be completely unknown to someone else. Trampoline Tales put their favorites on their blog, and I figured I'd go ahead and do the same.

It may be obvious, but these are video games. I don't pay much attention to how many or what kind of video games I play during the year except occasionally to wince at the hours spent on a particularly catchy title. For tabletop games, I log my plays on Board Game Geek and RPG Geek, which makes it easy to collect the data I need to write my annual retrospective. For this reflection on video games, I was pleased to see that Steam makes it easy to see which games I played by month over the past year. GOG's website  and my Epic account show games in order of activity. All these data sets are somewhat polluted by a combination of judging for the IGF and acquiring (but not playing) freebies from Prime or Epic. 

I ended up with seven games that were contenders for my favorite five of the year, but the ones I've chosen to list below really stood out from the others. These were not the only games I played, and in fact, they were not even the games I played most. There are some games I played this year that I found deeply disappointing, but I will probably keep those as internalized design lessons rather than writing a separate post about them.

Here are the five I listed for my fellow Indiana gamedevs, along with links and a very short blurb about them. 

  1. Dave the Diver
    I didn't know much about this game except that it was popular. I found the whole experience to be delightful.
  2. Tactical Breach Wizards
    Turn-based strategy, defenestration, and magic. One of the characters had an ability that I still think about, something I've never seen in a game before that is beautiful, elegant, thematic, and hilarious.
  3. SKALD: Against the Black Priory
    This is a wonderful homage to classic CRPG gameplay with just enough modern twists to feel fresh.
  4. Balatro
    This is a great example of a simple idea taken to a logical and beautiful end.
  5. Steamworld Heist II
    A sequel to one of the most interesting takes on the turn-based tactics genre, combining a 2D camera and platform elements with robots and firearms. Fun battles and rewarding power escalation.

Tuesday, November 26, 2024

Bloom's Taxonomy, Teaching, and LLMs

Recent discussions of LLMs in the classroom have me reflecting on Bloom's Taxonomy of the Cognitive Domain. Here's a nice visual summary of its revised version.

Blooms Taxonomy of the Cognitive Domain
(By Tidema - Own work, CC BY 4.0, https://commons.wikimedia.org/w/index.php?curid=152872571)

Bloom's Taxonomy, as it is called, is a standard reference model among teachers. The idea behind it is that a learner starts from the bottom and works their way upward. As far as I know, it has not been empirically validated: it's more of a thought piece than science. This is reflected in the many, many variations I've seen in the poster sessions of games conferences, where some young scholar proposes a play-based inversion that moves some piece into a different position on the trajectory. All that is to say, take it with a grain of salt. The fact remains that this model has had arguably outsized influence on the teaching profession. (Incidentally, I prefer the SOLO taxonomy.)

There's been a constant refrain the past few decades among a significant number of educators and pundits that technology has made obsolete the remember stage. Why memorize this table of values when I can look them up? Why remember how this word is spelled? Spellcheck will fix it for me. My skepticism of the concept has only increased as I have worked with more and more students who use digital technology as a crutch rather than a precision instrument.

LLM-generated code comes up in almost every conversation I have among teachers and practitioners in software development. There are ongoing studies into the short- and long-term implications of using these tools. My observations are more anecdotal, but it's no exaggeration to say that every professional developer and almost every educator has landed in the same place: LLMs can generate useful code, but knowing what to do with it requires prior knowledge. That is, the errors within the LLM-generated code are often subtle and require knowledge of both software engineering and the problem domain. 

From the perspective of Bloom's taxonomy, a developer with a code-generating LLM is evaluating its output. They come to their evaluation by building upon the richness of cognitive domain skills that undergird it. At the very fundamental level, they bring to bear a vast amount of facts about the praxis of software development that they have remembered and understood.

If Bloom is right, then among the worst things we could do in software development education is throw students at LLMs before they have the capacity for viable evaluation. Indeed, before LLMs, the discussion around the water cooler was often about how to stop students from just searching Stack Overflow for answers and submitting those. Before Stack Overflow, it was that students were searching the web for definitions rather than remembering them. My hypothesis for learning software development then is something like this:

  • Google search eliminates the affordance for learning to remember.
  • Stack Overflow eliminates the affordance for learning to understand.
  • LLMs eliminate the affordance for learning to apply.
This hypothesis frames the quip that I share when an interlocutor discovers that I am a professor and, inevitably, asks what I think about students using ChatGPT. My answer is that I'm considering banning spellcheck.

Monday, November 25, 2024

Walking away from a November game project: A reflection on NoGaDeMon 2024, Dart, Flutter, and Bloc

I would hate to make this a tradition, but it seems that I once again entered NoGaDeMon. National Game Design Month (NaGaDeMon) is November, and for several years, I created interesting little projects during the month. Last year, I was not able to pull a project together, and I'm afraid that's the case this year as well. However, I was able to learn a bit through the attempt, so I want to capture some of it here before it slips away.

Before November, I had been tinkering with an intersection of ideas related to posts in the last few months: interactive narrative games like my The Endless Storm of Dagger Mountain, which drew from the Powered by the Apocalypse tabletop RPG space, built around some concepts from Blades in the Dark and Scum & Villainy. I figured that, for November, I would try building a very small slice of the idea. For various reasons, I also wanted to try building and releasing a game using Dart and Flutter. I dug in and started making reasonable progress for a side project.

A few days into November, John Harper released Deep Cuts, a campaign and rules expansion for Blades in the Dark. I bought a copy and was quite surprised at the rules changes. I had expected little tweaks and balancing maneuvers, but Deep Cuts actually provides a complete overhaul of the most fundamental Blades action resolution system. This was too cool not to play with, so I rehashed my planned NaGaDeMon project, essentially starting from scratch to support some of the Deep Cuts ideas.

Before last week, I was able to get a very small version of the game working, letting the player experience a single, badly written game scene. The user-interface was just awful, so in order for the game to come together would have required adding a ton of content and a complete player experience design and implementation. Both of those would be tedious efforts, especially the latter, since I am not very fast with Flutter UI development. Part of the inspiration for choosing Flutter was to gain more practice with engaging UIs. 

About two weeks ago, the work of one of my committees exploded into taking most of my unassigned work hours, and this was not altogether unexpected. We also just got the good news that we will be hosting family for several days around Thanksgiving. This will be wonderful, although it also means these won't be hobby-project days. The result is that I've decided to put this project to rest. I did learn quite a bit going this far into the project, and that is the topic for the remainder of this post.

First of all, the obvious lesson is that if I wanted to really focus on learning to make a top-notch interactive Flutter UI, I should have chosen something with zero other design risks. I knew that the best I could do in one month was to make something just functional, yet I am not sure I was honest with myself about how ugly that would likely end up. Maybe I will find a game jam that will let me get a better handle on combining turn-based game timing with implicit animations.

Prior to November, I had been tinkering with some of these design inspirations in Godot Engine, which is of course the engine I used to build The Endless Storm of Dagger Mountain. I was using a rather conventional mutable-state object-oriented architecture. I found myself frequently frustrated by the lack of good refactoring tools for GDScript. This is a significant hindrance to evolving an appropriate design. This is part of what made me switch over to Dart, which is a joy to work with in part because of the excellent tooling support from Android Studio. 

A few summers ago, I spent a great deal of time studying Filip Hracek's egamebook repository. Nothing shippable came out of my efforts—I don't think I ever even blogged about it—but I did learn a lot. I was struck by how Hracek separated the layers of his architecture, and it was the first time I spent a lot of time in a game that used immutable data models. At the time, I had looked into the Bloc architecture and struggled to make sense out of it.

Approaching this November's project, I decided to dig deeper into Bloc. I spent a lot of time with the official tutorials and puzzling over this seemingly simple diagram:


The simple tutorials are simple, which is convenient, but the more robust ones separate the "data" component into a data provider and repository. It seemed clear that the game state could be conceived of as data, but I struggled to conceptualize where the game rules should live. The game rules can be considered part of the domain model, and as such, should be separated from the bloc. This would mean that a response from the domain model may be the modified game state, which then is echoed back through the bloc to the UI with a bloc state change. However, it's also reasonable to conceive of the game state itself as the data layer and the "business logic" as being the transformations of that state. Indeed, this seems to be the difference between the simple and more complex tutorials: the simple ones deal with simple in-memory state, and the more complex ones draw data from different sources and transform them in the data layer. 

Of course, there is no silver bullet. Given the tight time constraints on the project, I simply considered the immutable game state to be my data layer, and I put the game logic in a bloc. I also simply passed the game state along to the UI, but in a more robust solution, I would have had clearer separation between layers. Including a dependency between the UI and the data layers was a matter of expedience and the intentional incurring of technical debt.

My first pass at the implementation had me writing my game states and bloc states by hand. The Equatable package meant that I didn't have to fret over writing some of the boilerplate that's necessary to do state comparisons, and it was easy to integrate this in Android Studio using Felix Angelov's Bloc plugin. When scouring the Web for help with Bloc, one quickly also comes across discussions of Freezed, which library is also integrated into Angelov's plugin. I had tinkered with Freezed in my egamebook-inspired explorations, but I have not shipped anything that uses it. After having built up my understanding of Bloc using Equatable, Freezed was an obvious next step. Next time, I would jump right into using it for cases like this.

Writing a functional Flutter user-interface was straightforward using BlocBuilder. I found this to be a convenient way to conceptualize the game, especially since it had very clear states. For example, in my original explorations (before Deep Cuts), I had the player choosing an action from a list, then customizing the action with various options from Blades in the Dark, such as pushing yourself to trade stress for dice. After rolling the dice, the player is now in a different state of the game in which they are responding to the result, such as by resisting its consequences. This was elegant to express in the code, and I am confident that with enough effort, I could make a compelling user experience out of it. By contrast, Dagger Mountain used an architecture inspired by MVP but that depended too heavily on the undocumented, unenforceable behavior of coroutines. Both of these are "only jam projects," but they are helping me to conceive of how I would approach something more significant in this problem domain. The aforementioned coroutines were my solution to synchronizing the model and view states (for example, to finish an animation before continuing to the next step of the narrative); I'm fairly certain I understand how I can do that with bloc's events and states, but since the November project will remain unfinished, there is risk.

All this exploratory coding meant that I did not follow a test-driven process. I ended up not getting into the testing libraries specifically for bloc. It's possible that this would have helped me better to conceptualize the business logic versus the domain layer, but that remains future work. 

There are still a lot of questions about the game design itself. Indeed, this entire exploration is inspired by design questions around the adaptation of Blades in the Dark tabletop gameplay into a digital experience. Citizen Sleeper is the only project I know of that has worked in this space, and it's a fantastic interpretation. I only became aware of Citizen Sleeper after I started doodling my own ideas, and it's interesting to see where they converge and where they diverge. I hope to dive back into this design space later, but for now, my attention must go toward wrapping up this semester, planning for next semester, and enjoying the upcoming Thanksgiving break.

Wednesday, November 13, 2024

What people believe you need to do to be an independent game developer

Aspiring game developers are starving for advice. I recently attended a meetup of game developers where an individual gave a formal presentation about how to become an indie. The presentation was thoughtfully crafted and well delivered, and it was entirely structured around imperatives—the things that you, the audience member, need to do if you want to be a successful independent game developer. The audience ate it up and asked for more. They were looking for the golden key that would unlock paradise.

There are two problems here, one overt and one subtle. The overt one is that there is no golden key. There is no set of practices that, if followed, will yield success. I imagine most of the audience knew this and were sifting for gold flakes. However, it was also clearly a mixed crowd, some weathered from years of experience and some fresh-faced hopefuls. I hope the latter were not misled.

The subtler problem was made manifest during the question and answer period when it became clear that the speaker was not actually a successful indie game developer at all. Their singular title had been in development for three years and had just entered beta. They had no actual experience from which to determine if the advice was reasonable or not. The speaker seemed to wholeheartedly believe the advice they were giving despite not being in a position to draw conclusions about their efficacy.

Once I saw the thrust of the presentation, I started taking notes about the kinds of advice the speaker was sharing. 
  •  Document everything, and specifically create:
    • Story and themes document
    • Art and design document
    • MDA document
  • Have a strong creative vision
  • Be a role model for the work environment you want
  • Consider these pro tips for hiring staff:
    • Use a report card to score your candidates
    • Look for ways to get to know what it would be like to work with them
    • Try collaborating with them as part of the interview
    • Always have a back-up candidate, not a top candidate but someone you know you could work with
    • Being their best friend does not mean you should work with them
  • Thank people for their contributions and efforts
  • Use custom tools to help you work better
    • Use the Asset Store in Unity
    • Use tools to help you test
    • Automate as much as you can to save you time
    • Learn to prompt so you can use generative AI
      • It allows an artist to be a developer by removing coding barriers
      • LLMs can replace tedious use of YouTube, Google, Reddit, etc.
  • When pitching to publishers, have two versions of your slide deck:
    • pitch slides: the version you send
    • pitch presentation: the version you present
  • Take budgeting seriously
    • Budget for specific deadlines
    • Don't spend your own money if you can get money from someone else (e.g. publisher)
    • Get a job so that you can support yourself until you can get funding from someone else for the game project
      • Quoting one of his professors: "To make money, you need to spend money, and to spend money, you need money."
  • Don't get distracted by others (e.g. on social media)
These aren't the things you need to do to be an indie game developer. These are the things that an audience believed you need to do to be an indie game developer or the things that someone with a modicum of experience thought would be worth telling indie hopefuls. It seems to me that this is the advice you would get if you spent an afternoon collecting advice by searching the Internet. It's helpful for me to have a list of what people are likely to believe from consuming popular advice. Sometimes advice is popular because it is accurate; sometimes people tell you to make your game state global.

Three other things jumped out at me about the presentation. First was the unspoken assumption that one would be using Unity. There was no indication from the speaker that this was even a choice, and none of the questions reflected on it. Second, the speaker acknowledged the importance of automation and automated testing, which was great to see. Third, no one pushed back regarding the use of CoPilot or other LLMs to help with coding, whereas I suspect there would have been a riot had he suggested using the same tech to generate artwork. There's a study in there.

Tuesday, November 12, 2024

Serendipity

As mentioned in yesterday's post, I was at Meaningful Play 2024 a few weeks ago, and I'm finally processing the many pages of notes that I took there. 

Sabrina Culyba gave the morning keynote on that last day of the conference. She spoke about serendipity in game design, sharing a compelling story about the development of Diatoms. The talk was brilliantly prepared and executed. She summarized research findings around serendipity that shows that the following factors can affect its likelihood:

  • Having a prepared mind
  • Openness
  • Being connection-prone
  • Belief in serendipity
These are really interesting, and if I didn't have a pile of other research projects in the hopper, I'd be curious to dive into the literature here. The first item sounds like a variation on the maxim, "Luck favors the prepared." The second sounds to me like the eponymous Big Five personality trait that tracks with creativity.

I don't have much else to contribute to the discussion, but it's a neat idea that I don't want to waste away in my notebook.

Monday, November 11, 2024

Fantasy heartbreakers

 I am currently reading William White's Tabletop RPG Design in Theory and Practice at the Forge: 2001-2012 after having met the author at MeaningfulPlay. This excerpt from Chapter 3 made me shout with delight at having a name for a phenomenon.

A fantasy heartbreaker was [Ron Edwards'] term for an independent game that contained interesting innovations, usually without realizing that they were in fact innovative, but whose designers had failed to fully examine their underlying design assumptions—thus producing games that were highly derivative of D&D, whether or not that was actually a design goal of the game—and who were either naïve or overambitious in their expectations for success in the marketplace. (p.93)

Ron Edwards' original post on the topic is cited, but I haven't made the time to read the source yet. White's summary was enough to excite me and want to share it here.

Tuesday, October 1, 2024

Paper!

I have a pile of things to grade, seemingly unlimited committee work to complete, and major decisions to make. I am having a bit of a stressful week. But you know what I just did that made me so happy that it's worth taking the time to write a blog post?

I graded something on paper.

My new coworker Travis Faas shared with me a format he uses for peer critiques during his game programming class. It's something I want to draw into that class. Today, in CS222 Advanced Programming, my students were to showcase their two-week project submissions. I've traditionally done this in an unstructured way, something like an academic poster session. Just a few minutes before class, I thought to myself, "What if I tried out that crit format here?" I literally did not have time to lay out even the simplest of templates, so I just grabbed a stack of blank white paper and headed downstairs to class.

I told the students that, during their showcase, they had to write at least three outcomes from their discussions. I suggested (following Travis) that these could take the form, "I learned X," or, "Y is something I want to learn more about." I also foreshadowed that there would be a secret final step.

As always, they walked around with real interest in what each other had done. This time, however, they paused after each station and jotted little notes on their paper. What might otherwise be fleeting thoughts were tracked, held on to.

Once we were done—and gave out the Audience Choice award, of course—I gave them the final step: to write down some action that they plan to take next that relates to the outcomes of their discussion. I gave them two or three minutes to do this before collecting their papers.

Both of my Tuesday/Thursday classes had major deadlines today, so it was quiet during office hours. I sat down in my chair, grabbed my favorite pen, picked up the stack of papers, and read through them. On each, I gave a little, hand-written affirmation, encouraging students or providing tips on how they might move toward their goals.

Paper! Wonderful paper!

I am looking forward to turning back their papers on Thursday. I wonder when the last time was for them that they had such a human experience as handing a teacher their ideas and then waiting, waiting without a chance of hearing from me about them before our next meeting. No anxiety about checking grades. No notifications. Quiet, from which comes a chance for peace. 

Paper!

Tuesday, September 24, 2024

Grading rather than improving

I talked too much today. I had back-to-back 75-minute class meetings, first of CS222 Advanced Programming and then of CS315 Game Programming. Both times, I spoke almost the whole time. I would much rather have had structured exercises to help teach what I wanted to show. It wouldn't have been that hard to set them up, just an hour or two each of setting up a template project that demonstrates what I want to show. I don't have an hour or two for each meeting for each class. I have filled my allocated class time with grading. This is partially due to the new grading system I am using. I'm having a lot of back-and-forth with my students. Turns out that getting them to mastery is a lot harder than giving them partial credit. I believe it's bearing fruit. But it's also taking all or more of the time I can give to a class. 

I am not sure what the path forward is. I will do less grading later as both classes move from individual lessons to large project integrations. Then, however, it's too late: we will have passed the point in the semester where a strong introduction is better than 75 minutes of my talking.

Thursday, September 19, 2024

CS222 and CC17

It has been many years since I have required my CS222 Advanced Programming students to read chapter 17 of Robert Martin's Clean Code. This chapter is entitled "Smells and Heuristics," and it contains a wonderful collection of common code problems and potential solutions. This year, I had my students read the chapter just before starting our two-week project, and I gave them the challenge to pick three items from the reading that were particularly interesting to them. These were fun for me to read, displayed thoughtful reflection on programming, and to top it all off, were easy to grade.

Some of my favorites showed up in the students' responses, such as the advice to extract conditionals into named functions, to replace magic numbers with named constants, and to avoid selector arguments. Feature envy showed up more than once, which surprised me. Students recognized that some of their previous courses actually habituated them to these smells rather than their cleaner alternatives.

I need to remember to keep this assignment. I plan to ask my students today whether they think this chapter would have made a good introduction to our reading rather than a capstone on it. Because the chapter is so accessible, it's possible that reading it first might help them get better faster, and to do so before they get into the trickier distinctions such as SRP (Chapter 10) and the distinction between objects and data structures (Chapter 6).


Wednesday, September 18, 2024

Docs is code

Clint Hocking's birthday blog post led me to look at the EXP tabletop roleplaying game, and in turn, that got me looking at AsciiDoc and the Docs as Code movement. I understand completely the arguments that AsciiDoc makes against Markdown. Regular readers will recall that I experimented with converting my course plans to GitHub-hosted Markdown and almost immediately backed away from it: Markdown almost immediately requires a polyglot approach for anything significant. However, I don't see AsciiDoc nor Docs as Code as addressing what I consider the most important tool for technical writing: the ability to embed scripts.

I have been using lit-html for years (and Polymer before that). What it lets me do is separate the structure of my writing from its display. For example, when I write an assignment for my students, I might conceive of it as having a list of objectives. In Markdown, AsciiDoc, or even HTML, I could easily represent that information as an ordered or unordered list. Later, however, I might decide to change the representation, instead showing it as a definition list, or making sure the name of the objective is bold, or generating unique links to each individual objective. In any of those plain markup environments, I have to do this by hand or, worse, with a regular expression.

What I don't see from Docs as Code, although I admit I haven't done more than a cursory search through their materials, is the observation that docs is code. If I separate my model and my view, I gain a robustness that any journeyman programmer understands. For example, using lit-html, I can create a simple JavaScript data structure that represents a goal, with a name and a description. Either or both of these can be html templates, not just strings. With that structure defined, I can create a list of them for an assignment. Now, on my first pass, I show them as list by iterating through the list and dropping the data into list items in an ordered list. When my requirements change—as they always do—I can modify my script and make the same data into a definition list, section headings, etc. If I need to change the actual definition of an assignment goal, I can make that change explicit.

Of course, the whole thing is in version control with sensible commit messages.

I have taken a similar approach in the past to build documents using LaTeX, coordinating the execution of multiple scripts through GNU Make. That works when LaTeX is needed for document output, but it feels less elegant to me than being able to generate the HTML directly from the Javascript.

If you know of an approach in the AsciiDocs or Markdown vein that gives the same level of robustness as what I can do with lit-html, please let me know.

Tuesday, September 3, 2024

A Morning with Scum & Villainy

After writing about my first experience with Blades on the Dark, I heard from a friend who recommended that I also look into Scum & Villainy. It is a sci-fi interpretation of the Blades in the Dark rules following the Forged in the Dark license. I use "sci-fi" intentionally since the rules and setting lend themselves to space westerns or space operas—anything with scoundrels on spaceships—but it would be difficult to do science fiction with them. The rulebook makes it clear that it's drawing on the "rag-tag group of outlaws traveling across the sector" trope as seen in Firefly and Cowboy Bebop. Both are clearly space westerns.

This theme is a good thing, and those two shows are among my favorites. It is a shame, then, that one of the first things one notices on opening the book is that it doesn't mesh with these themes. Blades in the Dark sings out its theme in graphic design and illustration. In contrast, Scum & Villainy feels like it cannot decide what it wants to be. This is exacerbated by the initial impression given when the structure of the book and much of the copy itself are taken verbatim from Blades in the Dark. None of this is inherently bad, but it gave a negative first impression after having been given such a strong recommendation to read it.

The few mechanisms added to Blades are quite good. Developing your ship rather than your headquarters captures the theme well, also lending the feeling of an episodic series. Getting bonus dice from gambits is a welcome addition to my group, since they have a penchant for beating the odds by rolling consistently low.

My favorite addition consists of the three starting scenarios, one for each of the ships. Playing Blades in the Dark, or even just reading and imagining it, it wasn't quite clear where to start. Scum & Villainy gives more tightly scripted introductory scenarios. At least two of them boil down to simple chase sequences, but there is nothing wrong with that. Each of these scenarios has just enough background to fill in details as needed, and each one provides clear hooks into the next episode. On top of that, there three outlines for other, unrelated jobs that are fit for the theme of the selected ship. 

We got the game to the table yesterday morning, and I played with my three eldest sons. My third son had previously expressed disinterest in tabletop roleplaying games, having not enjoyed whatever fantasy game we had tried together once years ago. I convinced him to try this one, knowing that he's a storyteller at heart, and he and his two older brothers had a great time. They chose to be bounty hunters on a Cerberus ship, playing a Scoundrel, a Pilot, and a Mechanic. We played the recommended started mission: tracking down a member of the Ashen Knives gang with multiple bounties on his head. There was a little hiccup due to an ambiguity in the scenario description, but once we got into that, we had a blast. The two older boys had a handle on the action resolution protocol as well as the role of flashbacks. They used flashbacks much more successfully as part of the storytelling than in our two Blades games, using them to set up a two-pronged assault on the mark's location, and then using one to set up and soup up hoverbikes for big chase scene. A glorious failure by the Mechanic led to a potentially disastrous desperate situation for the Pilot, but he used a gambit and pushed himself to ace it. It was exactly the kind of thing one wants out of a chase scene.

There are a few places where Scum & Villainy falls short of its august predecessor, doomed perhaps by its own lineage. For example, in Blades in the Dark, there are sensible limits on how much coin (or value in coin) a person can carry or that one can stash. This is actually quite interesting, a point that I don't remember seeing before: you can only carry so much money, and you can only have so much liquid cash, particularly in a Victorian setting. Scum & Villainy borrows this mechanism despite it describing money as being kept as software on credsticks. Also, while both games admit that any given action may be sensible under multiple action ratings, the action articulation in Scum & Villainy feels more forced than Blades'. I suppose, due to my career, I am particularly puzzled by how the Doctor action rating is for "doing science" and the Study action rating is for "doing research." It makes me wonder about how I would take the Forged in the Dark idea and put it into a setting of my own choosing, as many others have done. For example, making Kapow! years ago was a great exercise in understanding how Powered by the Apocalypse ideas could apply to campy 1960's superhero action.

I find the setting of Blades in the Dark to be more intriguing, but the setting of Scum & Villainy appeals to me personally while also being a "safer" space to explore with my boys. One could do a sci-fi criminal gang drama, but maintaining a ship vs. expanding gang turf really pushes toward the Firefly vibe. Scum & Villainy certainly stands alone, although there are parts whose rationale would make more sense if one is familiar with Blades in the Dark. Reading the Blades book was enough to see why there has been so much excitement about it,  even though I know I'm late to the party. The Scum & Villainy book may have lacked some of this pizzazz, but the table doesn't lie, and we had a great time. 

Initial reflection on Bowman-style grading

I had my first batch of submitted student work last week, and I would like to share some reflections on exploring a new grading system. As I mentioned over the summer [1,2], I have revised two of my courses to use a new grading scheme. CS222 Advanced Programming and CS315 Game Programming are both using a technique that I have lifted from Joshua Bowman's work. This technique looks at each goal and assesses a student's contribution into one of four categories:

  • Successful
  • Minor revisions needed
  • New attempt required
  • Incomplete
The first and the last are clear, but I found myself tripping up between the middle two. I think this is in large part to an important distinction between this technique and Rapaport-style triage grading, which I have used for years. In that model, you have four categories as well:
  • Done and correct
  • Done and partially correct
  • Done and clearly incorrect
  • Not done
The distinction between "partially correct" and "clearly incorrect" is very clear to me, and these are the second and third categories for Rapaport. I started using that as a heuristic to differentiate between "Minor revision needed" and "New attempt required," but I don't think that's right. With Rapaport's approach, "partial correct" captures a huge category of errors that one would put into the "C" letter grade bin: such a submission has some elements of correctness but significant flaws. I think Bowman's "Minor revisions needed" is much closer to Rapaport's "Done and correct." Clearing up the differences between these two rubrics caused me to have to re-grade many submissions.

Bowman's philosophy, which I am also bringing to bear in my classes, is grounded in mastery learning. Hence, recognizing the affordance for resubmission is fundamental to understanding the system. I knew I wanted to throttle my students' resubmissions, so I set up a two-tier system. With minor revisions needed, students could make the necessary tweaks within three business days, then get full credit for their submission. With new attempt required, or if they didn't make minor revisions within three business days, they could resubmit at most one per week.

I switched to Bowman's model in an attempt to clarify evaluation, and I'm already confused. I think this kind of system could work brilliantly if there were any tool support for it, but every gram of this technique fights against Canvas. Not only does Canvas lack robustness to anything but the least interesting of point-based pedagogic models, it and its LMS ilk breed an intellectual laziness among the students. The student usage pattern is to look at how many points were earned and then ignore any formative evaluation. My conclusion so far is that doing this on paper would be a great improvement over using Canvas if it weren't for the fact that my students' submissions are often inherently digital and not just accidentally digital.

It is early in the semester, but I have yet to see that Bowman's approach is going to be any more clear that Rapaport's. I've been using Rapaport-with-resubmissions, and that fills the middle ground between a clear representation of points and clear feedback about which parts are wrong. I will have to give it another two or three weeks to see how students respond before I make any systemic changes: there hasn't been ample time to get complete submit-evaluate-resubmit-evaluate loops from enough students yet.

Last year, I experimented with EMRF grading and ended up quickly dropping it. Canvas had no clear way to express this system either, and I did not see any clear benefit from distinguishing between "excellent (E)" work and "meets requirements (M)". It's easy to blame the tool for its shortcomings, and in this case, that's exactly the right thing to do. I know folks who "make it work" with tricks and hackery, but in my mind, there is no excuse for having a system that demands that the only real part of a class is something that has points and contributes to a pool of points. It's not how learning works, and it's never been how teaching should work.

Monday, August 26, 2024

An Afternoon with Blades in the Dark

I heard about John Harper's Blades in the Dark tabletop role-playing game from a talented undergraduate student around 2018. He was creating his own RPG as part of a games research group I was running, and he regularly brought up Blades along with the Powered by the Apocalypse movement as inspirations. I came across it again when looking for information about non-hit-point damage systems, which Blades has, although not via inventory manipulation—the particular topic of my investigation.

I bought a copy of the rules, read them while on family vacation at the end of the summer, and found them quite inspirational. It made me want to run a session or two in order to see the systems in motion. As anyone who enjoys tabletop games knows, it's one thing to read the rules and another thing to try running them: the latter exposes ones incomplete knowledge from the former. I hesitated to invite my boys to play though because of the vicious nature of the game. Blades in the Dark is a game in which you play a scoundrel who is part of a criminal crew. You advance in the game through illegal and immoral activity. I prefer to encourage fantasies about heroic living. Yet, I found myself thinking about how one can learn from stories of heroes and of villains, and if nothing else, I knew my boys would also enjoy experience the game and exploring its setting. 

In my retelling of our experience, I want to highlight places where I felt unsupported by the book and online resources. This is constructive criticism meant that I hope myself and others can use to improve future sessions of this and other games. Note that in this blog post, I will be freely referencing rules and lore from Blades in the Dark. If you are the type who enjoys reading or playing role-playing games, I recommend you pick up a copy. That said, you can also get an overview of the rules from the public System Reference Document.

We played for about three hours on Sunday afternoon, during which time we created characters and crew and completed one score. I had downloaded and printed the recommended materials, and so we dove into character creation. I had also crammed a lot of lore into my memory, which made it harder to introduce the game at a high level. I would have liked a canned paragraph I could read to set up the experience for new players. It was also too late for coffee, which could have been a contributing factor. Also, my boys, because they are my boys, are probably not familiar with any of the cultural touchstones that are referenced in the rulebook: we just don't watch stories about criminals and antiheroes, and I myself had not heard of most of the things in the list.

The playbooks were useful for letting the boys start creating their characters. One picked a Leech (saboteur, tinkerer, alchemist) and the other, a Hound (sharpshooter,  tracker). Among the first decisions one makes in character creation is choosing a heritage, and here is another area where a handout would be useful. The book has short descriptions of each, but the playbook only lists the name. A simple handout that gives a single sentence about each would be sufficient for a table of players to pick the one they like; otherwise, the GM has to explain each while players hold the lore in their heads. When it came choosing vices, we had a similar problem: I explained that one had to choose the category of vice, then the particular vice and its purveyor (for example, "Poker at Spades' Tavern"). The boys looked at me rather blankly: without knowing more about the world, it was not at all clear what kind of creative boundaries they had for this. I remembered that there was a list of vice purveyors in the appendix, so I turned to page 299. They readily chose from this list, and this makes me think that this, too, should be a handout in the starting materials.

When we turned to creating the crew with the corresponding playbooks, I realized that we should have inserted a step before the character creation: a quick discussion about what kind of game we wanted to play. They didn't talk much during character creation, but when we got to crew selection, it became clear that the Leech wanted to do sabotage and the Hound wanted to do assassinations. I ended up encouraging them to compromise and create a Shadows crew, which leans more into Leech styles but should have room for the Hound as well. In part, I was thinking about an initial score that would resonate with their crew playbook, and I did not want to open with an assassination.

We had some trouble with defining the crew's hunting grounds. The district map from the downloadable resources was useful, and the players figured that their lair could be in Crow's Foot while their hunting grounds was across the river in Whitehall. After all, wouldn't a band of spies want to spy on something worthwhile? I looked up more details about the district in the rulebook, and I found that it was listed as having maximum wealth and maximum security. That doesn't seem like a reasonable target for a crew that is just starting out. Mechanically, the Shadows were Tier 0 but their targets would all be much higher tier. If there were a recommendation for new players, we could have just taken it. In the absence of this, setting up the crew felt overwhelming, being high-stakes and made almost blindly. We ended up shifting the hunting grounds to also be in Crow's Foot. 

A related complication came up in the required decision of how to deal with the faction that controls the turf containing your hunting grounds. Unfortunately, there is no concise summary in the rules about which factions control which hunting grounds. For Crow's Foot, I remembered that the Crows claimed control over the whole district, but that there were also smaller factions who were trying to take it over. When the crew thought they would use Whitehall as their hunting grounds, I had no idea who controlled it. Would the Bluecoats—the corrupt law enforcement officers—be the faction that gets paid off? This is another case where a simple reference or a table of defaults would really help new GMs who don't have the spare cycles to memorize the litany of factions. A GM can always override a default, but in the absence of a default, I felt stranded in 150 pages of lore.

The book gives a recommended starting score that brings in three competing factions and gives the player some choices about whom to trust and whom to target. I was intimidated at the thought of doing this because it introduces several important NPCs and multiple factions, and the scenario is still likely to require improvising believable within this complex setting of Doskvol. I had previously searched for tips about how to start a Blades game, and I had read an article by Justin Alexander about alternative starting situations. I liked the simplicity of his "Aim at a Clock" advice. The book provides long-term goals, with progress clocks, for each of the factions. Given that, Alexander recommends picking a faction whose goal plays into something the crew could do, then having them pick up a score on behalf of that faction. This felt more controllable, and so as the players were finishing up their crew details, I had already started pulling pieces together: the Red Sashes and the Lampblacks each want each other eliminated, the Lampblacks are pushing some new drugs in Red Sashes territory, and the Red Sashes want the players to stop the production of these drugs. This would advance the Red Sashes long-term goal to eliminate the Lampblacks, and it would give the upstart players a powerful ally. However, the players had already decided that their crew had paid off the Crows for their hunting grounds, which also introduces a little conflict, since the Red Sashes and the Crows both want control of the district. Also, while arson is hardly virtuous, I liked the idea of having my boys focus on stopping the manufacture of drugs rather than, say, assassinating a union leader.

Part of the art of running and playing Blades in the Dark is knowing how much planning is too much planning. It is so important that the designer put the planning constraints right onto the character playbooks: choose a plan and provide the detail. The crew knew where the drugs were being manufactured, but they knew they did not want to go in guns-blazing. They asked where the raw materials came from, which is a great question. In the moment, I decided that this was an Information Gathering move. That would make this the first dice roll of the afternoon, and in retrospect, I don't like it. Information Gathering is a roll without stakes. I would not have recognized how this put the wrong foot forward until reading Matthew Cmiel's thought-provoking (although hyperbolically titled) article, "The Unbearable Problem of Blades in the Dark." I like his heuristic that dice rolls should always be with stakes, but Information Gathering just gives you better results the higher you roll. Also, it wasn't clear to me if the fact that an action rating was being used for Information Gathering meant you could aid each other, take it as a group action, or push yourself. Looking back at it (in light of Cmiel's analysis and other reading), I think the intended answer is no. In any case, the players rolled, and they discovered that some materials come by carriage regularly and some come by ferry intermittently.

After having thought about it, I think this step could have been a small score of its own. It would have made a decent introductory mission to gather this information as part of a long-term plan to take down the factory. Indeed, this would have helped me meet my own goal of understanding the whole Blades in the Dark system, including downtime. As it is, we did not have time to wrap up the score or do the downtime actions since real-life obligations interrupted the session—including the need for the dinner table.

The crew decided that this would be a stealth mission, sneaking into the factory via the river, starting a fire, and then getting out. A few times, the players wanted to get into details such as whose gondola they could use, but I assured them that Blades wants us to get to the action. They made a standard engagement roll, and we picked up the action with them silently sliding their boat into the factory. I described an enclosed dock with several rowboats moored to it along with two thugs, chatting and smoking. The players and I had a good short discussion about how to use the game's rules to indicate the character's goal in a fiction-first approach, and they decided that their goal was to sneak past the guards and into the main body of the facility. They succeeded at this but with the complication that the factory floor was just beyond the crates. 

The players talked about trying to sidle up to the work tables and pretend to be laborers, and we discussed how a flashback could be used to set up an insider. Instead, they decided to go for broke, with the Leech tossing a vial of flammable oil into the midst of the work area while the Hound fired off a few rounds to cause a panic. I told them that this was a desperate move, and the Leech botched the roll. Here is where things started to go badly for our Shadows. The Leech badly failed the roll, getting all ones and twos. Since it was a desperate move, I described how he botched the throw and spilled the oil mostly on himself, inflicting Tier 3 Harm. This allowed me to introduce the rules for Resistance rolls as well as Armor, and by using both, he reduced the consequences to minor burns, Tier 1 Harm.

As part of my post-play reflection, I realize now that I violated one of the GM rules for Blades in the Dark: "Don't make the PCs look incompetent." I treated the roll like a critical failure in part because of the incredible number of ones that the player rolled. It was also funny, in a tragic sort of way. However, if I could do it all again, I would have had him throw the vial and have it hit something else, something dangerous to them but not immediately deadly, and certainly not something as incompetent as wandering onto a factory floor and setting himself on fire. Alternatively, since I had already established that the workers were dealing with open flames as part of the production process, they could have immediately followed a fire suppression protocol.

Their cover blown, the Hound decided to use his special ability to lay down suppressing fire to buy them some time. Unfortunately, despite having taken a Devil's Bargain that this action would anger the Crows who claimed control of the district, the Hound botched this roll, too. This was clearly a desperate move, and after accounting for armor, he took a bullet in the chest, Tier 2 Harm. 

At this, the crew decided to beat a hasty retreat while trying to start a fire near the docks. The Leech had plenty of fire oil to attempt this. They wanted to escape, but they also wanted to succeed, so I offered them another Devil's Bargain: they fling the fire oil recklessly and end up setting fire to the very boat they came in on. The Leech took it and got a partial success, so I described how this area went up in flames, but several Lampblacks from the work floor were charging at them, wielding pistols and clubs.

The crew charged at the two guards who were still standing by the rowboats, and the Hound incapacitated them with some quick shooting. The complication for this filled up the clock I had started for the Crows' tolerance. At this point, the big faction controlling the region was going to take action against our Shadows for causing such chaos. The crew was more concerned at this point about survival, so they tried to unmoor a boat and get out before the charging reinforcements arrived. You guessed it, they botched this roll, too, and both of them took a beating in the attempt (Tier 2 Harm). 

Faced with no other viable option, they undertook a desperate maneuver and dived into the water to swim away. This, dear reader, resulted in the first and only six that they rolled the entire afternoon. Despite their burns, bruises, and bullets, they swam out of the dock area and into the river. To me, the fiction demanded that some of the Lampblacks grabbed a boat and chase them, but I also realize that this was a place where we could have made their exact goal more precise in our discussion: did they think that their diving into the water was to get completely safe or to simply get out of the immediate scrap? I interpreted it as the latter, but we could have been more clear.

I started a four-slot clock for them to evade the Lampblacks and gave them one tick for swimming out into the river. The players thought their only choice was to swim for shore, and I pointed out that there were some other options, such as swimming out into the river, or pleading for their lives. That said, swimming for shore made the most sense in the moment, so they tried... and botched the roll. The Lampblacks in the rowboat got into the river and took a few shots at them. This was enough to max out the Leech's Stress, and he took the Trauma of being Unstable, which is completely understandable given how badly this mission had gone. 

Now we were in a strange situation. I had established a progress clock for the crew's escape, although it was down to just the Hound now. He said he would just swim for shore, but I recognize that this would violate the Blades GM advice, "Don't roll twice for the same thing." It felt like it would just be "Swim again, but better this time." That didn't feel right, so I retconned the previous situation so that the Lampblacks had brought their boat between the swimmers and the shore. Hence, the Hound could do something like swim out into the ocean (with his punctured lung and bruises) or do something else, like beg for his life. He chose the latter, and I don't blame him. I offered him a Devil's Bargain on this attempt to sway the ruffians: he could have an extra die on his attempt if they let out their bloodlust by killing the Leech. To my surprise, he took it. The Hound knew that they were both as good as dead anyway. It was better for one of them to live than for both of them to die. The Hound succeeded at a cost, so they beat him with Tier 3 Harm and left him for dead on the shore.

We completed neither the score wrap-up nor the downtime activities. Both seemed moot with half of the crew dead, and as I previously mentioned, there were real-world pressures to clean up the table and get one of the boys to a youth group meeting. I plan on reading through the rules regarding how to wrap up a score later today so that I can do a mental walkthrough of how it would go. If the three of us play again, I think we'll just start afresh with a better understanding of the world and the rules.

And I would play again. Despite the game going badly for the crew, we all enjoyed the experience. It was a little rocky at times when I had to reference rules or lore, but that's the way it goes when you learn a new system. Every review of Blades that I have read says that you have to play several sessions before you really get into its way of playing. Although I would play again, I do not currently have plans to play again. I think it would be great fun to play with an adult group with beer and snacks, but getting a bunch of fathers together for a game night is already a desperate move where the dice are loaded. In the meantime, my boys and I got to share a fun afternoon together, and now they have a story to tell about what happens to those who turn to a life of crime.

Thursday, August 22, 2024

User Stories, Being Able To Do, and Philosophy

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

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

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

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

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

Tuesday, August 20, 2024

Notes from Cal Newport's Deep Work

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

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

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

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

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

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

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

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

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

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

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

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

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

Tuesday, July 23, 2024

Mulberry Mead

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

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

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

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

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



Friday, July 12, 2024

Summer course revisions 2024: CS222 Advanced Programming

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

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

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

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

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

Friday, July 5, 2024

O teach me

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

    O teach me how I should forget to think

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

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



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