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.

What we learned in CS222, Spring 2026 edition

I worked my CS222 students through my usual semester reflection exercise today. I gave them five minutes to write down everything they learned this semester that was related to CS222, then we set a timer for 30 minutes while they offered items and I wrote them on the board. For some reason, we only had nine people in class today, but these nine came up with 88 items. I was going to give then six votes (because ceil(lg(88))=6), but a student in the front agreed with me that five was more symbolic, so they got five votes to mark the items most important to them.

The distribution of votes was unlike any I have seen before, and this may be because of the low attendance. Two items rose quickly to the top, with five and four votes respectively, but the next classification were with two votes, of which there were six. After a brief reflection, I decided to seize the opportunity and go ahead and mark all eight of these as "top items" for use in the final exam. These items, and their vote counts, are as follows:

• Clean Code (5)
• TDD (4)
• Version control (2)
• Using an API (2)
• SRP (2)
• Coding with a team (2)
• Red-Green-Refactor (2)
• Always run all the tests (2)

There is clearly some overlap among these, but that is fine. I look forward to seeing what the students have to say about these topics in the final exam.

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.

Amphibian-based grading

I have a friend, roughly my age, who studied architecture at Ball State as an undergraduate. He told me a story many years ago about his most formative interaction with the faculty. He asked his professor how he was doing in a class, expecting a quantitative answer. Instead, the professor drew a line: on one end, he drew an egg; on the other, a frog; in the middle, a tadpole. He pointed to a spot on the line and said, "You are here."

I tell that story to my students every semester when the question of grades come up. I recently shared the story with a faculty discussion group dedicated to improving teaching practices. Everyone who hears this story immediately understands that the professor has given the student valuable information—that this feedback is much more valuable than something like "86%" or "C+".

At the faculty discussion group, one of the participants asked us if we still had any marked-up papers from our own undergraduate years. I do not, though many did. She pointed out how modern undergraduates don't even have the opportunity to hold on to such things. All their interactions are mediated by technology; all their interactions have become transactions.

Yesterday, I recorded the podcast discussion around my essay for The Raised Hand. The other guest was the author of February's essay, which will be published in a few days. The moderator identified a theme between our essays: that there is an intrinsic danger to separating people with technology. Reflecting on the conversation, it strikes me that technology allows us to have a limited communication with people who are distant, but also limits our communication with those who are nearby.

Earlier this week, I graded my CS222 students' two-week project submissions. The explicit goal of this short project is to prepare students for the eight weeks of the final project. The short project integrates all the challenging ideas from the first four weeks, and so it is designed to help students figure out which of those things they really understand and which require more attention. How should such work be graded? I expect each team to miss some fundamental concepts in their project, often things like having clear names or following the Single Responsibility Principle. If a team misses one of these, should they get a low grade because the work is wrong or a high grade because they did what I expect? A low grade suggests that they have done badly, but they have done well, and a high grade means they have done well, but they actually misunderstand important concepts.

I end up giving them low grades because that feels like an honest assessment of where they are. What I really want is to show them how close they are to becoming a frog. Why am I giving them numeric grades despite having told them about amphibian-based grading?

After grading these projects, I always tell the students not to panic about the grades. I point out that in the course grading scheme, this grade will be dropped if they do better on the final project than they do on the short project. Everyone does better on the final project in part because the short project actually works: it shows them their weaknesses. But look at what I have done here: I have crafted a mathematical system, justified pedagogically, so that I can give grades to things. It's true that at the end of the semester, I need to have enough evidence to tell students where they are on the amphibian line. It is a line after all, and so letter grades can be interpolated over it. Yet, while a tadpole is in the pond, it is nonsense to say that it has failed to be a frog.

In my podcast discussion yesterday, my interlocutor described how an integral part of education is helping people develop well-ordered desires. The desire to quantify human formation is disordered. I did not become a professor so that I could make good Canvas experiences. I became a professor to kneel beside the pond and cheer on the tadpoles. 

I write this so that I will remember 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.