Intrigue: A Three-Player Print-and-Play Card Game made for National Game Design Month (NaGaDeMon 2020)

Introduction

This is the third post in my series on National Game Design Month (NaGa DeMon) 2020. The other two covered:

• Ideas I was considering for the month, and
• How I spent two weeks chasing failed prototypes

I was able to pivot mid-November and get cracking on the second idea from my October post—a game about manipulating the relationships of other non-player characters to secure a political win. The game kept its working title, Intrigue. It's a print-and-play card game for three players, and you can download all the materials on the GitHub page. The remainder of this post gives some more details about the project's inspiration and execution.

Part of the inspiration for the game goes back to 2012's or 2014's Meaningful Play conference, when I first heard of the game Fiasco. This is a short-form RPG themed around movies in the Cohen brothers' style. I have a copy and have thought of picking up the new edition, despite my never having actually made the opportunity to play. Part of what intrigued me in this design is that the relationships between players are represented by cards that sit between them. This was the first time I saw this mechanism, and for some reason it seems to be very rare. It has some similarity to the idea from 7 Wonders in which your left and right neighbors are your closest competitors for resources, but it manifests it into a tangible game piece. I actually designed a game using this mechanism years ago, a small card game about evolutionary adaptation. I made it for a game design contest that was hosted on BGG or BGDF, although now it seems to be lost to vague memory.

Design Process

The original theme of my NaGa DeMon game stayed throughout development, although not without the occasional consideration of whether it should be changed. The king was dead, and three potential successors were vying for the throne. The players are advisors to these successors, and the point of the game is to ensure that your preferred candidate is the one who becomes the new monarch.

The first prototype of Intrigue

The initial prototype was made fairly quickly using halved index cards. I grabbed a bag of pieces from my drawer o' bits and used these as tokens as I interrogated the core mechanism. The three characters were placed in the center of the table in a circle, these representing the potential successors to the throne. Players had hands of three kinds of cards: support cards that are played with a character to advance or inhibit their cause; action cards that have a one-time effect and are discarded; and relationship cards that are played between characters. I wanted the game to play fairly quickly but over multiple rounds, sort of like Red 7 or Love Letter in that an individual round may go badly, but you play out several short rounds to jockey for position. Hence, I kept the hand size small. I quickly landed on the idea that the round is over when any player is out of cards, and that the start player would rotate, with the game ending after as many rounds as there are players. 

Working through the use of support cards made me think of the elegant subterfuge in Shadows Over Camelot, in which players benefit by drawing a card if they play their own face down, but that playing a card face down increases suspicion from the other players. I brought that in to my prototype for a similar reason, with the additional benefit that drawing that card stretches the game and increases options. A face-down support card might be real support or a feint, which then introduces a vector for action cards that manipulate face-down cards as an interesting secondary mechanism.

My own testing also demonstrated that simply earning points round to round was not devious enough to match the theme, so I pulled a trick from Camel Up. Each player now had a small hand of favor cards, which are a different size than the others. Each named one of the three characters, and players could play these face-down to the middle of the table to show their support. These are revealed only at the end of the game, with the player earning points if they favored the victorious character or losing them otherwise. The number of points earned diminishes with each successful gambit, and so there is an incentive for players to decide early who has their favor if they want the best reward.

After some testing, I realized that some of the support cards were a bit dull, so I revised the system so that every card had a support value at the bottom. Now, any card could be played as a support card or for its printed ability, as in the Focus values in one of my favorite CCGs, Legend of the Five Rings.

My original design had the board cleared after each round, but post-playtesting discussion raised the idea that relationships should stay on the board. This made relationships much more interesting because they were now static through the game, but that also meant that I could introduce mechanisms to remove or replace them. This is thematically appropriate as well, since it is possible that a savvy advisor could turn enmity into friendship as long as it benefit's the advisor's end.

With half the month spent on other prototypes and the week of Thanksgiving spent getting some much-needed R&R, I feel like there are some loose ends to the design. I wanted to spend some time seeing how the game scales to four or five players: would it make sense to keep three characters on the board, or should that match the number of players? If I needed more characters, I would have to actually design more. Right now, there are three different traits in the game (Nobility, Royalty, Religion), from which each character has two; this gives four unique combinations, and there are four characters available. It's a clear maneuver to add another trait and then get more variety in the characters, but I didn't have the opportunity to do this in November. 

Production

With a solid, tested prototype, my next task was to determine how to prepare the game for print-and-play production. I have assigned this tasks to my students before, but while I had read some about it, I had never actually released a print-and-play game before. When my team produced Race to the Moon, I had all my card designs in a spreadsheet, and my graphic designer laid out the cards from that. Hers was a manual process, but you know the maxim of pragmatic computer scientists: if it can be automated, it should be automated.

After a bit of hunting, I settled on nanDECK. It is free (as in beer) Windows software for producing cards and tokens from scripted input. Once I decided it would be my tool of choice, I delved into making it run on Linux using WINE; the only hiccup was that I had to determine how to install Windows core fonts using winetricks. With that set up, I was able to learn how to write nanDECK scripts to produce my four different types of cards and tokens, including double-sided favor cards and drawing data from a LibreOffice spreadsheet.

Sample sheet of printable cards

When I started using nanDECK, I used the visual editor to drag and drop layout elements. However, this quickly outlived its usefulness as I wanted to incorporate conditional elements. For example, arrows are shown on cards if and only if they are relationship cards, but it seems the visual editor is not robust to that kind of flow. I quickly transitioned to using percentage-based layouts. For example, laying out the type of the card is done with this command:

TEXTFONT=[all],[TYPE],0%,15%,100%,10%,CENTER,CENTER,0,100,Oxygen,14,I

That is, on all the cards, put the TYPE field from the spreadsheet into a box that is at X=0%, Y=15%, Width=100%, Height=10%, centered vertically and horizontally, with 0-degree rotation, completely opaque (alpha=100), in 14-point italic Oxygen font. At first, this looks like gobbledygook, but the more you work with it, it gets to be a really convenient shorthand. The nanDECK script editor provides hints along the bottom of the screen telling you what each command expects as arguments, and while they are sometimes arcane, they also provided me everything I needed for a quick transformation from spreadsheet to printable card.

I talked with a friend who does a lot of paper prototyping about tools, and he prefers Component Studio. I was turned off by it some years ago because, at the time, it seemed to suffer from serious vendor lock-in, so that you could not access your files unless you continued to pay a subscription fee. Maybe that has changed, I don't know. He is a UX designer, though, and we both agreed that nanDECK has an amazingly retro 1990s interface. It's like the bad old days, when there were essentially no standards and everyone making interfaces was just winging it. For example, nanDECK has idiosyncratic interpretations of left and right click: you might think left click is select and right click brings up a context menu, but you might be surprised at what you find. Still, like Blender, UE4, or Gimp, just a little usage starts to make the idiosyncrasies invisible, and you can start moving from idea to execution without the hurdle of interface interpretation.

A final note about nanDECK: if you try to learn it and start searching for help, you will quickly find that the creator is amazingly responsive on the nanDECK Users Guild on BoardGameGeek. I love that this person wanted a tool to automate something, made the tool, shared it with the community, and continues to improve it based on interest and feedback. Cheers, Nand!

The rulebook was written using LaTeX. It has always been my preferred document preparation software, although I did find myself wanting some of the terseness of Markdown while writing. I stuck with LaTeX, though, in part because I knew I could have control over image placement and document flow so that the output would be attractive when printed. In the end, there is only one figure in the three-page rulebook, and it's possible I might have saved time by doing it in a more lightweight language.

First page of the rulebook

I wanted to set up automated builds using GitHub actions, but I ran into significant technical problems. The Linux images provided by GitHub do not include wine. I'm not savvy with docker, and so it wasn't clear to me if I should invest time in figuring out how to script the install and configuration via the GitHub action script, create an image and upload it somehow, or do something else entirely; furthermore, it wasn't clear that I could run nanDECK headlessly, since my experiments with automation still brought up the UI as part of the process. I learned that GitHub also provides Windows Server images for actions, but I don't know the scripting language there, so either way looked like headaches that were not integral to the project itself—an artificial rather than essential complication. Hence, although it pains my automated heart to say it, the builds are all done manually by me and then uploaded via push.

I turned back to the old standard for client-side build automation: GNU Make. I haven't written a makefile in ages, and it was kind of fun to get back into it. I used one makefile for each of the two project directories, with one master make file at the top level. I don't remember ever having done this before, but it worked like a charm. I'm still a bit hazy on the reason for phony targets, but I also don't expect this to be a problem for a one-off NaGa DeMon project.

The obviously missing piece of my digital files is any kind of intentional visual aesthetic. Reviewing my game design students' work, I noticed that one of my art-inclined students has a lovely palette for her work, and this gives it an enviable level of polish. It would not be too difficult to pick a few colors and splash them onto my files; I simply ran out of November. The only interesting bit of visual design I incorporated was separating the support value of cards from the rest in a half-rounded rectangle. I would like to return to a nanDECK-powered project some time when I have more ideas and time to execute more compelling visual design.

The makefiles and nanDECK scripts are all publicly available on my project's GitHub page, so feel free to go take a look. I would be particularly interested if any nanDECK hackers look at my scripts and see easier ways to use the tool to accomplish my goals.

Conclusions

This is my third NaGa DeMon project, and I enjoyed working on it. In retrospect, it's easy to say that I should have done more paper prototyping of my first two ideas before getting into the code. Both of those were, in a sense, code experiments, and I did learn a bit from them. The lesson here maybe is one of prudence: yes, I should do code experiments to learn new things, but no, I should not do it during a jam where I want to have something useful to show at the end.

Intrigue: NaGa DeMon 2020 Release

This wraps up the discussion of my participation in NaGa DeMon, but I anticipate sharing with you one more post in this series in the coming days. I wasn't the only one in my household completing a project this November! Subscribe and hit the like button. Err, I mean, stick this blog in your RSS reader for part four.

An open letter to my students on the topic of course evaluations

The following is an open letter to my Fall 2020 students.

November 30, 2020

Dear Students:

In every semester of my 15 years at Ball State, I have made time to talk to my students about course evaluations. This presentation has grown over the years as I have learned more about the history and impact of course evaluations. In recent years, the discussion has touched upon four major themes, and I will describe each in turn.

The first theme is that I take the evaluations seriously. I give more consideration to written responses than the numeric ones. Written comments provide more context, which help me identify affordances for action. I have made changes in my courses based on student feedback, including clarifications and modifications to my grading scheme, sequencing of assignments, and team accountability systems. One significant example that should resonate with Ball State Computer Science students is expanding the final project in CS222 from six to nine weeks, even though it meant shortening the early-semester instructional period.

The second theme is that course evaluations are generally misused in contemporary higher education. These instruments emerged in the middle of the 20th century to provide formative feedback to faculty. Formative is a key word here: the feedback was meant solely for a faculty member to be able to improve their teaching. This is like the written feedback that I might give to you on an assignment, pointing out areas of particular strength while pointing out directions to remediate weaknesses. Predictably, administrators made the mistake of looking at these data from a Taylorist, scientific management point of view, using them as summative evaluations of teaching. A summative evaluation is like the grade you get at the end of the course: impersonal and lacking in context. Hence, we see a process designed for one end (formative evaluation) being misapplied for a different end (summative evaluation) without apparent regard for fitness of purpose. 

I maintain antipathy for the summative ends for personal and professional reasons. It doesn't matter to me where my department or my college rates me with respect to other faculty. I only care about the formative ends; that is, I want to use the teaching evaluations as one of several sources of data to help me improve my teaching.

There is a relevant corollary to this second theme: I believe that many students believe that my teaching evaluations primarily serve the summative role, despite my exhortation to the contrary. I have noticed that many written comments over the years have been composed as if they are going to my supervisor rather than to me. This manifests, for example, in talking about me in the third person rather than addressing me directly. This is pertinent because it supports my argument that this is a systemic failure, not an isolated one.

The third theme of my presentation to students is that they are always welcome to give me private, personal feedback on my course, both during and after. I follow a white box pedagogy in which the inner workings of my course designs are available for any who are curious. For example, my course plans frequently include explanations of my reasoning for assignments and grading schemes, and I post both my course plans and my reflections upon them in public. I inform my students that I am happy to talk to them now, but I also acknowledge that there is a power differential: even if I claim to be unbiased and open, I am still the one who determines their grades. Hence, I welcome and encourage them to talk to me about the course after it's over—whether it's that week, the next semester, or years after graduation. I am happy to hear their stories because I know we can learn from each other through real and honest discourse.

The fourth theme is that the direct beneficiaries of an honest evaluation are the next generation of students. That is, I try to impress upon my students the idea that completing a course evaluation is a form of charity, a service to those students who will come after them whom they may never meet. I don't like the term "giving back" since it implies an obligation of reciprocity that does not exist, so I  frame it instead as an act of volunteering for the good of the community.

With those themes articulated, we can address the current situation. Several years ago, the university switched from paper-based teaching evaluations to online. Response rates plummeted. I have spoken with a few faculty who saw negligible decline in response rates because they continued to have students complete the evaluations during class time. However, most switched to an asynchronous model and had concomitant reductions in response rate. Informal conversations reveal that all faculty and administrators are aware of the severe reduction in response rate, and yet there has been no observable change in how these teaching evaluations have been used. That is, in discussions of promotion, tenure, and merit, I hear people making decisions based on the teaching evaluation data as if they were meaningful.

The problem, of course, is that they are not.

A scientific epistemology reveals the problem clearly. If all students submit honest teaching evaluations, then we can clearly conclude that the results are meaningful. If a majority submit evaluations, then the results are probably meaningful. This was the case with paper evaluations, although one ought to consider that potentially valuable feedback from those who stopped attending class is missing. With the online asynchronous approach, I consistently see only a minority of students completing evaluations. This has been consistent despite my allocating more time and attention to the matter and providing numerous reminders in person and via Canvas. 

It is theoretically possible for a minority of responses to validly represent the population but only when using random sampling. However, evaluations are not completed by a random sample, so this is a non-starter. Indeed, the sampling problem is worse than that: it is only those who are motivated to complete evaluations who do so, and that motivation is often emotional rather than rational. We all know what happens when you combine strong emotions, anonymity, and the Internet.

Reading non-representative student evaluations is far from innocuous; it contains a subtle and serious danger. Scholarship of learning tells us that people effectively cannot "unlearn" ideas. Once you learn something wrong, it is very difficult to overwrite that idea with something correct. Misconception seems to prowl about the subconscious, continuing to direct thought and action. Hence, even if a faculty member knows that the teaching evaluations are not representative of the whole class, the ones they read will still impact their future course designs—potentially for the worse. The feedback loops are insidious when considering the power of confirmation bias, that one reads into the evaluation what one wishes to see, and then uses that to affirm rather than interrogate existing patterns. Garbage in, garbage out.

My conclusion, then, is that I ought not to read your course evaluations this semester for any course that has low response rates. I expect this to be all of my courses, given the ineffectiveness of exhortations and reminders in my past experience, combined with the fact that all my classes are asynchronous and online this semester: I don't even have a time when I can casually discuss the four themes with my students. I want to be explicit that my decision not to read the evaluations is not because I don't care but precisely because I do care. Reading unreliable data has the potential to cause more harm than good. I take my scholarship of teaching too seriously to allow a flawed system to potentially damage my work. 

As always, I welcome feedback from you. Feel free to reach out to me now or in the future. Whether you want to discuss content, pedagogy, or philosophy, know that I am happy to talk with you. Those are the conversations that I want to be formative to me and my practice, for it is there that I believe we can find goodness, truth, and beauty.

Sincerely,

Paul Gestwicki, Ph.D.
Professor
Computer Science Department
Ball State University

The Most Terrifying Story in Fairyland: The Scarecrow of Oz

 Several years ago, I read through all fourteen Oz books by L. Frank Baum with my second son. They are fun fairy tales, although few of them are very interesting. Most have a loose plot that is summed up in chapters of the form encounter a situation, talk a bit, resolve a situation. 

For the past several months, I have been reading the series again, this time with the younger boys. I was excited to start The Scarecrow of Oz the other day because my recollection was that this book, which has almost nothing to do with the eponymous Scarecrow, contains one of the most chilling stories in all of literature.

A few chapters in to the book, the protagonists enter the kingdom of Jinxland, which is part of the Land of Oz that is geographically separated from the rest by impassable mountains. Jinxland is currently ruled by the paranoid King Krewl. On their way to the castle, our protagonists meet Pon, a distraught young man who works for the royal gardener. Their conversation reveals that Pon is in love with Princess Gloria, who loves him as well and wishes to marry him, but is banned from doing so by her uncle, King Krewl. When the protagonists point out that a princess ought not marry a commoner, Pon reveals his lineage: he is the son of the previous king! His exposition lays out the story:

“My father used to be the King and Krewl was his Prime Minister. But one day while out hunting, King Phearse—that was my father's name—had a quarrel with Krewl and tapped him gently on the nose with the knuckles of his closed hand. This so provoked the wicked Krewl that he tripped my father backward, so that he fell into a deep pond. At once Krewl threw in a mass of heavy stones, which so weighted down my poor father that his body could not rise again to the surface. It is impossible to kill anyone in this land, as perhaps you know, but when my father was pressed down into the mud at the bottom of the deep pool and the stones held him so he could never escape, he was of no more use to himself or the world than if he had died. Knowing this, Krewl proclaimed himself King, taking possession of the royal castle and driving all my father's people out. I was a small boy, then, but when I grew up I became a gardener. I have served King Krewl without his knowing that I am the son of the same King Phearse whom he so cruelly made away with.”

The fact that the Oz natives are immortal is well established in the earlier books. Mortals such as Dorothy who come to Oz do not share this quality, which is occasionally a plot point in the earlier books. In Ozma of Oz, the central plot is about a group of good Ozites going to the neighboring Land of Ev to rescue their royal family from the Nome King, who has magically transformed them into ornaments. Ozma and company would never want the rightful rulers of Ev to spend eternity as a nome's baubles. 

Here, in Jinxland, we get the first mention in Oz of a character being essentially killed. Keep in mind, however, that even as Pon points out, they are not actually killed. 

Right after Pon gives this explanation, he is asked about Princess Gloria's father, to which he responds,

“Oh, he was the King before my father,” replied Pon. “Father was Prime Minister for King Kynd, who was Gloria's father. She was only a baby when King Kynd fell into the Great Gulf that lies just this side of the mountains—the same mountains that separate Jinxland from the rest of the Land of Oz. It is said the Great Gulf has no bottom; but, however that may be, King Kynd has never been seen again and my father became King in his place.”

This is how Pon relates the story. Ten chapters later, after Ozma has sent the Scarecrow to Jinxland, the Scarecrow describes the succession a bit differently:

[The Scarecrow] told how Gloria's father, the good King Kynd, who had once ruled them and been loved by everyone, had been destroyed by King Phearce, the father of Pon, and how King Phearce had been destroyed by King Krewl.

It seems that King Kynd's falling into the Great Gulf was no accident. 

By the end of the story, Krewl is deposed, Pon and Gloria are wed, and the two are installed as the rightful rulers of Jinxland, to much celebration and fanfare. The Scarecrow explanation that both King Kynd and King Phearce were "destroyed" may be true, since the fiction does not clearly define the boundaries Ozites' immortality. Indeed, perhaps The Scarecrow of Oz is the canonical explanation. Being held underwater and crushed by rocks does seem like it would be hard to come back from, but we know the Nome's Magic Belt let him turn people into ornaments with no lasting effect on their well-being. Endlessly falling similarly does not sound lethal, especially since in Tik-Tok of Oz, the main characters fall through the Hollow Tube, which ran from Oz all the way through the center of Earth to come out on the other side in the land ruled by Tititi-Hoochoo. Incidentally, that tube was created by a Magician...

“...who tumbled through the Tube so fast that he shot out the other end and hit a star in the sky, which at once exploded.”

“The star exploded?” asked Betsy wonderingly.

“Yes; the Magician hit it so hard.”

“And what became of the Magician?” inquired the girl.

“No one knows that,” answered Polychrome. “But I don’t think it matters much.”

Even the Magician who shot into space and blew up a star with the force of his impact is not necessarily dead nor destroyed.

Maybe the Scarecrow is correct in his pronouncement that both Kynd and Phearce have been destroyed, but maybe this is, in fact, a coup. Ozma rules over all of Oz, but she knows that the geographically-isolated region of Jinxland is prone to rebellion, and King Krewl is not one to bow to her wishes. On the contrary, Pon and Gloria both seem amenable to maintaining Ozma's preferred political order. So, Ozma sends her emissary—the charismatic and clever Scarecrow—to help arrange the coup. The people cheer at Krewl's elimination, for he was an unjust ruler. This allows the Scarecrow to emerge as the hero and subsequently to install Pon and Gloria as the new rulers, both of whom vow fealty and gratitude to Ozma. Pon and Gloria both know their claims to the throne depend on their fathers' disappearances. Despite the prevalence of magic in the kingdom—in characters such as the Wizard of Oz and Glinda the Good, or in artifacts such as the Magic Belt—they damn their fathers to eternal suffering and isolation while their people rejoice at their ascendancy.

That is the most terrifying story in fairyland. It brings an entirely different light to the claims made throughout the series that all the subjects of Oz love Ozma, how they all believe her to be kind and good, and how people throughout fairyland believe her the greatest, wisest, and most beautiful ruler. They all know what may happen if they don't toe the line. 

Beware ye to whom Ozma sends the Scarecrow.

NaGa DeMon 2020 Status Report: Two out the window, One in the oven

At the end of October, I shared some preliminary plans for my NaGa DeMon 2020 project. Once the calendar flipped to November, I started work on a roguelike. After a little over a week of work (off and on), it looked like this:

I made this in Godot Engine using Kenney's 1-Bit roguelike pack. As I mentioned before, I have never made a classic roguelike, and it was fun to build this project up this far. Getting into using BSP for dungeon generation was quite interesting, but I hit some serious technical and algorithmic frustrations in creating useful tunnels between rooms. This took some of the wind out of my sails, in large part because it made me face the fact that, following this path, I would end up with basically "NetHack but worse." I love NetHack, but I didn't really have any inspiration for my roguelike that would make it stand apart. It didn't have a hook, as Josh Ge put it in his inspirational talk.

I let my wander into the realms of hooks, and a thought crossed my mind that's been flitting about intermittently: what happens if you combine PbtA-style action resolution with a CRPG? Regular readers may recall that my NaGa DeMon project last year was a PbtA campy superhero RPG. I am not aware of any game projects, even experimental ones, that attempted to put PbtA mechanisms into a video game; small experiments may be out there, but I think if there was a major one I would have heard about it. In any case, this line of thought combined nicely with the roguelike mindset I was already in, and I found myself thinking about the interface and style of Hero Generations. I have also been reading about Dungeon World and prepping to play the Unlimited Dungeons hack with my family, so that was on my mind. 

Working along these lines, I built a prototype in about a week that looked like this:

It actually looked a little better than that, but not much. It seems I abandoned this one in the middle of working on a feature branch, so you cannot see the text indication that there are some goblins in the dungeon. 

What made me abandon this project was a similar sense of being directionless that hit me a few days into the development of the earlier prototype. I implemented action selection for actions akin to Dungeon World's Hack-n-Slash and Discern Realities, as well as Escape and Advance moves for dungeon-delving. Each of these supported the three traditional PbtA roll outcomes of failure, partial success, and success—an important and symbolic part of the game that I have written about before. Middling successes resulted in a variety of options that depended on the contents of the current room.

This all worked in a technical sense, but it was just a mechanical toy: I didn't have a goal besides seeing what happens if I did it. Indeed, I think both this prototype and the previous one were fun implementation projects that merited more attention to paper prototyping. I think part of me knew for both of these that, if I had spent more time paper prototyping, I would come to the clear conclusion that I could make these things but that I didn't have much reason to do so.

After stopping work on this prototype, then, I went back to first principles: what project is exciting enough to me that, with only half the month left to go and another pile of looming work, would keep me inspired to finish strongly? I decided to go back to the first idea that I had written about in October, that idea that has been pulling at my interest for some time: a card game about manipulating the relationships of powerful characters who are not controlled by any player directly. 

I started work on that other project in earnest late last week, and today, I published v0.1 of the rules as a print-and-play game. The working title is "Intrigue," and you can download the rules and cards on the Web site. The graphic design is rudimentary, and there is a complete absence of illustration. That said, I've been happy with the game in playtesting. The story of this game's development, including twists, turns, and technology, will be the subject of a future post.

Teaching Game Design with Player Practices: A Blog Letter to Chris Bateman

The following is a blog letter to Chris Bateman, in response to his "Write to Me" post on October 27. We had a brief email exchange, based on which I have moved the question here.

I heartily enjoyed reading your three-part serial on game dissonance on the International Hobo blog [1, 2, 3]. Your theory of Player Practices is intriguing, and it certainly is appealing in that it bridges gaps left by systems-focused or story-focused approaches.

My question for you is a practical one: what would it look like to teach an introduction to game design using player practices as the frame?

For background, I teach an introduction to game design course that is terminal and elective: it is not a prerequisite to any other course, nor is it a formal part of a games-related curriculum. Although the course is hosted in a Computer Science department, the course involves no programming—a point that sometimes surprises students who enroll! Instead, we focus on analog games, which means anyone with markers, dice, and a deck of cards can be productive. My emphasis in the course is in helping students learn the value of rapid iteration and player-centered philosophy. That is, they should move quickly from idea to testable prototype, and they should evaluate their games with real players. Incidentally, this is something that is of special value to the Computer Science majors and minors who take the course since it brings a People focus in a curriculum that overwhelmingly emphasizes Things.

How might you bring Player Practices to bear in such a course? My thoughts turn, for example, to how I have had students pitch their final projects. Usually I have them write a one-page concept document in Tim Ryan's format. This format includes a Background, in which I expect them to cite how their work is inspired by or based on other ideas they have seen; clearly, Player Practices may be applicable here. I also have them write a second-person narrative describing the player's experience playing the game. I have touched upon a peculiar phenomenon in a few other blog posts, but I don't think I ever devoted one post to it; namely, that almost all of the students struggle with writing about the player's experience and instead write about the character's experience. This seems to happen regardless of the amount of frontloading I do to explain the difference. It struck me as I was preparing to write this letter that, I think, this is a case where player practices may provide a language to help the students.

Thanks for your willingness to share your thoughts on the matter. I am always revising my courses, and I look forward to considering how your perspective on Player Practices may be incorporated.

Cheers!

UPDATE: Here is Chris' thoughtful response.

Preliminary plans for NaGaDeMon 2020

I have enjoyed participating in National Game Design Month (NaGaDeMon) for the last two years. Last year, I made KAPOW! The Campy Superhero Roleplaying Game, and two years ago, Heroic Uncertainty. For this year, I have had two ideas tickling the back of my mind. The other day, when I was in a conversation about them, I actually forgot what one of them was. That's a good indication that it's time to write them down! This has been a great month for blogging, and I have this afternoon set aside for thinking and writing. Even though I just finished a post about something completely unrelated (or is it?), there's no time like the present.

Idea #1: Character-Interaction Generation

This has been at the back of my mind for some time, but it's pretty amorphous. The inspiration is a somewhat formalist approach to the relationship between characters in a world, simulating the changes in their relationships over time. For example, given a tableau of six characters, and drawing a "secret enmity" card, you could roll a die to determine who is secretly plotting against whom. Perhaps later, though, a "false rumor" card comes up and targets the "secret enmity" card, changing the table again. Now, maybe there are no cards and maybe there are no dice, but that's the basic idea of the setting, although my idea was that the players would actually be doing a different game for or with those characters. For example, maybe players are striving to earn the favor of one character who may become king of the popes, but their actions are interpreted differently based on the political, interpersonal state.

That's a bit vague, I know, and it also hints at suffering from the same problem as Heroic Uncertainty, where the thing I want to play with is a secondary system rather than a central system. However, something that brought this idea to mind was reading about A War of Whispers, a game in which the players are manipulating resources on a map, but that's actually secondary to their victory condition, which is ensuring they are backing the right political power. That's very much in the spirit of what I was considering, and in fact, I backed the recent Dark Alliance expansion Kickstarter. My copy of the game will be here sometime, though definitely not with enough time to study it as an inspiration before the beginning of November.

Again, a lot of uncertainty here, maybe even a heroic level. It's not clear in my mind even if it would be tabletop or digital, so that means it would have to be tabletop. See, writing is epistemic.

Idea #2: Roguelike

I came across Bob Nystrom's talk about ECS at Roguelike Celebration 2018 through, I think, YouTube's recommendation system. Nystrom is the author of the wonderful Game Programming Patterns, a book which I've said before I wish I had written. I have done some research and development around Entity Component Systems as well, and I've long said that Nethack is one of the greatest games ever made, so I loved hearing his talk on ECS in Roguelikes. In fact, I just put it back in my watch later queue to listen to it again. His talk got me thinking about making my own roguelike, which is a genre I have never explored. I have been recommending Kenney's excellent public domain artwork to my game programming students, and I know that he has a few different asset packs for 2D roguelikes. 

I don't have any particular ideas for innovating in this space. I think if I went this way, I would just take inspiration from the art that is available and use it as an excuse to work with some of the classic dungeon generation algorithms and data structures. Heck, maybe I could even dust off my knowledge of ECS to flex those muscles, although deploying ECS was much easier when I was using PlayN than in GDScript or UE4.

That's it, my second blog post for the day, and a place to come back to if I find once again that I have forgotten my own thoughts. Feel free to leave a comment if you have a suggestion or preference. I expect that on Sunday, I'll be able to do a more focused cost-benefit analysis and choose a direction to start working on NaGaDeMon.

On Philosophy in Computer Science

Recent events have given me the opportunity to spend some time with a colleague at the university from another department. He told me how, many years ago, he met a developer who told him about Linux, and it was the first time he realized that Computer Science involved philosophy. Really, how else would someone from outside the discipline know? 

The discussions involved making a distinction between two ways of looking at Computer Science. I identified myself as being in the "human-centric" camp, and a respected colleague identified himself as being in a "math-centric" camp. I believe that the distinction I made was between human-centric and technical- or formalist-centric. Interestingly, when he later recounted the distinction, he described me as "anti-math" and him as "math". That, itself, demonstrates an interesting sort of Manichean reasoning seen from his philosophy: that either you're for math or against it. I responded that I was not anti-math, but human-centric, and that one can do math in a human-centric way. This was a sort of distraction from the main purpose of our meeting, and predictably, the conversation did not go anywhere except to clearly establish that there are different ways of looking at the discipline.

As I have thought more about this, I think there's a clearer way to make a distinction between these philosophies. One of them sees mathematical formalisms as an ends in themselves: the math is beautiful, and you should study it and admire its beauty. Another perspective is to look at them as a means to an end: the math is a tool that allows us to do things we could not do without it. These have very different implications for curriculum design, which in large part is the most important thing that CS computer science departments have to do collectively.

It is import to note that most of the formalists that I know will also claim that the mathematical formalisms empower you: they are not just beautiful, but also useful. Indeed, the inciting incident of the conversation was a claim that studying algorithms helps you write more efficient, more effective, and more correct programs. This claim is ubiquitous in discussions of academic computer science, and yet I have never seen any evidence for it. Indeed, the educational theory that I know suggests that it is not true. Transfer is hard and is never free, so to suggest that studying one thing makes you magically better at a different thing is specious at best. Studying algorithms makes you better at algorithms, but if your goal is to get someone to be an efficient, effective, and correct programmer, you're much better off teaching them Test-Driven Development, Pair Programming, intellectual humility, and a love of lifetime learning. When I took this issue to Facebook, one of my alumni put it best: the most likely case is that there is a correlation between being a good programmer and being good at algorithms because both are difficult and can serve as a measure of intelligence and conscientiousness. That is, correlation is not causation. 

This is crucial when deciding, for example, where to place discrete mathematics, algorithms, and computational theory in a curriculum. I know many math-trained computer science faculty who claim that you cannot understand data structures unless you study discrete math first, but that claim is easily refuted by counterexample: we have plenty of students who drop and retake discrete math and yet have no problems with CS2. To steelman the opposition for a moment, it could be that the problem is that our courses do not draw enough upon their prerequisites, and indeed, I think that's a good point. We—collectively, as a discipline—have not distinguished clearly between what exactly we want students to know coming out of a three or four credit-hour discrete math course and how exactly it manifests in the follow-up courses. We are locked into a "course" model of higher education, where ideas come in neat, delineated packages, taught by people who focus on those areas or, in some cases, focus on no areas. A lot of faculty get uncomfortable at the very mention of shaking this up.

A few years ago, when our Foundations Curriculum Committee tried to look into the question of what elements of discrete math were needed for courses that listed it as a prerequisite, the answers we got were completely inactionable, being either "They need all of it" or "They don't need any of it." Indeed, I have led that committee for something like twelve years, and we have been constantly fighting against problems of how to improve the discrete math and algorithms courses, in large part because the people who teach those courses see nothing wrong with them.

The old joke goes like this: ask five computer scientists to explain computer science and you get seven different answers. I would like to know if other academic departments have this kind of culture war. Are mathematics departments hobbled by differences about whether math is a means or an end? How about physics? Biology? What about non-science fields such as Architecture, which I think some of us see as closer kin than mathematics.

I make the case when I teach CS222 that Computer Science is applied philosophy. While anybody can use computers, we are in the amazing position to be able to imagine worlds and then make them real. This is what drew me to the field. To be clear, I loved my Computational Theory course in grad school, but at the same time, I'm a melancholic introvert who loves ideas. I also loved reading The Design of Everyday Things, and I think it helped me much more in my day-to-day scholarly work than Godel, Escher, Bach. 

I think it would be interesting to try to measure the distribution of different philosophies among Computer Science faculty. It would be a challenge to develop a reliable and valid instrument for measuring such a thing. I know people at big schools and at small schools, and I'm not sure that the distribution of philosophies would be that different. I suspect you would find a greater concentration of human-centric computing at schools with a longer tradition of HCI research, and at places like Georgia Tech, where the media computing approach was born. That is, I suspect a human-centric approach to computing may be able to be grown.

Naturally, we need productive disagreements, but I think my field is hamstrung by a preponderance of activity on the formalist side. I have been on many search committees now, so I have some sense of what freshly-minted PhDs look like—or at least the ones who apply here. Most tend to have gentle words about student-centered teaching, but it is less common to find those whose scholarship is integrated. Of course, I don't think my work was integrated with my scholarly self either when I was fresh out of graduate school. But, if we continue to reward isolation and scientism, we will miss out on the opportunity to help scholars develop a real philosophy. I consider myself fortunate to have ended up, whether by chance or by grace, at a place that valued my interests in exploring a Boyer-inspired view of scholarship. Indeed, sometimes I wonder where I would be today if I had not taken the time to read Boyer and Glassick around 2007-2008.

How does this relate to Linux? Understanding the Free Software movement requires an integration of technical and non-technical aspects of computer science, in alignment with an understanding of economics and ethics. There's a lot of room under this umbrella, and it's not just applied math.