A few notes on branching, microbranching, and pants

I am wrapping up work on a preproduction build of a digital gamebook that has me writing a lot of interactive fiction. After exploring my options and spending a few days on a custom engine, I landed on using ink. I have enjoyed working with it, and after a short learning curve, I find that it really does help me focus on the writing. That is, although it has a formal syntax that one must deal with, it mostly stays out of the way.

Coincidentally, a friend recently pointed me to the Game Narrative Kaleidoscope podcast. I just finished listening to the sixth episode's interview with Kate Gray. Two bits caught my attention that I wanted to capture here on the blog so I don't forget them.

The first is just a simple turn of phrase that the interviewers and guest all knew but that was new to me: the distinction between planners and pantsers. Writers of interactive fiction seem to identify as one or the other, the former being those who plan out their story carefully before writing and the latter being those who go "by the seat of their pants." In my case, I had sketched a quest structure with a few important branches, but once I got into writing, I really found that I could pants a lot of it.

The other was a distinction Gray drew between conventional branches and microbranches. She pointed out that many use "branching" to refer to the big, game-changing decisions that a player makes during play. However, there are also lots of smaller decisions one can make, particularly in dialog, that can serve other purposes. Often, this purpose is merely performative, allowing the player to choose a voice for their character. Other times, it is used for subtle worldbuilding. The important thing is that they are not important things, and Gray discussed how much she enjoys attending to them.

This struck me since I spend a lot of time with my students talking about how, in game design, decisions should be meaningful. A decision that is not meaningful is a false choice. Of course, that's a sort of ludological perspective, and it's true in the cases where it applies. Gray's interview gave me a vocabulary to talk about those other kinds of choices, the ones that only matter to the player and not necessarily to the game.

I have been playing Heaven's Vault in part to try to see through the experience to the ink layer below. It presents a lot of microbranches, some of which seem to have long-term impact on the game but many others of which are decorative. The dialog is all brief and punchy, no more than one or two sentences before another choice is made. It has a good rhythm. I am trying to understand the game in the context of other playful narrative experiences. I have been enjoying my page-a-day adventure calendar more than I expected even though it has very few decisions and no significant branching; after all, the next day's page has already been printed. I also picked up The Raiders of the Dune Sea, a gamebook that, at first glance, seems to favor longer narrative passages.

In my preproduction prototype, I have some scenes with lengthy text passages and some with frequent microbranches. Once I pull it together, I need to get it in front of some different representative players to see which best carries the themes I am exploring.

Reflecting on CS215, Spring 2026 edition

Introduction

It was a delight to teach CS215 Introduction to Game Design this past semester. I had not taught the class since Fall 2022, and I didn't realize how much I missed it. I had a really wonderful cohort of students, as good as I could ask for. They were eager with questions and comments. More than once, I was just warming up a story, and hands would go up with thoughts and reactions, before I even got to the good stuff. I am glad to have these students in the program and look forward to watching them over the next few years.

The class was overall a great success. I followed my tried-and-true approach, using the first half of the semester to go through readings and exercises that helped lay out what is known about game design and the second half to work on final projects. 

Course Structure

As in the past, I still feel like there are missed opportunities to help students deploy the ideas from the first half into the second half. One complication is that, because students design their own projects, there's no way to know which ideas from the first half will be salient to their work. I would like to get them thinking more about this, but at the same time, I don't want to add more load without a good reason.

The one universal is the iterative design process. This came up in informal meetings among the faculty who teach in the CS GDD concentration, and we agreed that it is the most important objective for students to meet. Currently, my final project structure recommends a particular sequence, but I do not mandate it. I wonder if it would help the students learn the importance of playtesting earlier if I required them to do it earlier, the way that I require acceptance testing in CS222 for example.

Player Logs

I asked the students to complete five player logs during the semester. These logs involved briefly describing a game they played and reflecting on what they learned from it. Because we were working in the analog game design space, I required that at least half be analog games or digital interpretations thereof. My hope is that they would be playing games anyway and that this would help integrate their personal and academic experiences. Judging from their selections, I think many chose games for this exercise, although curiously not the ones I suggested as good starting points. I did not ask them to explain why they chose the games they did, but I might ask that in the future. No one should be choosing a knock-off of Uno over a brilliant design like Carcassonne.

The player logs were evenly spaced throughout the semester. This had the advantage of appearing elegant on the calendar but the disadvantage of colliding with other deadlines. Of course, many students did the work right before the deadline, but this meant it competed for attention with other work rather than complementing a continuous practice of study. I may need to reframe the exercise as either formal assignments or as the building of a portfolio that is routinely verified.

I realized too late that there was an opportunity to tie the player logs into the final projects. Next time, for late-semester player logs, I should require that the game be related somehow (mechanically, thematically) to their final projects. A lot of the students admitted to having explored a genre in which they had little experience, and this could be a way to help them understand the design space they are in.

Design Logs

Once again, I required my students to maintain design logs during their final project. I love this idea, and I am sure it helps them think through their practice. However, I think I can make the progress a bit smoother. For example, I required them to follow a particular document structure, but many struggled to read and follow the instructions. Rather than be indignant about this, I could provide a template to remove some friction. Similarly, I gave them some latitude as to what specifics go into the design logs, but they probably lack the experience and wisdom to make this decision well. I have them read Dan Cook's article, where he appropriately provides some guidance but no rules. I think I should give them a few more rules in the spirit of shuhari.

Workshopping

We used six weeks of class for workshopping. I split the class into four groups, and since we met twice a week, each group had three days to focus on workshopping their games. Each presenter took a section of the room, and the rest of the class moved among the stations. For the first round, this was done ad hoc; I set a timer, but moving was a recommendation, not a requirement. We ran a little postmortem after that iteration, and the students liked the ad hoc groupings but not the optionality of rotation. Thereafter, groups had to move when the timer went off, and it went well.

I gave them a feedback structure that I learned from Lemarchand's Playful Production Process. Any feedback during workshopping had to be framed as, "I like..., I wish..., What if...?" The students who tried this loved it, but some were too eager to give advice without the framing. They desired some kind of accountability, so I decided that we needed a magic word that could be invoked: what better for a game design course than "xyzzy"? If anyone heard feedback without the format, they could say, "Xyzzy!" and the hearer would have to re-frame their discourse. I think I was the only one who actually used this, but it was a good reminder to have on the board.

Similar to the feedback structure, starting in the second iteration, I asked students to begin each workshopping session by giving their elevator pitch and stating their design question. This was not always followed, and a little more accountability could have helped here, akin to the magic word for feedback. Students also struggled to articulate a design question, but I did not give much guidance here either. Many students came in with questions like, "Is this fun?" despite our earlier conversations about the danger of the F-word. I think this is a place where I can help them develop better practices and tie together the two halves of the semester. For example, I could give them a template like, "What mechanic can I add or remove in order to improve [emotion] from playing my game?" or "What goal can I add for [player type]" These would require students to think about their games in the context of the theory we studied rather than falling back on colloquialisms like, "Is this better than that?" 

Along those lines, I wonder if it would help the students to articulate design goals, to be explicit about what their game is supposed to do. This is something my preproduction students have struggled mightily with, and I don't know if this means that it should be introduced earlier or that it requires more wisdom than many new game designers possess.

Rules

I was initially surprised when, reading their final submissions, that their rulebooks were low quality. Many were missing fundamental details so that it was clear that the rules articulations themselves were not tested. My evaluation rubric enthroned a clear rules articulation as being a requirement for a good grade on the final project. I reflected on the course and realized that most of the students had completed the semester without ever reading an actual rulebook. For their player logs, they either used a digital interpretation of a game such as Board Game Arena or they were taught a game by a friend. Digital adaptations are deceiving here because software prevents players from doing things that they ought not do whereas in a tabletop game, you are only beholden to the laws of nature and localized miracles.

The students had never worked with the genre of game rules, and so clearly I could not hold them accountable to that genre's standards. It still bothers me that the CS majors in particular did not deploy their programming knowledge to write clear rules anyway, since rulebooks are essentially programs run on people, but that doesn't change the fact that I did not scaffold a good learning experience to make them good at it.

Being able to articulate the rules should be part of the class. After all, I encouraged them to think about posting their work on itch.io or someplace similar, but if the work is unclear, then it may do more harm than good. Next time, I need to think about this particular deliverable the way that I handle other incremental development tasks: give them a scaffolded experience with deadlines for draft submissions and/or rules-based playtesting.

Vlaada Chvátil's observations on diplomacy and winning

I just finished listening to Vlaada Chvátil's appearance on Justin Gary's Think Like a Game Designer podcast. It's definitely worth a listen for game designers and fans of Chvátil's work, and there were a few surprises along the way. Today, I want to share two brief observations that were shared at the end of the episode.

First, Chvátil mentions that he stopped caring to make or play games of diplomacy: the metagame is entirely about convincing the table to go after the person in the lead but never to go after yourself. All the resource management that comprises the systemic game becomes moot in face of the human game of negotiation (or, as Gary quipped, who whines best). This is particularly interesting to me because of some conversations with my game design students this semester. I have pushed several to think about the player as a first-order component of the game—that they are something you should contemplate when designing systems. Obviously, player interaction can be fun and interesting, but Chvátil is pointing out a limit. It is like an amortized analysis of an algorithm: when one factor dominates, the rest become irrelevant.

Second, Chvátil says he does not care for games where the dominant strategy is to hide that you are winning: it is unsatisfying other players if you can obscure your standings and then surprise everyone that you have won. This played into a theme of the whole interview in which Gary was trying to understand what connects Chvátil's incredibly diverse oeuvre. Chvátil mentioned offhandedly, "winning a game is overrated." That is, what matters is that everyone has a good time. I also discussed this with my students since many of them are still struggling to understand why few contemporary designers use player elimination or even Uno-style "Skip turn" actions. I encouraged my students to think about it narratively: you invite someone to your house to play a game, and then during the game, you tell them that they don't get to play any more. It's just not polite. Yet, students who are all-in on player elimination will find a justification!

Paper prototyping, digital prototyping, and the DORA Metrics

My video game preproduction class formed teams and started work on their final projects a few weeks ago. Each group started working on digital prototypes before they had really settled on the core gameplay. I encouraged them to move toward paper prototyping so that they could make changes faster, even radical changes. I am pleased to report that they have embraced nondigital tools as part of their process, although I'm still concerned that they are not iterating fast enough. 

This was on my mind when I watched Steve Smith's latest video from the Modern Software Engineering YouTube channel, which reminded me how the DORA metrics can positively influence software development practice. It got me thinking about the metric change lead time, which measures how long it takes from a change to go from committed to deployed into production. I realized that this is essentially the same idea as I have been advocating for their prototypes, whether they are analog or digital: the less time it takes for an idea to go from implemented to tested, the better. It doesn't matter whether we are committing in the sense of version control or in the sense of having made a coherent change to a paper prototype. I suspect that the DORA metrics would still hold, that a team that reduces that time is going to be more productive.

In today's meeting, we talked about what this means for us as game developers. I borrowed part of Smith's analysis, discriminating between activity metrics, output metrics, and outcome metrics. The students got the idea that the outcome metric is most important, and that this could be something like profit or it could be something like delight. That is, if we are making a game that is designed to bring joy to people, then the amount of joy we bring the player is the intended outcome, so we should measure that. In fact, we often call that playtesting.

This led me to hypothesize that we can use change lead time metrics as a tool to determine when to switch between forms of prototyping. I have that students sometimes have difficulty understanding physical prototyping and other forms of lightweight prototyping when they are developing video games. The DORA metric points toward a solution: one should change modes of prototyping when it reduces change lead time. That is, given an intended change to the game system, one can ask which mode of prototyping allows us to go most quickly from implementation to playtesting. While that is paper, stay with paper. At some point, though, there will be more systems or crafted aesthetics than the low-fidelity form is accurately conveying, and so we use higher-fidelity prototyping instead. 

There are at least two potentially confounding factors within this hypothesis. The first is that it assumes that we can accurately assess whether a particular system can be accurately playtested in a given prototyping medium. Drawing a physical card feels different than tapping a depiction of a deck, for example. The second is that it may require an amortized analysis when getting started. Engineering a system that allows for rapidly changing design components requires some up-front work. The point remains, though, that one cannot build software that is infinitely malleable, and the low-fidelity prototyping ought to inform which parts of an implementation are expected to change and which are not. Like the first challenge, this deals with the inherent risks of software development: the only way to know exactly how to build it is to have already build it.

Introducing students to Capture Go

I am enjoying teaching introduction to game design after my years-long hiatus. The class is very eager, the sort that I rarely have to wait for comments and instead have to urge to move on.

On Thursday, we discussed core mechanics. It's something we had talked about earlier in the semester as well, but now we returned to it so we could talk about primary systems, secondary systems, and so on—and how crucial it is for small teams to remove anything beyond secondary systems. One interesting aspect from the discussion was the question of what is "core" in Skyrim: is it combat? discussion? walking about? This allowed us to discuss a designer's perspective on elegance, how it is not the same as goodness of design, but that there are good reasons to strive for it.

I followed this by teaching them to play Capture Go. I don't often cover this in my class, but I was inspired to put it into Thursday's discussion of core mechanisms given that Go is practically all core. There's just not much else to it, which is part of why it's such a fascinating object of study.

I introduced the game, and we got into pairs to play. There was an odd number in attendance, so I got to join a student for a few rounds, which was a treat. She was having some trouble seeing the patterns, so I started pointing out when I was about to win, and this led to our having better games. Also, however, she also set up her own goals, such as covering the star points; this was more important to her than winning the match.

After playing for only about seven minutes, I polled the room to see if anyone had thoughts to share. Everyone seemed to have fun, and I didn't get the sense that anyone was confused by the rules. One student pointed out how there was a strategic element to hitting the edge of the board in such a way that they could entrap the opponent. What really struck me was a discussion from another pair, where they immediately recognized that there was "aggressive" and "defensive" play. They described how, at first, one of them was defensive to the others' aggression, but that aggression seemed to win out, so then they both played aggressively. It doesn't matter to me which is more strategic; what I want to point out is that they recognized that in this simple stone-placing game, there was something deeper than simply marking spaces: there was strategy, there was a feeling, there were patterns, even if they only scratched the surface.

This neatly tied up our discussion of cores and elegance, and I have marked my teaching notes to remind myself to use this combination again.

Shove Off! at Global Game Jam 2026

This past weekend, I participated in Global Game Jam at Ball State University. This was the first time in many years that I was not hosting the event, and it was a nice change to simply jam and not have to worry about logistics.

My team created Shove Off!, a local-multiplayer arcade game. The source and binaries are also available on GitHub. The game is for four players with game controllers.

Title Screen

My son and I started kicking around ideas right after the theme announcement. We briefly discussed making a survivors-like where the powers come from masks, but we tossed it as requiring too much balancing. We pivoted to using masks of world cultures to provide power-ups in a platformer brawler game. This idea played well into our observation that local multiplayer games can generate a lot of fun even if they are rough around the edges. Choosing this to go forward, we then decided on pushing as the core player interaction would be such that masks modify it. (Incidentally, I have played Smash Bros. exactly once, and my son has not played it at all.) Our whiteboard designs revealed an opportunity for two kinds of attacks: a horizontal push from the ground and a diagonal push from the air. The simple level layout we sketched provided all we needed for a playground.

We tried to get the core gameplay working Friday night, but we could not get all the pieces together. Crucially, we did figure out the sizes and shapes that everything would need to be. We also recruited a musician who agreed to write a retro-style, high-energy song together with sfxr-style sound effects for us.

Saturday morning, we got the core gameplay and representative placeholder art in place; that is, we replaced the Godot icon with stick figures. We enjoyed the core gameplay even without powerups. Knowing we were a small team with limited time, we decided to try to build a complete game using only the core gameplay. If it was good, it could be what we shipped, and if we had time, we could add powerups. During the day, the theme became less generic and focused more on lucha libre. Masked wrestlers pushing each other off of platforms seemed the right way to go. Once the musician's main theme landed, it changed everything: the song was perfect for the madcap gameplay and bold visuals we had brought together.

My youngest son was the only one with nothing scheduled Saturday afternoon, so I invited him to come hang out at the jam. I set him on some research tasks, including finding fonts and figuring out a palette for the characters. He started by simply poking around Google Fonts, but then I taught him about the value of using image search for reference images. We brought up images of luchador posters, which changed his whole approach. It was a good learning opportunity, and I'm glad he came along, even if he had to spend some time awaiting assignments.

Starting the match

Many of the posters we reviewed featured a starburst background, and it looked to me like something I could do with a shader. I tried puzzling it out myself but did not make much progress. Shaders are interesting to me but I frequently get stymied by them. I ended up searching the Web and finding exactly what I was looking for. Sunday morning, I added my favorite subtle feature: at the end of the game, the background color changes to match the thematic color of the winner. One of the other jammers required shader cleverness in his game, and I told him how I'd love to lead a seminar on the Book of Shaders. He said he'd be interested, so I guess I only need nine more undergraduates who are intrigued by this intersection of art, math, and design.

I should mention that all of the visuals were done by my other son who was in attendance. He did a great job iterating on ideas and taking feedback, reworking the characters several times as we worked towards our goal. One of the best things we did in terms of the project architecture was to separate the body animations into their own scene so that he could work on those independently while I worked in nearby systems. We only had one merge conflict during the whole weekend, and it was quickly resolved.

By Sunday morning, we had already covered the "mask" theme with our luchadores, but we had time to build on the core gameplay. Our testing showed that players could get stuck in pushing matches, and so we pulled our favorite powerup from Friday night's listing: fireballs. Every few seconds, a stylized sun shows up in the middle of the screen, and the player to grab it gets three fireballs. These proved perfect for breaking up the gameplay.

We were all happy with how the game turned out, and it was popular during the post-jam party. I felt good about making a complete, playable, and enjoyable game. I have spent a lot of time the past several months in preproduction and exploring engineering practices, but I haven't shipped anything in a while. The jam was a great opportunity to go from nothing to something in 48 hours.

If you try out the game, I hope you'll let us know what you think.

An Improvement in Brainstorming Game Ideas

I have used brainstorming exercises in my game design classes for many years. When I first started, the goal was to fill the board with ideas within one class period—and we did. But it wasn't that helpful. Brainstorming is recommended in Richard Lemarchand's Playful Production Process, and so I used it in my 2023 and 2024 game studio preproduction classes, following his helpful rules. These exercises can result in unexpected items, but it seems like every time, no matter my framing, the participants failed to grasp the point of the exercise: game ideation. Instead, what overwhelms the list is inspiration for theme, setting, or characters, but these are not game ideas.

I saw a different possibility when I watched Joe Baxter-Webb's video on ideation methods. The video recommends seven different approaches for ensuring that one is pursuing worthwhile game ideas. One of the approaches is to describe a game in terms of "Action Action Goal." An example he gives describes Into the Breach: destroy the kaiju and upgrade my mechs so that I can save the cities. It struck me that this simple formula might help my students stop listing things like "bacon" which everyone likes but which is not a game idea. 

I explained the structure and goals in class yesterday, and in twenty minutes, my small group of students came up with forty game ideas. The very first one was only a goal, but with a little prompting, it was revised into action-goal. The next was fully robust in its action-action-goal structure. A few of the entries were quick "Yes, and..." entries, where someone riffed off of another idea, but most were standalone ideas.

Forty is much less than previous teams have made, and that's a good thing. Everything on the list can be turned into a game, although many of the actions seem to describe narrative events rather than player actions. For example, one of the concepts was to "embarrass" someone else, but turning this into a player action would require some interpretation. 

Each student brought an original game idea to class, inspired by Baxter-Webb's video, and I hoped this would warm them up for the exercise. However, I am not sure that items on the list represent the games that the students actually want to make. I say this in part because, earlier in the week, I had them do a short analysis of a game they enjoy, but in the brainstorming list, I don't see elements of those games. In retrospect, I could have been more transparent, telling them that they should expect to be doing creative ideation in class. To me, this is clear from the preparatory exercise, but that's because I have the whole class plan in my head already.

As I was writing this, I looked at my blog for old brainstorming notes and came across my notes from Justin Gary's Think Like a Game Designer. My plan for Monday's class was to have my students start greyboxing, but I realized last night that we should some more time narrowing down what we want to make. I think I may review the notes from Gary's book more carefully and have those as a back-up plan to help the students figure out what they want to make. 

Intelligence, Wisdom, and Charisma

I am going to try to capture some elusive concepts that require me to reach into philosophy and sociology, which are areas outside of my professional specialization. Caveat emptor. If you recognize a mistake or misunderstanding in my arguments, please let me know in the comments or over email.

I have been mulling over the idea that every D&D player knows the difference between Intelligence and Wisdom but few consider that they are engaged in classical epistemology. Aristotle wrote about the distinction between the intellect and the will, although I came across this by way of Thomas Aquinas. Thomas described how the intellect apprehends and abstracts while the will chooses. This is essentially the distinction in D&D and related tabletop roleplaying games. 

It's a fascinating case where players learn philosophy without knowing that they are doing so. I hypothesize that this has a real impact on their lives as well, that when people come to think of the powers of the mind in terms of Intelligence and Wisdom (or intellect and will, or intellectus and voluntas), it gives them a lens to think about life outside the game. If my observations and hypotheses are correct, then if D&D can do it, so can other games.

Yesterday, I listened to a podcast that gave me a different perspective on the matter. In the Conversations podcast, Mark Bauerlein interviewed Molly Worthen about her work on charisma and leadership. She caught my attention when she pointed out that sociologist Max Weber secularized the word "charisma." The word had traditionally only been used in the New Testament sense, where the Pauline epistles refer to spiritual gifts. As I understand it, Weber took this idea and turned it to refer to extraordinary (but not supernatural) leadership capabilities.

This forced me to recognize that I had never really considered the two definitions of "charisma" despite being familiar with both. It was a revelation to me to hear that it was a scholar's intentional appropriation of a term, not a gradual evolution of a concept. It also made me recognize that D&D players would only ever recognize Weber's concept, not Paul's. Here is a case in contrast to Intelligence and Wisdom, where a player comes to understand only half a concept while presuming to understand a whole.

To me, it is a cautionary tale about learning from games, that a designer must choose words carefully. I do not know whether Gygax or Arneson dove into the etymology of the terms they used to describe player characters in D&D. I suspect, like most designers, they simply chose the words that evoked the right sensibility for what their game was trying to communicate. If I am right about this, then this means that they were clearly established in a classical epistemology and a modern secular sociology. That itself is a fascinating thought, for if they were, then what about us?

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.

Walking away from a November game project: A reflection on NoGaDeMon 2024, Dart, Flutter, and Bloc

I would hate to make this a tradition, but it seems that I once again entered NoGaDeMon. National Game Design Month (NaGaDeMon) is November, and for several years, I created interesting little projects during the month. Last year, I was not able to pull a project together, and I'm afraid that's the case this year as well. However, I was able to learn a bit through the attempt, so I want to capture some of it here before it slips away.

Before November, I had been tinkering with an intersection of ideas related to posts in the last few months: interactive narrative games like my The Endless Storm of Dagger Mountain, which drew from the Powered by the Apocalypse tabletop RPG space, built around some concepts from Blades in the Dark and Scum & Villainy. I figured that, for November, I would try building a very small slice of the idea. For various reasons, I also wanted to try building and releasing a game using Dart and Flutter. I dug in and started making reasonable progress for a side project.

A few days into November, John Harper released Deep Cuts, a campaign and rules expansion for Blades in the Dark. I bought a copy and was quite surprised at the rules changes. I had expected little tweaks and balancing maneuvers, but Deep Cuts actually provides a complete overhaul of the most fundamental Blades action resolution system. This was too cool not to play with, so I rehashed my planned NaGaDeMon project, essentially starting from scratch to support some of the Deep Cuts ideas.

Before last week, I was able to get a very small version of the game working, letting the player experience a single, badly written game scene. The user-interface was just awful, so in order for the game to come together would have required adding a ton of content and a complete player experience design and implementation. Both of those would be tedious efforts, especially the latter, since I am not very fast with Flutter UI development. Part of the inspiration for choosing Flutter was to gain more practice with engaging UIs. 

About two weeks ago, the work of one of my committees exploded into taking most of my unassigned work hours, and this was not altogether unexpected. We also just got the good news that we will be hosting family for several days around Thanksgiving. This will be wonderful, although it also means these won't be hobby-project days. The result is that I've decided to put this project to rest. I did learn quite a bit going this far into the project, and that is the topic for the remainder of this post.

First of all, the obvious lesson is that if I wanted to really focus on learning to make a top-notch interactive Flutter UI, I should have chosen something with zero other design risks. I knew that the best I could do in one month was to make something just functional, yet I am not sure I was honest with myself about how ugly that would likely end up. Maybe I will find a game jam that will let me get a better handle on combining turn-based game timing with implicit animations.

Prior to November, I had been tinkering with some of these design inspirations in Godot Engine, which is of course the engine I used to build The Endless Storm of Dagger Mountain. I was using a rather conventional mutable-state object-oriented architecture. I found myself frequently frustrated by the lack of good refactoring tools for GDScript. This is a significant hindrance to evolving an appropriate design. This is part of what made me switch over to Dart, which is a joy to work with in part because of the excellent tooling support from Android Studio. 

A few summers ago, I spent a great deal of time studying Filip Hracek's egamebook repository. Nothing shippable came out of my efforts—I don't think I ever even blogged about it—but I did learn a lot. I was struck by how Hracek separated the layers of his architecture, and it was the first time I spent a lot of time in a game that used immutable data models. At the time, I had looked into the Bloc architecture and struggled to make sense out of it.

Approaching this November's project, I decided to dig deeper into Bloc. I spent a lot of time with the official tutorials and puzzling over this seemingly simple diagram:

The simple tutorials are simple, which is convenient, but the more robust ones separate the "data" component into a data provider and repository. It seemed clear that the game state could be conceived of as data, but I struggled to conceptualize where the game rules should live. The game rules can be considered part of the domain model, and as such, should be separated from the bloc. This would mean that a response from the domain model may be the modified game state, which then is echoed back through the bloc to the UI with a bloc state change. However, it's also reasonable to conceive of the game state itself as the data layer and the "business logic" as being the transformations of that state. Indeed, this seems to be the difference between the simple and more complex tutorials: the simple ones deal with simple in-memory state, and the more complex ones draw data from different sources and transform them in the data layer. 

Of course, there is no silver bullet. Given the tight time constraints on the project, I simply considered the immutable game state to be my data layer, and I put the game logic in a bloc. I also simply passed the game state along to the UI, but in a more robust solution, I would have had clearer separation between layers. Including a dependency between the UI and the data layers was a matter of expedience and the intentional incurring of technical debt.

My first pass at the implementation had me writing my game states and bloc states by hand. The Equatable package meant that I didn't have to fret over writing some of the boilerplate that's necessary to do state comparisons, and it was easy to integrate this in Android Studio using Felix Angelov's Bloc plugin. When scouring the Web for help with Bloc, one quickly also comes across discussions of Freezed, which library is also integrated into Angelov's plugin. I had tinkered with Freezed in my egamebook-inspired explorations, but I have not shipped anything that uses it. After having built up my understanding of Bloc using Equatable, Freezed was an obvious next step. Next time, I would jump right into using it for cases like this.

Writing a functional Flutter user-interface was straightforward using BlocBuilder. I found this to be a convenient way to conceptualize the game, especially since it had very clear states. For example, in my original explorations (before Deep Cuts), I had the player choosing an action from a list, then customizing the action with various options from Blades in the Dark, such as pushing yourself to trade stress for dice. After rolling the dice, the player is now in a different state of the game in which they are responding to the result, such as by resisting its consequences. This was elegant to express in the code, and I am confident that with enough effort, I could make a compelling user experience out of it. By contrast, Dagger Mountain used an architecture inspired by MVP but that depended too heavily on the undocumented, unenforceable behavior of coroutines. Both of these are "only jam projects," but they are helping me to conceive of how I would approach something more significant in this problem domain. The aforementioned coroutines were my solution to synchronizing the model and view states (for example, to finish an animation before continuing to the next step of the narrative); I'm fairly certain I understand how I can do that with bloc's events and states, but since the November project will remain unfinished, there is risk.

All this exploratory coding meant that I did not follow a test-driven process. I ended up not getting into the testing libraries specifically for bloc. It's possible that this would have helped me better to conceptualize the business logic versus the domain layer, but that remains future work. 

There are still a lot of questions about the game design itself. Indeed, this entire exploration is inspired by design questions around the adaptation of Blades in the Dark tabletop gameplay into a digital experience. Citizen Sleeper is the only project I know of that has worked in this space, and it's a fantastic interpretation. I only became aware of Citizen Sleeper after I started doodling my own ideas, and it's interesting to see where they converge and where they diverge. I hope to dive back into this design space later, but for now, my attention must go toward wrapping up this semester, planning for next semester, and enjoying the upcoming Thanksgiving break.

Fantasy heartbreakers

 I am currently reading William White's Tabletop RPG Design in Theory and Practice at the Forge: 2001-2012 after having met the author at MeaningfulPlay. This excerpt from Chapter 3 made me shout with delight at having a name for a phenomenon.

A fantasy heartbreaker was [Ron Edwards'] term for an independent game that contained interesting innovations, usually without realizing that they were in fact innovative, but whose designers had failed to fully examine their underlying design assumptions—thus producing games that were highly derivative of D&D, whether or not that was actually a design goal of the game—and who were either naïve or overambitious in their expectations for success in the marketplace. (p.93)

Ron Edwards' original post on the topic is cited, but I haven't made the time to read the source yet. White's summary was enough to excite me and want to share it here.

Representing character damage through loss of skills and equipment

I was surprised to come across two recent tabletop RPGs that both eschew "hit points" as a means of representing character damage: Lester Burton's Grok?! and Runehammer's Crown and Skull. Neither cites the other nor any common inspiration, which makes me think that there's an interesting games history project hiding in here: is there a common ancestor or is it convergent evolution?

In Grok?!, the player has seven resource slots that can hold items. When a character suffers duress, there are a few possible outcomes. The player may choose to create, remove, or change one of their items, or they may take a condition that uses up a resource slot. These are intended to be temporary, but if a character has no more slots, then the character is incapacitated and the condition instead becomes a permanent trait. A player may also voluntarily add conditions to their character in order to roll additional dice after failing a check. Grok?! is clearly a story-focused game, using an elegant universal resolution system that invites creativity and narration.

Crown and Skull has an intricate point-based character-creation system in which players determine a character's skills and gear. Taking damage involves crossing off skills and gear, which is temporary, and sometimes destroying gear, which is permanent. Damage is classified by whether it targets skills, equipment, or both, and it is further classified by whether it is a random target or whether players choose. Runehammer describes this as an attrition system, and it's easy to see how it invites more interesting narration than "You lose five hit points." Crown and Skull is presented as a game that the players themselves get better at, learning more about it by playing it. Part of the challenge of the game is learning to create and manage a versatile, robust, survivable character.

I have played a lot of CRPGs, but I don't remember ever seeing a system like this—one where damage is exclusively represented by the temporary or permanent loss of gear or skills. It makes me wonder how well such a design could be adapted into a video game. Could such a system be adapted into a satisfying video game experience, or are these formal systems too strongly coupled with the improvisational storytelling of tabletop games?

An evening with Microscope

I heard about Microscope from Ben Robbins' interview on Justin Gary's podcast. It is a game about creating a history: the rules guide the players in the collaborative creation of the periods and events that make up a historical arc. I became intrigued, and it seemed like the kind of game one would have to play to follow a conversation about it. I borrowed a copy of the rulebook and convinced my wife and two elder sons to try it out with me.

The rulebook gives specific advice on how to introduce the game, and I appreciated being able to follow the script. Our first decision was the overall theme of the history, but we could not settle on one that we all liked. We agreed to take the first one of three that were recommended for players like us who weren't sure how to start: three nations are united as a single empire.

Our next step was to bookend history. One of my sons recommended that the end of the history should be that three nations, each on the back of a turtle, come together under one emperor. We then came up with the idea that at the beginning of history, there was one nation, on the back of the Great Mother Turtle, but she died, and the nation divided onto the backs of her three children.

As we got into the game, we created the history of three turtle-nations who lived in harmony until a blight caused scarcity of Turtle Orchids—the only food eaten by the giant turtles. The three turtle-nations separated to search for new sources, and their cultures evolved due to the different environments under which they found themselves. We never got into the details of how the turtle-nations came back together after this separation, especially not how they resolved religious differences that emerged, but we know they did, and that it was positive for them.

There were some rocky spots, as to be expected in any first play of an RPG where only one person has read the rules. The last page of the rulebook is a convenient rules summary, but Robbins has not provided this as a downloadable player aid. I feel like it would have helped the players—including me—keep some of the terminology and sequencing right. 

One scene did not go particularly well. Scenes answer particular questions in history, and this one was supposed to answer the question, "What monsters attacked Medium Turtle that caused the society to become more militaristic?" It was only our third played scene, and we jumped into it with gusto. It didn't seem to go anywhere, though, as no one roleplayed an answer that satisfied the question. At one point, I just put the kibosh on the scene, suggesting that the answer seemed to be that we didn't know. This was a little unsatisfying, but so was the scene at that point. 

I did some work afterward to better understand the rules for played scenes. The introductory advice that we followed had us start with a played scene, and that one had gone well. In re-reading that portion of the rulebook, though, I was reminded that playing the scene is a combination of narrative and dialogue. We had only been engaging in dialogue, and if I were to teach the game again, I would make sure to open a scene by using both. We also were too light with setting the stage, which is an explicit part of playing a scene: while we had established who and where we were, we had not established what we all knew and what happened prior. 

I came across two interesting resources during my post-play research. One is this rules cheat sheet created by Nicole van der Hoeven. It may be a good way to introduce someone to the game, but it's a great summary of the rules. Reading it provided a more convenient reminder about the core rules over re-reading the book itself, since the book necessarily combines rules and exposition. Seeing the topic list on van der Hoeven's site, I think I may spend some more time exploring her notes on other topics as well.

The other interesting resource I found was a recent blog post by Robbins himself. It presents alternate rules for scenes which I am sure would have given us a better experience even in our first play. Among the benefits of the revision is that it eliminates the need for "push" rules. These are the rules that allow players, during a played scene, to push back on something that someone has introduced into the world. They seemed necessary but secondary in the book, containing more details than I could hold in memory when teaching the game. They were to be deployed in reaction to play, which also meant that I did not want to review them while we were actually in the game. I am not just happy with the simplification of the scene rules, but I am also chuffed to see a designer improving a game he published over ten years ago.

In summary, I enjoyed my first play of Microscope, and I would like to play again, now having a better understanding of the rules and a handy revision thereof.  If I were teaching my game design class in Fall, I would likely bring this in as an example of an RPG. In an era where all of my students are at least aware of Dungeons & Dragons, it would be a great example of how "role-playing game" is bigger than that.

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?

Notes from the Inaugural Game Preproduction Class: Draft Macro Documents and Charts

My three teams presented drafts of their game macro documents and macro charts today. I am glad that I devoted a day to this. Each team made reasonable progress on the documents, and our discussion highlighted places for them to improve.

One of the groups had shown a draft macro chart earlier in the semester, and they had a lot of ideas contained in each row, essentially one level per row. I advised them to break these down into gameplay beats or player experience beats. The one that this team showed today had much better decomposition of ideas. I am grateful that they showed that early draft since it meant that the whole team could see how much better the newer version was.

I asked the students to compare the macro document and the macro chart and whether one of them drove the other. The one respondent mention that he felt that the two complemented each other, that they worked together. My inclination is to think he is right, and I presume the rest of the class felt the same way despite not speaking up. I still have no personal experience with macro charts, and I'm torn between those and one-page design documents for potential exploration in my personal work.

One of the teams covered their title screen as being part of the macro chart, but an aspect that all of them missed was the concept of fail states. That is, all of them treated their draft of the macro chart as a "happy path story." I urged them to also think about what happens with the player loses or fails so that they do not miss requirements in the draft schedule, which is due at our next meeting. The students pointed out that Lemarchand does not address death or failure in his macro chart, and so they weren't sure how to do it. I suggested that simply breaking down the chart into headings, like "Narrative Path" and "Fail States" might do it. I will be interested to see how they decide to handle these cases.

Another fruitful conversation arose around the linking between rows. In a few cases, students talked about how there was a narrative connection between chronological experiences, but these were not represented in the chart. This was a good opportunity to point out that this is what the chart was actually for: to express these linkages clearly at the macro level. This dovetailed into a good though short discussion of macro vs micro design, and also to one student's frustration at not feeling confident in making design decisions. Once again, this discussion pulled into the value of these charts: that the chart makes you face these decisions, and it's a low-stakes way to figure out your scope before you even start worrying about scheduling the production of individual assets.

Notes from the inaugural Game Preproduction class: Divergence followed by Divergence

This is a follow-up to my previous post, in which I focused on particular problems that arose in the prototyping process from the inaugural offering of CS390. Here, I want to take a different perspective on the last few weeks and share some thoughts about the course itself.

The preproduction approach described by Mark Cerny and codified in Richard Lemarchand's book maps well to the Double Diamond model: diverge, converge, diverge, converge. The first diamond is ideation and the second results in the vertical slice. Yesterday, my students got together for our first big convergence meeting... and we got nowhere. What happened?

As laid out in the course plan, we spent January getting started by framing our work with the first several chapters of Lemarchand. February included some reading but mostly a major brainstorming session followed by the development of prototypes: first paper prototypes, then digital, then a 2-week period that was supposed to be intensive, variable-mode prototypes, leading up to the big convergence on February 16th.

Even while we were in the middle of the prototyping, I noticed that we weren't converging. I mentioned it to the class, and I got a general consensus that they understood what I meant, but it wasn't obvious that behavior was changing. The students' work that I observed from their prototyping fell into two categories. One group of students went head-down into one idea and never came out of it. Some got locked into a theme and others into implementation details, but in either case, they didn't explore the design space—they never diverged. The other group of students continued to diverge: each prototype picked up a completely different idea, some not even related to the original brainstorming session. This meant that at our Feb 16 meeting, when I asked them to share what directions they had in mind, some of them were still locked into a single concept while others became enamored of something that we had just seen the previous day. 

It should be clear why that first group is carrying risk: they have not explored the design space. The reason the second group carries similar risk is that they are hooked on an idea. Keep in mind what I wrote about yesterday, that the ostensible prototypes were not actually answering important design questions themselves. While I could be wrong, and more careful research would be required to prove it, I have strong faith in my hypothesis that students were still getting caught up in ideas rather than findings. They had not found the fun in a concept but imagined that a concept must be fun. 

At the end of our 75-minute conversation (which I myself derailed at least once, and which I had to pull back from the students several times), we ended up deciding to do another round of digital protoyping, this time in pairs. In order to help them proceed, I'm requiring them to answer Lemarchand's seven questions. I am hopeful that this will help us move forward, even though we've already passed the 15% of project budget that Lemarchand recommends for ideation.

What makes me hopeful? After our meeting on Thursday, I wrote an announcement to the students trying to give a little more basis for what we ought to be seeing. This prompted a student to reach out to me, to share with me a possible design question for a prototype to answer, and to ask whether it was a good question. It turns out it was not a good question... not yet. It showed that the student was moving in a fruitful direction, though, and so after a lot of typing, I was able to explain why that question was not good yet, but how it could be modified. I took this asynchronous conversation, removed the particulars, and reposted the essence of it for all the students. Some of it felt like hard love, but I held out hope that it was what they needed. This hope was validated later in the evening, when a pair of students reached out to talk about their design question. It turns out that their question, which they explained came after spending 1.5 hours reviewing the messages I had sent and the framing from the reading, was excellent. It was not just good; it was qualitatively better than anything that had been shown or discussed in class up to this point. I hammered that point home in our conversation, and I think they understood me.

My point, as ever, is not just to share stories, but to use the stories to reflect on my experience so that I can improve. Here are a few things that I need to think about doing differently in the future.

• Collectively reduce the brainstorming output. Retaining all ~100 concepts throughout ideation pushed students toward continued divergence. One of the students pointed out that we could have had some kind of elimination strategy to help us see the space reducing. For example, simple voting could identify top contenders, and prototypes would answer the specific design questions.
• Encourage working in pairs or small groups. The way I framed the problem, it sounded like students had to work alone, but I would have accepted group development. Working together would mean more fruitful discussion and more shared ownership: it's not Bob's idea, it's our idea. This also means students with less production skill could pair up with someone who could show them the ropes.
• Spend more time on the problem of question identification, as previously mentioned. This could be done by workshopping questions together such as when returning to the big list of concepts, and it could also be done by requiring students to use Lemarchand's seven questions.

Notes from the inaugural Game Preproduction class: How Do I? vs. Should I?

As I mentioned back in January, I am teaching our CS390 Game Preproduction class for the first time this semester. I have a small class of students who already know me, and so it's been a real pleasure to teach. It has not been without some hiccups, though, and I need to start capturing some of them here on my blog. This will help me to understand and contextualize what happened and also give me an archive of observations for future improvement.

From February 7 through February 14 was set aside for the goal of making as many prototypes as possible so that the students could form teams and focus in on goals by February 16. That date marks 15% of the project time, which Lemarchand recommends as the extent of the ideation phase. On February 2, I gave the students the option of how they wanted to be held accountable to this goal. Together, we agreed that each student should present one prototype on each of the three upcoming classes (Feb 7, 9, and 14), and that at least one of these must be a paper prototype and one of these must be a digital prototype. One of the reasons for the latter constraint is that our previous presentations of paper prototypes showed that many students did not understand how best to use this medium. 

Upon returning to the reference text, I also realized that the students did not seem to understand the distinction between a playful prototype and a paper prototype, and this gives me something specific to improve next time. Students brought in playful physical artifacts and experiences that were enjoyable in various ways, but they did answer any design questions about video games. For example, it is fun to move a ship around and make shooting noises, but this doesn't tell us anything about a particular design for a shmup, or it is fun to run across the room and try not to be caught by classmates, but this doesn't tell us anything particular about a stealth or action game. The distinction between playful prototypes and paper prototypes is clear in the reading but was not evident from my students' presentations.

While watching students present their digital prototypes, I realized that there was another important distinction to make: the difference between How do I? and Should I? A lot of the students who showed digital work were really asking the question of whether they could accomplish some design goal, but this question is not fruitful for making decisions about video game direction. It should be a given that anything one has seen in a videogame before is something that they can make, given enough time. And yet, even I fell victim to this during our in-class digital prototyping workshop, when I tried to see if I could make a weapon-switching shmup in an hour. The real question to answer with a prototype at this stage is, "Should I pursue this idea?" Would a shmup where you can swap weapons be fun? Yes, of course it will. That is well trod design territory. Sketch the weapons and Bob's your uncle. (Well, he's my uncle, anyway.)

On one hand, it's easy to say that I should simply push students toward the question of whether a design is worth pursuing rather than whether they can engineer it. On the other hand, Lemarchand makes it clear that one of the first steps in the process is to learn your tools... but my students, by and large, are not very good at their tools yet. Some have been gamedev hobbyists, others have taken an elective in game programming, and others have no experience making videogames at all. When facing your own ignorance about how such things are done, it is natural to be slow and to need to tinker. It is not clear how to resolve this conflict. Next year, as our curriculum matures, more of my CS majors will have game programming experience; however, then we will also have students from other production majors coming in, and I suspect we will run into the same kind of second-order ignorance.

Rereading the text, I was reminded that Lemarchand provides a set of questions that a prototype should answer. His list comes right before the aforementioned playful-physical-digital distinction. Having the students frame their work within these questions may be another important step to improving the process. Adding a reporting layer may look like it is making them do more work, but I think, if it is done right, that the questions will help the students do less and better work. For reference, Lemarchand's questions (from page 23) are:

• What player activity am I prototyping?
• What game verbs am I investigating?
• What kind of experience does this player activity produce?
• What tone or mood does the player activity have?
• What interesting gameplay and story things can I do with this player activity right now?
• How much could I do with this player activity if I had the time to devise different situations and scenarios in which to use it?
• What question am I trying to answer with this prototype? (Emphasis in original.)

Global Game Jam 2023: Stormclouds Over Spudville

Last weekend was Global Game Jam 2023. I recently discovered that my GGJ profile page includes links to all the games I've made at the jam, allowing me to determine that this was my ninth GGJ. Wow. As you can see from my university's GGJ 2023 location page, we had six games completed during the event. It was a fun weekend, and I enjoyed spending time with folks who were inspired to work hard to make something new.

My team made Stormclouds Over Spudville, a game in the Worms genre. Our spin on the classic formula is that the potatoes bury themselves when it is not their turn. My idea was that this would force players to try to get accurate arc shots. An alternative strategy is to take the high ground and then ploop out a low-power explosive onto an enemy's head, but this does run the risk of catching yourself in the blast as well.

My two older sons and I were the core of the team, and we also recruited Robin Walma (a.k.a. Harmonic Legion) to compose as a thrilling original game theme. Seriously, it's a perfect fit for the gameplay. It's a march in the style of John Philip Sousa.

When the theme of "Roots" was announced, I was the only one in the room who understood the LeVar Burton reference that I made. Some of us wanted to go in a rather literal direction, and you can see that also in the games that were created, but I explained to my boys that I really wanted to use the jam to explore a genre I had never worked in before. Worms-like games came up, and so on Friday night, we set out to create a proof-of-concept of destructible terrain. We figured that if we could get that working in two hours, we could make a game out of it, and if we couldn't, then we could pivot. I don't remember exactly how it became about potatoes, but from very early on, it was about potatoes.

We were able to get destructible terrain working with time to spare, thanks in part to the tips from MrElipteach. Saturday then became the day for getting the core gameplay in place. We were limited to a two-player game due to the fact that my USB Hub had disappeared from a storage closet at work, but maybe that was for the best. For a while, each player only controlled one potato. I was concerned about how we would both design and then implement the damage system: if the potato is hidden in the ground, and someone blows away a hole, what exactly happens? The potato becomes a rigid body then falls then becomes a kinematic body when the player gets control again? We ended up taking the wise design strategy of circumventing this problem by simply making one shot kill a potato. By the end of the day on Saturday, we had a completely playable game and came home for a late supper.

Sunday, we only had a few hours to work on the game, but we were in a good position to focus only on polish. Robin rendered the final version of the soundtrack, and we put that into place. It sounds great, and purely by chance, the entrance of the piccolo syncs up almost perfectly with the introduction of the potatoes on the main menu. The best thing that I worked on was having the eyes track nearby projectiles. I do believe I squealed with delight the first time I saw it on screen: it was just what we needed. My older son added "potato angels" upon death, which is another great touch. Not too long before the deadline, he really wanted to add randomized terrain... and he did! I tried understanding the implementation this morning and couldn't quite sort it out, so I think I need to talk to him a little about the value of comments and not using magic numbers in the implementation. Still, I'm proud: he was an efficient and accurate programmer all weekend.

The game was a big hit during the end-of-jam celebration. I pointed out to one of the other jammers that there was a sense in which we cheated: a game like this draws a lot of its fun from the fact that you're up against another human player who is sitting next to you. Whereas a single-player game has to live or die by its own merits, a two-player game pushes part of the experience into the social space. It is not really "cheating" of course: it's clever use of constraints. After we came home, we played for another 45 minutes or so with the rest of the family. I'm glad the game was well received: it's good feeling to work hard on a creative endeavor and have the result be that you've made someone else's life a bit more joyful.

I just uploaded Linux and Windows builds as GitHub releases, so please feel free to grab those and check out the game. 

Course Planning: The First Offering of CS390 Game Studio Preproduction

One of the most exciting aspects of my department's new Game Design & Development Concentration is a three-semester capstone experience. Eventually, this sequence of courses will be team taught through Computer Science, Animation, and Music, but since my department is a year ahead in the curriculum approval process, we will be having a CS-focused sequence the first time out.

The first course in the sequence is CS390 Game Studio Preproduction, and I am teaching it for the first time this Spring. I have spent many hours prepping for this course, and this week, I am finally feeling confident in my design decisions.

As the title implies, this is the preproduction experience for the production courses, which will be a sequence of senior-level courses offered for the first time next year. The success of production hinges on good preproduction, and so there's a lot of pressure in CS390 to get things right. I decided to use Richard Lemarchand's A Playful Production Process as the primary text for the class, and we'll be reading through the book and completing exercises from it during the semester. The advice in his book is that 15% of time be spent on ideation, and mapping that to a three semester sequence means that my students will spend the first six weeks of the semester in that phase. Coming out of ideation, I expect the students to be able to form teams around ideas as they move into preproduction proper. At the end of the semester, each team will be expected to have a vertical slice (or at least a beautiful corner), a game design macro, and a production schedule.

The semester will culminate in the student teams' presentations to a Game Proposal Review Board. This board of industry professionals will give feedback to each team and have the power to approve or reject each project. The approved ones will be the ones that move forward into production next year. Students on rejected projects will be reassigned to other teams so that we can produce the highest quality outcome. I already have two board members signed up, including one alumnus, and I am waiting to hear back from one more.

Lemarchand's book gives a good intellectual framework for thinking about preproduction, but I was still left with many course design decisions. One of these decisions was how to grade the students; since I am required to give a grade, I need to make sure it is done in an appropriate manner. I have been thinking about how to get more results out of the efforts I put into grading, and this course provided an opportunity for me to think more about that. In particular, I would like a little more clarity and a little less of the reduction in implicit motivation that comes with grading. As a result, I'm taking a page from my colleague David Largent's handbook and trying a more by-the-books approach to specifications grading. 

I have set up categories in which students can earn "tiers" (grades) based on their work and dedication to the class. The easy two to set up were participation and exercises, the first of which deals with classroom engagement and the latter with individual assigned work. These are all graded on an S/U basis, and satisfactory performance unlocks higher tiers. I will do something similar for the four end-of-semester outputs, but I want to be able to think more about those and also to negotiate the details with my students. For the final category, I added achievements. As in CS222, I was inspired by the idea of rewarding students for doing authentic work that excites them, but I did not use the same formal system as in that class. Instead, I set it up so that the achievements are harder and, essentially, someone either completes one or not. Then, in the final course grade, the achievement acts as a sort of buffer, allowing students to gain higher course grades. A student who does no achievements but aces the rest of the requirements will still get a well-deserved A, while a student who slips up in another category can use an achievement to still demonstrate excellence and get a well-but-differently-deserved A.

The class is actually below the usual enrollment threshold, but because it is part of a new program, the dean has approved it to go forward regardless. I know all the students who are signed up since they have all come through other courses I have taught, and so they all know that we're in for some serious business and hard fun. A couple of the students are also taking my immersive learning CS490 class, which means they are actually taking more than the normally allowed number of games-related courses since they are sitting in a transitional curriculum—good for them!

As usual, I have put my course plans publicly online, and you are welcome to read them. I am looking forward to getting to work with these students and see what they can make.