Dungeon Crawl Classics: Putting the Family through the Funnel

I picked up the Dungeon Crawl Classics Humble Bundle many months ago, and I thoroughly enjoyed reading the core rules. This was my first foray into OSR gaming, and I was blown away by the scholarly nature of Joseph Goodman's magnum opus. For those who are unfamiliar, let me summarize by explaining that when Goodman calls you to "adventure as 1974 intended you to," he really means it. The aesthetic heart of Dungeon Crawl Classics RPG is in Appendix N. In this appendix, Goodman explains that Gary Gygax, in the 1979 AD&D Dungeonmaster Guide's own Appendix N, lists the fantasy and science fiction novels that inspired him. In his own eponymous appendix then, Goodman explains his research process—that he took a deep dive into these inspirational works so that he could emerge with a mid-1970s vision of fantasy role-playing adventures. My own survey of Robert E. Howard's Conan's stories enabled my perspective to expand, and so I am duly impressed by the rigorous methodology that Goodman followed, balanced with admiration and perhaps a bit of jealousy.

After my initial reading of DCC RPG, I reached out to several friends and encouraged them to check it out. My copy then sat on my digital bookshelf for some time. A week or two ago, I realized that it had been some time since I had the "I want to play tabletop role-playing games with my family" urge, and this surprised me. That momentary realization started the snowball that became the avalanche, and I found myself re-reading DCC RPG and convincing my family to give it a shot.

All six of us came to the table to play on Sunday afternoon. I had explained to them about "the funnel," which I think is one of the most wonderful concepts in DCC RPG. I gave each of them four zero-level characters, which I generated using Purple Sorcerer's excellent online tools. These twenty schlubs were going to go into "The Portal Under the Stars," which is the funnel adventure provided in the DCC RPG rulebook.

I explained to them that the characters were all randomly generated and walked through the basics of the character sheets. I asked them to name their characters. Alignments are important in DCC RPG, and I gave them the option of choosing right away whether the characters were Lawful, Neutral, or Chaotic; however, I think everyone took the other option, which was to leave it blank and resolve it during role-playing later. The older three players chose what one might broadly call "genre-appropriate" fantasy names. The eight-year-old named his characters with traditional English-language names: Andy, Jimmy, and Joe. The six-year-old seemed to pull his names from the other things we talked about during the rules explanation: Old, Farmer, and Loc (which is pronounced, and probably a misspelling of, "Luck"). His other character was named Cram, and no one knows where that came from.

From this point on, there are many spoilers of from The Portal Under the Stars. You've been warned!

The adventure starts with all the characters and their menagerie standing before a magical door. I mention the menagerie because these 0-level characters begin with just the basic tools of their occupations, and we had excellent representation from the agricultural sector: as twenty men and women looked at the magic door, they were joined by a cow, a goat, a hen, and a duck. The door is clearly magical from its markings and origin, and so there is obviously some kind of puzzle or mystery involved. You've already read my spoiler warning, so I will just come out and say that the door becomes unlocked and untrapped if the players wait until the stars align with the constellations shown on the door. 

I am no expert in level design, but I would like to posit that this is a bad opening for an adventure. Anything the players do besides wait is going to be wrong, and waiting is neither obvious nor interesting. If a player looks to try to determine whether the constellations are in line and fails that one Intelligence check, then they are stuck fumbling about and taking trap damage from the door. My wife, who had been hesitant to join, even shouted out how this was "just like last time" we played an RPG, where we got to a door and got stuck. I wish I could remember that actual situation (and I haven't asked her to jog my memory, partly out of fear), but I think it drives home a more general design point. Doors by themselves are not interesting, and a puzzle that requires you to do nothing is more like a meta-puzzle, something to make grognards chuckle but that has no resonance with new players.

Once they had the door open, Old was the first one to cross into the dungeon proper. The trap in this room was eventually triggered, four spears being thrown at the party. Old was spared, but the other three were direct hits and kills—or so we thought. One of my wife's characters was a mercenary with Hide Armor, which was the only armor in the whole game. When I asked players for their Armor Classes, everyone read what was given on their sheets. However, it turns out those Purple Sorcerer character sheets do not take into account armor when listing the character's default AC. It was a life-and-death difference for her character, whom we role-played as having a near-death experience from the impact of the spear that didn't quite go through his armor.

This was, incidentally, not our first misreading of those convenient Purple Sorcerer sheets. Armor is listed merely as an inventory item with no stats given, but weapons are listed together with the player's to-hit bonus and their damage bonus. Reading across the sheet then, a character with 13 strength is shown as having a "+1" modifier, then their club (for example) is listed as "Club +1 (1d6 +1)". Those are all the same +1, listed multiple times, but some of the players regularly misread this as meaning the club had a +1 and also they had a +1 from their Strength, for a total of +2. I mention this here in case it is helpful to other new players: as cool as the Purple Sorcerer sheets are, they have some idiosyncrasies that are not the way I would prefer the information presented to new players.

The party moved more slowly into the next room, which was the central room of the dungeon, doors on each of the four walls. One of the players set off the trap here, which put everyone in peril, so we rolled initiative to see who would do what. DCC RPG generally uses individual initiative, but for the funnel, we followed its advice and had each player roll once for the characters under their control. The 11-year-old was first, and he had his guys run back to the chamber they came from. The 6-year-old was next, and he had his characters run through a different door into the unknown. I had assumed he would follow his brother's lead, and I was getting ready to have his characters roll against his brother's to see who would get to safety; I never expected him to go through a new door. We'll come back to that point, but for now, suffice it to say that this put all of his guys in immediate mortal danger as well. Now the party was fighting danger on two fronts, which was cinematic gold. 

The party survived with a few casualties, but let me digress for a moment to an interesting conversation from the family's reflection. In a conversation with my wife and the older kids, I tried to express my concern that the youngest son, after choosing to send his characters into an unknown room, likely did not possess the abstract thinking skills to determine whether this was a good or a bad idea. My wife heard this differently and got defensive, saying that she did not like the implication that there was a "right" and a "wrong" way to play it if we were supposed to be role-playing. For her, I think this is a sticking point of role-playing games: she recognizes that one one hand, you are role-playing, but on another hand, there is a tactical, resource management aspect. However, that wasn't my point: I was not so concerned that he went into the unknown, even though it's not at all what I would have had my characters do, but that, given his age, he likely doesn't have the tools to even frame that question. Put another way, it was perfectly reasonable to jump through a doorway that may contain danger to escape a room that certainly contains danger, but I'm not sure he can really weigh the implications or reflect on it as an adult would. It's a curious thing to play with children.

Later in the adventure, the party entered a room that contained six crystalline humanoids who moved slowly but ominously toward the party. The players did not know if they would attack or not, and after some uncertainty, one of my wife's characters hurled a hand axe at one of them. This turned out to be a mistake. It prompted the creatures to defend themselves, and it was quite the melee. I think this battle took out half of the remaining characters, including Old, who had become something of an icon. I had encouraged the players not to make Old such a central figure: I could see how my youngest son would not move him off the front line, even after he miraculously survived many chances with death. I was afraid he would die, and die he did. To my youngest son's credit, he got a little misty, but he moved forward with Loc, his one remaining character.

The final major encounter of the adventure is interesting. It presents, on its own, an almost insurmountable challenge, but other actions that the party takes in the dungeon can make it manageable. Indeed, my family's characters had inadvertently done everything they could to facilitate success in the final room. It was awkward, then, when the adventure's read-aloud text described the room as if none of these things had happened; I had to stumble through a few sentences and improvise alternatives in a way that the other rooms had not required. 

The party found the secret treasure room, which contained a desiccated corpse, evidence of evil activity, and some clues about the background of the whole adventure. There was another odd bit of writing here, where the corpse was referred to by its in-fiction role, but there was no way that the players would have known this at the time. Given the popularity of this module, I would have expected that to be edited more tightly. In any case, whether because the few remaining characters were not interested in dying, or because their players were just tired, the party decided to grab the loot and skedaddle. It was ironic, then, when my wife said that there weren't any indications in the dungeon of what it was all about: Who was buried there? What happened to them? In fact, clues were available, but the party took the arguably wiser risk-averse approach: grab the treasure and avoid the corpse. 

Playing the adventure reminded me how secret doors and traps, if not handled well, really destroy the rhythm of a game. If you allow that secret doors or traps can be anywhere, then players are forced into looking for them everywhere, which is not interesting. There are parts of the module that have really interesting traps, such as the central chamber mentioned above: there's something that clearly looks dangerous, and the party can consider what to do about it. It also contains a secret door that has no indicators in the fiction that it exists. I will have to keep my eye out for this as I look at some of the first-level modules, keeping myself open to modifying them to remove what I consider bad game design elements. Incidentally, I mentioned this frustration in an online discussion, and I was pointed toward The Angry GM's article, "Traps Suck." I agree with the spirit of his article, and it's good to see other people taking a design-oriented look at these tropes.

I believe my family is interested in continued adventures after the funnel. I noticed something really surprising in reviewing their characters after the adventure: not a one of the survivors has a Strength higher than 10, and only one of the deceased characters had a Strength as high as 13. I had not reviewed the character attributes ahead of time, but I expected that random distribution would give us a greater range of highs and lows. That, of course, would make it pretty easy to determine who might step up to the role of Warrior. At first I was taken aback, but then I thought about it, and it's actually quite interesting: in this town, from which twenty randos risked life and limb to retrieve hidden treasure, they didn't have any brawny men to lead them into the fray. Now, the survivors have a taste for adventure, and some will have to devote themselves to martial study, not because of their strength but despite it.

Running tabletop roleplaying games is a funny thing. I used to do it every weekend when I was younger, but that was before I had anything like access to the networks that I have now. I could only learn by reflection and by the very limited number of other peoples' games I played in. Now, there are endless resources for learning about running games. It's a skill that sometimes I fantasize about developing further, which I think is in part because of the realization of my weaknesses when I was younger. Playing DCC RPG was a good weight for me, since the rules are fairly simple, the challenges are immediate, and the module I ran—despite my criticisms—was certainly competent. I have enjoyed some of the more narrative games my family has explored in recent years, such as FATE and Dungeon World. I think DCC RPG might be at the right weight for me to run family games more regularly with just a minimal threading of narrative between modules.

Depersonalization

I recently came across a paper that referred to "personalization" of feedback to students being generated by a machine-learning algorithm. For some reason, this gave me pause to think about this use of the word. What the authors meant, and how this term is used across e-commerce, is a reductionist view of humanity; it is one in which people are considered as feature vectors in a machine learning algorithm. You bought Product A, and so you might like Product B, because other people in your cluster bought Product B. Using the most popular contemporary machine learning techniques, an analyst cannot even look at the cluster and tell what it is in any human sense: it is a computational and statistical phenomenon with predictive powers, so here is an ad for Product B. 

That is the opposite of personalization. Personalization means that I know you like puns so I stick one in my email. Personalization means I know to put just this much sugar and that much cream in your coffee. Personalization means I know you're struggling with this course, and so I give you an extra emotional boost in my written comments, reminding you that you can do it. Personalization means I love you. The adoption and abuse of this word by modern businesses is shameful. It is the antithesis of personalization. It is the reduction of the person into mere bits.

User stories vs Sprint Planning in the Spring 2021 Game Studio

I'm excited to be able to teach my Spring Game Studio course this semester, even if it's not ideal. The ways in which it falls short are that we cannot use the actual studio space due to physical distancing restrictions, the time it's offered was determined by the college rather than the department and is terrible, and it's almost all Computer Science majors--in part because of that awful scheduling that prevented our being able to synchronize with the other majors that regularly send students. That said, I am very grateful to have about a dozen eager and excited students, and I am able to continue to explore how to manage multiple simultaneous teams. When it comes to distributed work, we can be more intentional about it than we were when the Spring 2020 studio had to suddenly change character due to the pandemic.

The Spring 2021 studio started with six different game ideas, and it took us until the fourth week of the semester to narrow it down to just three. This process involved building MVPs that were valuable in explaining the games and building teams around them. I wrote up a methodology for distributed development, based on my notes from last year, and that is currently available on GitHub. 

On Friday of last week, all three teams met together so that I could talk about the planning and production process. This was designed to help them bridge the pre-production work and prototyping they had been doing to get us into the expected rhythm and rigors of the methodology. I showed them how we could use HackNPlan to manage parts of the project, and conveniently, I was able to use the context of one of the abandoned projects: it was something new and unbuilt and yet still familiar, which is much better than talking about re-engineering something that already exists.

This allowed the teams then to come to our Monday meetings and plan their projects. Here, however, is where I think I made a mistake. I had hoped that they would be able to articulate their features as user stories, then break them down into tasks, and then assign tasks during the meeting. Even though I knew how hard it was to turn ideas into user stories, I don't think I gave them enough time here. When I am leading an immersive learning team, I will often just do this for them, based on their discussions. The result was that it took well over an hour for each team just to figure out what a few of their stories are, let alone the problem of prioritizing them, committing to them, and planning the work required to satisfy them. The meetings went too long, with the concomitant fatigue.

I think I could have handled it differently. One option would have been to schedule separate meetings, one for story identification and one for sprint planning. This also would have given me a chance between meetings to give feedback on story articulation, whereas what I had to do on Monday was traipse between three different online meetings. An alternative would have been to allow the teams to designate one or more team members who would devote their time to the story identification. That is, they may have served as I have done in a Product Owner role.

I'm still happy with the work they have done and proud of their progress, but I wanted to make sure that I tracked this idea here on my blog so that next time, I might remember to separate these processes. Also, the methodology (as of this writing) mentions Trello as an option, but I had forgotten that Trello does not allow for convenient separation of story articulation and commitment vs. task articulation and planning. I should simply remove it from the methodology next time, because it does not allow for the precision that I would normally have on the studio's whiteboard. Unfortunately, I learned this lesson because one of the three teams tried to use Trello and then broke down in their planning meeting when they couldn't follow the steps I had shown in the previous meeting. 

Initial observations on splitting the two-week project into halves

I never followed up on my December frustrations about how CS222 is being offered this Spring. The short version of the story is that, after talking with some colleagues, I came to peace with offering the course in a rotational model. We're now at week five, and my two sections are each split into a Tuesday attendance group and a Thursday attendance group. It's not ideal, but it's what we have.

Today, I want to capture a few thoughts about a change I made in the course. This was inspired by an insight from my colleague Huseyin Ergin, who has taught CS222 just a handful of times. He came up with a clever way of helping students understand model-view separation early in the semester: during his version of the two-week project, he had the students first build a console application, then augment it with a GUI. Through this process, his students got to see that if they separated their model, they would reduce the redundancy in their code. I believe my colleague David Largent may have done this last semester, too, when he taught both sections of CS222. I decided to give it a shot this semester with my two sections.

I kept the overall course calendar that I usually use, but I divided the two-week project. Normally, I have the students create a GUI application that can pull in the latest changes and also sort by who made the most changes, as you can see in the Spring 2020 requirements. I knocked out the sorting requirement for simplicity, in part because I became aware that practically none of my students had ever built a GUI before. Usually, the instructor teaching the prerequisite course introduces some simple Swing or JavaFX, but this wasn't covered last Fall; hence, I wanted to give the students more time with the GUI.

At first, I only published the requirements for the first week. These requirements, as usual, expressed the functional requirements as a user story and the nonfunctional requirements as a checklist. I used a familiar context: reading recent changes from Wikipedia. I also added a required submission at the end of the first week, which I do not normally do: indeed, since it's "the two-week project", I usually just give students two weeks to do it. With the two-phased release, I decided to grade the first part, in hopes that the feedback would help them improve the final submission. At the time of the first week's submission, I released the additional requirements for the second week, which the students are working on now. The added requirement is to add a JavaFX GUI while maintaining the functionality of the console application.

In truth, when I first set up my assignments on Canvas, I didn't think critically about how I would grade the first week vs. the second week. It wasn't until we got into the project itself that I decided that the first week would be purely formative, and only the second week's grade would "count". However, Canvas just shows it as a deadline. This led to the predictable result: a few students nailed the first week's requirements with some minor problems, many realized that they didn't know what they were doing, and a few rushed in to push out anything that compiles right before the deadline. A few students expressed a kind of "woe-is-me" attitude in the submission comments, but most were actually quite positive. That is, they acknowledged that this wasn't what they wanted it to be, but they were eager for feedback to help them with the second week.

Now, I would not say I intentionally tricked them, but I never sound aloud, "The first week doesn't really count toward your final grade." It is actually ambiguous in the course plan's grading scheme since it doesn't say anything about how the first and second weeks are graded. Reflecting on this experience, though, I think it might be a useful deceit: the deadline encourages the students to get started and realize where they are rather than push all the work (and realization!) off to the second week. No one pushed back and complained that this grade would not count, which makes me think that they released a collective sigh of relief. I'm eager now to see how this second week goes and whether the overall performance on the two-week project is improved from previous semesters, and more importantly, whether it better prepares students for the more important final project.