NoGaDeMon

It's almost the end of November 2023, and sadly, I don't have a National Game Design Month project to share this year. It was a good run, but I needed to take this November to focus on other things. It's been a busy semester, but a good one. I helped run the Symposium on Games this month, and I'm the chair of the search committee that is looking to hire a new colleague to help with our games curriculum. I am also currently working on a grant from the Indiana Space Grant Consortium to make a game that helps teach middle school youth about paths to college. We demonstrated our work at the Symposium and received positive feedback, and now the team is making plans for the next steps. In fact, I will have a course release next semester to focus on this project, but since I didn't have one this semester, it was like teaching an extra class to try to keep the project running. I also have a group study of game AI that has been interesting, and those students will be presenting their work in next week's department colloquium. 

So, to make a long story short, no NaGaDeMon this year, but plenty of game design (and game design adjacent) work happening. I am currently in the process of setting up Ball State to host Global Game Jam again in January, and that's the next major jam event on my radar.

Automatically publishing Godot 4.1 projects to GitHub.io

Some time ago, I wrote a blog post and made a video about how to automate the publishing of web-based Godot games on GitHub.io. It worked fine in 3.x, but with the release of 4.x, things got complicated because of SharedArrayBuffer. I have come across some tips online that claim to solve the problem, but I was unable to get any of them working entirely as advertised. After some effort last night, I've been able to pull all the pieces together into this GitHub workflow configuration:

Briefly, this makes use of barichello's godot-ci Docker container to build the web export for the game, then it brings in gzuidhof's service worker to provide the secure context necessary for SharedArrayBuffers. Deployment to GitHub pages is conveniently managed via peaceiris' actions-gh-pages.

Here is what you need to make this work:

• The script assumes you have a "project" folder at the root of your repository, and that your Godot project and its corresponding project.godot file are there.
• You need to have configured HTML5 export and called it "Web," which is the default. Set the export to go to the path "build/web/index.html" off of the repository root. That is, within the export settings, the export path will be "../build/web/index.html".
• Make sure your export configuration (export_presets.cfg) is in the repository. That is the default for Godot 4, but you'll find some sample .gitignore configurations that want to hide that file.
• Your repository must be public.
• You have to enable GitHub Pages in your repository. In the corresponding section of the GitHub repository settings, make sure your source for the pages is to "Deploy from a branch" and that the branch you select is "gh-pages."

I was blindsided by the HTML5 export complications when trying to build a web version of my last Ludum Dare game. I'm hopeful that this new configuration will make my deployment easier for Ludum Dare 54, which starts tonight.

UPDATE: Although I did not complete an LD54 project, I did get far enough to set up GitHub automation. I ran into a problem Saturday that I did not see on Thursday, which was the need for the build system to be able to write to the repository. It comes up in peaceiris' gh-pages documentation, and the fix is a one-liner: the addition of a permissions statement. I have updated the gist above to include this.

Teaching TDD... but what just happened?

In my CS222 class, I spend a lot of time talking about, demonstrating, and giving feedback on Test-Driven Development (TDD). Indeed, from the very first day of class, we're doing TDD. For several years, I've opened the course by talking about confidence and how we can take small steps to maintain it. Last week was the fifth week of the semester, and my students had just started the "two-week project." That project integrates the concepts from the first four weeks of the semester into a single deliverable that of course includes TDD.

On Thursday, I was showing them how we can write a custom parser for data pulled from Wikipedia. I started by writing a test that, given my sample data, my as-of-yet unwritten parser could extract the piece that I want. Then, we wrote a clearly naive implementation of the parser that just returned that value as a literal. The literal has no place in the specification, and so our refactoring moved us to a correct solution. I made a big deal about how we had just completed a red-green-refactor sequence, summarizing each step to them as I have just done for you above. I especially emphasized that at the time of writing the test, we didn't care at all how we would make it work.

A student pushed back a little on the solution, asking why we didn't just go back and change the test case itself to something else. I responded that this would not be right, because before we wrote any production code, we first had agreed that this case was correct--and it was. I reminded them again about red-green-refactor. At this, a different student raised his hand to comment. These are not his exact words, but his observation was essentially this: "Are you saying, then, that at the red step, we write a test that tells us what we need next, but we don't worry about how it will work; then we make it work however we can; and then we clean it up to make it work right?"

I paused for a moment and then agreed, telling him that I really couldn't have said it better myself, thinking to myself as I said this that I had, indeed, said basically that same thing, many times in the past five weeks. At this, several heads in the class nodded sagely, making expressions as if they had gained some new insight into the process.

On one hand, I am happy that they seem to understand it now better than they did before, that this students' summarizing the process seemed to resonate. Yet I am plagued by the question, What just happened? What was actually different about this explanation than before?

I will see the students again tomorrow, and I'm thinking about just asking them. I don't want to make anyone feel badly about not understanding it before, but I do want to know if they can identify what tipped them toward understanding it now.

The one question to ask playtesters (according to Mike Selinker)

I listened to some of Justin Gary's interview with Matt Fantastic on the "Think Like a Game Designer" podcast on my walk home from work today. The two were talking about how to interpret playtesting results, and Mr. Fantastic shared some advice he got from Mike Selinker. According to Fantastic, Selinker advises asking playtesters just one question, "What did you do?" 

This question completely avoids problems of the designer asking leading questions. Instead, the designer gets to hear what the player experienced in their journey through the game. It's a lot simpler than some of the other formats I have used and encouraged my students to use, and it's certainly simpler than the formal playtesting process that my students are pulling from Lemarchand. It would be fascinating to run parallel tests with these different formats and see if there's something objective that can be learned from this, but who has time for yet another research project?

Brief summary of Zinsser's "On Writing Well"

I recently read through most of the 4th edition of William Zinsser's On Writing Well, published in 1990. I pushed it to the top of my reading list after reading Filip Hráček's article, "The engineering principles behind GIANT ROBOT GAME," which references Paul Boyd's, "The Cargo Cult of Good Code," which lists Zinsser's book as his second favorite book on software design. I enjoyed roughly the first half of Zinsser's book, I worked through another third or so, and then I figured I had gotten what I could from it. I agree with some of the criticism of his book that he uses a lot of words to tell you that you should not use so many words.

Near the end of my reading, though, he had a helpful recap of the fundamentals that he professes. These are, briefly:

• Clarity
• Simplicity
• Economy
• Humanity
• Active Verbs
• Avoid windy concept nouns

The last one merits explanation since "concept noun" is not a term one comes across regularly. An example from his book of a violation of the principle is the sentence, "The common reaction is incredulous laughter," which has no people in it. Compare that to, "Most people just laugh with disbelief," which is something that the reader can visualize. When I think about concept nouns, though, I tend to remember the wrong thing: Zinsser's caution against "creeping nounism" as one finds in the gem, "Communication facilitation skills development intervention."

Taken as a set, Zinsser's summarized points provide solid advice, though I am not sure it stands up against George Orwell's rules.

While I enjoyed most of the book, one part that irked me was how journalistic he treated the wide tent of "nonfiction writing." He argues for paragraphs to be constructed of three, two, or even one sentence. This strikes me as counter to the epistemic value of writing as embodied in the essay—the attempt to understand. That is the space where I do the most serious writing, and it is the space I want my undergraduates to inhabit. For a book-length treatment of writing advice, then, I think I'll stick with Strunk. 

Notes on Boredom

Last Friday, I was able to attend a talk by Kevin Hood Gary about his book, Why Boredom Matters. The talk was sponsored by the Alcuin Study Center in Muncie. My wife was interested but unable to attend the presentation, so I took some notes to share with her. A colleague also told me they were unable to attend, so I decided I'd turn my notes into this post, which I can then share with anyone who is interested. Keep in mind that these are extrapolations of my notes from the presentation and should not be taken as a summary of the book. He acknowledged that the talk was designed for a general audience while the book goes into more technical detail. I'm sure any inaccuracies or misrepresentations in this post are my own.

The thesis of the book—as explained by Dr. Hood—is that we avoid boredom and thereby miss out on leisure. There are different ways to react to boredom, but they fall on a spectrum from avoidance to resignation. We can avoid boredom through amusements. I appreciate that, from early in the presentation, Dr. Hood clearly and explicitly distinguished between amusement and leisure, the former being a distraction and the latter being life-giving. This is a classical distinction that is clear to me, although from the discussion, I think that he has sometimes received pushback on these terms.

After acknowledging that the smart phone is a boredom avoidance device, Dr. Hood mentioned that he offers extra credit to his students if they put their phones in a box during class meetings. He said they happily take him up on this. I am not a fan of "extra credit" since it leads to inflation, and I wonder what differences would occur in making this simply for credit instead of extra credit. 

Dr. Hood referenced Wilson's shock test experiment. I think I had heard of this before, but I did not have it ready in memory. It's an amazing study from about ten years ago in which people were put in an empty room to be alone with their thoughts... except they could also opt to give themselves a mild electrical shock. Interested readers should learn about the actual experiment, and although I hesitate to spoil some results here, I will, in the name of having these data later for my own purposes. The study showed that 25% of women and 67% of men would rather give themselves painful shocks than be alone with their thoughts. I echo the response of one of the audience members who wondered how this broke down by age. Dr. Hood drew a comparison between this study and Pascal's quotation, that all human evil comes from the same cause: our inability to sit still in a room.

He also brought up a nice quotation from T. S. Eliot that I don't remembering hearing before. It comes from "Four Quarters" and states that we are "distracted from distraction by distraction." An unsurprisingly poetic interpretation of the theme from Mr. Eliot.

Dr. Hood briefly mentioned how Kierkegaard described human agency as being balanced between the despair of possibility and the despair of necessity. The former describes, for example, infatuation with celebrity, as well as the hesitation one experiences at trying something at which one might fail. During the Q&A, Dr. Hood confirmed that my understanding of this end of the spectrum was correct when I likened it to meeting incoming students who want to become game developers but who then do not do any of the actual hard work required to succeed in the field: imagining oneself as an ideal is easy, but reifying that ideal takes real effort.

Rather than eliminating boredom with amusements, we should instead pursue focal practices. These draw upon the classical notions of leisure, and these were connected to historical understanding of scholé. He illustrated the concept by referencing Groundhog Day, which everyone in the audience had seen. (Both he and I were surprised at this, given the range of ages present.) In the movie, Bill Murray's character eventually replaces his amusements and his despair with focal practices such as good conversations, walking, making music, and reading a good book. Dr. Hood talked a little about these as being done for their own sake and being driven by intrinsic motivation. 

Crucial to understanding focal practices is that they always involve a moral threshold. That is, focal practices are preferable to amusements, but they involve making a conscious decision. His example was that he could go home after work and watch sports highlights or he could go for a walk with his wife. The latter is clearly the more life-giving of the two, but it requires a decision to be made. This and several other parts of the presentation got me thinking about the virtues, both as habits of being and as choosing a medium between extremes.

He contrasted focal practices in an interesting way against videogames, describing how some will claim that videogames are their leisure. He explained that he himself had played a lot of videogames and that he knows that they work by producing a steady stream of delicious, delicious dopamine. He was a little reductive here but not inaccurate. There are hooks here for a scholar to explore the amusement vs. leisure elements of play. (Coincidentally, I was recently in conversation with a colleague about how it's almost certainly better to make videogames as a leisure activity rather than as a job. A "regular" job in software development will pay the bills more reliably.)

It may be worth noting that throughout the presentation, Dr. Hood never insulted amusement and acknowledged that they play a role in a healthy life. It is the absence of leisure that is the serious detriment.

Toward the end of the presentation, he offered some suggestions on what we can do about boredom. The first of these is a "boredom audit," in which one tracks how much time is spent avoiding boredom. This raises awareness. I think that sounds like a great challenge and perhaps even an achievement for my CS222 class. The second of his suggestions was to identify two focal practices that you enjoy and one you would like to enjoy. Again, this seems to me to be about foregrounding thoughts that one might be avoiding. The third was to pursue friendships of excellence, drawing on Aristotle's understanding of the different kinds of friendship. Here, he pulled in one of my favorite quotations from G. K. Chesterton, that "if a thing is worth doing, it is worth doing badly." (The line has been used and misused, but The Society of G. K. Chesterton has a helpful article explaining its context and interpretation.)

I enjoyed the presentation, and I look forward to reading the book. The Tower of Unread Books has spawned two or three additional piles throughout my home and office, so it may be a while before I get to it.

Summer Course Planning: CS222 Advanced Programming

Regular readers may have sense that I was running out of steam when I wrote my reflection of Spring's CS222 class. It wasn't a bad class, but the frustrations around the lack of participation drained my will. It was good to step away from it for a few months. This week, I continued the course planning work that I started last week, and my goal was to determine what I should do with CS222. The results are posted in the public course plan (CC-BY, as usual).

My reflection on Spring's class ends with some ideas about completely overhauling the class. It did not take long for me to realize I would not have time for that, especially not while teaching three classes and leading two independent research groups in the Fall. I did make one major change to the grading policy: I changed the final grades to be determined by specifications rather than weighted average. The major difference is that completing some achievements is now necessary for a C or better grade whereas they used to be a way to separate high performance from standard performance. I took this trick from David Largent, who regularly teaches this course as well. Many of the "achievements" are in fact remedial for students who have bad study habits, and so I think it will be beneficial to be able to push students toward ways that they can use this system to improve those skills. For example, if someone does badly on an assignment from the reading, I can easily point them to the "Re-reader" achievement (also one of Largent's inventions). 

The other major change that I am trying is using EMRF grading rather than triage grading of assignments. Triage grading is elegant although many students refuse to engage with it. (I blame the brainwashing of the rest of their educational experience, particularly the abuse of tools like Canvas and the administrative state's succumbing to the tyranny of metrics.) For years, students in CS222 have been free to resubmit any assignment from the class, whether they got a middling (2/3), low (1/3), or no (0/3) marks on it. However, unless my perceptions are wrong, I have seen a drop-off in the number of students taking advantage of this. To be clear, I don't know exactly why this is, and there are many competing as well as overlapping hypotheses. Suffice it to say, I don't have much to lose by trying something different. 

I came across EMRF grading from Robert Talbert's blog. What strikes me about it is that it's not that different philosophically from triage grading. However, because numbers are removed and replaced with letters, students cannot turn to a quantiative understanding. Whereas a student might look at "2/3 points" and think of it as "66% That's failing!" rather than "This is halfway good and halfway poor," I don't think I will see the same thing with someone who gets an "M" despite its serving a similar purpose. It's not exactly the same purpose, and I wonder if I will miss triage grading's ability to call something "kind of right, kind of wrong," whereas the output of EMRF grading essentially Boolean: either you pass or you don't. The choice of "F" for "fragmentary" is the one place where I am sure students will think of it as "failure," and that's an unfortunate impact here: it continues to put a negative rather than a hopeful connotation on the necessary step of getting things wrong on the way to getting things right. I suppose I have time before Fall to replace my link to EMRF grading with the invention of a variation such as EMRX. 

The EMRF system works well with the change to specifications-based final grade. I took another page from my colleague Dave when I characterized the requirements for A, B, C, etc. as having all the assignments passed, all save one, all save two, etc. I have not yet decided whether I will use EMRF grading, triage grading, or something else when it comes to the projects. Right now, the final course grade is based on the letter-grade achievement in the final project, and so I can punt on the decision on how exactly that will be graded; that will give me time to see how the first few weeks with these other changes works.

One other structural change to the course is worth mentioning. For years, I've used a structure where we have a three week ramp up to the two-week project, then a short break, then nine weeks in the final project, which is completed in three three-week iterations. When I switched to Dart and Flutter, I had to remove some interesting content from those three weeks so that the students could have time to learn more about the technical details of these. I missed some of the elements I pulled out, though, and I desired to add them back in. As another experiment, I annotated each assignment with an estimate of how long I expect it to take, and this exercise actually helped me see that I needed more time for this introductory portion of the course. There was just no way to get all the things in there that I thought were important to practice before getting into bigger projects. Hence, I added an extra week at the beginning of the semester and shrunk down the duration of the iterations of the final project. I think this will be a positive change: it will give students more time to practice some fundamentals such as TDD and Dart programming, and I think shorter iterations of the final project will reduce sandbagging. 

Last semester, an administrator forwarded this blog post by Alanna Gillis to all faculty in my college. To summarize, she frames participation as a skill to be formatively developed rather than summatively graded, managing this with student participation self-reflections at the beginning, middle, and end of the semester. I think this is a great idea, and I tinkered with different ways of incorporating it into this class. In the end, though, I ran into a problem that always strikes me when I think about this course: there's already enough (or too much) going on here. There is a definite overlap between the course's four essential questions and Gillis' participation grades, but I fear that students may not have the wisdom and experience to see this. Similarly, many of the achievements could help students directly make progress in these forms of participation, but I already have students reflect on this regularly, such as at the end of each iteration of the final project and the final exam. I do want the students to think about how their participation in the class shapes their learning experience, and I already do that through these reflections. I fear that I would get less coherent reflection by adding more requirements and nomenclature. In the end, then, I decided to work some of Gillis' ideas into my discourse around participation and to use this to encourage students' engagement with achievements (which, again, is now more "required" than it was before), but not to go so far as to bring in new surveys and additional self-assessments.

I am eager to see how this semester goes. The course is back to Tuesday/Thursday, which I think is much better for the students, but I had to rearrange all my plans to deal with it. Also, it will be directly after my game programming class, so I am little worried about my own ability to maintain focus. It may be a two-coffee semester.