My Impeccable Taste

When I was around ten years old, I started taking computer classes at the local library. This was where I first encountered software such as word processors, spreadsheets, and The Print Shop, as well as the first-generation Mac and mouse input. 

The teacher for these one-on-one sessions was a kind man named Jim. In addition to teaching computer classes, Jim had an affinity for music, and for many years he had his own radio show at the local college radio station. 

Fast-forward twelve years or so, and I was in graduate school in Buffalo. I found out that Jim was also living in the city, so we got together for coffee and traded stories. We talked about music some, he asked if I was still into They Might Be Giants (of course, yes), and he told me that he thought I would like Sparks. I had never heard of Sparks, but the name stuck in my head. When I got around to looking into it, I was hooked: here was some fun, clever, jaunty music, perfect for lifting a sour mood. The early stuff like "Something for the Girl with Everything" has a great powerhouse sound,

and pop just doesn't get any better than "Moustache."

The album that I spin the most has got to be Balls. The title track is just the thing to push through some challenging programming.

The trio of more recent albums Lil' Beethoven, Hello Young Lovers, and Exotic Creatures of the Deep explore some interesting themes and layered sounds. Even though the sound is different from the earlier work, tending toward melancholy, but still with the signature catchy tunes and clever lyrics, such as in "Metaphor."

I picked up their latest album, a collaboration with Franz Ferdinand called FFS (Franz Ferdinand & Sparks, naturally). The album has a lot of winners on it, but just to give you a taste, check out "Call Girl."

But I digress.

I had been listening to a lot of jazz while painting, but a few months ago I decided to try out Google Play Music. At first I just listened to my own albums, and then I decided to try Sparks Radio—Google's auto-generated collection of songs for folks who like Sparks.

What fun! 

The channel features classic Sparks music and lots of contemporary music that I had never heard of before. It introduced me to the likes of Lene Lovich, John Foxx, Bill Nelson, XTC, Tubeway Army, and Pete Shelley. Most of these I had never heard of before; I only knew of XTC because of the They Might Be Giants song about them.

Once I looked up Tubeway Army, I recognized Gary Numan, and there are some nice grooves in his early work.

Bill Nelson has some great synth-powered pop, like "Flaming Desire"

and "Do you dream in color?"

Some of John Foxx's songs are what the future used to sound like.

On the lighter side, Lene Lovich has some great catchy pop sounds, such "Be Stiff" with a simple chord progression and a touch of brass (which my searching just told me is a cover of Devo's third single).

How about the groove on "Meccanic Dancing" by XTC?

I heard a few great songs by Dukes of the Stratosphear before I found out that they're basically XTC doing psychadelic pop. This one feels like it came right out of the 1960s.

I don't subscribe to Google Play Music's service, so I tend to get the same songs coming up quite a bit, but really that's been fine: some nice tunes I'm coming to enjoy interspersed with new ones, perfect to listen to while painting.

People sometimes ask me why it took until 2017 for me to try streaming Internet radio. The reason is fairly simple. I was actually one of the first people on Pandora when it came out. Great, thought I, here's something that I can use to capture my esoteric and impeccable taste in music! Let's see: here's Ween, They Might Be Giants, Prince—augh, no, I don't like Prince! Down vote. Try again. Devo, Talking Heads, Prince—Stop, no, downvote! Bonzo Dog Band, Weird Al, Prince. Seriously? You have no idea how often this happened. Every path led to Prince. There was no way out except to continue buying physical discs and ripping them to a digital library for convenience.

OK, time to take another giant step back in time. Some time in the early 1990s, give or take, my friend Matt recorded a special where Weird Al took over MTV for "Al TV." This was a combination of mock interviews, sketches, and wonderful music. This special introduced me to artists who would later come to be some of my very favorites, including They Might Be Giants with "The Statue Got Me High", 

David Byrne with "She's Mad",

Matthew Sweet with "Girlfriend" (just about the coolest video for fans of 1980s anime),

and...

are you ready for this?

Hilly Michaels with "Calling All Girls."

Oh man. That is so ... 1980. I love it. When I found a cassette of the album Calling All Girls, I had to have it, and I don't think it ever left my car. Here's another for you, the "High quality audio" version of "Shake It and Dance."

There is one particular song that is so very bad that it has become, to me and my wife, an anthem for bad pop music. I speak, of course, of "U.S. Male," which I'm sorry to see does not appear to be on YouTube at all. Wouldn't it be convenient if some kindly soul hid a copy somewhere so that you could hear it? It's bad, but I love it, like a cheesy B-grade science fiction movie.

Incidentally, assuming Wikipedia can be believed, Hilly Michaels drummed for Sparks. I didn't know that until well after enjoying both artists. I'm sure it's not a coincidence: I seem to have a soft spot and a keen ear for this kind of stuff. Also, I know from Wikipedia that he had a second album, 1981's "Lumia", which I have never been able to find, neither on cassette nor on the deepest, darkest places of the Internet where one looks for forgotten culture.

For some time, I've thought to myself, "I should look up Hilly Michaels Radio on Google Play Music sometime when I'm painting," but inevitably I would think about this when I was doing something else and then forget about it. Well, today, I did it. Hilly Michaels Radio. My hopes were up. 

The first song was a tune by Hilly Michaels I had never heard before—"It Ain't Fair."

Success! The song is... fine. It's not from the mysterious Lumia, but I found out later that this is from his previously-unknown-to-me 2010 release, Pop This! The next song came on, an atmospheric piece, something familar... Danny Elfman? I wasn't sure, so I checked the app, ... Elfman, yes, with the theme from Tales from the Crypt.

Strange. Skipped that track, not quite the mood I wanted. The next piece was also instrumental, a selection from the Knight Rider soundtrack. (I looked for it to link here, but I couldn't recognize which one it was from what I could find. However, imagine 1980s action television background music. Yes, that's it, that's exactly right.)

OK, so was this just all going to be 1980's cheese?

The next song came on, sounds like synth pop...

And, ladies and gentlemen, I think that's the worst song I've ever heard—and I've listened to The Shaggs. I just listened to it again. My goodness, it's bad. There's a little tiny hint of Jonathan Richman in there, the rawness and earnestness. It's not like a good bad B-grade science fiction movie; it's like the ones that are so bad that they're just bad.

The next thing to come up was a TV commercial for Halloween III. Yes, I'll link it here, but I have not listened to more than 20 seconds of it. Caveat emptor.

I saw that the next track was from the soundtrack to Stripes, and I just couldn't take it any more.

The moral of the story is probably this: when your tastes run obscure, be careful on the Internet.

A Project Mentor's Reflection: Q&A

A colleague sent me four questions in response to yesterday's post. With his permission, I'm responding publicly here, so that others may also benefit.

1. How does the methodology document get created? Do you start out with an empty document, a document with topic headings only, a draft document that is then refined, or something else?

I started with a seed of a methodology years ago, based on what my teams had been doing successfully and what I knew to be best practices from industry. Now, each semester I revise what the previous semester left behind. I've made a public copy of last Spring's methodology document here. There's a published skeletal methodology and a bit of theoretic background as part of my and Brian McNely's 2016 TOCE article.

There are a few things that I am considering changing for next time, in part from writing yesterday's reflection. The Anzeneering link was a late addition, and I talked about but did not make Stop Work Authority cards. Thinking more about the principle of safety, I think I should require that reading and make the signs myself and have a few scattered around the room. This resonates with the Psychological Safety rule I linked in my post, which comes from Google's studying of team dynamics.

The Crystal Clear principles are good but only if people read and embrace them. I'm not sure that they do, although we are able to come back to them during our periodic retrospectives. As I mentioned, I've been watching some Robert Martin talks, and this one on professionalism brings up some interesting ideas not explicitly mentioned in Cockburn's list. The particular one that I want to add somewhere is Never Be Blocked. I think that's a piece that hindered a few team members, as they decided to wait for someone else to act rather than take the initiative to get things done. It's one of those things that I have fairly well internalized, which means it's hard for me to remember to teach my students about it! Some of the other pieces that Uncle Bob talks about tend to be tricky for students working in games development, particularly the bits about test coverage and manual testing, since so much of game development is experimental. I think it's hard for students to distinguish between code that should have 100% coverage and code that is not worth writing unit tests for; of course, they too often bias toward the latter!

I also note that the conversation around version control is stuck in the "for programmers" section, with only the value of frequent integration mentioned for everyone else but not the process. I need to make this more clear that it applies to everyone. Obviously, this would have to be couched in discussion of psychological safety, since this whole notion will be foreign to people from outside CS.

2. My sense is that you have students write reflective essays throughout the semester, and that this is what you use for assessment for their final course grade. What else, if anything, figures into their grade?

That's right, and this too comes right out of the Academic Studio pedagogy that McNely and I documented in TOCE. We borrow from Agile practices the idea of short iterations, incremental development, and reflective improvement. That last point manifests explicitly in two ways: collective team retrospectives and individual reflective essays. As project mentor, I lead the retrospectives and document the results, reflecting approved changes into the methodology document as well. The essays are framed with essential questions that are designed to help students see beyond the project to deeper academic issues. That's the good kind of "academic" of course, not the dismissive one. We only had two for this studio: how do teams coordinate activity to address interdisciplinary research and development problems, and what is the role of theory in research and development projects like ours?

In addition to each end-of-iteration essay, students make at least one entry into an individual portfolio, which is usually a link to a resource and one or two sentences of context. I started doing this a few years ago after having had a bad experience: I had a team with some slackers appeared to produce nothing all semester, but with so much collective work, it was hard to have evidence that they didn't contribute significantly. I was unsure if this exercise was valuable, so I polled my students after receiving this question. The one respondent indicated that he thought they may have been even more valuable than the essays, particularly the act of finding an artifact that represents specific learning. He admits that it sounded like busywork at first, but he came to appreciate the task. I will point out, though, that I could not find any correlation between the portfolio items and my observations about whether students were getting the big picture or experiencing personal growth, not like I could with the essays. Also, the portfolio entries were never intended to contribute to the final grade, but rather as a simple measure of accountability, although the course plan doesn't make this clear.

The final exam is just a pair of reflective essays chosen from a suite of options that I provide. Here's what their actual final exam looked like:

What is the final exam?

Most of our work this semester was bound up in the making of Spirits at Prairie Creek Park. Our team has built a shared understanding that is necessarily bound up in the context of our collaboration: the people, the problems, the places, the donuts, etc. The main point of the final exam is to help lift our thoughts out of the particulars of this context, to improve our ability to draw upon our understanding as we move on to other endeavors.

Choose two categories from those given below and give an essay response to one of the prompts therein. Keep in mind the definition of "essay" given on the course description; you are also welcome to reference my essay on essays. I encourage you to use your portfolio entries and past essays as evidence to support your arguments. If you think of a different prompt, or even a new category, let me know, and we can negotiate how to move forward.

Academic Miscellany

Consider one or more of these essential questions:

• How do teams coordinate activity to address interdisciplinary research and development problems?
• What is the role of theory in research and development projects like ours?

Note that you don’t need to answer the question per se: the point of an essential question is to guide inquiry because it doesn’t have a closed-form answer.

Expectations and Reality

• What was your biggest surprise of the semester? Delve into it in an essay, considering: why was it a surprise (that is, what knowledge did you have or not have coming a priori)? When did you realize you were surprised? What did you learn from the experience? Compare and contrast the final product to how you initially thought the game would turn out. What accounts for the differences?
• If you could improve upon the game in one way (including game design, asset production, and technology platform), what would you improve, and why?

Reflective Practice

• What was your biggest mistake of the semester? How did it come about, what did you do about it, and what do you think you learned from it? You might structure your response as a postmortem, for example, in the format described by Fitzpatrick and Collins-Sussman.
• Reflect on what you have learned this semester that is related to your involvement in the game studio, and choose one outcome that is most important to you. Write a reflection about the context of this outcome: Who was involved? In what places did it happen? Over what period of time? Was the experience mediated by technology writ large---software, designed spaces, furniture? What were the sights, the sounds, the smells, the tastes, and the tactile experiences involved? How did these factors contribute to this outcome?

Legacy

• Write an orientation document for future game studio students, something that could be given to them at the start of the semester to help them succeed in their work.

Discipline

• Produce an artifact in accordance with your academic focus that represents something significant you have learned this semester. Provide a brief author's statement to guide the perspective of someone outside of your discipline.

Some of the responses were beautifully composed and thoughtful, enough that it was worthwhile. I do believe that the essays I have read, and the conclusions I draw from them, align well with my observations of what students are doing. Once again, however, we run into an interesting research question that I don't have the resources to approach. Also, I am sad to report that in two years of using this final exam format, no one has taken that final option to produce a disciplinary artifact that represents their learning: some day I'll see a student dance a final exam.

3. How did you get the “official plaque”? Do all immersive classes get this, or only certain ones? 

I don't know. I haven't gotten one in years despite continued immersive projects. This was the first time in many years that I requested an official portrait, though, so maybe there's causation there.

4. What are some of the topics/activities you do during the first few weeks of the semester to get things started, and to get the students to understand that, in large part, they are “driving the bus” for this course?

I had used some preparatory activities in the past, but I found them mostly to be a waste of productive time. Now my philosophy is that the best way to get students acclimated to the work is to do the work. I usually spend the first week of the studio course doing some prep and background, though. I usually introduce a few board and card games that I believe exemplify game-based learning, and I teach them fundamentals of the MDA Framework as a rough introduction to understanding the differences between playing and making. There's an intentional playful bouncing back and forth between games and analysis that foreshadows the semester's work. We go very quickly into production mode though, where I have already broken down the user stories into sample tasks. I try to make the first sprint an easy win. For Spirits at Prairie Creek, we had a lot of unknowns we were trying to wrestle down in the first sprint, and maybe that was part of what caused some confusion moving forward. By contrast, for Traveler's Notebook: Monster Tales, I had already laid out the core gameplay and we could move forward with a minimum viable product. Of course, all of this leans on the fact that I am doing production courses; if a course is not based on production, then your mileage will vary.

One thing I neglected to mention in my previous post is that two students, in their final essays, wrote orientation guides for next year's students. Both of them addressed the need to recognize, up front, that they will have communication problems. Again, this is one of those things that I've internalized so much that perhaps I did not prepare the students well enough to expect it. Both of these students wanted future teams to know that communication problems were normal, but also something to be quickly recognized and addressed rather than hoping they would go away. I am still not sure if I should print those out and hand them out next year or incorporate those ideas into a more robust methodology-orientation document. When one of the problems is that I'm not sure students are reading the methodology at all, it makes it hard to know where best to focus my efforts.

I hope that helps!

Spirits at Prairie Creek Park: A Project Mentor's Reflection

The Spring semester is over, and my multidisciplinary undergraduate studio team has released our semester project, Spirits at Prairie Creek Park. This post is my personal reflection on the semester. The game itself can be found at SpiritsAtPrairieCreek.com, with a brief informational page at About.SpiritsAtPrairieCreek.com. It was designed in collaboration with Muncie Sanitary District to encourage families to come to Prairie Creek Park and the Reservoir. We worked specifically with Jason Donati, to reinforce the environmental and outdoorsmanship themes of Camp Prairie Creek, a free summer camp for kids.

This was the second half of a full-year immersive learning experience. I wrote about last Fall's honors colloquium on game design back in December, and that course also prompted my essay on sustainability in games. Two students from Fall's course continued with me into the Spring game production class, and we were joined by nine other undergraduates.

Gameplay Overview

Spirits at Prairie Creek Park is a geolocative game played at Prairie Creek Park, and it is designed for families or small groups. If you open the game while you're not at the park, you get a Google Maps link for directions. If you are at the park, you are given the option to start the game.

Title Screen while at t he Park

Players are given a map with five park locations to visit, each marked with a representative icon.

Map Screen while at the Playground

Upon reaching a location, players are prompted to use different senses to observe their environment for thirty seconds. Different sites use touch, sight, hearing, and smell.

Exploring the Playground

After the timer counts to zero, the players choose what they observed.

The Playground Checklist

The players then discover a different "spirit" depending on what they observed. The players can then collaboratively choose to name the spirit or to keep its default name.

Discovering "Scamp" at the Playground

After visiting all five sites, you see all of the spirits you discovered, with the names you gave them. You can also share a link to the game on Google+, Twitter, and Facebook, with the Facebook post including a template that lists the names you chose for your spirits.

What Went Well

We received significant encouragement from our community partner. Jason was always available for feedback, and he was eager to share his feedback and ideas. I think he could really see how a unique game like this could engage the kids at camp, and the families they brought to the park, in new ways. Working with a local community partner certainly has some benefits over working with those further out, such as my colleagues in Indianapolis. However, I think it was his enthusiasm that mattered more than his proximity: he treated us like he had a horse in the game, a real vested interest in our success. It helps too that the park and reservoir really are beautiful: my team was inspired by our handful of trips to explore and test.

The team made great use of our technology stack. The game is implemented in web components using Polymer. None of the students had used this before, and many had never even touched Javascript or Web development at all. However, most of them got over the hurdle fairly quickly, learning to deal with a stack that included Polymer, command-line git, npm, HTML, Javascript, CSS, Bower, GitHub, and Travis-CI. We also used Slack and Google Drive for communication and collaboration. I had to get my hands into the code quite a bit, trying to bring along a student wingman whenever I could, and I conducted a lot of the pre-merge reviews, since I knew the most about the stack. I built two versions of our debugging tools as well, which helped the team to internally test features without having to drive out to the reservoir. (Incidentally, the second version of the debugging tools are shipped with the product: click the menu in the upper-right and you can get to the developer options. This lets you play the game from anywhere by simulation your location, for example, which is how I generated those screenshots above.)

It is about a twenty-minute drive from campus to the reservoir, and so the team realized early that we should build a locally-playable version while we work out the kinks in the technology and explore the game design. For more than half the semester, the team worked on a version of the game that was playable on Ball State campus. It was given the placeholder name Spirits at Ball State, which ended up evolving into the final project's name. There were three sites easily accessible from outside the Robert Bell building where we met. We built and tested several paper prototypes that could be used locally as well, as we were sketching in the software architecture. We spent much more time on this version than I had wanted, but this is evidence that we made the right choice since we could fail faster.

The Team at the Butler Undergraduate Research Conference

Many of the design decisions were driven by a team member with a keen eye for analysis. For example, the number of options presented at each location, the amount of time provided for the senses, and the overall vocabulary of the application were all based on lightweight prototyping with representative players. Two team members took several sketches and ideas to a local library branch to get feedback from kids in an afterschool program there, and this led us to two of the most important design decisions of the game. First, before this visit, we had the player only discovering one spirit at the end of the experience, but we realized that this bit of motivating feedback was better done after each site. The second important change is related: we realized the kids really liked naming the spirits, and they thought of them as working together in teams, and so we added the ability to name the spirits, and the "Heroic Vee" presentation in the end screen.

I think reaching out to the community to show their work was more important for this team than any other since the actual number of people who can play the game is very slim. In past projects, we could share a link that anyone could play, but this geolocative game requires you to be at Prairie Creek Park. We made a trip to Indianapolis to present at Butler Undergraduate Research Conference, and while students enjoyed the trip, we had terrible placement: our poster was significantly off the beaten path compared to everyone else, and so they had very little engagement from attendees. However, I also scheduled a visit for the team to speak with my friend Cathy Hamaker at The Children's Museum, and this made the whole trip worthwhile. They were able to draw connections between the game design and exhibit design process, hear some wonderful stories about the struggles of good family interaction design, and also see amazing new exhibits while hearing the stories of how they came about.

The Team and Friends at The Children's Museum

I wrote back in February about how I was using story mapping to plan this project. I will briefly mention here that I found it to be a useful technique, particularly in contrast to the single-dimensional product backlog. I kept a lot of notes about story mapping with the intention of turning it into a publishable case study. However, the project itself—and my other responsibilities, but honestly, mostly this project—took up all of my attention this semester, and so I don't have those notes in coherent order. I would like to turn the experience into an article, but honestly, with the projects I have coming up, it's not clear when I'll have time to do so.

The final story map: More on that... someday?

What went less well

Students love the idea of naming their team, but I stop them from doing this too early in the semester. I remember reading advice years ago that suggested you don't have a team until you accomplish something together, and since then, I have held off on bringing up team naming until the students successfully completes a sprint. By that heuristic, this group of students never actually became a team—and that might not actually be far from the truth. Back in March, I wrote about how the team was struggling to find itself and hit stride, but I don't have much evidence that this intervention had much impact in our worst problem areas. We did not complete any of our six sprints; there were always tasks left incomplete. I believe this is a first for me, to have a group that did not complete any sprints. 

We had many discussions in our retrospectives about how to overcome this, including enforcing cross-disciplinary pairs for a week, holding each other accountable to test the game outside rather than through simulators, and posting sketches and works-in-progress to the walls. Some of these things never happened, even when we had individuals tasked with being accountable to them. When I brought it up wearing my Scrum Master hat, the best I got were lame excuses. I'll tell you, dear reader, it was strange, this deep sense of inertia among these students, unlike any I have ever seen. We had a methodology document that laid out particular kinds of ground rules, including rules for conflict resolution. In post-increment essays, students would write about their experiences in ways that clearly violated the methodology, and I would point this out in my feedback... and nothing would change. I read back through students' essays in determining final grades, and for some I saw this all semester: they would submit an essay, I would provide feedback, and nothing would change, and we would repeat this for the next iteration, all the way to the final exam.

I think it would be obvious to anyone observing the studio that we had two cliques. There were four students who served the role of artists, and then there was everybody else. The artists sat together and talked while they worked, but only ever with each other, while everyone else learned to cycle partners and help each other. Our methodology statement embraces focus as a key value and has specific rules about off-topic conversations in the studio, and one of my greatest failures of the semester was not calling people out on this. I was annoyed by the incessant jibber-jabber, but I did not point out the violation early enough, and then I got myself into a position where I talked myself out of bringing it up because I hadn't brought it up before. There is not a clean line between a short off-topic discussion and an hour's rambling, but I know I should have held up my Scrum Master responsibilities here. I do not know if other students saw this as my failure or not, or if they even saw it as their own failure for not speaking up, but nobody ever did, and so we did not have a good environment for focus.

The team suffered from serious asset pipeline problems. From the beginning of the semester, I was telling the team that everyone had to be able to be able to evaluate and integrate their own work, which means being able to run the game locally and push changes to git. There was a split almost exactly along clique lines, and even after multiple discussions, it was clear that most of the artists could not run the game or integrate their work into it. This means that they were unable to evaluate their work in context, which is, of course, ludicrous, but it's like the point above: there was a split, a miscommunication here that still puzzles me. More than once, we had artwork uploaded to Google Drive or Slack at the 11th hour, or even slightly—or grossly—after the deadline, that then someone else would have to integrate. Slack and GitHub were great for coordination among team members who were responsible about keeping up with them, but other students simply did not keep up—and their essays reveal that they did not think it was even their responsibility to do so.

Finally, as for the game itself, I think what we have is an interesting and novel design that encourages conversation about the environment and outdoorsmanship, being technology-mediated without being technology-focused like most games are. However, what we shipped is really just a first working prototype in many ways. There are many opportunities to improve the play experience without too much extra effort, such as replacing the digital timer with an animated one, animating the introduction of the spirits with some simple sound effects for more "pop," improving the overall look-and-feel of the application, and introducing more variety in the discoverable spirits. There is also the overarching narrative issue: why are there spirits at the park? In the final screen, what exactly are they protecting the park from? From an education point-of-view, we don't have any solid evidence or anecdotes to indicate that the game produces learning outcomes in the students since we ran out of time for any on-site testing with families. To be clear, I believe what we have is good, but we have only scratched the surface.

At the Reservoir

An Interlude about Llamas

With just a few weeks left in the semester, a subset of the team took it upon themselves to name the themselves. In a flurry of creativity, one of the artists whipped up an 8-bit flame llama, and a few of the students fell in love with it. It quickly became a mascot, at least to this subset, and so we dubbed ourselves Flame Llama Studio. A recurring theme in the studio among the programmers was that they would forget to update bower when dependencies changed, and so we coupled the flame llama with a reminder/slogan for a cool T-shirt idea.

We needed something that expressed the name of the studio as well, so the same artist made a studio emblem.

Conclusions

There's this lingering question I have had since near the end of the semester: how did we get into a position where four artists produced a total of ten shipped art assets in fifteen weeks? I was excited to have so many talented artists coming into a team: how did they produce so little? The best answer I have is that the artists—or at least most of them—never really saw themselves as members of the team, but rather as contract artists. If all they had to do was make art, then their role was to wait and be told what art to make, then to make it before the deadline. Indeed, looking only at the outcomes, this is what they did: they produced only the things they were specifically told to do. By contrast, if they understood that they were members of an interdisciplinary cross-functional project team, then they would have seen that they were expected to do much more than just produce art. There were a few points during the semester where some of the art clique were working on art that was not currently needed, while there was important work to be done for the current sprint, and in these cases I pointed out that we didn't need them to spend time on things outside of our current goals. Somehow they took this as, "Don't draw anything or show initiative," instead of, "We need all hands on deck to solve our immediate needs." Again, if a student's vision of themselves was as only being responsible for art, then the former sounds like what you might have heard, instead of what was actually intended. I am still unsure of the root cause of this misunderstanding, which bothers me, because without a good root cause, I'm not sure what actions I can take in the future to prevent this problem. (In truth, this starts to push into the realm of what I suspect vs. what I can blog about.)

I am reminded of a phrase we used a lot in my household when I was young: Missing the Big Picture. Here are two quick examples. One of the things we talked about doing was making coloring pages for kids that would have the game's URL on them. The last week of classes, a few team members said they could work on this. What they did was take spirit drawings and remove the color from them, leaving line drawings, ... and then they stopped. Of course this is a necessary step to making coloring pages, but it misses the big picture: you don't make coloring pages by just removing color from PNG or JPG images. A similar story: a subset of students worked on a poster for our campus showcase event, and just before they finished they asked for my feedback, and I saw they had designed it in Photoshop. These two short stories paint a picture of students who focus on doing what they know, rather than asking whether it is the right thing to be doing.

We can take "Missing the Big Picture" a bit more scientifically and apply the lens of the Dreyfus Model of Skill Acquisition. Being a novice or advanced beginner in this model means that you don't want to see the big picture and that you cling to the rules without considering the context. Of course, second-order ignorance is a defining characteristic of being an advanced beginner: I don't think the decolorization or the inappropriate use of Photoshop were malicious, but they were certainly ignorant. Perhaps then this is a call to action for me as a mentor to find ways to improve my awareness of the activity of the studio so that I can intervene more quickly to find the Zone of Proximal Development: find that critical difference between what students can do by themselves vs. what they can do with my assistance, and then help them advance from there. I think this is especially hard on a team where there is generally low knowledge about all the steps required, although this is a situation I have had the past few years in the Spring Game Studio. I am excited that in the Fall, I will be able to teach Game Programming before doing another Game Studio course in Spring 2018, since I think this kind of sequencing can help raise the bar of student understanding. Then again, maybe it's a false hope, since last year's excellent work didn't have this benefit, and it wasn't clear that the two students from last Fall's game design course became well-informed leaders of our design process. Maybe it's just more puzzles, and it still just has more to do with having the right people regardless of their backgrounds. It's a conundrum that despite years of doing this kind of work, I'm still not sure how to approach. My next step will be to take a closer look at Google's Re:Work, to see if I can find any evidence of local trends that would align with or conflict with some of their findings.

Official team photo with Amazing Backlit Action and Wall Phantoms

During this semester, I listened to some Robert Martin and Allen Holub presentations while painting, and these got me thinking more about how agile principles can be deployed with students. I was particularly struck by something Holub said during his "Death of Agile" talk: "This is a process for adults." To use the popular vernacular, some of my students have serious issues with adulting. I have written several papers on the use of agile techniques in undergraduate teams and I have read many more, but I do not remember this particular perspective brought up before. Another point Holub makes in his talk is that the fixed durations of Scrum's Sprints are decidedly anti-Agile. These two pieces have been turning around in my mind. Does Scrum work with students because it is not agile? Given a team that cannot complete a sprint, would they do better without the artifice of a sprint, or would they do worse? I had a similar thought after reading Kent Beck's excellent Extreme Programming Explained 2nd edition: can a team of novices go full-XP, or would their lack of experience cripple them? I will point out that these are all empirical research questions, but I don't have the resources to conduct the experiments or case studies necessary to investigate them, so I'm left in the land of craft rather than science—not necessarily bad, but also not provably good.

I know that most of the team had a great learning experience. I have observations of their activity, their essays reflecting on experiences, and knowledge represented in the artifacts themselves. Truly, in addition to the normal learning I expect, I saw some great transformative moments for students—but not for all. In determining students' final grades, I went back and reviewed their essays through the semester leading up to the final, which consisted of two reflective essays. Some did not actually show any signs of having learned much of anything, neither about the interdisciplinary goals of the course nor about how to learn from reflective practice. I re-read the feedback that I gave them as well, and it was sad to see how some of them apparently did not act upon any of it. 

Several members of the team were sophomores and juniors, and this means that I can continue to work with these students during their time at Ball State. Several have signed up for my Game Programming course in the Fall, and I look forward to getting them into leadership positions where they can draw upon their experience in the studio to foster success. Next year, I will also be continuing my own explorations into geolocative game design and interactive narrative—a topic I expect to blog about soon, so I'll link that in when it's ready.

The number of people who will ever play Spirits at Prairie Creek is pretty small: just getting the word out about any digital product is a challenge given how much stuff is available online. For us, we need players to not only know about it, but to also be at specific place to play. We have Google Analytics tracking plays, and I'm hopeful that Camp Prairie Creek will help spread the word about the game. In the meantime, we have an interesting game design, although it's not clear if I can turn this experience into a conventional scholarly article. I think there's round here for a great empirical evaluation, but I lack the resources to conduct that myself; maybe someone will be interested in doing this as an honors thesis.

And finally...

An easter egg for those who read this far, a late-semester alternative rendition of the team's slogan:

Thanks for reading! As always, please feel free to share your feedback in the comments. If you try the game, let me know what you think!

What We Learned in CS222, Spring 2017 Edition

It is time, dear reader, for the End of Spring 2017 Blog Posts!

I want to start with my traditional "What We Learned in CS222" post, wherein I share an overview of what my students believed they learned in CS222, as self-reported on their final exam. This semester, they came up with 104 items in half an hour, which struck me as kind of low, but it was also a talkative group: several had a rather long wind-up to stating the item that would eventually be written down. Each student was given five votes to identify the items that were most important to them. After voting, we gathered items with the same number of votes into bins. These were the top five—the items with four or more votes:

Item	Votes
Clean Code Naming Rules	9
Test-Driven Development Process	8
Single Responsibility Principle	5
User Stories	4
Test often	4

Interestingly, the first four on this list were the first, second, seventh, and eleventh items listed, while the fifth was the very last—the 104th.

Regular readers may recall that "Clean Code" usually comes up early and is highly voted upon. I was surprised when the first contribution from the students was not just the generic "Clean Code", but specifically the naming rules. It's true that students continued to struggle with naming rules throughout the semester, but I do not think that this was much different from any other semester.

I'm not sure I have other new reflections on CS222 that I haven't shared before, except that there were a few times during the semester that I realized too late I should have had achievements for out-of-class activities that I value. The first was the CS120 Art Show, which is run every semester by my friend and colleague David Largent. We use a media computing theme in CS120, and the Art Show is an opportunity for students to select their favorite work from each section and have it showcased in the Atrium on campus. Celebrity judges then give awards based on the visual design as well as the source code design. Most of my CS222 students went through this course, and it would be valuable to have them go talk to the first-year majors and minors about their experiences. Since it's valuable, I could easily make it an achievement.

Similarly, reading students' essays at the end of their third-and-final project iteration, a few mentioned getting feedback from Code Smash!, which is the closest thing we have to a CS club. Most that referenced it talked about getting feedback from upperclassmen, while one wrote with pride about how a particular aspect of his final project let him help an upperclassman. It got me thinking that participation in Code Smash is valuable and should be rewarded, and as I considered this, I realized the somewhat special place that CS222 students find themselves in: they know much more than the freshmen about programming, but they know much less than the seniors about the various subdisciplines of Computer Science. I can imagine adding some kind of achievement to reward either "reaching down" to help those lower in the curriculum, "reaching up" to get help from someone with more experience, or maybe a single achievement that takes the two experiences and invites reflection on the contrast. I am uncertain whether this would be the same as the Art Show idea or if it has a different spin, but it's something for me to consider when I do my annual course redesign.

A few days ago I wrote about the attendance problem in CS222, in the context of our roundtable evaluation. This has been simmering on the back burner, and I wonder if the achievement system provides an answer here as well. The truth is, I don't want students to come to class "because they have to." That's the wrong attitude, and it fosters disengagement and bitterness. Frankly, those students need to mature before they can succeed anyway. However, I can use achievements as an incentive, and I can perhaps close the loop between the in-class activities and the final projects or essential questions. I am thinking of an achievement that asks a student to reflect on three in-class activities they participated in, encouraging them to draw the lines between the specific actions of the activity and the goals of their project teams.

Next Fall, we're finally moving CS222 back to a Tuesday-Thursday 90-minute schedule, the way that it was the first 2–3 years it was offered. I have been asking for this revision for years, since 50 minutes is just not enough time to introduce an idea, engage teams in meaningful work, and have them share and reflect on their experiences. This means I will have to do some rather significant revisions to my course plan during my annual course redesign. I used to give daily assignments that were due Tuesday and Thursday, which caused some whinging from students but also kept everybody on strict schedule. I stopped doing that with the switch to MWF because the grading load was too high for me to keep up with. I am leaning toward bringing those daily assignments back as a replacement for the more broadly-defined weekly assignments I have been using for a few years. I expect I will post again over the summer as I sort out those details.

Thanks for reading!

Painting Descent Visions of Dawn, Part 1: Monsters

A few months ago, my brother bought me the Visions of Dawn expansion to Descent 2nd Edition. He knew I had been working on painting the base game monsters and gearing up to try the Road to Legend co-op app. His main reason for choosing this particular Hero & Monster expansion was one of the heroes, but I was honestly most excited about the monsters: more variety in monsters is always good, and I've always had a soft spot for manticores. As the semester has wrapped up, so has my painting of the six monsters from Visions of Dawn.

Ogre minion, front

Ogre minion, back

Ogre captain, front

First up are the ogres. I started with the metal pieces so I could drybrush chainmail with impunity. The flesh was then done using two-brush blending, and I am quite pleased with how that turned out. Maybe the shadows could have been even darker, but regular readers would know that's something I perennially question as I try to gain a better eye for contrast. As with the core set monsters, I've distinguished the captains in this set by including red features—for the troll, the glove and gorget (if that's the right term for it). The ogres took the longest of the three monsters in the set due to the number of different pieces and the nice quality of detail. I was worried that my approach to the metals was a bit too lazy, using a base coat, wash, and highlight, but really I think it turned out fine. The ogre's sword was large enough that I decided to try to do some fancy highlighting, running the highlights in opposite directions on the top and bottom sides of the blade, as described in this Massive Voodoo post. Mine was really not that impressive, but it's fine for tabletop quality.

As I started writing this up, I realized that there might not be much of a sense of scale for these guys, so I shot a bonus picture of the ogre captain fighting Master Thorn.

Ogre captain vs Master Thorn

Master Thorn seemed like an appropriate figure to pick since he's actually one of the heroes in Visions of Dawn. I have the figure from my painted set of Runebound heroes, although looking at the sculpt in Visions of Dawn I noticed a small difference: mine has his staff affixed to the robes, whereas in Visions of Dawn, it is separated. Looks like my Runebound copy may have actually had an error, unless they changed the mold at some point. No matter, I may just give the extra one to one of my boys to paint sometime.

Now, on to the next monster!

Troll Minion, front

Troll Minion, back

Troll Captain, front

All these figures were primed black, and I started the trolls with a total skin covering of cold grey, planning to layer up the highlights. For the belly area, I mixed a cold white and wet-blended it into the grey; the result was good, but it's a technique I should practice since I don't use it too often. I am pleased with the darker textured areas around the shoulders, as well as the dark spots on the sides. I think I could have gone in and darkened the recesses even more, but I didn't want to overdo it and risk trouble with that tricky white-grey transition. I also used layering for the loincloths, working up from a dark shade to tan or red. For these, I was sure that I had used too much contrast. However, I had recently watched Atom Smasher's interviews with several painters at Adepticon, and I was struck by the advice to carry a project to completion even if uncertain, since it's only at the end that you can really evaluate it. In fact, now I look at it, and I think it's fine. Perhaps it's yet another indication that I should be using even more contrast.

The massive stone club was painted using a different technique than the rest of the model, picking a slightly brown grey as a base color, washing with a dark brown to deepen the shadows, and then bringing the highlights back up. I am happy with the contrast here too, both on the stone and between the stone and the winding cables holding it to the shaft.

I'll point out here that in the card art for all three of these monsters, none of them have pupils, and I decided to follow that in my painting. The ogres and manticores have dead white eyes, while the trolls have red eyes. It's fine. I think the manticore's is best, and speak of the devil...

Manticore minion

Manticore captain

Manticore captain

Since my days running tabletop RPGs, I have always found manticores to be particularly creepy. I think it's the savage human face combined with the animal body. I don't know that I threw them at my players more often than anything else, and certainly less often than staples like ogres and orcs, but still, they made the occasional menacing appearance. My brother assures me that these will scare the chainmail socks off the heroes in Descent too.

I was able to paint these fairly quickly since although it's a nice sculpt, there's not a whole lot of variation. I base coated and drybrushed highlights onto the fur in two tone combinations, and then I applied a series of washes to add depth. I did some manual highlighting on the darker fur, and I added a little more wash to the undersides and shaded areas of the light fur. The face also got manual highlights to give it a bit more pop.

The tail and wings were done in a different shade, mixed from black, beige brown, and buff. My first pass at the wings, I thought they were too plain, so I brushed in some horizontal striations as highlights, remembering Dr. Faust's video about it. I found these lines to be too bold even after a few layers of ink wash, so I changed tack and just painted the base color over it again. This hid the striations, although if you look carefully they are still there. It's probably too subtle to make a real difference, but I like the idea that they add subtle texture. Truth is, the wings were just kind of a drag, and so after getting a good color and layering on some mild highlights, I was ready to be done. I think of these as velvety bat wings anyway, and therefore with more diffuse highlights than something like scaly dragon wings.

The only difference between the captain and minion is the stinger on the tail: on the minion, there are dark brown spots and stinger, and these are red on the captain. This difference is probably too subtle to pick out from any appreciable distance. However, playing Road to Legend with my wife and son, we realized only one deploys at a time anyway, so there's really no great need to distinguish them.

Varnish wars

There's one more note about this little painting adventure. For some time I have been using Golden's matte varnish, which dries quickly to a nice matte finish. I undercoat this with a gloss varnish for protection. Then I give one coat of the matte, wait a bit, and then use a second coat to touch up spots that I missed. Then I roll my eyes and use a third coat on the spots that I missed again. Then I say, "Nobody will notice those spots." The Golden varnish is very thick, a gel consistency, and the instructions are to thin it 25% with water. This is no problem, although it is a bit tedious, and it does mean that the consistency is not always the same.

The other day, Ghool posted a video about brush-on varnish. I have appreciated Ghool's videos about using brush-on rather than spray products, and I have been experimenting with brush-on primer in painting my Descent heroes—more about that in the future! Ghool is also very responsive and helpful in the comments to his videos. Anyway, I happened to have some Vallejo Matt Varnish, which I suppose comes from the land with a dearth of 'E's. I picked up the varnish on a lark once and I cannot remember what I tried it on, but I was surprised at how runny it was. I decided to use the Vallejo on the manticores here. After one coat, it had dried fairly quickly to a nice, slightly satin finish---not as flat as the Golden, but still pretty good. I needed a second coat anyway to cover the spots I missed, and the second coat took the shine down even more. Looking at the manticores next to the trolls, the trolls are really flat, with not a hint of sheen, while the manticores have slight reflectivity. However, I do have occasional problems with the Golden varnish, where I get a build up of matting agent in the recesses: the greyish powder is easy to miss at a cursory glance, but it is noticeable on inspection, and its appearance may be related to the dilution precision and thinness of layers, but I've never quite nailed it down. It's more prone to happening in highly textured areas, though, like the ridges in the trolls' loincloths.

Here's the other piece, though: that Golden varnish has all sorts of health warnings on it. I always take care not to get any on my skin and to wash everything immediately afterward. Is it worth the stress and hassle for completely flat models? I'll have to evaluate it again under my gaming lights.

A happy, evil family

My wife, my son, and I enjoyed the mini-campaign of Road to Legend, but we put it aside while I painted up these monsters to add to the mix. I'm looking forward to trying the full-length campaign with them, especially now that the semester is winding down and my summer schedule is almost upon me. We'll make due with the subset of heroes I have currently painted, figures that were prioritized because they were the ones we wanted to play. I imagine I'll get back to painting those base set heroes or the Visions of Dawn heroes next, but you know, I always have a few tricks up my painting-flannel's ratty sleeves. Certainly the next set of posts will be end-of-semester reflections, in any case.

Thanks for reading!