Why I am not using GitHub Classroom

As I mentioned the other day, I have turned my attention to preparing for Spring's courses. I am on deck to teach CS222 in the Spring. It's a fun and challenging course to teach, and I've been thinking about whether there are some ways to streamline the student experience. This morning, I spent some time investigating GitHub Classroom. It wasn't the first time, and that's why I'm writing this quick reminder to myself about why it's not the right fit for me.

There are two things that keep attracting me to GitHub Classroom. The first is that it reinforces the use of distributed version control. Anything that gets students into the habit of using version control and making small commits is good. The other is that it leverages the power of Markdown, where a writer can seamlessly integrate different kinds of text into one document: prose and code live happily together. This forms a synergy with the first point, since it gets students to start to think about version controlling all the things. 

What specifically got me looking again at GitHub Classroom though was its support for feedback via pull requests. This would allow me to comment on an individual line of student work as well as the work as a whole. The shortcoming is that the writer cannot do the same. 

I need a student to be able to do three kinds of writing:

• Traditional prose
• Source code
• Commentary on specific lines of the source code

The writing environment has to allow a student to say that a particular section of code manifests a particular property. This cannot be done in source code comments because those comments are part of the code itself. Rather, I'm talking about a kind of metadiscourse that is at a different level of abstraction than the code. It cannot easily be done in prose either. This requires either interrupting the code with commentary or using a referencing system, such as line numbers. The latter is not terrible, but it pales in comparison to the approach I have used for years: using Google Docs' comment feature to comment on different parts of the document. Using this approach, both the student writer and I can evaluate the text. In fact, I wish I had one more level of abstraction: I would like to comment on the students' comments, not in a thread, but at another level yet. 

These qualities describe a writing environment unlike any I have seen. It would be an interesting HCI exercise to explore how one might interact with such a thing. One might start by looking at Google Wave (RIP) or Code Bubbles. In the meantime, I will have to keep using word processors like Google Docs that allow for the metadata stream of comments.

Updated postscript:

I was thinking about switching from Google Docs to Office365, but after that experimentation, I don't think it is fit for purpose either. It seems like Word insists that we are preparing documents that will be printed on paper, whereas Google Docs has long allowed for continuous, non-paginated documents. 

Course revisions: CS390 Preproduction

I wanted to switch into writing mode this week, but I recently received my teaching assignment for Spring, and some relevant decisions were looming over my head. Of the three courses I'm teaching, I knew that my Game Studio Preproduction—the first in the three-semester game production sequence—needed the most attention. I have taught this course twice, both times closely following Lemarchand's Playful Production Process. It provided a useful framework for me and my students as we built our new curriculum.

The game production sequence has been on my mind as I have read other books over the last year, including Vasco Duarte's No Estimates and Tynan Sylvester's Designing Games, both of which I blogged about, as well as books like Mike Sellers' Advanced Game Design, which I did not. I have been particularly troubled by my agreement with Duarte about the distinction between scope-driven and value-driven software development. The former is based on a fixed scope, which unbinds budget and time, and the latter is based on fixed budget and time, which unbinds scope. I wrote a paper about this distinction that I will be presenting in two weeks at the Symposium on Games. To make a long story short, most of the published advice about games draws from AAA production patterns and takes a scope-driven approach, but my experience and learned intuition suspect that my teams will have much better luck with value-driven approaches. Sylvester was one who really helped me put a pin in this idea when he wrote about how much of game production borrows concepts from other fields rather than embracing the idea that software is different—which, of course, it is. He also introduced me to the phrase "therapeutic planning," which he cites to Nassim Taleb and which I find terrifyingly evocative. 

As a result, I have decided to forego my previous approach to preproduction and, if it goes well, the production sequence next year. The scope-driven methodology will be replaced by an agile, value-driven one. Preproduction has an agile bias no matter how you slice it, but where this change makes the most material impact on the course will be in the expected deliverables. In the past two offerings, I have followed Lemarchand's advice and had preproduction culminate in a macro document and production schedule. My experience is that these are always spectacularly wrong, but you cannot exactly blame the students for this: given their limited experience, of course these will be quite wrong. Laying them out feels like therapeutic planning to me. I will replace the macro document and schedule with the concept document format proposed by Sellers, peppering a few of my perspectives and additions. Sellers' is a three-part document that includes a high-level description, a business-oriented product description, and a lengthy detailed design that captures core loops and interactions. I hope that the production teams will be able to use these document as more appropriate starting points once production starts, compared to the compounded awkwardness I have witnessed of having teams attempt to base production plans on poorly composed progenitors. On the contrary, something from Lemarchand that I have seen teams make incredible use of is an articulation of experience goals and design goals, and that is something I want to weave into Sellers' recommendations for concept documentation.

My previous sections included an explicit element of learning how to learn from a book like Lemarchand's, and I have no regrets about that: the students who engaged with the reading did learn significantly from it. This included spending significant time at the beginning of preproduction talking about and practicing techniques of ideation. This was usually interesting, but I realized that the student projects rarely had any significant connection to this part of the class. It is more like pre-preproduction. In my plans for Spring, I have cut this down to two in-class exercises that are designed more to get people talking and thinking than to generate anything weighty.

This change allows me to move into a slightly more structured prototyping phase, for which I am borrowing ideas from my colleague Travis Faas. I am putting a little more structure into the prototyping weeks, including constraints that I hope will foster creative problem-solving. My sketch right now includes a short paper prototype, a short experience with greyboxing, and two two-week explorations. My plan is for students to get into teams and settled on a direction just before Spring Break.

I still have a few holes to fill in my plans. For example, I would like to incorporate a structured analysis of successful games, showing students how they might reverse-engineer a Sellers-style concept document from a game that they have played. I would like to have everyone play the same one or two games so that we can share our analyses. If you have ideas of freely available games that would fill the bill, let me know. I'm seriously thinking of Rogue, given the popularity of "roguelikes" and the dearth of knowledge about the original, but I want to make sure I'm not doing it only for my own nostalgia.

Experiences interacting with generative AI in my solo game development work

I have been reflecting on the role of generative AI in education. In order to better understand it, I decided to incorporate some generative AI systems into my software development work the last two weeks. To be clear, I had no great intrinsic motivation nor external pressure to do so; I mention this because it seems that most of the stories I hear about using generative AI involve either one or the other. Instead, I approached it from a position of curiosity while also trying not think too hard about the immoral ways many models have been trained and the incredible amount of power required to drive the models.

For my context, I have been developing a game prototype using Dart and Flutter. Some of my earlier attempts at using Flutter for game development were hindered by my own floundering with software architectures: several times, I built prototypes only to have a constant desire to refactor due to code quality deficiencies. This was especially true when using TDD, with its emergent architectures and constant refactoring, which had me frequently doubting whether I was programming myself into a low-quality corner. I suppose this is the danger of doing TDD outside of Pair Programming.

I started by using ChatGPT as a sounding board to talk about some of my goals, including following the principles of Clean Code, good architectural separation, and robust tests. My first significant conundrum dealt with separation of layers while using a functional approach. That is, I had a World object that represented the immutable state of the world, and then I had an Adventure object that held a reference to the current World. Taking actions on the Adventure updated the World. The programming for this was made easy by using freezed. At the same time, interacting with the Adventure could generate events to which the UI needed to respond, and so I took a page out of egamebook and had the Adventure create a stream of events that the UI layer can listen to. Dealing with streams is something else that Dart makes quite easy. 

These two different systems created a conflict regarding how exactly an interaction should play out, especially when one interaction generated multiple events. I explained this situation to ChatGPT, and I was impressed by how it summarized the pros and cons of each of the different approaches. It concluded that I should just stop what I was doing and simplify to a purely functional Adventure object that only transforms World objects, and in doing so, returns a list of events. The generated text was unequivocal and, I daresay, correct. I think I needed someone to point out to me where I was trying to do two things at once, and that my own constraints--using an immutable data model--logically led to my needing to abandoning streaming events in favor of a purely functional Adventure object. It took some rebuilding, but once I was done, the separation between layers was much more clear.

Dealing with automated tests is another area where I was surprised by the high quality of ChatGPT's recommendations. I had a test file with a few hundred lines of code, and I had written some helper methods to try to keep the test reading fluently. Yet, I felt unsatisfied with it. I pasted that code wholesale into ChatGPT and asked it to explain to me why I was feeling uneasy with that code, given my architecture. It observed that my code was mixing too many responsibilities together and that this could be improved by creating a separate test harness. This would move all the domain references out of my tests and into the harness so that changes to the domain would only change the harness, not the expression of the tests. Once again, it took some typing to get the system rebuilt this way, but the result was much nicer. In fact, a few days later, I made a significant change to the representation of actors in the world: I did not have to make any changes to my test code, and my harness only required a few tweaks to make it keep working.

Some time later, I ran into another problem, the nature of which I don't exactly remember, and I found that ChatGPT has lost the entire history of our discussions around software architecture. I asked it about what happened, and it gave me the impression that yes, sometimes context is just lost. I briefly considered doing more research into figuring out what this meant and how to avoid it, but I decided I should explore a different approach: generative AI that is integrated into the IDE. Because I'm using Android Studio, the path of least resistance was to enable the Gemini integrations and to give it access to my project.

My experience using Gemini was more mixed. Using the chat interface, Gemini provided advice that got me out of another architectural blunder with its recommendation to separate my Adventure object into different services. For example, I created a CombatService, and then injected that into the Adventure. My first attempt at this was to make the CombatService modify World objects just like Adventure does, but after some frustrations and interactions, I received good advice to make it only deal with the logic of combat, not with the logic of state management. This meant that my unit tests for CombatService could make sure it was working correctly. I could also inject a mock CombatService into the Adventure when I needed to control the output for Adventure's unit tests. For example, an actor has a chance to hit its target combat, but that kind of randomness needs to be factored out of a well-behaved unit test; making a mock CombatService that responds with a hit result meant that I could test that Adventure handled hits correctly without binding the test to a random outcome. Gemini framed this as a good place to practice separating unit and integration tests, which also gave me a useful perspective on this system I was building.

Gemini was less useful in terms of practical code examples, in part because it seems to not have enough training on Dart code that uses freezed objects. More than once, it tried to explain to me how I should be changing my code to use different kinds of object construction that just don't work with freezed. The agent mode, which is clearly labeled as being in beta, was particularly unhelpful because of this. As a result, I have barely touched software agents despite having heard some promising things about them, such as in this interesting conversation between the hosts of the Mob Mentality Show.

My initial reaction to these systems is that they have been helpful for me because I can understand the implications of their recommendations. There were several times where the recommendations were clearly bad because they violated some particular principle, and when I pointed that out, the system was sycophantic about how smart I was for pointing out this problem, and then it changed direction, presenting the new advice with as much certitude as the last. This combination was troubling: confident answers and fawning reactions to criticism. It would be a terrible team member. Despite my overall positive experience, I am left uncertain about how much it was teaching me versus how much it was helping me stick to my guns and reminding me of how various principles arise in practice. Put another way, I retain a suspicion that I would be much more productive if I was pairing up with someone of equivalent experience and similar goals to mine. 

Figuring out what any of this means for students is a subject for another time.

An evening with Torchbearer

I mentioned my interest in Torchbearer in my post about goblins and game design, and I was glad to be able to run my first session of it last night. The group consisted of my two older boys and two of their friends. We had a good time, and I want to capture a few thoughts about the experience here. What follows is a mix of a session report together with my reflections on the game.

Background

I cannot remember all the details of how I became aware of Torchbearer, but I can provide a little background about my interest. It goes back to an interest in Burning Wheel, which is always discussed with reverence and respect despite there being a small player base. The Burning Wheel rulebook is a wealth of brilliant and unique ideas for tabletop roleplaying, but it also feels too intimidating to run without some experience. More recently, I have heard amazing things about Mouse Guard RPG, which is rooted in the ideas of Burning Wheel. I tried for a while to get the Mouse Guard RPG box set for my family, but I heard about it after it went out of print. I even ordered one from a reseller who, after a month, acknowledged that they did not have a copy after all and refunded my money. Now Torchbearer is a riff on Mouse Guard RPG with a setting that appeals more to me, so I decided to get a copy of the core books for myself. 

Torchbearer is recognized for having interesting, interlocking systems, and it did not seem too overwhelming for me to run it without having played it. I am grateful that my players accepted that the game might occasionally get choppy. Good DMs know that rulings are more important than rules, but my players understood that one of my goals in running the game was to understand it.

Character Creation and the Call to Adventure

We started with by-the-books character creation. I expected this to take an hour, but it took almost 90 minutes. I did not present a complete rules explanation ahead of time, but instead taught the pieces of the game that we needed as we needed them. We ended up with a Warrior, Outcast, Burglar, and Magician. The players had just a little trouble with articulating beliefs, but reading the ones from the sample characters was helpful. They had more difficulty with instincts because to write these effectively requires some knowledge of how the game works. The instinct format restrictions helped: for example, one player wanted an instinct, "I always know where the exits are," and I was able to help him convert toward something active, like "I always look for the exit." One of the instincts was, "I always strike first," which sounds exciting and appropriate but is not really workable in a game without initiative. (When we got into our only conflict of the evening, I ended up giving him +1s on his first strike as compensation, and I figured we would just change his instinct if we play again.) The players' goals were reasonable given what they knew from the adventure seed, although no one ended up making progress toward them by the end.

The players decided that the characters did not know each other but were in the right place to be recruited for the "Tower of Stars" adventure from the Cartographer's Compendium. It is shorter than the one in the core books, so I thought it might fit better as a one-off. In fact, we only got through about half of it. I modified one of the introductions slightly to get the party headed toward the tower to deliver a letter to the reclusive Beholder of Fates, allowing us to start the adventure at the base of the tower.

The Adventure

Their initial plan was to split the party, half exploring the surrounding area and half climbing into the ruins. This was a good opportunity for me to suggest, especially in this kind of dungeoncrawl, don't split the party. They succeeded at getting inside, which gave me the opportunity to explain the Grind. This is a beautiful aspect of Torchbearer where every four turns, the characters gain negative conditions—and what makes a turn advance is any roll. It made it more clear to them why instincts were powerful and why it's better to have A Good Idea than to rely on skills. 

In the ruined ground level of the tower, while searching for treasure, the Warrior discovered the remains of a broken basalt statue with a magical rune emblazoned on its forehead. The Magician wanted to decipher the rune, but when he pulled together his dice pool, it was clear that he had little chance. At this point, I explained how he could use a trait against himself, reducing further the odds of success but earning a "check" that would be useful in camp. He described how his Quick Witted trait might lead him to jump to the wrong conclusion. Sure enough, he failed the roll, and it provided me a glorious opportunity to deploy one of the adventure's recommended twists. I described how in the back of his mind, he could hear the name of the rune, but as he thought more about it, he realized he was hearing it chanted all around him. This was when the party discovered that some kind of troll rats had emerged from the rubble, and they were chanting in a mysterious ancient language. Once they were recognized, the rats attacked the party, leading us into the evening's conflict.

Here, I explained to the group a few of my favorite pieces of Torchbearer. First, there are different kinds of conflicts depending on the party's goals. In our case, this was a Drive Off conflict since the goal was merely to get rid of the rats, not necessarily to kill or capture them. (In retrospect, I should have left the rats chanting menacingly and given the party the opportunity to take the initiative here, to decide if they wanted to chase them off or leave them as creepy watchers.) Second, I explained how disposition works, that characters don't have "hit points" until they are in a conflict, and these hit points are only relevant to the current goal. Third, I explained the conflict system itself in which the GM and the players each queue up three actions, each of which are then executed simultaneously.

I could not remember, nor quickly find, how to compute the disposition for a group of enemies. I mistakenly thought I would multiply their Drive Off disposition by the number appearing, but this is wrong: I should have used the base disposition and then added one for each extra participant. Because these enchanted troll rats had such low disposition, it was only a four-point difference. Unfortunately, I also could not remember the rules for whether damage would distribute across multiple enemies once one was eliminated. It does, but I treated it as if it didn't, which was unfortunate since the opening attack by the Outcast was a brilliant and brutal success, and it should have taken out at least two of the rats instead of just one. The battle went on a little longer than it should have, and the Burglar's elimination made me take away the party's Fresh condition as a minor compromise. Even though we didn't get all the rules right, the players enjoyed the excitement and narrative structure of the conflict. They could see that this would be a successful conflict from early on, especially given the Might difference between the groups, but they also saw that they could not be overconfident. During the conflict, we also saw the Magician use Beginner's Luck to take an unexpected swipe at the rats, which was much more memorable than watching him roll a d20 and hope for a high roll.

With the rats eliminated, the Outcast proceeded to work his way up to the crack in the ceiling, fail the Dungeoneering test to get through, and got stuck. This happened to trigger the Grind, and everyone became hungry and thirsty. The ceiling was only ten feet high here, and so the Magician decided to try to push the Outcast through with his staff, soliciting the help of the Warrior. I explained that this was a test of pure strength, so it was a Health check. The Magician's player, seeing that his character had only 2 Health, said that if it's a Health check, he won't bother. I explained that he was already doing it and had him roll. Again, this is a case where a simple rule—if you say you're doing it, you're doing it—gives the game a lovely gravitas. Naturally, he failed the roll. Rather than throw a new twist at them, I decided to give a condition. I described how he was grunting and shoving, standing next to the smelly and crude Warrior, looking up at the Outcast's rear end, and so although they got the dwarf out of his predicament, the Magician came away Angry. The table loved it. The Magician's player had earlier expressed how uncomfortable he was with role-playing and talking in character, but here, right away, he picked up on the series of things that compounded to make him angry: the tower is ruined, I don't know these people, the dwarf got stuck, the Warrior burps constantly, we got assaulted by magical rats... It was wonderful. Unfortunately, I forgot to give lesser conditions to the Warrior and Outcast, both of whom helped. I am still learning the ropes.

The part got up into the next room, where there happened to be a decaying corpse. The Warrior was very excited to check it out given his instinct ("Always look for loot.") and his being corpse-wise. He was surprised, and so was I, that his being corpse-wise didn't actually help him in evaluating the corpse: it would have been useful for him to help someone else do it, but in the absence of fate or persona points, it provided no benefit to him. This was an unfortunate bit of ludonarrative dissonance, and it's also where we decided to call it a night after almost four hours together. All the guys thanked me for running the game, and many expressed their being  impressed with Torchbearer. I think they all had come to understand why I was excited to run it, and they came away with some good stories to tell.

Thoughts on Torchbearer

I love the simultaneous actions in Torchbearer; it makes d20-style combat look like a tennis match.  Not only do simultaneous actions provide interesting opportunities for storytelling, but at the table, you get that lovely feeling of flipping over a card to reveal a secret. It's not obvious to me how much of the action selection is really tactical rather than blind choice, but it almost doesn't matter: it's still fun. On the side, I have been working on an OSR-style dungeoncrawl video game inspired by ICRPG and Knave, but witnessing the joys of simultaneous actions makes me waver in my dedication to traditional turn-based combat.

I was nervous about remembering all the moving parts of Torchbearer. I printed up two different cheatsheets, but I'm not sure either one helped as much as I had hoped. One particular thing I was concerned about was how Fate and Persona points work. It wasn't until my prep the day of the session that I realized that new characters don't have these anyway. I share this for other new GMs so they can reduce their cognitive load on the first session. On the flip side, I had forgotten how Nature works, that when a player is facing a situation where they have no skill, they can opt to use their Nature instead. The party may have missed an opportunity to use these in a narratively interesting way.

The Grind is a brilliant system for putting pressure on the party. It presents time dramatically, tying together time and action, rather than in a simulated way. This is another aspect of the game that inspires me to think more about tabletop-videogame crossover. It's easy to run any number of simulations in a computer, but where is it better to deploy a dramatic tool instead? For example, I think it's more engaging to say that a torch lasts for two interesting moments than for sixty simulated minutes.

The Torchbearer books explain that it is designed to produce stories that unfold over ten to twelve sessions. Mine was a one-off learning session with a collection of players that will be hard to reproduce. I had a great experience though, and it makes me want to run a more sustained campaign to see more about how these systems interact.

Notes from Tynan Sylvester's "Designing Games"

I just finished reading Tynan Sylvester's Designing Games. The book was published in 2013, but Sylvester is probably best known as the creator of Rimworld, which came out a few years later and is not mentioned in the book. I have read many game design books, but I still learned a lot from this one. This inspired me to share some of my notes here.

Sylvester's core conceit is that games are artificial systems for generating experiences. He presents a model early in the book that undergirds the rest of the text, that a game provides mechanics wrapped in fiction, which produces events with fictional meaning, which produces emotions, which leads to an experience. I am a collector of definitions for "game," and I think this may be the strongest formalized definition I have encountered. I appreciate that it highlights what makes games different from other media, which is a theme that also comes up frequently in the text.

An early chapter discusses emotions and their role in game design. He uses the term "human values" to refer to anything that is important to humans that can move through multiple states, such as life/death, victory/defeat, and friend/stranger/enemy. I am not keen on his terminology here since it sounds relevant to morals or ethics, but I like the hook for thinking about design. It reminds me of the binary opposites that are essential to imaginative education. Sylvester provides a catalog of emotional triggers that can be used here, each of which is given appropriate exposition in the text: learning, character arcs, challenge, social interaction, acquisition, music, spectacle, beauty, environment, newfangled technology, primal threats, and sexual signals. 

I have long been familiar with the idea that players cannot truly answer what caused different emotions, but that they will construct a narrative to explain the phenomenon to themselves. I was not previously aware of the technical explanation known as misattribution of arousal and the psychological studies around it. Sylvester focuses on the "bridge" studies, and a little searching online finds that this is a robust finding. A related psychological concept he draws upon is the two-factor theory of emotion, which explains that what we call "emotion" is a combination of physiological arousal and a cognitive label. This explains how the same physiological stress response could show up in Tetris and in Doom, but the latter's fiction is what leads us to call it "fear."

I would have preferred that Sylvester give more precise definitions around his use of "elegance" and "emergence" since he does not adequately address Kate Compton's 10,000 bowls of oatmeal problem. It's one of a few chapters where I wondered how Sylvester might approach a second edition. No Man's Sky came out a few years after the book was published, and Sylvester's own work on procedural storytelling undoubtedly gave him new insights into these ideas.

Sylvester uses apophenia to describe how humans find patterns in noise, but I wonder if he uses it a bit too broadly. Apophenia describes phenomena like "lucky streaks" in gambling. Seeing a face in the clouds strikes me as different because our visual cortex is programmed specifically to find faces. Similarly, anthropomorphising a non-human character seems like it appeals to our narrative sense, not to a matter of pattern-matching. I wanted to track this observation from my notebook because it's an area where I think precision matters, but I realize I am not completely confident in my own ability to describe the edges of these concepts.

The need for frequent playtesting also recurs throughout the book. I am glad that it does since it is such fundamental advice. In his discussion of balance, he points out that what we should be gathering from playtesting is experiences and not suggestions. Again, the essence of this advice is the same in any game design text, but Sylvester presents it with admirable clarity and succinctness, especially given that he is working within a specific and explicit definition for "experiences." He points out that each playtest is a story, but you need to playtest until you can see past the stories into the systems. This gives me an interesting heuristic that I plan to share with my game production students.

His chapter on multiplayer games includes a section on game theory. I am no expert in this area, and I appreciate his layman's covering of Nash equilibria. He points out that the structure of rock-paper-scissors is the only elegant symmetric game without pure Nash equilibria and matching pennies is the only elegant asymmetric game without pure Nash equilibria. All other (game theoretic) games add more entries to the decision matrix without fundamentally changing the structure and are therefore inelegant. I don't usually turn to game theory in my designs, but I enjoyed this section for its clarity and perspective.

I was a little surprised to see him adopt the term Yomi from David Sirlin to describe how players "read" each other—how they predict, deceive, and outwit each other in multiplayer games. I used to follow Sirlin more closely, and I recently uncovered my copy of Flash Duel. It was fun to see his name show up, and I see he's working on a second version of the eponymous Yomi.

I am guilty of colloquially referring to dopamine as a pleasure-causing drug, but Sylvester is more careful in the book to distinguish between motivation and pleasure. Dopamine causes motivation, not pleasure. Remove dopamine from rats, and they will do nothing, not even eat, even though they can still enjoy sugar syrup that is fed to them. It is an important distinction and one I should be careful not to blur since this biochemical understanding allows us to talk more clearly about how games can motivate us to play past the point of enjoyment.

The third and final part of the book is devoted to process. I expected a recommended series of steps to create a game as offered by other texts. Instead, Sylvester opens the section by pointing out that a lot of our terms around process and management are actually borrowed from other disciplines: director, preproduction/production/postproduction. Here, he applies a similar perspective to the process design problem as he does to the rest of game design. One needs to recognize assumptions and evaluate them, realistically but not cynically. Although he is right, also later uses terms like "production" as if we all know what they mean, and I found myself wishing he was more prescriptive here like he was in the section on emotions and experience.

His advice on process comes down to the same observation made by the signatories of the Manifesto for Agile Software Development: work in tight iterations with good feedback loops. This appeals to my sense of lean production, that we should only as much management as necessary. When it comes to sequencing, his advice is to figure out the dependencies among needs and then work upward from there. Here, I would augment his advice with some observations from story maps a la Jeff Patton, but I don't disagree with him. Sylvester is explicit about keeping the game as low fidelity (that is, grayboxing) as possible throughout so that time is not wasted re-creating assets. He mentions that working with an artist or level designer is important, but he is mum about what those other folks might be doing while this grayboxing is going on. I would have liked to know his thoughts about this, given that I mentor fixed-staff student teams.

The chapter on authority is beautiful, and I plan to use it as an assigned reading. Although he does not use these terms, what he describes is an approach to creative management rooted in natural law and subsidiarity. In particular, he talks about how a team member has natural authority over their work, and how it is a mistake to arrogate that. (Note: I learned the word "arrogate" from reading this book even though I've been battling arrogators in ISS Vanguard for some time without looking it up.) This chapter dovetails nicely with the next, which is on motivation. It is clear that he believes the only way a team can succeed is in an environment of trust and respect. Indeed, he goes so far as to say that one can only succeed by "getting people you can trust and then trust them." I used to recruit undergraduates for special community-engaged game development projects, but now, any student can elect into the game development track that puts them into the game production sequence; I am not sure what it implies for my teaching if Sylvester is right. 

Speaking of teaching, I am reminded of the essential challenges presented by the need to grade students in creative projects. Grades are an external reward, and we know that external rewards can kill intrinsic motivation. What then is a professor to do? 

One of the final points in the book is that the best way to motivate a creative person is to ensure that they have constant, small, visible progress. This is the progress principle. It turns my mind again toward considering physical task boards to replace the convenient digital ones my teams used the last two years.

I thoroughly enjoyed the book, and I am grateful for how much I learned from it. I will certainly return to my notes once I start pulling together my plans for the next game production sequence, assuming I get assigned to teach a section or two. The book inspires me to draw more from my own learning to build a process that I believe in, which will be easier after having stepped away from team-teaching for now. I am not sure how much of the book would resonate with beginning designers, who, in my experience, need more structured explanation and exercises to get them into the right mindset. I think it's a valuable reading for someone who has already moved beyond the amateur steps though, once one has come to tacitly understand iteration and the challenges of communciation and motivation.

On Goblins and Game Design

I recently purchased the rulebooks for Torchbearer 2nd Edition. Something reminded me of the project a few weeks ago, and the free introductory chapter captured my imagination. I have not had a chance to play the game yet, but I hope to do so in the coming weeks.

The Scholar's Guide includes a bibliography akin to AD&D's Appendix N and DCC's eponymous homage. I decided that I would add some of the references to my ever-growing pile of books to read. If nothing else, it will give me a good talking point about "remedial fantasy" during my sabbatical presentation. I started with Lord Dunsany's The King of Elfland's Daughter because it was easy to download from Project Gutenberg while I was on vacation. It contains the most poetic description of Elfland I have encountered: it is a place where poetry lives and some places can only be described in song. Yesterday, I finished The Wizard of Earthsea, which I have known about for decades but never took the time to read. It was an enjoyable story even if it was in the tired child-of-prophecy genre.

The Torchbearer Scholar's Guide describes various creatures that a brave adventurer might find lurking in ruins and caves. Many are classics of the TTRPG hobby described with the default setting's Norse flair. The description of the humble goblin blew me away. 

It is questionable whether goblins are alive in the same fashion as humans or halflings. Rather than being born, a goblin springs from the shadows each time a child tells a lie to its mother or a grandchild steals from its grandparent. They age but do not die from senescence or disease. They can be slain or driven off, but soon after they regather on the margins, hungry for more mayhem.

This is wonderfully mythical. Goblins are not just little green people: they are something else entirely. They are fearsome creatures born of sin. They reflect a dark world where evil is not just a privation of good but itself a creative force. It is both poetic and frightening to the core.

I got onto the Burning Wheel Discord server and asked whether Torchbearer's goblins were inspired by any particular work in the bibliography. I got into a discussion with the coauthors, Luke Crane and Thor Olavsrud. Below is Crane's description of how he designed the goblins, quoted with permission.

The inspiration came while editing tb2e and, as it often is for me, it was born of frustration. I have seen so many goblins slaughtered in my time as game master in D&D. Goblins as vulnerable diminutive anthromorphs might make sense from an evolutionary niche perspective, but it’s entirely unsatisfying to me in terms of a supernatural cosmology in a fantastical world.

As Thor points out in his example, categorizing supernatural beings is never easy. By their nature, these beings defy classification. The difference between trolls, giants and ogres, for example, is best left for the academics to debate. Adventurers should be more concerned with more pressing matters.

So for goblins, in the editing process, I needed a way to use Thor’s taxonomy of beings that demonstrated the vibrancy of these Others and gave goblins a reason to be. They needed a supernatural niche, not an ecological one. So I cackled to myself (out loud!) and gleefully muttered: Spirits! What if they’re spirits?

Since we were developing the spirit conflicts in the LMM [Lore Master's Manual] at the same time, I knew this classification would create problems and possibilities for adventurers.

To support this idea with the description, I attempted to reach into tropes found in folklore. What if those warnings to children about not lying and stealing were true? A second cackle emerged as I imagined goblins sprouting like weeds in the shadows of towns and steadings throughout Middarmark, while grandmothers fruitlessly wagged their fingers and plead with their charges to behave.

Even better, this supernatural provenance sketches a supernatural economy. Why should the simple folk of this land tolerate magicians, theurges, shamans and sorcerers? They are the only ones capable of banishing this incessant plague of goblins. Or what of a witch-queen who inveigles children to lie and steal for her, and so creates an army of mischief?

The possibilities are many, and they wear a different mask than that of the fearsome descendants of Azog and Bolg.

I love how his explanation combines mythmaking and systems. To me, that is the essence of good design, where the narrative and the mechanisms support each other, creating an engine for interesting experiences.

The Pyramid Point Games Summit

My family recently completed a lovely road trip around the Great Lakes. One of the most spectacular views was found at Pyramid Point on the Sleeping Bear Dunes National Lakeshore. The photograph doesn't do it justice.

When we reached the lookout point, a young couple was just turning to go back down the trail, and an older couple was behind us on their way up. The young man in front me wore a University of Michigan cap with "CSE" emblazoned on it. Upon my inquiry, he confirmed my suspicion that it stood for "Computer Science and Engineering," and he told me that he was a doctoral student there. I told him that I had completed my  Ph.D. at the University at Buffalo's CSE department, and I asked about his specialization. He told me that he studied game theory. I laughed and told him that I worked in game design and development, which was a different kind of "game." At this point, the other couple had caught up, and the gentleman joined us, telling us that he worked for the Michigan Gaming Control Board, working with the certification of electronic gaming (that is, gambling) machines.

And so it happened that we held the Pyramid Point Games Summit, where, by incredible chance, the three men on the top of the dune represented specialists in the three different definitions of "game." We laughed at this unlikely coincidence, enjoyed the view, and then parted ways.