What if Mario could choose his Princess?

I had my game design students read Keith Burgun's "What Makes a Game?" essay. I think it's an interesting perspective for helping students think about the roles of decisions, solutions, and ambiguity in their game designs. I used it myself a few years ago in a retrospective on my own game design projects. As I have done in the past, students had to bring with them examples from each of Burgun's four levels: Interactive System, Puzzle, Contest, and Game. I pointed out to my students, as I will also do for those of you unfamiliar with Burgun's taxonomy, that the names of these levels are essentially arbitrary: he's not claiming that only things at this level in his taxonomy count as "games", but rather that the things at this level in his taxonomy are what he references as "games." This is reminiscent of the classic McDermott article, "Artificial Intelligence meets Natural Stupidity," which points out that just because you make a Lisp function called Understand doesn't mean that you've made a program that understands anything.

A student presented 2048 as an example of a Puzzle, Super Mario Bros as a Contest, and Hearthstone as a Game. This was enough to spur serious conversation when I asked if the rest of the class agreed or disagreed. Students provided reasonable justifications for their claims. Once the conversation settled down, I clarified the taxonomy based on having read several other essays by Burgun as well as his two books, Game Design Theory and Clockwork Game Design. In one of those (I honestly cannot remember which), he uses Super Mario Bros as an example of a Puzzle because there is a series of inputs that will lead you to the "correct" solution. I pointed out that, in Burgun's lens, the choices you make in a level are not meaningful, not in the same way as the moves are in a game of Hearthstone. We also discussed how you could turn a Puzzle like Super Mario Bros into a contest by, for example, trying to beat your past high score, or by playing it in a tournament, but that now you're essentially making a new Contest where Super Mario Bros is one of the elements.

This got the students thinking back to their understanding of the reading, and I asked them to look at their peers' work, which was posted to the classroom wall, to see if they saw anything in particular that they thought strongly exemplified—or completely missed the boat about—Burgun's taxonomy. One jumped out to me: a student had identified Fallout 4 as their example of a game. I asked if, after the previous discussion, they agreed with this assessment. A student responded that, indeed, because the game has multiple endings and your choices are meaningful to which ending you get, that it was therefore a Game. This got me thinking about the Super Mario Bros example, so I took the devil's advocate position and asked, "What if, at the end of Super Mario Bros, you got to choose whether you got a blonde princess or a brunette princess? Would that now make it a Game instead of a Puzzle?"

We had actually run a minute over time, and so I left them with the challenge of considering where Fallout 4 fits into the taxonomy. As we packed up, one of my students told me that he was pretty sure it was "just" an Interactive System, and not a Puzzle, Contest, or Game. I encouraged him to write up his thoughts on the discussion board or share them in our next meeting.

I wanted to capture this little piece of my teaching experience in part because I like the idea of adding "narrative choice" to Super Mario Bros. I think we can all look at that and say it's not really an interesting decision, but it's harder to distinguish the systemic differences between choosing your princess and any of the binary-ethical-choice BioWare games. Isn't Mario choosing his princess effectively the same as Commander Shepard seducing a selected crew member? What if it didn't matter what you did the whole game, you just picked an ending that you wanted? Then, as I was writing this, I realized that I was describing the conclusion to Deus Ex.

The Paper Metaphor and the Brainwashing of Writers

I had a parenthetical phrase in my previous post that was about as long as the paragraph that contained it, so I decided to extract and reform it into its own post. It's something that's been on my mind the last few days in two of my classes, specifically game design and human-computer interaction. I'm using Google Docs in these classes, as I have done for years in many classes. Google Docs has some excellent affordances for learning, perhaps the most obvious being that student teams can collaboratively write in a convenient way. To me, however, this feature is secondary to the ability to highlight and comment on specific parts of a document and then to transform that comment into a conversation in the margins. If I see something interesting or confounding or insightful in a student submission, I can highlight it and leave a comment. The comment might be a question designed to make a point, an honest question of my own curiosity, a reference to relevant work or other student work, or really anything else I can express in text. Whoever wrote that section of the document gets a notification, and anyone who reads the document can join in this comment thread.

The problem is that my students are not responding to the comment threads. In fact, I believe that this entire semester so far, no student has responded to or even resolved my comments in any of their submissions. I paused to wonder why this was the case, and I came up with two answers. The first is the simple pedagogic answer that I had not incentivized them to do so. Students, like many of us, are busy—some are even busy with with their studies. If there is no incentive to respond to comments, then why bother?

When I teach CS222 (Advanced Programming), I often use a resubmission policy through which students can rework old assignments, learn from their mistakes, and resubmit for course credit. If a student resubmits something and they have not responded to my comments, they should expect me to simply kick it back to them. I believe that this policy is generally good for students, since they have a real incentive to learn from their mistakes, although it also has the negative consequence that some students submit substandard work knowing they can resubmit it later. That aside, the resubmission policy requires a lot of effort on my behalf: not only do I have to grade a submission more than once, I also have to try to understand and comment on the differences between the original and the revised submission. The burden on my time is one of the reasons I am not using a resubmission policy this semester.

I think there's something going on here besides just the incentive structure, however. Conventional educational practice involves students "turning in" work to the teacher, who then evaluates it, assigning a grade and giving some feedback. A student gets the paper back, looks over the comments, and then discards it. Online writing environments like Google Docs draw upon a conceptual model of writing on paper, in part because the legacy of text editors is often tied to the concept of printing onto paper. It's worth noting, however, that "plain text" editors make no such pretense. While it's possible ti know what "page" you're on when programming in your favorite programming environment, nobody does it. Concepts like "page" are purely metaphorical in a digital writing environment: there is not a "page" at all, not unless work is printed onto said page. Because rich text editors draw upon the conceptual model of paper, however, students get drawn into the same one: whether a student gives me a URL or a printed sheet, the culturally expected behavior is the same. This phenomena rose its head earlier this semester when I noticed how many students were putting hard page breaks into their Google Docs documents that are intended to collect all their work. This makes it tedious for me to scroll through their work, because to me, the conceptual model is "chronological log of work," but to them, the model appears to be "series of pages of work."

What I intend, when I leave comments into a student's document, is the conceptual model of conversation, not submitting paper to a teacher. Imagine sitting with a student who makes a claim such as, "I don't think Don Norman gives enough credit to the role of amateurs in his discussion of the future of design," and you say to him, "Why is that?" and then they simply walk away. Cultural constraints around conversations tell us that this is not only strange but rude. However, I have left, oh, let's say thirty questions in students' submissions already this semester, and they have all essentially got up and walked away. I think it's a mismatch of mental models: I think we're having a conversation, where they are in a transaction.

Unfortunately, it's not clear to me how to encourage students to use the feedback-as-conversation mental model without adding incentives such as resubmission. This means that once again, it breaks away from being an exchange of ideas and into a transaction around points. There's always the opportunity to turn it into an achievement in a course that uses it, although I'm not using many achievements this semester as I experiment with specifications grading instead.

My observations beg the question, "What would a digital writing environment look like that fosters the conversation rather than transaction mental model?" I hate to beat a dead horse, but I think this is exactly what Google Wave was getting at, and perhaps is one of the reasons why it didn't catch on. It was solving a problem that people didn't know they had, because they were locked into a different conceptual model of how writing and conversations manifest. For programmers, the answer is clear: digital writing looks like GitHub, which integrate writing and conversation along with version control and issue tracking. If GitHub supported commenting on text without needing a pull request, then perhaps using it and Markdown would be a viable alternative to Google Docs for the kind of learning environment I want to foster.

Fairy Trails as a Lens: A Tale of Classroom Surprise

Regular readers will remember that last Spring, my immersive learning team—Guy Falls Down Studio—collaborated with Minnetrista to release Fairy Trails. Fairy Trails was a notable project for its unconventional design. It is a geolocative game based on Minnetrista's campus, what I have sometimes called "hyperlocal" because you can only play it at these specific places in Muncie, Indiana. It is driven by an Android or iOS app, but the gameplay happens in the physical world outside the app. This is done in part by designing the app for facilitators, those who bring others to Minnetrista and are focused on these others' enjoyment. This design decision was made in consultation with Minnetrista, who use a local modification of Falk and Dierking's taxonomy of museum visitors to describe who comes to their site.

This semester, I am teaching my Serious Game Design colloquium through the Ball State Honors College. I posted about the course design a few months ago. I am continuing my partnership with Minnetrista, and so one of the major outcomes of the colloquium should be that each student produces an original game design based on our partner's themes. I have also peppered references to Minnetrista through the exercises in the first half of the semester. This semester's students had to play Fairy Trails in the first week of classes. A later assignment involved writing a critical analysis of a game they had played, and I was surprised how many chose to write about Fairy Trails. In almost all of these essays, the students made claims about (1) what, in their mind, the game was supposed to teach, and (2) about how it failed to do so. When I pushed back on these claims in my comments on Google Docs, none responded.

The assignment due yesterday involved the students' reading a chapter and a short summary about taxonomies of players and fun, and then to propose new fairy encounters for Fairy Trails, drawing explicitly upon the taxonomies in the reading. Here's the surprise hinted at in the title of the post: some of their designs were really good. Let me share with you a few of the more memorable ones:

• Several designs involved the herb garden, in which the players have to try different herbs and then are encouraged to gather a few for home cooking.
• At the wishing well, the players each make a wish. The fairy asks them to categorize each wish as love, fame, or fortune; they are then rewarded with an excerpt from a classic fairy tale based on the same theme.
• A fairy wants to get from the Oakhurst mansion to the E.B. Ball Center, but she has to stay in the shade. The players have to take paths through the Oakhurst Gardens rather than taking the direct route along the road.
• A few students involved the nature area in reflective exercises, including one that involved finding different particular sites or species on the trails. 
• A fairy explains that the Ball family had an enormous collection of fairy tales because Elizabeth Ball's love for them, and then asks each to share their favorite book.
• A fairy encourages players to engage in a game of hide-and-seek in the Oakhurst garden.
• A color fairy in the backyard garden invites the players to find and share colorful discoveries with their friends.

To me, the most fascinating part of this list is how different it is from anything we discussed in the production of Fairy Trails and how different these are from the kinds of prototypes built by last Spring's class. The crucial difference between last year and this year is, of course, the creation of Fairy Trails itself. I suspect that having this game available changes the lens through which students can consider the creative challenge of incorporating Minnetrista's themes into a game.

After their presentations, I asked the students to reflect on how these ideas came to them. In particular, I wondered if these were ideas they had from before playing Fairy Trails, immediately after playing it, or in response to the aforementioned readings that they had successfully incorporated into their presentations. Many of them responded that they felt the original Fairy Trails fell flat for them: they had assumed before playing it, based in part on my explanation of the course, that it should have more explicitly informative and educational material about Minnetrista. Those who have played the game know that it does not: it contains three fairy adventures that are designed to be fun for groups to play, especially family groups, and it is not at all didactic. Many of this semester's fairy designs then were informed by this idea, such as including reference to the Balls' fairy tale collection and the fact that you can sample and collect herbs from the garden. The student who designed the scenario to roam the nature area wanted something "less childish" than the current game. The hide-and-seek designer noted that Fairy Trails does nothing competitive, and so he was inspired to create something that would appeal to player types not currently served by the app; he used the readings to inspire him along an angle that he wanted to include. Only one student said that the readings directly influenced her design: she had noticed earlier in the semester that no existing fairy used the herb garden, but had not dwelt on this. When she read about "sensation" as a kind of fun, it brought this to mind and she realized that she could use taste in her fairy encounter.

We discussed briefly the fact that several people had chosen the herb garden (and one, the community garden) as locations, while the Fairy Trails production team never considered these. I wondered at this for a few moments until I remembered that we designed the game in the winter! Although last Spring's studio team could see where the herb garden and community garden would be, we could not actually see it functioning. I think this gave that team a blind spot that this group, who visited in the peak of herb and vegetable season, was able to see and take as inspiration.

Several of these fairy encounters are very exciting to me, but I don't currently have a team who can put them into the existing version of Fairy Trails. It's still a toss-up as to whether we will expand on the existing app in the Spring or whether we will pursue a different direction. In any case, I wanted to capture some of these experiences here on the blog. Even if we do not come back to them as inspirational fairy encounters for Fairy Trails 2, I think it's quite interesting how having a working version of the game changed students' ability to conceive of interactive, Minnetrista-themed activities.

Configuring Perforce Helix for simplified Game Programming project grading

My game programming students had their first mini-project due yesterday, and I'm happy with the results. The "Angry Whatevers" project is designed to get students familiar with UE4 and Blueprint by making a simple fire-a-projectile game. It's essentially the same introductory project I gave in Fall 2017, when I first switched the course to UE4. However, this year's projects were on average much more interesting and higher quality. I attribute this to two factors: first, I used a specifications grading approach, which made it very clear to students what they had to do to achieve different grades; second, I am more seasoned with UE4 and was able to articulate, teach, and clarify more easily than last year.

Last year, we used GitHub for version control, but this caused several problems for us, the most pressing of which was that a distributed model doesn't work well for the non-mergable binary assets that constitute the bulk of a Blueprint-based UE4 project. In the Spring, I learned and deployed Perforce Helix with my studio course, and I decided to go ahead and use that for this semester's game programming course as well. It was a little choppy to get started as I had become rusty with some of the core configuration. My first pass involved making one depot per team, but I my conceptual model of workspace mapping was wrong.

When I spent several hours trying to rebuild my understanding of Perforce Helix and how to integrate it with the course, I realized that I could get away with one structured depot. This depot was called CS315Depot, and I wrote up instructions and recorded a private YouTube video explaining how to set up the mapping. One of the crucial steps that I had forgotten was not to use the graphical mapping tool in P4V. Instead, we used the text-based mapping specification, so that if I was working on a Project 1 ("P1"), then I would make a workspace called PaulGestwicki_Laptop_P1 and use my UE4 project as the project root. Then, I use a mapping to the depot like this:

//CS315Depot/P1/PaulGestwicki/... //PaulGestwicki_Laptop_P1/...

What this does is map all the files in my local workspace to the folder P1/PaulGestwicki on the depot. The real magic, then, is that when I want to grade the first project, I can make myself a new workspace, something like PaulGestwicki_Laptop_GradingP1 and map it to the whole P1 directory:

//CS315Depot/P1/... //PaulGestwicki_Laptop_GradingP1/...

In one action, I can grab all the student projects into my workspace and then batch-grade them, without having to make N trips to the depot or create N different workspaces. Also, I could easily set up one group (CS315) for all the students and give that group write access to the shared depot and read access to my depot of demos. Note that this does mean that students can check out each others' projects, which I am happy to support; it also means that they can accidentally destroy each others' work, but that's why we have version control in the first place.

One of the common errors I saw with several students was that they forgot the last slash in the mapping, which ended up with them dumping their Content, Config, and .uproject files into the root of the P1 directory, prepending their usernames to each file. Some students recognized the problem, and I was able to just obliterate their old files so they could try again. Because it was so easy to recognize the error by glancing at the depot, I was also able to email students and point out where they had unwittingly made a configuration error.

Perhaps this idea will be useful to you, dear reader. In any case, I hope it will be useful to future-me in case I forget how to do such a thing in the future! I offer my public gratitude to Perforce for their academic licensing that allows my students to use their software, and of course, gratitude to Epic for the very generous licensing of Unreal Engine.

UPDATE: When I went to adjust some grades the other morning, half the projects were gone. I looked at the changelog history, and I found one that looked suspicious. It touched every file in the depot, which makes me think they had a mapping wrong. What was really strange to me was how this affected the tools themselves: when I viewed the project in p4admin, I could see all the files I expected; when I viewed in p4v, half the student folders were gone and could not be mapped. I am still quite perplexed about what could cause this. However, the good news is that after I backed out that changelog, everything ended up back where it was supposed to be. Version control for the win!