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

Wednesday, October 30, 2019

Lenses in game design and curriculum design

Yesterday, my game design students completed an assignment that had three optional paths. One path involved reading Richard Bartle's excellent summary of the Hero's Journey (1, 2), which includes not just an overview of the concept but also helpful pointers about what students often get wrong. During the class meeting yesterday, a student gave a masterful presentation showing how the The Last of Us maps to the Hero's Journey. Before his presentation, I gave a short lecture about what I've learned about lenses. My point here was to get out in front of issues around the masculine and feminine roles of the Hero's Journey, and I think students got my point.

One of the examples I like to give in this kind of discussion is the ludology vs. narratology wars in game design, which were dying down right around the time I joined the games scholarship community. As I understand it, scholars like Henry Jenkins applied a literary analysis lens to games and, from there, concluded that games are stories. My criticism is that if you hold up any lens, the thing you look at looks like the lens. Using the lens of literary analysis to look at games will always make them look like stories, in the same way that using a Marxist lens to analyze games makes them look like class struggle, or a systems analysis lens makes them look like systems. I made a little joke here and pointed out that we need lenses—if I take mine off, the students turn blurry—but we have to recognize their strengths and weaknesses.

Knowing that my class is mostly Computer Science students, I pointed out that Computer Science curricula still suffer from the fact that many of the discipline's founders were mathematicians. They looked at this new idea through the lens of mathematics and determined that, of course, Computer Science is basically mathematics, and that mathematics is the way to understand this thing that we called "Computer Science." Why, I asked, do we require calculus—which we almost never use in practice—and not philosophy or psychology, which we use multiple times a day?

In truth, I meant it as more of a good-natured jab, but that observation has been haunting me the last 24 hours. The lens of mathematics has undoubtedly done good things for the discipline, as lenses can often do, but it also makes the subject look like the lens. My own department is in the "natural sciences" division of the College of Sciences and Humanities, and that forces the administration to look at us from a particular lens as well.

The old joke goes like this: Ask five Computer Scientists to define "Computer Science" and you get seven different answers. I see the rise of interest in both computer science and in programming for K-12 education, but there's also infighting between the two camps. I heard at a conference the other day, "Logic is the science of Computer Science!" Meanwhile, adults who go to coding bootcamps are taking the jobs that my graduates would otherwise go for: why hire someone green and immature when you can get someone hungry for a challenge and capable of "adulting"? Why, when I try to push the old lenses out of the way, do my colleagues desperately reach out and pull it back like a comfortable blanket on a cold day?

Tuesday, October 15, 2019

The Fantasy Item Shop Trope

Two games I have recently been enjoying are Bargain Quest and Lord of the Rings: Journeys in Middle Earth (JiME). Juxtaposing these in a semester when I'm teaching game design got me thinking about the role of tropes in game design. In particular, I've been thinking about the ubiquity of the item shop.

Bargain Quest goes all in on the trope of the fantasy item shop. In this game, you are the proprietor of such a shop. You cleverly play your item cards to lure fantasy heroes into your shop so that you can sell them gear. Then, the heroes go off on their adventure.You earn victory points if they are successful, which raises the reputation of the shop that outfitted them. On the other hand, you also earn victory points by making them spend as much money as they can—even if you're selling them overpriced garbage. Once you've lured them to your shop, you can make them buy as much as you like. This clever spin on the item shop is infused throughout the design: Bargain Quest is entirely about the idea that you run a fantasy item shop, and this idea is executed superbly.

JiME follows in the design steps of Descent and Star Wars: Imperial Assault, all being tabletop adventure games that have app-supported cooperative campaigns. I have played both Descent and Imperial Assault, and they have a familiar rhythm: play a scenario, gain treasure, spend treasure at an item shop, repeat until victorious. This pattern is ubiquitous in CRPGs and has a strong presence in popular tabletop RPGs. The system is implied by the oldest Dungeons & Dragons rulebooks that I have seen: given that killing monsters gets you gold and items in the shop have a gold cost associated with them, then the feedback loop practically designs itself. The item shop is merely the narrative mechanism by which gold becomes power.

Bilbo, Legolas, and Gimli fighting off a hungry warg
Last night, two of my sons and I finished the fourth scenario in JiME. One of them, being familiar with both Descent and Imperial Assault, said, "I wonder when will we get to buy new items." I was the one who had read the rules, set up the game, and been responsible for understanding the basics, so I had passively noticed before that items did not have gold costs, but I had not pointed this out to my boys. When he mentioned his expectation of an item shop, I pointed out to him that there must not be one because there was no currency or costs. This got me thinking about it more critically. Why isn't there an item shop?

It is worth returning to the source material—the inspiration for the game, Lord of the Rings. Tolkien's stories of Middle Earth don't mention item shops. There must certainly have been places where Bilbo could buy a new waistcoat, but that's hardly the stuff of legend. When a character in the novels does gain an item, it's crucial to the story, whether its cram or lembas, Sting or the One Ring itself. Gaining items is an interesting part of the story; one is never so crude as to try to purchase an elven cloak. While Dungeons & Dragons drew clear inspiration from Tolkien's world, in some ways it threw away his storytelling in favor of maintaining the quantified spirit of tabletop wargaming: a mithril coat could not be part of the game without having a weight, an armor class, and a cost. That's practical and simulationist, but it's not particularly Tolkienian.

Kudos to the designers of JiME then, for eschewing the trope in favor of designing within the source material. They were not only fighting the trope but also inertia, given that the same company produced the Descent and Imperial Assault systems. I would have liked to be in the design meetings when these decisions were made. Was it more a desire to be true to the source material or a dissatisfaction with their existing systems that led to this interesting design decision?

(By the way, here are links to my painting posts for games mentioned above, in case you want to check them out: Descent 1234Imperial Assault 123JiME 1.)

Monday, October 7, 2019

Reflecting on my activities at CCSC:MW 2019

This past weekend, I attended the annual conference of the Consortium for Computing Sciences in Colleges, Midwest. I have been involved with this organization for many years, and I wanted to take a moment to share an overview of how I was involved at this conference.

Student Showcase

I am in charge of the Student Showcase. Many years ago, it was a Student Poster Competition, but it felt to me that this format gave inordinate status to the scholarship of discovery. When I took it over, I revised the format to have two tracks inspired by Boyer's Scholarship model: traditional "research" goes into the Discovery track, and interesting applications of computing goes into the Applications track. This year, we had six Applications track presentations and three Discovery track.

There are practically always Ball State students in the Showcase, and so rather than judge the event myself, I organize volunteer judges. The students are told ahead of time that they will be judged on the same six categories recommended by Glassick et al.; specifically, they are told they will be evaluated on the following:
  • Clear Goals (“What is the goal of this work? What problem are you solving?”)
  • Adequate Preparation (“How did you get ready to do this work?”)
  • Appropriate Methods (“How did you solve your problem? Why did you approach the problem in this way?”)
  • Significant Results (“What was the result of this work? Who is affected by this work?”)
  • Effective Presentation (“How well does this poster or demonstration communicate what is important about this work?”)
  • Reflective Critique (“What would you do differently? What does this mean for you and your career?”)
Over the years, I have fiddled with the judging form with varying degrees of success. This year, I asked each judge to rate presenters on a 1-5 scale for each presentation and each category, and there were no hitches. The scale I provided was Poor (1), Below Average (2), Satisfactory (3), Good (4), and Excellent (5). I have also put the actual judging form online, in case anyone would like to see it.

To determine the winners, I simply take the medians across the six categories and sum them. This led to a clear winner in Discovery and Application tracks as well as a clear Honorable Mention (the third highest overall score), so those are the prizes we awarded. I am proud that my own Canning Heroes team presented and won the Applications track award this year.

Tutorial: Unreal Engine 4 for Computer Scientists

Since getting into Unreal Engine 4 a few years ago, I have noticed many interesting manifestations of Computer Science concepts. I decided to run a tutorial session this year at CCSC:MW to show these to the attendees. However, it did not go as well as I had hoped. I did not have machines that could run UE4, nor could I expect attendees to have adequate laptops, so I designed the tutorial as a sort of Show and Tell. Then I was scheduled for 8:30AM on Saturday, which meant that attendees would be tired and very few students would be there. The room we were given was really awkward: it was a lab, which meant everybody was behind monitors where I could not make eye contact. To make it worse, there was no station where I could stand and work at my laptop, so I was seated and, because of HDMI cabling, facing away from the attendees. To top it all off, I was traveling with family, and my son got sick that morning at the hotel, so I was distracted and unfocused.

Suffice it to say, I would not be surprised if the session were poorly reviewed. Heck, I would poorly review it. I would like to do something like this again, but in a more controlled environment. Perhaps I will move forward with writing up an actual paper about some of the interesting manifestations, and then be able to give a shorter show-and-tell in a future year.

On a positive note, preparing for the tutorial gave me several new ideas for video tutorials. In fact, I could take my tutorial outline, chop it up, and have a pretty good series. Now, it's a matter of determining which ideas have sufficient weight to merit the time required to do the video. (For those who don't know, I have a YouTube playlist of game programming tutorial videos. In fact, I have written up this blog post while rendering my latest video in Blender.)

WIP: Mapping Game Design Learning Outcomes to CS2013

I presented in the Works-in-Progress session what I have shared here on my blog about mapping game design learning outcomes to the ACM/IEEE CS Body of Knowledge. I think it was well received. I have made the slides available online for anyone who wishes to see them, but as usual, my slides do not make a lot of sense without the stories to go with them.

I think the audience assembled for the WIP session was happy to hear my story, and they seemed to understand my frustration. I think they appreciated seeing how one becomes more critical of CS2013 as one digs deeper into the recommendations. One mentioned that his institution had given up on CS2013 and simply used instructor consensus. Ball State is really the largest school in the region that regularly participates in CCSC:MW though, and most of the attendees were in very small departments at private liberal arts schools. 

Wednesday, September 25, 2019

Learning objectives for introductory game design: Continuing comparison against CS2013

I am giving a presentation in the Works-In-Progress session of the upcoming CCSC:Midwest conference. This short talk is connected to my post from April about mapping learning outcomes of game design to learning outcomes of Computer Science. Conversation on Facebook led me to understand that I had not fully explained my goals in that post, in large part because I had skipped the first part of the mapping: the learning objectives of introductory game design.

As far as I know, there is no standards body or recognized formal recommendations for game design curricula as there are with Computer Science, where we have the ACM/IEEE CS2013 curriculum recommendations. However, if you look at all the various introductory texts on game design, you will find significant overlap, although these are by their nature written along the lines of content rather than objectives. Each time I have taught game design as an Honors Colloquium or a Computer Science seminar, I have had to articulate the learning outcomes of the course; what I did this morning is reflect on this process in an attempt to pull out my current thoughts about what a student should learn from an introductory course. Here is my proposal:

After taking my introductory course in game design, a successful student will be able to:
  • Apply common analytical tools to existing games, examples being MDA (Hunicke), Formal vs Dramatic elements (Fullerton), and Interactive Forms (Burgun).
  • Identify positive and negative feedback loops in a game.
  • Critically analyze existing games in order to understand their component parts and describe their interactions, including such components as rules, theme, and narrative
  • Describe, apply, and justify iterative prototyping models to produce an original game.
  • Describe and apply formal techniques of playtesting.
  • Compose and present status reports.
I think this is a good number and granularity of items for how I like to introduce game design. Furthermore, having taught such courses for years, I think it's a good representation of the skills that students develop.

As I reflected on this list, though, I realized that there's another layer to the learning objectives. There are objectives that are implicit—objectives that are hiding in the cracks and in the details. Here's what I came up with as the shadow objectives:

A successful student will be able to

  • Read, understand, and critique book chapters, essays, and articles on game design.
  • Articulate specific, measurable design goals from ambiguous constraints and inspiration.
  • Incorporate feedback to improve a prototype and reflect on that process.
  • Incorporate feedback to improve analytical, compositional, and creative skills and reflect on that process.
The first one here is not to be overlooked. When I look at the design and goals of introductory computer science, learning how to read does not come up at all. I believe it also to be completely absent from CS2013. However, this is a crucial skill for someone who wants to be a lifetime learner.

The second is, perhaps, the most important skill that someone can learn in this class, and its transferable to any other creative domain. By "creative domain" here, I mean any that require creativity in the technical sense—the development of new ideas—so we can include all the sciences, engineering, and education along with the arts and humanities. More specifically, it is exactly this skill I want to see strengthened for nascent software developers and computer scientists: every day we have to manage ambiguity, transforming it into measurable goals and progress. Again, however, CS2013 has very little to say about this except for a couple of hours of requirements engineering. It may simply be a case that CS2013 is too deep into the weeds, but that's kind of my point: stepping back from the weeds, managing ambiguity and turning into concrete communications is something that a computer scientist does daily, but it's also something that is often ignored in curriculum and assessement, in my experience.

The third item is a clarification of the objective to apply playtesting techniques, but as above, there is something more potent here than just playtesting: it's about closing feedback loops to improve a product. Reflecting on this led me to compose the fourth bullet point, that it's not just about the feedback loops of the game but the feedback loops of the person. Maybe you might just call this "learning", yet I think there's not enough of this going on across our campus. For example, for a course to be considered a writing intensive course here has required that a student complete at least one draft-feedback-revise cycle. In my department, there are a few places where we practice this explicitly, and all of these are places that I have touched, which would not have this otherwise.

My next step in preparing for the presentation is to take this list, look back at my earlier post, and turn again to CS2013 to make sure that my points are clear. Right now, I have a feeling like the things I want to be emphasized by CS2013 are simply not in it at all, or at least not explicitly. It will be interesting to see the reactions of the generally-conventional conference attendees.

Wednesday, September 18, 2019

Revisiting the state analysis of Every Extend

Back in 2007, my first Computer Science education research paper was published in the proceedings of SIGCSE. The paper provides an overview of how game programming can be used as a motivating context for learning design patterns. One of the examples in the paper, which I have used for years, is the behavior of the player-controlled bombs in the inimitable Every Extend, which can be used to explain the State Design Pattern. In the paper, I argue that the player's pawn can be described by a state machine like the following.
In yesterday's meeting with my CS315 Game Programming students, I was inspired to create a UE4 tutorial video about using state machines for state management. In particular, I wanted to show how an enumeration can be used to define the possible states, and then behavior can be switched depending on the current state. This is not, of course, the State Design Pattern, but it's a heck of a lot better than an ad hoc collection of Boolean variables. It also follows from Michael Allar's Gamemakin' UE4 Style Guide that is mandatory for my students, which says:
Do not use booleans to represent complex and/or dependent states. This makes state adding and removing complex and no longer easily readable. Use an enumeration instead.
To prepare for the video, I have spent a few hours the last two days building a simple playable framework similar to Every Extend. Over a decade ago, I did a similar exercise in Java to produce EEClone. This time, I did it in UE4. (A bit of an aside: Every Extend is like my kata for new game programming frameworks. I use the essential gameplay of it as a case study to understand how game engine functions. Of course, then, when I first started learning UE4, I tried making an Every Extend clone, but it went quite poorly. After a few years of working with UE4, it's become a lot easier to get the game up and running!)

With my gameplay framework in place, I started working on the diagram shown above to use in my series of game programming tutorial videos. However, as I looked at the diagram, I realized I had a rather fundamental problem: these are not the states of the player bomb. It's true that these are, abstractly, states of the game, but they are not the states of a single stateful object. Instead, what I had programmed was leading into the following state model:
That is, a player bomb is created, which has it play a spawning animation. When that is completed, then the player becomes vulnerable to collisions but can also press Space to explode. However, unlike in the initial analysis, there are no other states after this. If the player presses Space or is hit by an obstacle, the player's bomb is destroyed: that actor—that object—no longer exists. It is the game mode that either counts down to respawn or waits until a chain of explosions is complete and then counts down to respawn. These states are not part of the player pawn.

This observation shoots a hole in my plan to make a video using the Every Extend example. I still want to make a video about state analysis, but I need to find a better example—one where a single actor's state is interesting enough to be modeled but simple enough to fit into a tutorial video. Please feel free to share your suggestions in the comments.