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.

An overheard comment about the importance of knowing

Earlier this semester in my game design class, I overheard a student say to another, "If you don't know much, you won't be able to think of something."

He's right, contrary to the philosophy that believes that students don't need to learn facts because they can look them up.

Reflecting on CS215 Game Design, Fall 2022 Edition

I do enjoy teaching my introduction to game design class, and partnering with Minnetrista through the Immersive Learning program is always a treat. I want to capture a few thoughts here before the Fall semester disappears in a haze of planning for Spring.

Three things that went well

I still like following Schreiber's online Game Design Concepts book. Despite its age, which means that it doesn't have examples that resonate with the students nor touch on more modern phenomena like MOBAs, the fundamental ideas in it are good. You also can't beat the price. I have two new books here that I will flip through soon, but I continue to be impressed by how well Schreiber's online massive teaching experiment has held up.

The transition to a larger class size was not as bad as I feared. I love to teach the class in a manner that has everyone putting posters up on the wall for discussion, but there were too many students for that. The exercises had to move to other formats. I don't think it was as good, honestly, but it was also not so bad.

Having students track their time in their final project using labor logging was much smoother this year than last. Regular readers may recall that, last year, I tried to combine design logs and labor logs, and this confused the students at both the logistical and the epistemological level. This year, it was much clearer whether students were putting in the time being asked of them for the final project. As usual, the projects were graded on process rather than product, and putting effort in is an important part of the process (he says, as he writes his blog post rather than working on his side project).

Three things that could be improved

I am sure I have said this before, but I need to find ways to help students better integrate the first half of the semester into the projects of their second half. The final exam asks the students to connect some of the dots, and it's obvious from their answers that they are doing post hoc reasoning: they talk about these final projects using terms from the reading that never came up in their design logs or presentations. Put another way, I think it's fair to say that most of the student projects would be exactly the same with or without the studies from the first half of the semester. I need to get them reflecting about these ideas in a more structured way, perhaps by adding some additional writing or discussion assignments.

Compounding the issue above is an observation that shocked me early this semester: I don't think I've ever had a class with worse reading comprehension skills. The students and I talked about this more than once during the semester, how they did not understand simple reading assignments. This runs into a fundamental problem with being a university professor: it's almost impossible to distinguish between cannot and won't. That is, if they can read for comprehension but are choosing not to, then that is their problem, but if they cannot read for comprehension, then I have a responsibility to them to scaffold this better. Seeing how poor college students' reading skills are, it makes me wonder if I need to design some interventions here. For example, in my draft Spring CS222 course plans, I am requiring students to take notes while reading and then write summaries of those notes; I think the very notion of taking notes while reading is foreign to them, but I am hopeful that this will bear fruit.

Given the confusion around the tasks in the first half of the semester, it's also possible that allowing resubmission would help. Many students got fundamental things wrong around the basic theories, but very few students are motivated to actually correct these misunderstandings, opting instead to charge forward with muck in their eyes. I'd rather not have an exponential increase in the number of things I have to grade, but on the other hand, I also want them to understand these theories so that they can apply them in their own work and in looking at their classmates' work.

Students' Analog vs Video Game Critical Analyses: A matter of experience and vocabulary... or perhaps of pride?

The students in my game design class just finished studying MDA as an analytical lens and then writing critical analyses of games following Schreiber's recommendations. I advised them, for both exercises, to choose small, simple, analog games, cautioning them that contemporary videogames are games-of-games that are hard to analyze this way when you are just getting started. As one might expect, many students disregarded my caution, although I did not know that at the time of our last class meeting. During that meeting, I had them get into small groups to talk about their analyses and then to share some highlights with the whole group. 

One of small groups happened to have two people who analyzed digital games and one who analyzed an analog game. The interesting finding they shared with the group was that it was easier to analyze the video game than the analog game. This surprised me, in part because at the time I didn't realize how many people had failed to take my advice. I pointed out that there were at least two possible interpretations of their experience: one is that there is an inherent difference between video games and analog games in this regard, and the other is that they have less vocabulary for analyzing analog games. Either one is interesting from a scholarly point of view, and even at the time, I hypothesized that the latter was the case. Two students' hands shot up to further this discussion, but we had to move on: we were veering off topic on a day that had already been way out in the weeds.

After having read all of their analyses, I see that there's a third option: that they simply did a bad job. Turns out that this is the case. Almost none of the students who analyzed video games performed anything like a successful analysis, not in the format they were given. They woefully underestimated such aspects as the resources being used, the state of the game, and the way it is played. For example, none of the students who analyzed video games talked about what players actually do, what actions they perform as part of the core game loop. Rather, they painted with broad brushes, saying things like, to fabricate an example, "The player moves Mario to the end of the level." While that is true, it is hardly an analysis. The state issue struck me as particularly interesting since so many of my students are Computer Science majors. I pointed out to them in my comments that the state of the game consists of those data that you would have to save so that you could load the game later. None of them came close to this understanding, many talking about "state" as if it dealt with the screens of the game: you're either choosing a level or playing a level, to continue the example.

When this kind of thing happens, I am left wondering, "What happened?" and "What now?" A majority of students did not follow my advice and then did a substandard job. I hope that they can learn something from this experience. However, what they learn is about hubris rather than about critical analysis, and I would ideally like them to learn both. This particular class does not have a resubmission policy, and I'm wondering if that is a reasonable thing to add. Resbumissions are convenient for the students, but they lead to more work for the professor and, every time I've used them, worse work by the students. That is, a student who knows they can resubmit later can just submit something poorly the first time, which the professor then still has to grade. The ideal thing would be for a student who did badly on the assignment the first time to recognize this as a deficit and then dedicate themselves to learning the content anyway, but alas, our university systems seem set up contrary to endorsing such virtue.

Summer Course Revisions: CS215 Introduction to Game Design

I know what you're thinking. Planning for the Fall already? The trouble is that I was scheduled to teach the new capstone course for the Game Design & Development concentration in the CS department even though this semester will be the first time anyone can actually declare that concentration. We were given orders to try to get students graduating from the new concentrations as soon as possible. Unfortunately, advising didn't push students into this course, and it wasn't in the system when they picked their courses, so that course is critically underenrolled. On paper, I'm still scheduled to teach it, but it will almost certainly be cancelled.

This is relevant because that capstone course was supposed to be the locus for a community-engaged immersive learning project. We always had the back-up plan, though, which was to put that collaboration into the academic year structure I have been using, splitting the project across CS215 Introduction to Game Design and CS490 Software Production Studio. Given the enrollment in that capstone course, I went ahead and "finalized" the plans for an immersive game design class.

The good news is that this is how I have been teaching the course for a while now, and it has been successful overall. I modified the project schedule to include the exercises from Justin Gary's Think Like a Game Designer, which I wrote about earlier this summer (1, 2). I also had to modify the schedule to allow for some of the conference travel I have this semester. I put up the course site today, which has public plans for the first four weeks of the semester. I have the rest planned but have not yet formally published them, waiting until I have a chance to get to know these students a bit.

Because the enrollment in CS215 is a bit higher than I have had in the past, I have moved away from in-class poster presentations. I really like having students present posters, but it doesn't scale to over 15 or so students. I tinkered with the idea of breaking them up into an A and B group and alternating posters and conventional submissions, but this got too awkward. Instead, I'm asking them to put their work on Canvas discussion boards. My plan is to combine small group discussion with random (or intentional) selection of submissions for brief presentation. There are a lot of interesting things that come up during poster presentations, and I am hoping this will still allow those to emerge through the discussions.

Reflecting on CS215 Introduction to Game Design, Fall 2021

This was the first semester that CS215 was officially on the books as "Introduction to Game Design," and I expected a deluge of students. That didn't happen, probably because (1) we didn't get the word out and (2) nobody knew to look for it. Over time, I hope we can fix both of those. It's a good class, and I think students get a lot out of it. 

My relatively small class was part of another immersive learning project, a collaboration with Minnetrista. I was going to link to my course planning blog post, but it seems I never made one last summer. The structure of the course was very much like past ones, and being face-to-face meant we could get back to doing a lot of the in-class exercises I enjoy so much. The students missed out on some of the digital boardgame and print-and-play content that we had to use last year when asynchronous and online, but that's an acceptable cost as far as I am concerned.

The only friction here lay in the students' final project submissions. Before 2020, I had students create prototypes and deliver those to the community partner. This has two problems: the students don't walk away with a copy of the thing they made, and the partner doesn't always really want them but has to take them. In Fall 2020, I had students make print-and-play games instead, and that format worked well in that students could both have their own copy while also sharing the content with anyone who might be interested. With this in mind, we decided to have the students create their prototypes in the print-and-play style. As described above, however, the students didn't have a whole lot of experience with this format, and many underestimated the effort required to go from their handwritten cards to something reasonably printable. I shared my experience using nanDECK, which at least one student used, but many went through a more laborious and nonautomatable process.

A related problem is one I've seen before but seems exacerbated when looking at print-and-play articulations. Many students show little recognition of how rulebooks work. This is likely related to both their unfamiliarity with the hobby but also, relatedly, with their not having to learn games themselves. If someone else is always teaching you games—including folks on YouTube—then you have very little exposure to what it means to express rules. I am not entirely sure if this is a real weakness of the course or not; it's possible that all I need to do here is encourage the students to try writing the rules earlier. The danger then, though, is that inertia will set in and they may not change the things they ought to change.

I had the students keep design logs, as I have done before. Maybe my memory is poor, but I don't remember so many people being confused about them. Very simple things, like the fact that there is one log for the whole project (as opposed to different logs each week) and that they should be in reverse-chronological order, seemed to trip up most students. I admit, though, that I may have been a confounding factor there, since early in the project I was trying to have them submit combinations of design logs and labor logs, and only one student read the instructions and followed them correctly. Now, of course, the instructions were perfect and it was entirely the readers' fault, but one should not ignore an endemic issue. When I separated the labor and design logging process, students still were confused about what each did. The moral of the story here may be that I need to more clearly express exactly what I want as separate deliverables rather than try to kill two birds with one stone.

It may be worth stating that some students didn't really keep design logs at all, not in any real sense. These students also did not have very polished projects, as one might expect. The trouble came in when I asked the students to self-report a summary of their playtesting results, and I saw some students grossly exaggerate the truth here. I hate that feeling of having to write back to a student and say, "I don't think that's true." When the response is silence, at least I am vindicated.

I still have a major struggle in this course in that the students come in with such vastly different games literacy. I had some students get mad at me this semester when I offhandedly mentioned that Uno is not a very good game. I did not expect such a defense! Others based their games off of contemporary designs such as Photosynthesis, and they're just in a completely different place in the hobby. I explained it to one student this way: imagine teaching a creative writing class where some students have only read "See Spot Run" and others have read The Brothers Karamazov.

Overall, I was happy with the projects. I have already had my end-of-semester meeting with Minnetrista where we talked about which projects look most amenable to digital production in next semester's studio course. I am excited about the direction we're planning to take, but to hear more about that, you'll have to come back to the blog another day.