Reflecting on the Fall 2017 CS315 Game Programming Class

Several times during the semester, I have wanted to share thoughts about my game programming course here, but time and other obligations have gotten the best of me. Now that the semester is wrapping up, I am making the time to focus on the last few weeks of the course and the roller-coaster of emotion it has been for me.

Background

To set up the story, it had been two or three years since I was able to teach my game programming course (CS315), and I revised the course design over the summer to center on Unreal Engine 4 and my Collaboration Station project. The students started the semester with a two-week project designed to get them into the UE4 basics. The project was called Angry Whatevers, and students had to create a simple playable game that involved physics and parabolic motion. I started a new playlist on YouTube to support the class during this period, starting with this pair of videos that give an appropriate framework using UE4's 3D primitives and Paper2D sprite system, respectively:

Because I was recording these videos on Windows, I had to learn a new video production pipeline as well. My first attempt used OBS Studio for the screen capture and OpenShot for video editing, in part since OpenShot is what I've been using on Linux for some time. I realized after posting the first edit of the first video that there were significant editing glitches. When I brought this up in class, the students expressed disdain at OpenShot and strongly encouraged that I learn Blender. I didn't even know that Blender had video editing support! It took some time to learn Blender's video editing system, but I ended up becoming fairly productive at doing simple editing with it.

In any case, all the students who did not withdraw from the class did fine in their Angry Whatevers project. Several students withdrew during this period, but none talked to me about their experience, so I have nothing but conjecture about causality here. We had a class meeting after Angry Whatevers during which I gave them the option to either move forward with another tutorial-style assignment or to move into forming teams for a bigger final project. They chose the latter. I prepared and delivered a presentation about Collaboration Station, showing the three minigames that I had not yet implemented, and I encouraged students to choose one of these as their semester project; however, I also gave them the freedom to propose something different, with the cautionary explanation that game design is hard. As you can probably predict, dear reader, all of the teams decided to pursue their own projects.

I had the teams write their pitches in Tim Ryan's game concept format, which I had to approve before they could move forward, and they organized their work as user stories expressed in Trello. More specifically, they used the "front" of each Trello card for the name of a user story in Mike Cohn's format, and they used the "back" to track the conditions of satisfaction, hour estimate, and team member assignment. My intention was to monitor teams' progress via their changes on Trello, but I quickly had to drop this plan as out of scope: I was overwhelmed this semester with the number of different projects I was supervising, and I could not afford this level of oversight. I was surprised when, after the first iteration, the students elected to continue using Trello the way I required for the first iteration. They found value in it, and so they required themselves to show their progress via Trello at each end-of-iteration presentation.

I'll note here that toward the end of the second iteration, the students expressed interest in learning more about the C++ side of UE4. Some students had thought about shifting some of their existing work from Blueprints to C++, but they were unsure how to dig in. I recorded a series of five videos that walked through an example designed for students with no C++ experience, although these were not ready until we were into the third iteration. No students ended up using C++, and avoiding such a thing in their third iteration is wise. However, looking at the video series, the first video has 49 views, the second has only 28, the third has 13, the fourth has 37, and the fifth has 29. If you can make any sense out of that, let me know. For the time being, I interpret that as meaning that students by and large didn't watch the series for their own edification. It took roughly 10 hours to make that video series, so hopefully I can recoup the investment either in a future class or in the long tail of YouTube.

The tumultuous end of the third iteration

I know that was a heck of a wind-up, but now we can get into the story of the last few weeks. At the end of the first iteration, I was pretty lenient in what I considered "satisfactory" since the teams were still really getting their feet wet with UE4. The second iteration, some teams did not have working core gameplay, and so I told them the work was unsatisfactory. What surprised me was that at the end of the third iteration, a majority of the projects had fundamental problems such as broken core gameplay, no audio or visual feedback, or no attention paid to user experience. This made me go look at their version control logs, and these pointed to the idea that many had simply not put in adequate effort. Before grading these final iterations, I went back to check the course description to see how specifically I had defined "satisfactory." To my great embarrassment, I didn't. I honestly remembered having written it up, but either I wrote it somewhere else and misplaced it, or I simply thought about it and never typed it up. In the absence of a rubric, the best I could do was fall back on the clear dictum: "Note that, because this is a three credit-hour course, you should expect to invest nine hours of attention to it per week." Clearly, some teams did not do this, with gaps of 15-19 days between commits.

There's another important piece to understanding my emotional reaction to the third iteration. The teams' presentations were split over two 75-minute class periods, with the day of a team's presentation being essentially random. It turns out that the Tuesday group was the disheartening one: no team presented something that I would call, in any way, "done." This led to an interesting conversation on Slack with a few students who were willing to speak up, though. I expressed my distress that they had not produced shippable games, but some students said that they never wanted to finish a project in the first place—they really just wanted to tinker around. That's interesting for several reasons, one being that they clearly didn't understand what I had tried to teach them about Scrum, but the other is that they claim to have had a fundamentally different perspective of the course goals all along. One student put it very clearly that he thought he was "learning game programming in order to learn Unreal Engine," which is vastly different from my intention, which was for them to learn Unreal Engine in order to do game programming. Students in the former category would probably have been disappointed at my lack of didactic lectures about specific UE4 features, whereas students in the latter category would appreciate the seminar-style of individual exploration and sharing of lessons learned.

After these conversations came the Thursday group, where two groups really nailed it, showing off games that were truly shippable. In their presentations, they shared specific and interesting tech tips in such a way that everyone in the room learned something. (We called this requirement the Feature Focus™). I thought about going back to Slack to try to understand how people in the other teams felt about the excellent Thursday presentations, but I did not. I did not want to come across as crass or petty, although I do really want to know what they thought, as I try to understand their perspective—or what they claim their perspective is, anyway.

This isn't even my finals form

When we wrapped up the second iteration, I gave the students the option of either working on their final project through to the end of the semester or to end a week early and do a different final assessment. The result of our discussion was that the students wanted to be able to choose either a traditional written final exam or a "jam" final. I had used the jam format back in 2011, and they seemed to like the idea when I told them about it.

I tried to make the two equitable, each designed to take four to six hours. I designed the jam format first, using my university's recently-announced new branding campaign, "We Fly," which appears to be beloved of upper administration and generally denounced by students. I put the following constraints and requirements on their submission to this final format:

• Playable game implemented in Unreal Engine 4.17 or 4.18
• Implemented by an individual student in CS315
• The creators of any third-party assets are credited and licenses identified as per licensing requirements
• Player input is managed through project settings
• Core gameplay includes interaction of multiple actors in a level
• Dynamic game state is tracked in the user interface (e.g. score or health trackers)
• Clear goal and ending conditions
• Include music and/or sound effects
• Captures an interpretation of the theme

A casual observer will notice that these include some of the specific features whose absence surprised me in the third iteration.

The students presented their submissions during our university-assigned final exam slot, and I was delighted at the quality of their work. Students whose technical contributions and understanding were unclear to me showed that they had minimum expected competence with UE4, and students who had really pushed themselves showed some impressive jam-quality work. It was fun to see how many students poked gentle fun at the university's marketing efforts, with several games involving the destruction of money, amassing money, or throwing money into bottomless pits in order to create new slogans.

Seven students opted for the written final format, which consisted of three questions. The first had students research and report on binary space partitioning and its role in BSP brushes; we did not address this in class, and so I figured this would be a good assessment of their ability to explore new topics related to game programming. The second question involved deconstructing a classic arcade game and discussing how it would be implemented in UE4, along with a project management plan such as a Scrum product backlog. The third was a post-mortem of their team project in classic GDMag format.

Their responses to the first question were a mixed bag, the biggest problem being that some did not distinguish between BSP and UE4's BSP brushes. In a sense, the assessment "worked" because I was able to see their confusion.

The problems with the second question were more interesting. Some students showed significant trouble analyzing the game to determine its formal components and then arranging those into a series of steps. In retrospect, I had not given them much feedback on the project management portion of the class, and I know from experience with immersive learning teams that this is hard enough just by itself. Similarly, these students generally had no experience with game design, and so they lacked some vocabulary and mental models for how to separate a player experience from formal components. This part of the question may have been "unfair" in that it wasn't something I had really emphasized throughout the semester. There was also variance in the second part of the question, where some students waved their hands and talked about implementation in broad strokes, where others were more specific about what was actors, what was pawns, who should have what responsibilities, etc. I think if I were to give this type of exercise again, I would have to include more a specific description of what a correct answer would contain, since it was hard to distinguish whether students thought their submissions were adequate or whether they were writing and hoping for points (a phenomenon any instructor is familiar with). In the end, however, everyone that did anything reasonable on the written format got a satisfactory mark, so it's not worth fretting the details at this point.

Students' Review of the Course

At the end of our finals week meeting, I ran a quick semester retrospective with the students. I wrote four columns on the board: + (for positives), - (for negatives), Δ (for things to change), and ? (for lingering questions). I encouraged students to speak up and share their thoughts, and I logged them onto the board without commentary except occasionally to ask for clarification. I then asked if there was anything on the board that anyone strongly disagreed with, and the only point of contention was that some people seemed to dislike Blueprints, while others thought they were valuable. Finally, I went through each item and asked for a show of hands to get a sense of whether it was a majority issue or a minority issue. I've transcribed the list below, marking majority issues with a capital M and minority issues with a lower-case m; the one item without a marking was instead discussed as being a mix of positive and negative.

Positive:

• Two-week intro (M)
• Choice of project (M)
• Open-endedness (M)
• Working off of the same basis for the two-week project (M)
• Video tutorials for the two-week project (M)
• Showcases at the end of iteration and the final (M)
• Feature Focus™ (M)
• Slack (M)

Negative:

• Ambiguous grading scale (M)
• GitHub
• Infrequent use of Slack (m)

Change:

• More smaller projects (M)
• Require participation in game jams (M)
• More emphasis on scoping and estimating projects (m)
• Host more class-based jams like the final (as opposed to external jams) (M)
• Use "jam" format for intro weeks (m)
• More C++ (m)
• Smaller projects with specific technology learning outcomes (M)
• More videos on specific Blueprint features (e.g. variables, conditionals) (M)
• Encouraging more student-presentations on UE4 technology (M)
• Theme the entire class, in part to help control scope (m)
• Encourage use of Slack (M)
• Less distribution of course content between Canvas and the course site (m)

Questions:

• I may have learned more from the final jam than from the big project (M)
• More jams? (M)
• Would having more jams  early in the semester positively influence the formation of final project teams, their preparation, their estimation? (m)
• Blueprints vs conventional text-based code (esp. for things like data structures) (m)
• Production pipeline, e.g. working between technical artists and gameplay programmers (m)
• Canvas is better than Blackboard but Canvas is less than ideal (M)

The student who brought up that first item in the questions, he spoke for a few minutes about how the scale of the final project contributed to his putting off working on it. By contrast, he said, the final jam had a very tight timeline and very clear requirements, and so he knew he had to dive right into it. He did not address whether or not he could have done the final jam without having worked on the major project.

At the end of this discussion, I shared with them something that had been heavily on my mind the past two weeks or so. Many of them had experienced problems or complained about the challenges of their final project with respect to scope, estimation, and creative direction. I looked across the room and I asked them to think back to when we were first planning the final projects, and specifically, how I had laid out for them three minigames from Collaboration Station that were already designed and were perfectly scoped for their work during the semester, and how I had warned them that going in a different direction was not advisable for reasons of design and scope. Ah, I wish I could have captured the flood of emotions that I could see on their faces! At first, a moment of shock and surprise, and then a look of understanding, and then nervous laughter as all the pieces came together. When I followed this with, "I don't want to be an 'I-told-you-so...'" they really let loose and had a good laugh. It's true, though, and I told them that I hoped that this was a good lesson for them in understanding how complex this area of study really is. I think we were all able to leave with high spirits despite having been a bit in the doldrums a week earlier.

Jam in the place where you work

Clearly, the idea of "jams" came up quite a bit in our semester retrospective, I'm sure in part because they had just had a generally positive experience working on the final exam jam. As I got to thinking about it, though, I still had some questions about what they were really talking about. A single-person effort isn't really a "jam": the term comes from musicians' jam sessions. The metaphor is also just a sort of fun wrapper around an academic assignment, and isn't it strange that students would say, effectively, "give us more assignments!" Maybe not so strange, given the one student's comment about learning more from the short experience rather than the longer one. In any case, I turned back to the class' Slack and posed the problem back to them. I articulated what I thought were the five characteristics of the jam format, and asked them to thumb-up the ones that they thought were most important or essential. Here's where the votes have stabilized:

• Individual completion (1)
• Themed (6)
• Timeboxed at no more than one week (4)
• General guidelines of satisfactory completion, as in the final exam jam format (9)
• Presented in class (0)

I am a little perplexed at the zero votes on the bottom one, given some of the other results of the retrospective, but that one was also last in the list just before a block of text, so maybe people missed it.

What stands out to me is that the things they most wanted were the guidelines, which are really standard fare, and their omission from the final project was an oversight on my part. I've been thinking more about specifications grading and how that might be useful for a class like this. My colleague David Largent has been using specs grading in his classes and has started giving some regional presentations about his efforts. I could see criteria for a future iteration of the course looking something like this:

• D: I can run the game without crashing.
• C: The core gameplay is functional and gameplay state is tracked on-screen
• B: The game includes audio and visual feedback for core gameplay
• A: The game can be packaged and launched 

That's just a sketch, but I think you get the idea. I can set up the hurdles that teams have to cross more explicitly to get the grade they want. Of course, this opens up a problem I had this semester and alluded to above: I had a student come to my office upset with his grade, and I told him the core gameplay didn't work. He asked, "What's the core gameplay?" I would have to be careful in the specifications and future course design to qualify any game design terminology, since clearly not everyone will be familiar with it, even if they are hobbyist gamers.

Wrapping up

The coarse-grained grading scheme that I adopted turned out working OK, although not without its own struggles. When students mentioned "ambiguous grading scheme," I assumed they meant that I had not rigorously defined "satisfactory," but judging from some of the questions I've received the last few days, it's possible they were confused by the variable MacGuffin system. This is another area where I wish I knew what the students actually were referencing, but I'm afraid that moment has passed. It's possible each student meant something different, but they generally didn't like ambiguity, so may as well vote for that one. However, looking at the grades on my spreadsheet, I think they lined up to fairly represent my intuitive understanding of what students learned during the semester.

There were also opportunities for achievements that I didn't think of until it was too late. Regular readers know that I enjoy painting miniatures, and the last few weeks I decided to listen to a few GDC lectures on YouTube while painting. I realized, in retrospect, that I should have had an achievement for students to do the same. The 2016 Tech Toolbox, for example, would have been a great item for students to study and respond to. The way that I had articulated the Connected achievement gave preference to in-person meetings, but there is such a valuable repository of knowledge distributed on the Internet, I could have used the course as a chance to get students connected to that as well.

That about wraps it up for CS315 in Fall 2017. Word on the street is that we may be able to go back to offering this every Fall, now that we have had some successful faculty searches. I would like to get it back on a regular rotation and hone the structure of it the way that I have CS222. This semester felt a bit choppy, but I had some very talented students who were willing to talk with me honestly about it, and I'm grateful for that.

Thanks for reading!

Troubles articulating questions for the Serious Game Design final exam

I am having some trouble articulating a particular question (or family of questions) for Serious Game Design final exam. When having trouble thinking about something, it helps to write about it, so here goes.

Regular readers may recall that I am teaching a Serious Game Design course as an Honors Colloquium this semester. My students are prototyping educational games as part of a larger immersive learning project with Minnetrista, a local cultural center and museum. Over the summer, I wrote about a structural change in the course: my hope was that by investing more time into readings and activities early in the semester, my students would create better prototypes by the end of the semester. We spent from August 24 through October 5 engaged in a series of readings and exercises, which you can read about on the course schedule if you wish. October 12 through 24 was spent on a series of concept documents and project pitches as students figured out what kind of game they wanted to create, and then October 26 through November 30 was spent on production. Next week, they present their projects to our community partner, and after that, it's finals week.

During the production period, students gave a series of in-class status reports, during which they had to comment upon what design challenge they were working on, what kind of evaluation they conducted, what evidence they gathered, and what conclusions they drew from this. These requirements were not treated rigorously, neither by my assessments nor by the students; I see this now in retrospect, that I would wager students couldn't even tell you what the status reports were supposed to be about. I will need to consider more rigorous assessment of this in the future perhaps.

Be that as it may, I noticed about two weeks into these status reports that up to that point, students had made no reference to any activity from the first half of the course. What triggered this observation was when a student explicitly tied their game to a visitor classification taxonomy that our partner shared with them. In particular, she acknowledged that her game was for the "rechargers" who came to Minnetrista's grounds to mentally, emotionally, or spiritually recharge. Her observation caused me to reflect on how no one else had done this, and then by extension, that no one had framed their work within any of the formal or theoretic models we had studied. Going back even to their various concept documents, there is no mention of the work from the first half of the semester. Crucially to this discussion, it was not required to do so. I mentioned the lack of explicit theoretic grounding to them this past week, when we had a minute or two before class was dismissed, as something that had been on my mind. They nodded in acknowledgement but their minds were clearly on their way to their next obligation.

The fundamental question I have is Why? It's a question I have for myself, but it's a question I want them to wrestle with. I took my first pass at articulating this as the last part of their final exam, which I was working on this morning:

Consider the discussions we have been having in class during the pitch and production period (October 17 through November 30) along with the essays you have written above. My notes suggest that during the second half of the semester, there were essentially zero student-generated references to the theories we studied in the first half of the class. Write an essay addressing the question, Why is that? To address this, you might consider corresponding questions such as Could it have been otherwise? or What are the relative merits of personal opinion vs. theory?, although there are certainly other directions one could take a thoughtful discussion.

The prompt above is the result of considerable revision, but I am still not entirely happy with it. As I explained it to my wife over lunch, there's another side to it that perhaps is even more difficult. Given that the students did not justify their designs using the theories we studied, and that they did not reference these theories in the feedback they gave each other, I have to ask the question: if they had not spent the first half of the semester grounding themselves in theory, would they have still made the same product at the end? There's another, potentially less charitable way to put it: did they actually learn anything during that first half of the semester?

There's a sense in which these are research questions: I could, in theory, teach a pair of courses that are structurally identical except for the entire first half, and see if the resulting games—and discussion around those games—shows any qualitative difference.  That would be interesting, but I lack the resources to pull off such a thing. A related study would be to take two courses that are structural identical except that in one of them, I require students to contextualize their work in theory, for example in each status report.

Those questions are more about me and my scholarly interests: I see the inherent problem for the final exam as being something that students should grapple with. What does it mean for them that they did not reference any of the theories we discussed? Do they believe they learned? Maybe more pointedly, did they not ground their work in theory on purpose or on accident? That is, were they lazy by choice or did they not even consider the idea that those earlier concepts should be referenced? And if the latter then, by extension, we're back to: Why?

Collecting my thoughts here hasn't exactly cleared up the issue in my mind, but at least I have my thoughts all in one place for future reference. Once we get through the final presentations next week, I will have some time to more carefully consider the matter and come back to the questions on the final exam.

A footnote of sorts: One may think, "Aren't you concerned that you are writing your final exam questions online in public prior to them being assigned?" The truth is, if any of my students are following my writings on games in learning, I think they are far enough ahead of the game that it wouldn't matter, since they'd have seen this question coming a mile away!

If you have any suggestions on how to frame the question, feel free to share them in the comments. Thanks for reading!

A Design Thinking Exercise and the Stories of Redirected Edges

I've written occasionally about how I use an adaptation of George Kembel's design thinking framework in my teaching and research. Back in April 2016, I gave an overview of how I use it in CS222; today, I will give a few more details, since I saw something new happen this semester that I haven't seen before.

A Design Thinking Framework

I introduce this design thinking framework during the third iteration of the CS222 final project. I tell my students about how I use it and how my teams have used it, usually by leaning on the story of my VBC seminar—a story that is repeated in my Meaningful Play 2012 paper. The short version of that story is that, even though that team knew this reference model ahead of time, they fell into an Ideate-Build-Test loop that brought them further and further away from the community partner's needs and an understanding of the audience. It wasn't until an outside force pushed on them that they were able to recognize the problem and realign themselves.

The CS222 exercise has each team start by drawing the model on the whiteboard, and I challenge them to trace their paths through the different phases, starting with what initiated their project pitch. I encourage them to annotate each arc with evidence, noting how they know that they shifted between phases. I have to be careful to tell them that no path is wrong, especially since they didn't have this model ahead of time; rather, we are using this reference model to describe different kinds of activities and consider the transition between them.

After fifteen or twenty minutes of working at the whiteboard, a student team might come up with something like this:

The above diagram is from a team who decided to create an Android project, and they did not know what kind of challenges they would face by having to learn a new platform. It's not uncommon for these teams to have no activity in the Empathy area: it wasn't required, and teams usually jump in with Ideate. After all, my CS222 class is the first place in the curriculum where I empower them to make what they want, since I'm evaluating the processes they follow rather than looking for a specific implementation detail.

Some of the teams take a bit more care in laying out and labeling the diagram, producing something like this:

This happens to come from a team that is building a tool to assist students in scheduling classes. Again, it's not so much the content of these figures that's important, but the form. Once everyone has completed their diagrams, we go around the room and ask for an overview of the process. This usually leads to some interesting discussions, for example about the role of empathy, or the difference between identifying problems and coming up with solutions.

On Tuesday, I noticed something on the board that I didn't remember seeing before. Check out this diagram from a team that is creating a Dungeons & Dragons character generator:

In particular, look at the arc coming out of Ideate and how it heads toward Build and then spins back around to Identify. I asked the team about this to make sure I was reading it right, and they confirmed: after coming up with ideas, they were prepared build a model... but then they realized that they weren't really sure what problem they were solving. In pure graph-theoretic terms, it's just a directed edge from Ideate to Identify, but it's clearly so much more than that: the team felt a force on them, they felt a shift, and they pushed themselves purposefully in a particular direction. I am not sure what to label this phenomenon. I thought about "storytelling arcs" but that sounds like three-act structure, and I thought about "narrative arcs" but that's even worse. I'll call it a "redirected edge" for now.

I talked to this team as they were working on the diagram, and a few minutes later, we had the class presentations. The first team to present is working on a tool that aggregates online information for people who are moving to a new city, and their diagram looked like this:

Look at the black arc from Identify to Build: it's another redirected edge! In this case, the team identified the problems that they would like to solve and had planned on using the Zillow API. When they sat down to start building experimental code, it was only then that they realized the API would not work, and so they bounced over to Ideate to come up with new potential solutions to their problems. Now, one might argue that they had in fact been in the Build state, or that they were not really coming from the Identify phase because they had ideas of how to solve the problems, but that's not relevant here.

I'm not so interested with how well the students understood the design thinking framework after a thirty-minute introduction, but rather with how they are using the diagrams to build a visual narrative of key events in their project. The rest of the arcs in all the diagrams I have shared are drawn in a pragmatic way, with some care toward making the lines clear and reducing edge crossings. These redirected edges are different: they are capturing a feeling the teams had. In the case of the D&D team, they had a feeling of moving in one way and then being pulled in a different one. In the case of the Moving Cities team, they felt like they "bounced" off of one phase and landed in another.

I am not entirely sure what all this means, but it strikes me as interesting. I don't remember having seen it before, and the fact that I saw it twice on Tuesday struck me. If nothing else, I want to keep my eyes open to this kind of phenomenon, where the team is breaking out of the genre norm to express something meaningful to the team. Maybe there's even something there that could be used as a seed of a team retrospective meeting. The diagrams reminds me in some ways of when I used to use mind maps in CS222, that most of them would be somewhat perfunctory but occasionally I would see one that told pieces of a coherent story. I have since cut that exercise primarily for time's sake, although I think about bringing it back in.

Thanks for reading, and if you're reading this on the day it was published or its anniversary, Happy Thanksgiving!

Painting Massive Darkness: Base Set Heroes

Let's talk about priming. I'm coming up on the four year anniversary of my return to the miniature painting hobby, and regular readers may remember that I just don't like rattle can priming. I've gotten past the early hurdles to a point where I can do it with confidence, but it still seems awfully fiddly. The narrow temperature and humidity requirements mean that I cannot always spray prime when I would like to. Of course, the smell is terrible, too. I've had some success brushing on Vallejo Surface Primer, as recommended by Brant "Ghool" Benoit. This approach has some benefits, including the sort of pre-painting meditation that gets me familiar with the model. It takes quite a bit of time compared to spray priming, and occasionally I have had problems of—for lack of a better word—hydrophobia on the primer layer. I talked to Benoit about this, who acknowledged it as a problem of the technique that is overcome by using relatively thick base coats.

Lately I have been intrigued by the potential of zenithal priming, wherein a model is primed in black, then in grey from roughly 45 degrees, and then in white from above. The result is a sort of brightness map, showing where highlights and shadows lay. Like so many of the techniques I have tried, it was watching Sorastro's videos that really pushed me to explore this idea. Zenithal priming can be done with rattle cans or an airbrush. We're heading into winter here, which means I'm out of rattle can season. Also, after a bit of a stressful run at work—some of the stressors of which have clearly eaten into my blogging time!—I ran a successful event and received some other good news. I decided to take the plunge and buy myself an airbrush set-up. Another inspiration for the airbrush is that my two older boys and I have been having a surprising amount of fun with Massive Darkness. There are way too many miniatures from the Kickstarter for me to even consider paint-to-play, but the fun we've been having means it merits some beautification.

Step one was cleaning my hobby table, which was long overdue. I needed to make room for the portable booth that I bought, the same type Dr. Faust reviewed. It does indeed collapse down into a tight package. However, that doesn't take into account the huge and awkward exhaust duct. Also, it's much louder than I expected, so loud as to drown out any reasonably-volumed music or podcasts. However, it has great suction. The first time I used it was during the day, and the natural light combined with my desk lamp were perfectly adequate for lighting; the second time was at night, and if I could go back, I would pay a little more for the model with embedded LED lighting.

I did a fair bit of research, and it seems to me that there are two philosophies about the airbrushes and compressors themselves: either you should buy a nice one from the get-go to avoid the problems associated with cheap airbrushes, or you should just buy a cheap airbrush because it will be fine. I am primarily [pun intended] interested in priming and varnishing, although I hope to expand to some other techniques once I learn the basics, especially for some of these enormous Massive Darkness monsters. I ended up buying a cheap Master G22 airbrush that came with a small tankless compressor.

Once I got all my materials, including the cleaning pot shown in the photo, I eagerly set to, and I got about a minute's worth of puffing air before the whole thing stopped. I referenced this particularly useful customer comment on Amazon to ensure I had set up everything correctly, and although I had indeed forgotten that the pressure gauge would only be accurate while spraying, this didn't explain why my airflow had stopped. I kept my chin up and started searching the Web. After some time, I found this crystal-clear video about how to disassemble and reassemble a Master G22. There was a minor difference between his and mine, but this gave me the confidence to follow along. Unfortunately, even after lubing up the moving parts with some sewing machine oil, I wasn't getting more than about two seconds of air before it stopped again. There was a part of the airbrush that the video didn't cover: the assembly where the hose meets the brush. This required getting pliers to loosen up, but it led me to the discovery that my valve was a bit wonky: there's a pin that opens the valve, and mine was getting stuck. After manually fiddling with the pin and reassembling twice, the problem went away. I don't know if maybe some of the lube worked its way in there, or if it just needed to be jostled into alignment, but I was grateful to get regular airflow.

I decided to start with the six base set heroes from Massive Darkness, and here's the result of the zenithal priming:

Six heroes, zenithally primed

I remember when I finished them worrying that there was still too much black showing, but looking back at the photographs, I don't feel that way. This approach really does help show the model's details better than priming entirely in white or black. I have read about a "speed painting" approach where you put thinned paints directly over the primer, and I may try this with some of the dozens of Massive Darkness minions; however, the heroes deserved a little more careful attention. Without further ado, here are the finished results in the order I painted them.

I decided to start with Bjorn, which has a great variety of textures and details but without having an overwhelming number of fiddly details. Also, he looks like Conan, which seems like a powerful way to start. I took several work-in-progress photos as I tried to sort out the effect of various techniques. For all of these figures, I followed the color scheme on the card art where possible. The flesh was painted in a solid base color, a mix of VMC Medium Fleshtone along with some Buff and Ivory. I used the same mix on Siegfried. Here's an early WIP:

Barbarians receive two or three layers of base color on the flesh

Even with just a few layers of a thinned base color, the zenithal priming doesn't seem to make a dramatic difference. The difference diminished as I worked with it, adding a wash and layered highlights. However, it did provide an excellent surface on which to work, in two ways: it was a smooth surface that accepted paint well, combating the hydrophobic effect I've had brushing on the same primer, and it was very clear where the model's features were and highlights should be.

Here's Bjorn after finishing the flesh, hair, and some leather bits, with the solid base color for his green skirt in place:

Bjorn WIP

I finished up the skirt with wash and layered highlights, leading up to this potentially-finished version:

Bjorn, unaware that he's a work-in-progress

As I continued to work on him, I started thinking about another technique I've been watching Sorastro use: different colored washes and glazes to introduce tonal variation to large, monochromatic areas. The skirt here is a good example: could I make it even more interesting by adding some other colors to it, without ruining the paint job I already had laid down? That question was actually what made me capture the image above, which I sent to my brother. By the time he sent his reasonably conservative response, I had already jumped in with a purple ink glaze. This led to the actual final version:

Bjorn

Bjorn

If you compare the WIP to the final image, you can see the subtle difference, and the final result really has a lot more visual interest. It especially helped the folds on the rear of the skirt, although I don't have a WIP photo from that angle. Looking back, I could have done the same thing with the flesh, adding some tonal variation there as well. I did not go back and alter Bjorn, but working through these thoughts and techniques gave me courage to practice these approaches on other heroes.

The axe, by the way, is just OK. Compared to the incredible motion and detail in the muscles, pose, and skirt, it's just a static instrument of destruction. At first I was unhappy with it, but now I'm looking at it as a material contrast. I am still not sure what I could have done to make it bit more visually interesting, though, since it's not clear that runes or gore would make it significantly better.

A quick word about the bases: I decided to just do simple grey and black bases in the interest of time. I wanted to minimize the time these would have to be off the table, although my boys and I can generally only play Massive Darkness on weekends. I figure I can go back and add texture and flock later if I wanted to, but I opted to keep it simple: these are just Americana Slate Grey and Lamp Black.

Next up is Bjorn's pit fighter friend, Siegfried:

Siegfried

Siegfried

Siegfried has a lot more detail, with his hair and beard weaving around his chest and the adjacent cloth and metallic details on his ... battle apron? Billowing cloth seems to be a visual theme in Massive Darkness, and with Siegfried I decided to try something a little different. You guessed it, I decided to take yet more inspiration from Sorastro. In his videos, he has started using wet blending to block in the base colors. I figured I would try that with Siegfried's dark blue skirt. In fact, I ended up wet blending the whole thing, with just a little highlighting touch-up at the end.

His hammer struck me as being like Bjorn's axe [pun intended]: it's a lump of plastic on an otherwise fantastic figure. His card art looks like a shining gold hammer, but the sculpt has cracks that suggest stone. There's not a clear way to add runes or other effects, so I decided to wet blend colors to suggest a kind of granite texture. Like Bjorn's axe, it's passable but not that interesting.

Sibyl

Sibyl

Next up is Sibyl, not to be confused with Sybil. Oh, I know, people get them confused. Sibyl's card art suggests a soft blend from pale green to deep purple, and I was very excited to sit down and try to paint that. I mixed up the endpoint colors with some Liquitex Glaze Medium to extend the drying time, and I made a half-and-half mix of those to get the mid tone. After carefully wet-blending the two, I ended up with what I consider an excellent gradation along the skirts. Once that was dry, I was able to go back in and accent the shadows with the next tone darker. The rest of her armor is a brighter variation on the base pale green color that was given a medium green wash and then highlighted in layers.

Her hair is fairer than Bjorn's or Siegfried's, and it provides an example of how zenithal priming was useful. Most of the highlights you see on the hair are the result of using thinned browns to paint the hair, which let the bright white primer show through. I did also work in a few darker shades into the shadowed area along with a modicum of manual highlighting.

Elias

Elias

Who doesn't love a blue-robed, white-bearded wizard? He breaks the stereotype by wielding a longsword rather than a spellbook. Good for him. Elias is mostly one color, and I decided to continue some of the new techniques from the rest of the series. He provided an excellent case study for wet blending, which I did for the entire blue robed areas and hat, along with a bit of edge highlighting in near-white. After that, I mixed up another dark purple ink glaze and painted it into the recesses. This gave some real visual interest by getting away from the simple blue gradations.

The staff is a mix of blue and silver, and at first I left the orb atop it pure white. I had thought about object-source lighting, but at this point I had not taken into account that light source in my highlighting, and I certainly didn't want to re-work the areas that would be hit by it. It didn't work to leave the orb white and not make it look like it was shining. My son offhandedly suggested adding a warm color to contrast with the cool ones, but I decided to add contrast in a different way: I tried reusing similar colors but in a marble texture. I think the result is nice, suggesting a magical stone or dragon's egg at the end of the staff.

Owen

Owen

Owen is basically two colors aside from his armaments and small details. My first pass at the gold armor was a bad match with bad coverage, and I probably mixed six different combinations trying to get a good color. For all of these, I was using one of my gold metallics as a constituent in the mix. It wasn't until I broke away from this that I was able to make some progress: by mixing yellow, buff, and ivory, I was then able to add Metallic Medium to give it a metallic sheen. A brown ink wash added depth, followed by layered highlights. The robes were painted like Elias', using wet-blending for the basic colors, additional layering of highlights, and deepening of shadows with a violet ink glaze.

The sword hilts originally looked very much like the gold armor color, but I wanted more variation here as is present in the card art. On a whim, I tried hitting it with the same P3 Armor Wash that I used on the swords and shield, and this worked perfectly: it brought the color down more than I expected, and a touch of highlighting got it right to where I wanted it. I mixed a very thin blue glaze that I used on the swords and shield to add some tonal variation. It's barely perceptible, but you can see the effect on the lower-left side of the shield. I probably could have taken it further, but I'm going to leave fancier metallics for another technical experimentation session.

Silence

Silence

Silence is mostly cloak. He's more cloak than man, that's for sure. This one has the most significant differences between the sculpt and the card art: in his drawing, he has a bare fists with spiked armbands. In the sculpt, obviously, he's wearing gloves and has one hand completely wrapped within his cloak. Why is he doing this? Is he hiding something? A gold coin? Eczema? Nobody knows.

With this much cloak, the only reasonable way to proceed was with more wet-blending, a full-cloak dark purple wash, layered highlights, and additional purple ink glaze for color variation. I thought about doing something like green to really vary the palette on Silence, but I decided to go all in on the cool blues and purples. He has a few spots of shiny metallics where I reused the approach I used on Owen, applying P3 Armor Wash to bright gold elements to get a bright but not overpowering tone.

Completed Base Set Heroes

The final technical experiment of this project was airbrushing varnish. I used my Vallejo Matt Varnish straight out of the dropper bottle, and it worked fine. I think I had the pressure up to high originally at 20 PSI, which created some pooling on the first ones I varnished. Once I turned that down I was able to get a more careful and deliberate coat. A few needed a second coat, in part because the glaze medium lends so much shine, but this was all very easy to do, and it was no harder to clean up the airbrush afterward with that than with the primer. I think I actually used more varnish this way then when I brush it on, but this might also be from my inexperience with the airbrush; time will tell.

I really enjoyed painting these six heroes, and I'm excited to get them to the table during Thanksgiving break. The characters have wonderfully dynamic poses and fine detail. The casting was also top notch, with very little cleaning required and only one tiny bit of Elias' hat where I needed a dab of putty. My only criticism is something that I may not have noticed if it weren't for having recently watched Dr. Faust's storm giant video, and that's the fact that every piece of fabric is frayed. Bjorn looks like he should have a worn and tattered skirt, but what about Owen? Shouldn't a Paladin of Fury be taking more care of his appearance? It's a minor quibble. Maybe I should be taking the time to add more weathering to the fabric, to really send home the "tired and tattered" theme. However, for now, weathering is in the same bin as improved metallics: a project for another day.

I'm sure that part of the reason I had such joy in painting Bjorn was that he has such wonderful exaggerated detail compared the last thing I painted, the tiny 15mm figures of The 7th Continent. It wasn't until I was working on Elias that I thought: these miniatures don't just have great details because they're bigger than The 7th Continent, I think they're just plain big! My Descent heroes were handy, so I grabbed Avric Allbright and set him up next to Bjorn, in what looks like a heated dispute that's about to come to blows.

Go ahead, make my day.

Yes, definitely bigger. Despite the extra quality that can be put into the larger figures, I was a bit disappointed to discover the scale difference. One of the reasons for my backing the Kickstarter was to get a quantity of miniatures that I could bring to the table for a hypothetical fantasy tabletop roleplaying game, but these guys would be all out of scale. The unique monsters will likely be fine, but Bjorn and Avric would look a bit silly side by side, and who ever heard of seven-foot goblins?

By the way, you may have noticed that these photos look a bit different than recent ones. I'm still using my collapsable lightbox, but the biggest difference is that Google finally released a patch for the Nexus 5X that includes manual exposure control! Now I can shoot these similar to how I shot my old minis on my Nexus 4, although the controls are more fiddly now than they used to be, requiring resetting between shots. Still, I can happily say that the figures on my table actually look like the figures in these photographs. Progress!

I have nine more heroes already primed that should have me painting through the end of the semester. My pocket notebook is filled with thoughts to blog about, but if I don't get to those you can be sure I'll devote time to my annual between-semester reflection and planning posts. Thanks for reading!

UPDATE: Here is my write-up about the other heroes I painted.

Painting The 7th Continent

I have quite a backlog of ideas I want to blog about, but I've been a bit stressed with other things lately. These stresses also got me into a bit of a painting funk. The full story starts at the end of August or beginning of September---right around the start of the semester---when I received my copy of The 7th Continent. I was quite excited about this Kickstarter project, in part because it explores a modern, narrative-rich variation on classic "Choose Your Own Adventure" gameplay, similar to some of my recent work.

The game comes in a beautiful and well-designed box.

One of the reasons for backing the Kickstarter was to get the exclusive plastic figures, whereas the standard game comes with cardboard standees. I was eager to see how the miniatures look for painting, and I was a bit surprised to see how very miniature they really were.

That's Eliot Pendleton from The 7th Continent next to a standard reference Runebound Master Thorn. Wow, that's miniature. It took some of the excitement out of the whole package for me, but I was still eager to play, so my wife and I did our first foray into the wilderness with the standees. We followed the suggested starting curse and must have been very near the end of that story when we lost. With one completed play under our belts, we were able to look a little more carefully at the characters and pick two that seemed they would work well together. We had barely used the special abilities of our chosen characters during our first play. Our second trip to The 7th Continent would be with painted miniatures, which surely would change our luck.

I started by painting the four campfire miniatures:

This was fairly standard stuff, but I had been in a little painting lull before working on these, too. Believe it or not, I painted them upside-down to start with: newbie mistake, putting red on the bottom. Fortunately it was an easy repaint, after a little self-deprecation on Facebook. I did try something different here: using a little dark gray on the ends of the fire to imply soot. I saw this in someone's fire paintings, I cannot remember where, and I thought it would be fun to try. It's OK, but I'm not sure if I didn't give it the attention it needed or if it's not for me. Honestly, the whole bonfire probably could have had more gradation, now that I look at it: more white and yellow at the bottom, more orange up top.

Above are the two characters my wife and I chose for our second adventure: Eliot Pendleton and Dimitri Gorchkov. I let her choose the curse for them, so she picked one based on its interesting fiction. I don't think it's a spoiler to say that she chose the one that's basically a locked box, and you have to try to open it. However, unlike the first curse, there was no map or clues or anything. This made the curse a bit uninspiring: it would make a good second curse perhaps, but there's not much reason to go forward into the jungle if all you have is a locked box. We haven't actually picked up the game since. I got base coats on two other figures around that time, but then I went a few weeks without feeling the call to sit at the painting table. I finally broke out of the funk two days ago and got the rest of this set completed.

And so, here they are!

The colors are taken more or less from the cardboard standees. They were all primed by brush with Vallejo gray, basecoated, washed, and then highlighted. It's a fine tabletop quality for the tiny miniatures that they are, many of which will likely never hit the table anyway. Still, you know it's nice to have a completed set.

As I was painting, I found myself wondering how they compared to some of the smaller miniatures I've painted before, such as halflings. I happened to have my Descent heroes nearby, so I set up a quick shot for scale.

Yeah, they're small. Note that they fit nicely on the game map at this scale, so they are certainly fit for purpose.

You know, if you have a set of adventurers and some bonfires, it's tempting to set them up in a circle around a bonfire. Then, you might notice that it looks like one of them has just had enough of creepy H. P. Lovecraft there and tells him to get lost,

so then you take another photo from a low, dramatic angle of poor Howard going off to meet his accursed fate.

A few more words about the game are in order. My wife and I really enjoyed playing it as a two-player game while the eldest son was tinkering on the laptop. There was tension and excitement as we explored and got to understand the systems and the world we were exploring. The second visit lost some of the glitter since we very quickly ended up on the same little island that we were on before, so that felt more rote. I think it would be fun to set it on the shelf for a little while and come back to it in some months, or even years, when one or two of our sons might join in and we've forgotten some of the details. Even writing this, I want to go check out what those other two core set curses are and see if one looks like it would draw us in more dramatically.

It felt good to break out of my painting rut. I have some responsibilities this week that, hopefully, I'll be blogging about soon---though as I said above, I have a backlog of ideas I want to write about and a shortage of working hours to do so. The good news is that I have an ace team recruited for Spring's immersive learning Game Production Studio, and all my Fall responsibilities do seem to be falling into place. Thanks for reading!

A novice game designer's self-assessment instrument

Yesterday's meeting of my game design colloquium was where the students and I developed a schedule and expectations for the remainder of the semester. We have finished the foundational material of the first half of the semester, and we are shifting into final project mode. I might write more about that meeting later, but for now, I want to share a small piece of the meeting. Most of these students have no prior game design experience, and some seemed a bit nervous about the final project. Of course, I think the source of their nervousness was grades and not quality of outcome, but let's leave that alone for now.

One of the students posed a question to me that I don't remember being asked before. They wondered if I had some kind of self-assessment that they could use to determine if they are "moving in the right direction." I believe that was the phrasing, although it may have been "doing the right thing." In either case, there was a clear assumption that there is a right way to move forward in game design and, furthermore, that I could grant this.

My instinctual reaction was "No," but then I immediately thought, "Why not?" The students have spent most of their time reading Ian Schreiber's Game Design Concepts, along with some other of my favorite readings as listed on the course schedule. We have talked about design as a cyclic process—a feedback loop where testing results inform design modifications. However, in the student's defense, we have talked about a lot of things. It's easy to see how a novice could feel lost.

Here's what I came up with as a suggestion for a self-assessment the student could apply:

• Is the goal clear?
• Is there conflict that prevents you from meeting that goal?
• Are the decisions meaningful?

I don't think that's too bad for an off-the-cuff response. A couple of things were floating through my head as I articulated this. One was the very first exercise I gave them, which was the 15-minute game design challenge from Schreiber Level 1. The challenge walks you through making a simple race-to-the-end board game, and he walks you through four steps: draw a path; come up with a theme or objective; define movement rules; add conflict. Another was Sid Meier's famous quotation, "Games are a series of interesting decisions," tempered with Keith Burgun's assertion that these decisions must be endogenously meaningful.

I offer this as a thought-piece and the draft of a tool. If you try using it in, let me know how it works out. 

What questions would you put onto a self-assessment for novice game designers?

MDA, Cheating, and Levels of Analysis

One of the early-semester assignments I give my students is to read the Hunicke et al. paper on MDA analysis, and then to analyze a familiar game within this framework. This works best after I have introduced the concept in class with an example, usually Buffalo since that game is worth studying in its own right. Re-reading the classic paper reminds me that although it has had undeniable impact, being one of very few pieces to transcend the games research / games practice divide, it is not very rigorous. I think the core idea of it is quite brilliant: that we can, and should, consider the differences between what designers control and what players experience. Years of using this model have led me to internalize it with my own variant, which I explain to the students roughly thus:

• Mechanics are all those elements that the designer directly controls.
• Dynamics are what happens when the mechanics enter a play experience.
• Aesthetics are the sensations that arise from the dynamics.

By this framework, which I believe resonates with the original paper, then we can see that the rules, story, art design, physical components, etc. are all mechanics—leaving alone for the time being whether these ought to be called "mechanics" or "mechanisms", though it's almost certainly the latter. The dynamics would include phenomena such as strategy, bluffing, and negotiation, and the aesthetics are all the sensations: fear, joy, shame, kvell, and the satisfying tick of a meeple hitting cardboard.

I have met with this year's game design class four times so far, and I have a good feeling about them, and about the changes I've made to the course structure. In their MDA analyses, several brought up cheating, which I honestly don't remember coming up before. It came up in three different manifestations, all of which were framed as "cheating" by the students. Two students brought it up in terms of card games, engaging in activity such as looking at opponents' hands. One mentioned stream sniping in online games, a phenomenon afforded by the trend toward modern gameplay technology and culture. One other student mentioned "glitches", referring to taking advantage of defects in software to take actions in computer games that were—presumably—not intended by the designer.

It is interesting to consider at what level cheating exists within MDA. Cheating is, by definition, a violation of the mechanics. However, I agree with Koster's assertion that if you change the rules of a game, you are playing a different game with the same pieces [although right now I cannot find his essay that states this, so if you do, hit me with the link so I can update this]. The classic example is that many people play Monopoly such that money accumulates on Free Parking and is gathered by players who land there—but this rule is, of course, not in the rules of Monopoly. Hence, we could consider them to be playing a Monopoly variant with the same pieces as Monopoly. From this perspective, then, cheating means you are playing a different game. I think that's an important observation that emerges from this kind of formal, ludological study of games. Note that it's different from a game that permits "cheating", such as the variant of Cosmic Encounter that says you can do anything not in the rulebook as long as you are not caught. From the formal perspective, though, what's really happened is that we've changed the rules of the game to include all possible activity as mechanics, most of them tagged with the caveat that if you are caught, you pay the price. That is, it is not cheating as such since it is actually part of the game variant's mechanics.

I have been listening to Jordan Peterson's lectures on personality, and it has been interesting to learn more about Piaget—a superstar of educational theorists, which is where I have previously seen his name and theories—from a personality psychology perspective. Piaget seems to have framed practically all interesting developmental human activity as a game, which certainly resonates with my experience and research. From Piaget via Peterson, I have been thinking about the game of being invited to play games, which for simplicity I will call the social game. Why do we say "It doesn't matter if you win or lose, it's how you play the game"? We do this because each game is instantiated within the social game. If you are ungracious in victory, if you are bitter in defeat—or if you cheat—you lose at the social game. Hence, we can assert that "cheating" is actually a mechanic of the social game: it is a move that is allowed, but it is almost always a losing move.

The idea that there are multiple levels of analysis has also come up several times this semester. For example, it has given us a way to think about the sometimes-toxic communities around online games: there is a poorly-regulated social game around these which was brilliantly skewered in Koster's most grave presentation, his GDC 2017 talk "Still Logged In". We applied a similar form of analysis to consider the game of competitive Magic: The Gathering, that there is the embedded game that is a round of MtG, but that is within the context of the gambling-and-trading-game of buying packs and chasing rares. Both are also simultaneously within the "meta", the game of knowing what decks are popular, locally or globally. Some of my students were surprised to consider these higher-order games as also being designed; they had previously considered that the designers made a game and that the community somehow made the rest. However, MDA gave us an important tool here too, to look at the mechanics of rarity, legal deck sizes, and distribution, and how these designer-specified mechanics led to dynamics such as chasing rares.

Peterson's lectures frequently bring up the concept of multiple levels of analysis, and this seems to be a critical concept in understanding personality psychology. I suspect that it was my studies here that have influenced my looking at games from this lens. I suppose this speaks again to the power of interdisciplinary, since I know that some of my best scholarship has arisen from my seeking out novel ideas and integrating them into my areas of specialization. Even studying games themselves, it was a journey from Summer 2006 that shaped how I think about all the work I do today. Seems Piaget had it right.