Notes from Spring 2026 CS390 "Final Exam" meeting

Back in April, I mentioned that the "final exam" for my game preproduction class was primarily a discussion. Cleaning up my office, I found my voluminous notes from that meeting. The four questions I asked of the students were, in order, the following:

1. What do you think is missing from your preproduction work?
2. What is something you know now about preproduction that was unclear before?
3. What advice would you give yourself or to someone starting preproduction?
4. What questions do you have?

One of the major themes in my notes is that the students recognized, maybe only in retrospect, that they had lost sight of the players. They were building things they wanted to build but not conceptualizing the player experience. Curiously, a student pointed to the final presentation as the first time he recognized and understood the omission. One of the students made a clever suggestion: early in the semester, when experimenting with different constraints around ideation and prototyping, I should challenge the students to make something for someone else. 

Another theme was how challenging it was for them to understand and articulate design goals. After having struggled to maintain a vision and a direction, they came to understand why these are necessary, and all wished they had spent more time agreeing on such goals at the start of the project.

When it comes to the second question, the students came to much better understand the role of playtesting, what it means to answer questions with prototypes, the dangers of analysis paralysis, and the importance of planning in order to understand scope. 

These are my notes about the advice that they would give to new students. I am leaving out a few that were very specific to this group or repetitive. I don't know yet if I will share these verbatim with my next cohort, but I also didn't want to lose them.

• Think of game design as gift-giving, not as tinkering
• Fast prototypes to articulate ideas are good
• Don't spend too long trying to solve a problem
• Take prototyping and playtesting seriously—don't make something just to have it
• Set deadlines, use a calendar
• Write game ideas down
• Take feedback and write it down
• Prototype instead of just thinking it will be fun
• Mess it up
• Don't be afraid to fail
• Learn your scope (explore, but know strengths) and know when to move on

Some ways to get a McGuffin from the Goblin King

Cleaning my office this morning, I came across some design notes that struck me as too interesting to throw directly into the recycling bin. I don't quite remember the context, but I must have been thinking about Apocalypse World style "moves" (in-game action types) and generative storytelling. It's probably from when I first learned about Viv, which I still have yet to play with. The paper itself contains a list of the moves that will be included in the third edition of Apocalypse World, a few notes about what it would mean to randomize locations and their denizens, and then an exploration of the different ways one could get a McGuffin from a Goblin King. These are what I came up with as possible stories:

• Find him, kill him, take it
• Find him, convince him to give it to you
• Find him, steal it, escape
• Find someone else, convince them to steal it
• Find him, threaten him, he attacks (jump to another case)
• Find him, threaten him, he gives it
• Find him, beat him up, demand he gives it, get it
• Find him, offer something else in trade, trade for it
• Find him, observe him for leverage, deploy leverage as part of demand, receive it

There are certainly more, and clearly, some of these weave into each other. For example, convincing someone else to do it for you still requires that that character end up having to go through some other matrix of options.

Reading these simple statements starts stories forming in my mind. Each is a seed that could grow into something compelling, but they could also turn into something rather dull. Paying someone else to go questing is economically efficient but narratively unfulfilling.

It stands in contrast to my current project, which involves writing a lot of interactive fiction. This current work requires me to be very careful about branching since each alternative increases production costs. I am playing with the idea that you are a particular character, and so I do not feel like I have to expose all possible options to the player--only those that are reasonable to the character's situation and demeanor. 

I do hope to get back to exploring the kinds of narrative systems analysis that the McGuffin Acquisition represents, but in the mean time, I am finding more traditional gamebook-style interactive fiction to be a rewarding creative experience.

Now I can recycle this paper and get back to cleaning.