Wednesday, November 27, 2019

My sons' reflective essays for NaGaDeMon 2019

Yesterday, I wrote about my experience participating in this year's National Game Design Month (NaGaDeMon), but I was not the only one in my household to participate. My 12-year-old and 9-year-old sons each created their own projects as well. Following the Create-Play-Talk structure of NaGaDeMon, I am pleased to share their reflective essays as guest posts here on my blog.

Both of their games can be played online: #1 and #2.

Here is the reflective essay from #1 Son:
For NaGaDeMon, I made a dungeon exploration game with Construct 2. I used Construct because it is the platform I am most familiar with. Construct is a drag-and-drop system, and events are Construct’s way of structuring actions. 
I am glad that I was able to add an avatar creation system where you click on arrows to cycle through different colors of clothes and hair. To do that I had to learn how to use the modulus operator to cycle through a list. Modulus is when you divide a number and take the remainder, so one divided by five has a remainder of one. The cool part about this is that when you divide six by five, the remainder is still one! You can use that to go through a list using only one click. The way I did it before was using a double-click for when you reached the last item in the list so that it wouldn’t loop around and skip a color. 
I am quite happy with the outcome, although the free version of Construct that I am using has a 100-event limit. Originally, I had the player unlock a new weapon with each level, which worked well. The biggest problem I had was getting all of the enemies and bosses in, because the free version has no way to group all of the enemies into one class, so I had to make a different event for each weapon and enemy. Since that took me way over 100 events, I had to take that feature out and replace it with one weapon that got more powerful with each dungeon. I still wasn’t able to add everything that I wanted, but I was able to get all the different enemies in.
Here is the reflective essay from #2 Son:
I have always liked programming. My first programming system was Kodu. I made this in Construct 2 because in Construct 2 I can draw my own sprites. 
I was inspired by my brother’s game about a wizard exploring dungeons. To make it I had to learn how to make more than one layout. I feel like I spent more time than necessary drawing, but with all the left over time I think it was worth it. 
I think I am happy with how it went. I accomplished what I wanted, but what I wanted could have been put in a better game
It was fun to have these guys participate in the fun of NaGaDeMon. I gave them a little coaching in how to write a reflective essay, showing them one of my favorite forms that I use with my college students: What went well? What did you learn? What would you do differently? What still puzzles you? I offered to let them read my reflection as well, which #2 Son did after writing a rough draft of his own. I sat individually with each of them to give them feedback on their handwritten drafts, and  we reviewed them again after they typed them up. Changes were made both times, and I think the results are quite strong. With #1 Son, I encouraged him to expand why the modulus was important to him and how the 100-event technical limitation affected his process. With #2 Son, I encouraged him to expand on why he chose Construct and how to articulate a bit better what "I think I am happy with it" means.

Thanks for reading! I'll be happy to relay any comments you have to the boys, whether they are about the games or the reflections.

Tuesday, November 26, 2019

KAPOW! NaGaDeMon 2019 Project Reflection

As I mentioned in my previous post, my 2019 National Game Design Month (NaGaDeMon) project is KAPOW! The Campy Superhero Role-Playing Game. Earlier today, I published the rules and all the sources on GitHub. The game is free to download, play, and modify, with all the resources provided under the CC BY-NC-SA 4.0 International license. NaGaDeMon has simple rules: Create, Play, and Talk. I created the game was able to play two full sessions, and this post is crafted to satisfy the third rule.


In my formative years, I used to play a lot of Dungeons and Dragons as well as some Shadowrun. I also crafted and playtested some of my own systems, the notes and sites for which have long since disappeared. For the curious, the two that I actually got as far as testing included a time-traveling system in which you roll boatloads of dice and, on the opposite end of the spectrum, a completely diceless fantasy system. These days, I read many more rulebooks than I have a chance to play. The Clay That Woke and Apocalypse World are two amazing systems that I supported on Kickstarter and for which I have read the rules, but which I have never actually played.

One of my scholarly activities in Spring 2019 that I have not mentioned before is that I had two students in a CS499 Independent Study experience. We each were working on our own game design projects, mine being Race to the Moon. One of the students was Austin Tinkel—whom I will mention by name here because I want to link to his work—who developed a pulp action tabletop RPG called That Belongs in a Museum! He gave an excellent presentation about this at the 2019 Symposium on Games, where he talked about how it transitioned from an abstract idea about action momentum into an Indiana Jones-style adventure with PbtA mechanisms. (That is, it drew upon design ideas established in Apocalypse World.)

Working with Austin inspired me to re-read Apocalypse World and reinvigorated my interest in narrative-first tabletop role-playing. I don't know what made me connect this to 1960s Batman, but my family and I have been slowly working through the series since I got myself the box set for Christmas in 2017. We're on the final season, and in fact, we just watched the famous "Bat Shark Repellent" episode, which I have to say—as a fan of campy superhero stories—is one of the worst pieces of television I have ever seen. In any case, the idea tickled my fancy to try to combine campy superhero stories with a PbtA ruleset. This seemed like a good hook for trying to get my head into the PbtA space.

I sketched no more than a page of ideas in the intervening months until around September or October, when I started thinking about whether I should participate in NaGaDeMon again. I had some professional and personal obligations looming (including the aforementioned Symposium), so I decided ahead of time not to pursue a programming project: the odds of getting caught in a debugging death spiral was too high. My mind drifted back to the idea of marrying 1960s Batman sensibilities with ideas and systems from Apocalypse World. This seemed like the kind of thing that would fit into the time I could afford, and I'm glad I made this choice.

The Tech Stack

I started by writing my notes on paper, and then I transcribed them roughly into Markdown. However, I knew that I didn't want to compose the whole thing in Markdown because of its lack of expressiveness for structure. Consider the concrete case of defining the basic moves. At the time I was writing, I wasn't exactly sure what all the basic moves would be, but I knew that I didn't want to have to redundantly define them in a rulebook and in a handout. This would be a DRY violation—anathema to my personal idiom.

Choosing the best method to compose my rules required me to make a decision about how to disseminate the final product. On one hand, I considered a Web-first writing approach using lit-html. I have significant experience with lit-html since I have used it for my course sites such as this semester's CS315 class as well as some side projects such as my Call to Adventure scorecard. I knew that I could do some tricks with JSON-formatted data and html templates in order to separate, for example, the basic moves' definitions from their representation in the rulebook or in handouts. On the other hand, I considered using LaTeX for a print-first writing approach. This would let me easily generate PDFs and niceties like a table of contents and an index. However, I have never done anything like a "model-view separation" in order to keep my writing DRY in LaTeX; it has simply never come up.

I decided to go Web-first, which seemed like a very well-considered and contemporary choice. I wrote this way for really only a few hours before I ran into a significant problem: how exactly was I going to produce the kinds of handouts that players would want to have at the table? Playbooks are a standard technique in PbtA games, and lists of basic moves and narrator moves seemed like a good idea. I started tinkering with using different CSS styles for screen and print media, and very quickly realized that this was basically an instance of the "debugging deathtrap" that I had wanted to avoid by making a tabletop game.

I turned instead to LaTeX and immediately started to consider how I could separate my basic moves' definition from their explanation in the rulebook and their summary on a handout. It dawned on me that I could do something akin to concrete data structure like JSON by having different documents interpret environments in different ways. The narrator moves provide a good example. The project has a file narratormoves.tex which contains several narratormove definitions, like this:

\begin{narratormove}{Separate them}
  Use this move to separate the members of the team or to separate
  the team from their objective.

Notice that the custom narratormove environment has two arguments, the first of which is the move's name and the second of which is the explanation. Then, in the rulebook, I can define the narratormove environment before importing the source file like this, which will print each move as an unnumbered subsection with its explanation:

{\subsection*{#1} #2}

Meanwhile, in the Narrator handout, I can define it in such a way that it produces only the moves' names in an itemized list:

{\item #1}

Not too shabby! I'm happy with this approach, which is used throughout the project. It reminds me that, somewhere in my courses, I should be showing my students this kind of thing to break them from their trained dependence on Microsoft Word—to show them how thinking like a Computer Scientist lets you solve complex problems in more interesting ways.

The Unexpected

There were a few unexpected twists in the design of this game. I wrote about several of them in my playtesting notes post, and the most important of these was really that I was coming in green to the PbtA scene. I had read Apocalypse World several times and recently also read Dungeon World, but the only exposure I had to playing a PbtA game was Austin's That Belongs in a Museum—and that was pretty early in testing. I have been playing ICRPG again with my boys using a traditional fantasy setting, but the kinds of DungeonMastering advice that I listen to on YouTube is very much aligned with D&D-style systems, not PbtA. That said, I do feel like this project met my design goal of helping me put my head into the PbtA space a little better. Each time I tried to either talk through a scenario myself or run a session with playtesters, I got a little better at thinking within the balance of hero moves and Narrator moves.

The 1960s Batman stories, and my dad's 1960s CCA-approved superhero comics that I grew up reading, are almost always mysteries: the hero needs to figure out the who, what, why, and where of the problem before the Villain gets away with it. This stands in stark contrast to the character-driven harsh open world of Apocalypse World or high-school melodrama of Monsterhearts. Dungeon World is somewhere in between, in that it tries to take the traditional D&D approach and wrap it up in PbtA clothing. KAPOW ends up looking more like Dungeon World than Monsterhearts, where parts of the system really sing while other parts are strung loosely together.

The principles section of the rulebook was one of the last things that I wrote, and it represents my current thoughts about how to reconcile these different pieces. I challenged myself to think about the Narrator's ground rules: what would help them creatively tie together the Villain's scheme with the player's agency? I think I did a fair job of articulating these, but I think it's the sort of thing that can only really be tested by another gamesmaster trying to run the game from what I have articulated. Unfortunately, that was out of scope for this November, but I'm eager to hear from anyone who tries. After all, with a CC BY-NC-SA license and GitHub's collaboration tools, there's always an opportunity for improvement.


This was a great creative exercise. It allowed me to explore an idea that has been on my mind in a rigorous, timeboxed way, with the additional help of a supportive community. I think the resulting game rules provide a fun setting, and I legitimately enjoyed all of my playtesting sessions. If other people can also get some joy out of it, then that's all the better for it. In the meantime, I feel like I was able to strengthen my writing muscles while learning some new perspectives on design. 

Given unbounded resources, I know of a few places where I would shore up the current design. Obviously, the rulebook and the handouts would be greatly enhanced with some genre-appropriate art and graphic design. A brilliant idea from Apocalypse World is providing sample answers to open-ended questions in the playbooks. For KAPOW, I would like to give players a list of choices for hero name, real name, appearance, occupation, and contacts, but this was both too onerous to implement and would have broken the one-page design of the character creation sheets, such as it is. Having such options would greatly speed up play, especially in my testing sessions: I was able to confirm that many players enjoyed the open-ended questions and creativity of making characters, but this was also fundamentally individual-creativity time rather than collective storytelling time. Finally, I think it would be helpful to new Narrators to have an appendix of sample villains and schemes. Many of the examples that are provided in the game come from the simple designs I put together for playtesting, but an easier on-ramp could be provided for new players by giving them something more clearly canned.

Thanks for reading! Feel free to post here if you have any questions, and feel free to share the link to KAPOW to any of your tabletop roleplaying or campy superhero friends.

Saturday, November 16, 2019

Playtesting notes for my NaGaDeMon 2019 project: KAPOW!

Last year was the first time I participated in National Game Design Month (NaGaDeMon). I used the month to chase down a game design idea that had been tickling my curiosity for a long time, and the result was Heroic Uncertainty. This year, I decided to participate again but with a very different mode of game design this time around. Since last year, I have been intrigued by the "Powered by the Apocalypse" movement in tabletop role-playing game design. I have also wondered whether this kind of narrative-forward game design would work well with something else my boys and I have been enjoying: the 1960s Batman television show. Hence, I'm glad to announce here—publicly for the first time—that my 2019 NaGaDeMon project is KAPOW: The Campy Superhero RPG.  The project is on GitHub, but I have not made it public yet because I have not yet written the introductory fluff to establish exactly what the game is about: I don't want someone to trip across it and misunderstand the design space.

Yesterday, I was able to gather five volunteers for my first full playtesting session. My primary objective for the session was to test whether the systems were adequately supporting the "caper" tropes that come up in every Batman episode: a Villain sets up an unnecessarily complicated plot for fame or fortune, and the heroes need to unravel it to lead up to an epic showdown. Everyone had a great time, and I was overall pleased with how the story and systems worked together.

I know that for you, dear readers, the rest of this post will appear like I have my cart in front of my horse, because what I wanted to write up this morning are some of my concrete playtesting notes. I want to capture my main observations and provide a little bit of context while they are fresh in my head. It will also give me something concrete to reference when I write up my summary post at the end of November.

Without further ado, then, here are some notes and action items for myself.

  • Each hero has a contact, but the articulation of how they know each other is not clear. Also, I did not include in the playbooks that the contacts had to be introduced, but during the introduction phase, the Narrator really needs those names. Perhaps one way to deal with this is for each playbook to also have a "secrets" sheet that is filled out and shared only with the Narrator.
  • Having stock options for real names, occupations, and contact options would speed up character creation, especially for those who are new to or uncomfortable with tabletop RPGs. This may take a significant amount of my time to assemble, but could be worth it, especially for one-offs.
  • A player pointed out that secret identity names should be alliterative. Yes, they should, unless they are both first names. This should go into the rules.
  • The Enigma playbook could instruct them not to share their real name at all to make them a mystery to the players, or it could acknowledge that the camera knows their real name, and so the players do also, even though their characters do not.
  • I definitely do need some kind of "undercover" rules for exposing secret identities, since this was one of the first disagreements the players had. This would keep with the Batman-style genre. An alternative is to let the players choose this in the Team intro: do they have secret identities (Batman) or are they simply known as who they are (Johnny Quest)? I need to be careful here that the number of rules does not snowball out of control, since this is a one-month design project!
  • At the last minute, I changed Nimble to Focused, and this change worked well. However, the earlier change from Charming to Amazing didn't go so well. The players wondered why Amazing was used for influencing people and why it was not used for a heroic feat. "Amazing" is too metaphorical; I should return to something like "Charming" that implies social savvy. Hm, "Savvy" is a nice word.
  • The Second Wind ability on the Tough may be redundant since he already has so much Endurance.
  • At the end of the session, they pointed out that the Investigate move, although described as being for "situations or locations", is really more for locations. We discussed having a selection such as "What is out of the ordinary here?" or "What is an important clue?" They really wanted an option like "Where should we go next?" but the problem I had with this—which they understood when I explained—is that this could too easily remove the mystery of the villain's caper. I need to consider the balance here; there may be a role for Contacts.
  • Most players did not use their Contacts, but one player used the Contact almost too much, to the point where the Contact was basically a member of the team. I should consider making the Contact option only usable once per session, or risk losing them as a contact.
  • I forgot for half the game to tell them to mark Experience when failing a roll, so I probably need some kind of visible reminder on the character sheet about this. 
  • Similar to the above, I should add reminders on the character sheet about which attribute goes with which basic action, like Apocalypse World does, so that they don't have to scan the whole Basic Moves sheet so often.
  • Also, I forgot to tell them about the new "use the scenery" and "onomatopoeia" options for brawling, which need to be on the basic moves overview sheet and not just in the rulebook. However, brawling was also one of the least interesting parts of the game, although this could have been because of the lack of those rules. (Also, we went over time, so the big battle at the end turned slightly perfunctory.)
  • One of the impediments to the story was my own discomfort with PbtA-style gamesmastering. I had never done this before, so I was learning along with them. I struggled with the idea of what Apocalypse World calls "announcing off-screen badness." In fact, I think one of the reasons Apocalypse World caught my attention is that this concept is something I didn't understand when I DMed regularly (decades ago) and still struggle with occasionally in my handful of gamesmastering opportunities per year. One of my players was very familiar with PbtA, and he encouraged thinking of it like a movie, quickly describing a scene for the players that their characters know nothing about, but that moves the action forward, such as "A car door slams and the car speeds away from the hotel." I do not know if I need to more prescriptive in the rules about this, practice it myself, or both.
And now, hopefully, a quiet Saturday with lots of work on the rulebook.

Monday, November 11, 2019

Department Vision and the Reflecting, Brainstorming and Imagining Worksheet

My department recently concluded a self-study that included a visit from two external evaluators. We are now beginning discussions about what to do in light of our self-study and the evaluators' recommendations. This comes at a time of organizational change within the university, since we have relatively new administration, a new strategic plan, and a new financial model.

In preparation for an upcoming departmental meeting, the department chair emailed the faculty a "Reflecting, Brainstorming, Imagining Worksheet" that was provided by the office in charge of institutional assessment. I took some time to write up answers to the five questions on the worksheet, and I am sharing them below. I am not sure that these are my best answers, but I've used up the timebox that I gave this exercise. I'm happy to take any feedback or questions about the responses, as I expect to refine them later.

1. What is the purpose of Computer Science to you? To you, what does Computer Science endeavor to accomplish?

Computer Science is the study of the social and technical processes around computing systems, including their inception, development, and maintenance. It is a "science" in the sense of developing falsifiable theories that are supported by principles and rigor. It is distinct from information technology and information systems, which applies extant systems to problem domains, and computer engineering, which seeks to more efficiently or effectively manufacture hardware. "Software engineering" is a common application of Computer Science.

Computer Science drives us to a better understanding of computing systems which, in turn, leads to the development of improvements in those systems.

2. What is the purpose of BSU Computer Science? What is at the core of our work?

The purpose of the department is, primarily, to educate the next generation of practicing computer scientists. This implies a focus on contemporary methods of software development, as incorporated into the broader goals of a liberal education.

At the core of our work is a shared desire for our students to live a good life: to be successful, to be productive, to contribute to their communities, and to reflect on what is good and beautiful.

3. What are three strengths of the BSU Department of Computer Science? 

  • Small class sizes allows students to work closely with faculty.
  • Students have significant opportunities for high-impact educational experiences, including the capstone, immersive learning, community-engaged projects, and research.
  • Faculty are engaged with research that informs and strengthens the courses they teach.

4. What are three weaknesses of the BSU Department of Computer Science?

  • Little shared vision about program outcomes and, hence, course and curriculum design.
  • Little sense of community among the faculty, students, and alumni.
  • No clear communication channels to reach students or alumni.

5. When students (undergraduate and graduate) graduate from our department, what do we want them to know? What do we want students to be able to do? What do we want students to value?

We want them to know:

  • Fundamental concepts of programming, including: sequencing, selection, and iteration; data structures such as lists and hash tables, with an intuition for their implications on performance; integration of systems such as clients, networks, and databases
  • How to work effectively on a team, including: articulating measurable goals; giving status reports; and suggesting improvements.
We want them to be able to:

  • Think critically
  • Act respectfully
  • Ask clear questions
  • Engage in reflective practice
  • Learn to use new programming languages, computing systems, or APIs
  • Work on a team to design, develop, improve, or maintain computing systems.
We want them to value:

  • The responsibility they have to their team, their employer, and their community
  • The dignity of the individual
  • Lifetime learning