Reflections on the making of Fairy Trails

Last semester, I mentored Guy Falls Down studio in the creation of Fairy Trails as part of a collaboration with Minnetrista. As is often the case, I did not blog as much about the experience as I intended, sharing only this story about a design epiphany, our excellent coffee burn-up chart, and a few words about a frustrating version control oversight. I remember that there were several instances that made me think, "I should blog about that," but as time went on, I would forget what they were.

Here's the TL;DR: Fairy Trails is a free app for groups who are visiting Minnetrista's beautiful campus. You can find it on iTunes or the Google Play Store. It is an app for groups: one person installs the app and leads their group on a fairy-finding adventure. Enjoy!

For the rest of you, read on for a few more stories and reflections about the experience!

Fairy Trails Main Menu

The "Put down the duckie" post does a good job of introducing the essential elements of the background and game design. What I would like to do here, a bit like my Spring 2018 HCI reflection, is to pull out some of the most important anecdotes and lessons. This makes it easier for me to look back and remember what I thought I learned, and I hope it makes for interesting reading for others as well.

Good: Spending time on one scenario

One of the questions that students could address in their final essays dealt with the differences between their expectations at the start of the semester and what we produced. Many of them wrote about how they expected to make a game where you find a wide variety of fairies; in Fairy Trails, we have three. In fact, we almost had only one! We spent many sprints iterating on one scenario, the one which would become meeting Henrietta at the wishing well. During this time, the team was getting up to speed on Unreal Engine, Perforce Helix, and working across conventional disciplinary boundaries. More importantly, they were coming to understand what we were actually doing: making a game for groups that is moderated through an app.

Some of the students get a bit antsy about working on only one scenario for so long, but I kept reminding them that we could negotiate scope, but we could not negotiate quality. I think this was hard for them to recognize since a subset of them assumed their designs were fine in absence of playtesting. Frustratingly, some of these students had gone through my game design course the previous semester. You'd think if you learn nothing else from that experience, you would learn that game design is hard. Maybe that's a call for me to make even more structural changes to the course to drive that lesson home.

I think many other students had a more important realization, though, when they saw that iterative refinement was such a powerful technique. In our final retrospective, we loaded up the initial minimum viable product that the team produced and ran it beside the final version. They laughed about it, saying, "I can't believe we thought that was good!" Of course, at the time I had congratulated them on their accomplishments while recognizing they were on the road to doing much better.

A subset of Guy Falls Down Studio at the Butler Undergraduate Research Conference

Risky: Not spending enough time on the others

As we finally wrapped up the Henrietta encounter, the team started looking at what would go into making two more encounters. It wasn't the student who had the excellent learning experience of leading the design of the first scenario, with all its multiple prototypes and user testing; it was the ones who clearly had not learned the lessons of the first one.

Fairy Trails is a geolocative game that is supposed to be closely tied to Minnetrista's grounds, but it wasn't until several hours into their paper prototyping that they admitted that they had not been to the scenarios' locations. I encouraged them to put on the brakes, to make the half-mile journey to Minnetrista, to go to those locations and seek spatial inspiration. Their response was to hop on Google Earth. I was flabbergasted, and really, I still am. These guys had no sense of the value of space and yet were designing scenarios that were supposed to reflect that value. They charged forward with paper prototypes, reporting soon afterward that they were ready for implementation. I asked if they had done any playtesting—no. I asked if they had done any on-site testing—no. I asked how they knew that these these scenarios were good? They responded that they learned from the process of making the first one, and so these scenarios would be good. You know what I say to that? No.

The end of the semester was approaching, and the team decided to take the creative risk of incorporating the two additional scenarios as-is. The last day of the semester, I sat with the student who had been de facto lead on the wishing well scenario and we edited practically all the text of one of the scenarios. I also improved the usability with a bit of Blueprint scripting after the semester ended, as I was shepherding the app through the iTunes approval process—a simple fix, really, and something that any rudimentary playtesting would have discovered.

It was not an unreasonable risk for the whole team to agree to incorporate these two extra scenarios. Indeed, shipping a title where you only find a single fairy was a worse risk! What is unreasonable, to me, is the lack of rigor in the process from students who should have known better. Was it ignorance, pride, lack of good coaching, or a combination of factors? Is there something I could have done differently that would have had them get off their butts and go to Minnetrista? It's not clear to me.

Henrietta will meet you at the wishing well

Incidentally, I do wonder if past team members read my blog and what they think about my reflections. There should not be anything here that they have not heard from me elsewhere, and hopefully they will leave a comment if they saw or remember something differently. Sometimes events happen in the studio that I don't blog about at all, hoping that I will simply remember my lessons without airing our dirty laundry on the Internet. One of my fears is that I will repeat the mistakes I don't write about.

Conundrum: Having a methodology is different from using it

For many years, I have given my students a "Starter methodology" based on best practices of agile game software development. It includes a mixture of technical and social rules. One item I added several semesters ago—maybe inspired by my work at the VBC in 2012, although I do not quite remember now—was a protocol for resolving design conflicts. The protocol itself is simple and elegant, and it's designed to combat the endless discussions and justifications in which students (at least) are eager to participate. If a design discussion goes on for more than five minutes, then you transition to prototyping; the discussants chose a timebox, build something to show their idea, and then bring that back. Now, you're evaluating artifacts instead of amorphous ideas. When this is followed, it usually doesn't even get this far, because someone will realize their concept just doesn't materialize as they expected it would.

On paper, that's a great idea. In practice, the team has to actually follow it for it to be useful. Let me say clearly and for the record: this was a really good team! Everyone can fall into the trap of endless discussion or analysis paralysis, though, and this team had a hard time with it. Sometimes it was because of ignorance or confusion, and sometimes it was because someone just wouldn't let go of an idea. What's interesting is that the students recognized in their retrospectives and essays, over and over again, that they were aware of the protocol, they did not follow the protocol, and they regretted not doing so. There are lots of tips and tricks in the starter methodology that I have picked up over the years, such as requiring that students who come late to a meeting bring treats to the next one. It's less clear to me how to quickly get students on-boarded, especially since each team is a new team: they have to learn the lesson that is crystallized in the methodology statement before they can recognize that they need it.

Meet Francine at the Rose Garden

Smooth: Unreal Engine and Perforce Helix

Three team members coming into the Spring game studio course had just finished up the game programming course that I taught using Unreal Engine. They were instrumental in convincing the rest of the team that UE4 would be a good technology to use: it was free, Blueprints scripting was eminently learnable, and it could scale up to incorporating advanced augmented reality if we desired. (We would end up not incorporating AR due to the time required and device restrictions.)

I was really impressed with how quickly the other team members were able to get in and get productive with UE4. Of course, these were bright and ambitious students, otherwise they would not have applied to the studio and made the cut. Several of these students had just taken CS222, and one was actually taking CS222 concurrently with the game studio. By the end of the semester, some of these guys were outperforming the graduating seniors, by their own admission. 

The team spent a lot of time creating interactive UIs with Unreal Motion Graphics (UMG). They did struggle a bit in the way that a lot of novices do when given a tool like this: they slapped pieces together until it worked right in one particular configuration and then assumed they were done. Even after showing them how to test different screen sizes, some still struggled to incorporate that into their workflow. Once they learned how to use the tool correctly, rather than hoping random mutations would work, they became more reliable in this regard.

The previous semester, we had used GitHub for version control, but this was not really the right tool for the job. UE4 uses practically all binary assets, which cannot be merged, and git does not natively support file locking. I was able to secure an academic license to use Perforce Helix, which is integrated nicely into UE4; aside from a few hiccups, it was smooth as silk. Everyone appreciated the ability to lock assets, and being collocated or on Slack, it was easy to communicate about who needed what. I think the guys who had struggled with GitHub were most appreciative about this.

Meet Chestnut at the Stage

Clearly: Guy Falls Down Studio

At one point, someone wrote or drew something on the board, and I pointed out that it looked like a stick figure falling on its head. None of this was caught on camera, as far as I know. For several years, I have used a team-building technique where a team only names themselves once they have had their first real success. To my mind, this is evidence that they are a team and not just a group of students. Given the many iterations on the first fairy scenario, it took a while for this group to name themselves. Once they started that process, they collected names on Slack, and "Guy Falls Down" came back up and won the day.

It's a fine name, and folks who don't even know the story have told me they think it's a classy name. What they don't know, though, is that I had proposed the best name. Ball State University started a new marketing campaign last semester based on the theme, "We Fly." The best name for a studio at Ball State would be, of course, "Wee Fly".  How did this one not win?

I suppose it's best that a student suggestion wins, but maybe they should have acknowledged that even if mine didn't win, it's clearly the best.

Guy Falls Down Studio Logo

Incidentally, every year, students suggest a name that ends with the word "Studios," as in "Guy Falls Down Studios." Then I have to ask them, "How many studios do we have?" There are inevitably students who are confused by this question and assume that pluralizing "studio" is just some kind of industry standard as opposed to, you know, plural.

Doomed: The Mac Guy

When I mentored the team that created Children of the Sun, I said I would never mentor another iOS project. You know, we get forgetful as the years go by, and somehow, people still keep buying Apple products and promoting their walled garden. Point is, if we wanted to get this app out to the most people, we had to consider releasing on both Android and iOS phones. This was another reason we chose Unreal Engine: we should be able to have one codebase and simply build for each platform.

Early in the semester, the team sought a volunteer from among them to figure out all the iOS stuff. This guy earned his stripes. The rest of the team was very grateful to him, teasing him a bit at the seemingly-ridiculous loops he had to go through while the rest of the team simply plugged in their Android devices and deployed. We're all grateful that he was on the front lines, teaching the rest of us what to do. I should give an extra shout out to Brandon Smith and Bryon O'Conner of the Ball State University Digital Corps for helping us out with the development, deployment, and distribution process for iOS.

Amazing: People

Speaking of amazing people, all of the wonderful artwork in the game was done by one very talented animation major. Occasionally I work with people and I get this, "I would hire them in an instant" feeling. She was one of them: smart, creative, thoughtful. We got her right into Unreal Engine and Perforce in no time, and her work—as you can see—is top notch.

I also want to mention George Buss, the Director of Experience and Education at Minnetrista, who was our main contact for the project. He was an amazing partner, coming to campus several times to meet with the students and answer questions, really digging into the students' designs, involving more members of his staff, and even putting on a workshop for the students about narrative design for museum experiences. I am glad to announce that he and I will be continuing our partnership next academic year. What form this will take is still on the table: perhaps a parallel project, perhaps an extension of this one. I'm still wrapping up Spring a month after the semester ended, so it's too early to worry too much about Fall! 

Wrapping Up

Come to Minnetrista, download Fairy Trails, and let me know what you think.

I believe, at long last, that this is the last of my Spring 2018 wrap-up posts. I haven't picked up my brushes in about six weeks. Time to remedy that. Happy Summer!