Notes from the Inaugural Game Preproduction Class: Commencing with a More Aggressive Schedule (and something about 4 C's)

One of my tasks for the day was to take my digital notes for CS390 and turn these into activities for the students to do. Up to this point, I had a reading schedule in mind, but my notes about the kinds of activities I might ask students to do outside or inside class were unrefined. I began working on it this morning, but very quickly I came across something troubling in the schedule: my original plan had us reading portions of the textbook and doing supporting exercises up through the end of March, which only left less than a month of dedicated time for teams to pull together a vertical slice, a game design macro, and a schedule. Yikes.

I took this to class today, and we spent half of the day discussing plans for the future. I suggested that we could keep to the original plan, giving the benefit of building a deep understanding of the ideas in the reading while also having the drawback of less time for hands-on work. I proposed that we could flip this around, cramming about 120 pages of reading into very little time, basically just getting used to where things are in the book, and then devote ourselves to our immediate design problems. I also suggested a middle path. That is the way most of the students wanted to go, and so that's what I just updated on the course plan.

The timing of this turned out to be in our favor. The readings naturally clump into themes that correspond to the three deliverables. Hence, our next three meetings will involved focused discussion on the vertical slice, the game design macro, and the schedule, respectively. 

Looking back, I wonder if we could have followed a more aggressive reading schedule from the beginning. I enjoyed a leisurely pace through some of the chapters and the opportunity to explore things like automatic writing, brainstorming, and mind mapping with my students. Some of these were more useful than others, however, and I've already written about how these things didn't help us converge during the ideation phase. Next time I teach the course, I will have to give this careful consideration.

The expectation that I had for the students today was that each team explore what Lemarchand calls the Four C's: Core loop, Character, Camera, and Control. Honestly, I thought this would be a slow pitch for the student teams, but when we got into the discussion, I wished we had the whole 75 minutes for it. Having to express these four concepts got each of the teams to have important discussions, some of which were clearly not quite resolved at the time of the presentations. There wasn't direct disagreement, but there was definitely uncertainty. Also, there were a lot of good comments from the other team members (and me) about some of the decisions and the way they were articulated. I had a hard time expressing to the student when I was giving recommendations about process and when I was giving advice about design, which makes me wonder if I ought to be distinguishing those more clearly. Maybe I'll ask the students what they think about that.

Amari 4 and 5

I enjoy continuing to make amari. I wrote about my three in a series of posts (1, 2, 3), and now I'll share a few notes about numbers 4 and 5.

For my fourth amaro, I used the 20-50-30 AWS ratio that I learned about for number 3. For the ingredients, I pulled together some things that I thought would make for a nice, light, citrusy amaro. This would be a good foil to the intense #3. Here's what I used:

• 2 tsp. juniper berries
• 1/2 tsp. anise seeds
• 1/2 of a stubby long pepper
• 1/2 tsp. decorticated cardamom 
• pinch dried sage
• 1 tsp. dried orange peel
• 1 clove
• 2 allspice berries
• 1/2 tsp. coriander seeds
• 1 tsp. gentian root
• 1/2 tsp. cacao shells
• 1 tsp. dried peppermint
• 1 pinch dried rosemary
• 1 tsp. dried lemongrass

I set these for a week in a 50% alcohol-water solution and then filtered and bottled it. It has a very nice citrus flavor and, like its predecessor, is not too sweet. This concoction really sold me on that 20-50-30 AWS ratio. This amaro is good as a digestif, but my favorite thing to do is to use it in an old fashioned cocktail: 1-1/2 oz bourbon, 1/2 oz amaro, a touch of orange syrup, served on the rocks. I dubbed this batch "Amaronge you glad I didn't say 'banana'?"

Incidentally, that orange syrup was the result of an attempt to make an elevated syrup. I packed orange peels in sugar to extract the flavorful oils like in a video a friend sent me. I think the video exaggerated the effect, but my results were still good. After letting the peels macerate with the sugar for a day or two, I ended up just rinsing the container with some water and then heating it until it became an excellent orange syrup. The peels would have gone in the compost anyway, so this was a worthwhile.

Speaking of saving things from the compost, let's talk about my fifth batch. I bought myself a bunch of new amaro ingredients for my birthday. When they arrived earlier this month, I now had what I needed to replicate the Open Source Liqueurs Base Amaro recipe. My first step was to save some grapefruit rinds from ending up in the compost and remove the zest from the pith. The recipe calls for three grams of grapefruit peel... but is that fresh or dried? All the zest I could salvage still did not register as a gram on my kitchen scale. I had no fresh oranges, and so for reference, I measured three grams of dried bitter orange peel:

How is one to compare amount by volume of fresh zest and dried peel? It's not at all clear to me, but these two look approximately the same. I marked in my notes that three grams of bitter orange peel was about 1-1/2 teaspoons. 

The Open Source Liqueurs recipes are by weight, which is a good and proper way for fancy people to cook, but my scale is clearly not up to the task. Hence, I measured where I could, substituted where necessary, and winged it as inspired. Mine ended up like this:

• Some fresh grapefruit zest
• 3g bitter orange peel
• 10g Turkish rhubarb root
• 6g gentian
• 1 tsp hyssop (which still didn't measure as a gram on my scale so maybe that's close to 0.5 g?)
• 1 tsp dried peppermint (no spearmint available)
• a little broken stick of cinnamon (weighing under one gram)
• 1 tsp whole dry rosemary (again, under one gram)
• about a teaspoon of myrrh granules
• 1/2 tsp. decorticated cardamom
• 1 clove
• a generous pinch of dried sage

Here's how it looked once everything was mixed together.

That's a nice light amber color. After a week, it was much more intense:

The lighting here makes the maceration jar look dark brown, but there was also a slight purple hue when held to the light. It was really beautiful, and that got me excited when I gave the jar its periodic swirl.

Here's how it looks in the glass after sweetening with demerara sugar syrup, which also brought it to the proper AWS ratio.

It's good, but it is very grapefruit-forward. If you feel like grapefruit, this is your thing, but if not, then it's not quite right. I've tried it in some cocktails, but grapefruit and orange are just not the same. I'd like to try a riff on this recipe some time later with either less grapefruit, less grapefruit maceration time, or increased fresh orange zest, or some combination of those.

Because this one is really a spin on the Open Source Liqueur's recipe, I've named batch #5 as "OSL v1.0."

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. 

The sound of the 1980s

I wrote this little reflection for The Facebook this morning. I'm copying it here in case I ever needed to find it again. It's not likely, but hey, one never knows.

Do you have a moment to talk about Kajagoogoo?

I enjoy playing bass guitar from time to time, though I'm not as good at it as I'd like to be. Sometimes I watch bass-related videos on YouTube, which of course means that YouTube tries to give me more bass-related videos. Last week, I watched one about Nick Beggs, bass player for the band Kajagoogoo.

I had never heard of Kajagoogoo before. Keep in mind that in the actual 1980s, I really only listened to Weird Al. I recognized the catchy pop song being discussed in the video, though. "Too Shy." Sing along with me: You're too shy shy, hush-hush, eye-to-eye. That's the one.

Unexpected to me was that this song has an absolutely killer bassline. It's wildly complicated, deploying a host of techniques that are beyond my skill. Listening to the song again with the ears of a bass guitarist, I was blown away. This inspired me to put on a Kajagoogoo album while cleaning up the kitchen the other day.

Now, we have to turn to the other important part of the story: I love bad 1980s movies. Give me MST3K or Rifftrax and a movie like Miami Connection or Pumaman, and I'm a happy camper. Part of what makes these movies so iconic is the sound of them: they sound like the 1980s.

Putting on Kajagoogoo's second album while cleaning up the kitchen made me feel like I was in one of these bad movies. I had never heard any of the songs before, but each was poppy and catchy and could have been used in the Mac and Me soundtrack. Turns out, there's a good reason for this: the lead singer from Kajagoogoo sang "The Neverending Story." That basically *is* the sound of the 1980s. Well, that and the screaming of "Atreyu!" and "Falcor!" but that just goes to show why my generation is the way we are.