Author Archives: mim.harries@gmail.com

The Sculpture’s Journey (Transformational Game Design)

The Sculpture’s Journey is a cooperative tabletop game I developed for iThrive games, aimed at encouraging teenagers to develop a growth mindset. Specifically, I chose to build an experience that would help players recontextualize setbacks as opportunities for growth. Ultimately, I designed a game that provides a low-stakes opportunity for players to experiment (and be successful) with growth mindset behaviors and demonstrates the idea of gaining experience from failure in a concrete, literal way. I playtested with both teenagers and adults, and showcased the game at the Entertainment Technology Center’s fall festival, where several sets of teachers tried it for themselves and requested copies.

The complete game layout, including player instructions and Moderator Guide.

iThrive Games is a California-based company that focuses on empowering teens through gameplay. Through game jams and educational projects, they explore the potential for games to have positive impacts on teens. The Sculpture’s Journey was one of three games developed by my team at the Entertainment Technology Center as part of a semester-long project during the fall of 2017. As the game designer for The Sculpture’s Journey, I developed the gameplay and accompanying Moderator Guide. While the game can be played independently by two players, the Moderator Guide is designed to enable a third person (particularly a teacher, parent, or counselor) to guide the conversation towards the specific ideas they want to emphasize and help the players draw conclusions about how the game reflects their lives.

In The Sculpture’s Journey, the players work together to help two little clay creatures fulfill their dreams of becoming a sculpture. To do that, they must explore the board to collect clay tokens and defeat each stage of the sculpting process. The game is intentionally light and low-stakes; the biggest blocker to people developing a growth mindset is fear. Growth mindset behavior is centered around taking risks that often do not have immediately obvious rewards. For someone used to the seeming security of a fixed mindset, the idea of accepting and forging ahead into the unknowns in their life can be terrifying. In order to get past that fear, I designed The Sculpture’s Journey to demonstrate the eventual benefits of growth mindset behavior without requiring any personal risk from the players.

The clay characters players help fulfill their dreams.

Developing Understanding, Not Skill

The first major question I needed to answer while designing The Sculpture’s Journey was how to use a game to demonstrate something that is relatively easy to explain but incredibly hard to discover for oneself. Growth mindset is typically taught by explaining that brains grow and change in response to our lives. We become better at the things we do a lot because our brains are adapting to the practice, just like our other muscles get stronger the more we use them. When someone has a growth mindset, they understand that any desired trait can be developed, including things like artistic ability, athletics, and intelligence. When someone has a fixed mindset, they believe that their traits are innate and therefore not changeable. Unfortunately, mindsets develop subtly and early. Even growth mindset people are rarely conscious of their mindset –  it’s just how they work. Therefore, instead of designing a game to help players discover that a growth mindset exists, which would require long term guided observation of their own behavior, I designed The Sculpture’s Journey to supplement a lesson about mindsets and act as an opportunity for players to discover the benefits of a growth mindset.

The partially-revealed game board, with the tracker for movement resources.

The next big question that came up during development was whether or not to make the game skill-based. The straightforward solution to demonstrating a growth mindset is introducing someone to a new skill and getting them to try it long enough to observe that they improve. In fact, a common technique for studying mindsets is asking people to complete a task (say, a series of math problems) and telling some of them that studies have shown that our brains get better at these problems the more we do them. The problem with this method, for my purposes, is that it focuses the mindset on one particular skill. Everyone has different mindsets about different things. Someone may think that their coding skills will improve the more code they write and simultaneously believe that they will simply never be good at drawing. My goal was not to help students develop a growth mindset about a particular skill or trait, it was to encourage them to cultivate a high-level growth mindset that could apply to many things. Knowing that, I chose not to center the game on any particular skill.

Designing Growth Mindset Behaviors

The first half of the game is spent exploring the board using Effort and Courage, which are literal resources in the game. Players need to use Courage to uncover unknown parts of the board and Effort to move through known parts of the board. This is designed to contradict the common misconception that with a growth mindset all you have to do to make progress is to put in more effort.

The Effort and Courage counter. Players roll the two dice each turn and choose one value to allocate to each resource.

As players explore the board, they encounter monsters based on the stages of the sculpting process, which they must defeat to win the game. To defeat a monster, players must roll equal to or higher than it’s XP on a single six-sided Experience die. Players quickly discover that there are monsters with more XP than the players could possibly roll. The crucial learning moment of the game is when players understand that they can earn more Experience, but only by losing to monsters. This is based on a central concept of growth mindset: that failure is more valuable to learning than success. It demonstrates how much progress those who are willing to fail can make, as players who refuse to attempt to fight monsters they are not sure of beating cannot progress all the way through the game.

During development, I learned that the game was encouraging another misinterpretation of growth mindset: the idea that you should try everything, no matter how impossible, instead of attempting things that are just barely out of reach. To fix that, I added a threshold below which players do not earn experience for failing. After that change, I saw players seek out the monsters that were a little too big for them instead of going straight for the biggest monsters to be sure of losing to them.

Results

During playtesting, I found that players generally fell into one of two patterns of behavior:

  1. Diving in and fighting monsters right away, and therefore quickly gaining Experience.
  2. Revealing the entire board in search of something they can be sure of beating, and only then starting to fight monsters and gain experience.

The game is actually more effective for the second group, which tends to be the group that needs it more. The group that starts fighting monsters right away are often those inclined towards growth mindsets anyway. They typically lose to a monster and get an Experience die accidentally, and immediately integrate that understanding into their play strategy, so there is less of a distinct realization. The second group does not believe that losing to a monster can be beneficial until they do so and are handed their new Experience, despite the fact that all monster tiles explicitly say that losing results in increasing Experience.

Two of our student playtesters.

What makes this game work is the fact that the major learning moment happens about one-third of the way into the game. This leaves the remaining two-thirds for players to try out their new strategy and be incredibly successful with it. I intentionally overpower players towards the end of the game so that monsters that seem to have terrible consequences are defeated surprisingly easily with their accumulated experience and so that seemingly terrible consequences are merely inconvenient. This way, rather than getting to the end of the game and learning that they should have done things differently, players learn early on that there is a more effective strategy and get to feel good about using it for the rest of the game.

The fully-revealed game board, with both resource trackers.

The other major component of The Sculpture’s Journey is the Moderator Guide. The Guide is designed to help someone like a teacher, parent, or counselor prompt the players to consider how the game represents real life. Originally, the Moderator role existed to be a source of surprise information, but playtesting quickly revealed that the game is much more satisfying when players uncover information for themselves, and more versatile when it can be played without someone reading out instructions. The role shifted to what it is now as a result of a particularly illuminating playtest during which I asked the 17- and 18-year-old players what happened when they fought a monster and lost. One answered that the two of them had gained Experience that made it easier to fight the monsters, connecting the dots as he explained. The other mimed having his mind blown as the metaphor dawned on him, and the two chatted about their realizations for the next few minutes as we packed up for the day.

That playtest helped me realize that while players always adjust to the in-game logic, they sometimes need a little push to realize what it represents. Therefore, the Moderator Guide is a set of instructions for emphasizing particular ideas represented in the game. These instructions include questions to ask during gameplay to get the players talking, when to ask those questions, ways to adjust gameplay and the setup of the board for particular outcomes, and follow-up discussion questions. The fact that the game is cooperative means that the players are typically already talking to each other and explaining their strategies, so all the moderator needs to do is guide that conversation towards the ideas they want their players to discover.

Playtesting an early version of the game with a student as the moderator.

In addition to students, I have been able to show The Sculpture’s Journey to several teachers, all of whom have been enthusiastic about it as a teaching tool. Several have requested copies, and iThrive is tracking their use of the game and their results for research, which they plan to use to secure the funding to produce The Sculpture’s Journey commercially.

Game materials, including the moderator guide, can be found here.

Wonderland (VR Game Design)

As the lead designer and producer on the Wonderland project at Carnegie Mellon University’s Entertainment Technology Center, I lead my team to find the right questions as we designed, pitched, prototyped, and playtested six short experiences for the Oculus Rift with Touch.

Our client was the director of the Alice program. The Alice program is responsible for the educational software Alice, which helps beginning computer science students (particularly grade school students) learn to code in an appealing, image-based way. The goal of the Wonderland project was to explore virtual reality as a potential avenue for expanding this style of education.

Ultimately, we developed six experiences that each illustrated one specific computer science concept. We playtested with teachers who were enthusiastic and optimistic about the potential for these experiences, or others like them, to enhance their lessons. With their feedback, we came to the conclusion that virtual reality is most useful as a way to illustrate abstract concepts like parameter passing in a simple way that gives teachers and students a common vocabulary.

Finding the Question

A slide from our final presentation to faculty, where we explained the evolution of our understanding of our goal.

The biggest challenge of this project was framing the central question in a way that enabled us to break out of our own ideas of what computer science games look like. It took us a few tries to figure out the version of the overall question our project was trying to answer, beyond what each prototype was trying to accomplish. We started with “how do we teach computer science in virtual reality?” However, the designs we made based on this question were largely re-creations of existing, 2D computer science learning games.

Furthermore, as the semester went on it became clear that our individual ideas of what we were trying to accomplish were diverging. I met with each team member individually and got them to talk about what they felt we were trying to accomplish, then met with the client to get his version. Then I brought the team together and wrote each different version of our goal on our whiteboard, and we all agreed on the interpretation that aligned with our client’s. From then on, we were asking not “How to we teach computer science in VR?” but “What does VR have to offer to the world of computer science education?” That change opened up our designs and got us to start building teaching tools rather than lessons, which was far more effective.

Playtesting and Feedback

Technology teachers playtesting one of our prototypes.

Another challenge was figuring out how to evaluate something that we knew would not be a finished product by the end of the semester. The project was about prototyping and exploring, so our goal was never to release polished products. We would have loved to test in classrooms, but the fact was that equipment was limited and each prototype had usability quirks that required careful instruction to navigate, so attempting to lead several children through these experiences together was not a possibility. We needed a way to evaluate the potential of these games as teaching tools.

My solution to this problem was to go to teachers instead. After all, if teachers do not see the value in a teaching tool, the students will likely never see it. And working with a few teachers at a time meant that we could easily guide them through the games and make it clear that they were not experiencing finished products. From the beginning of the project, I sent out a survey to teachers that follow the Alice program to ask which computer science concepts they find most difficult to teach and why. We chose our topics based on the answers to this survey and designed to solve the problems they presented.

A group of teacher observing their colleague play one of our prototypes.

For playtesting the prototypes, I wrote a verbal questionnaire that asked their history with computer science and their level of familiarity with the concept the prototype they were about to experience was based on. I took notes as one of my teammates led them through the game (and recorded when we had permission), and then asked them follow-up questions about how well they felt the experience demonstrated the concept and how they might use it in their classroom. It turned out that some of the teachers were not familiar with some of the concepts we were demonstrating, so in their case I briefly explained the concept and checked to see if they connected it to what they had just experienced and felt like they could understand the concept. Finally, I asked teachers who experiences more than one of our prototypes to rank them in several categories like accuracy, enjoyment, and potential for classroom use.

A high school student playtesting one of our prototypes while I observe and guide her through it.

As it happened, we did get the opportunity to playtest with grade school students, and that presented another challenge. We did not have control over whether or not the students we playtested with were already familiar with computer science and the settings we were playtesting in required that we move quickly and did not allow for us to embed the experience in any type of lesson. So how do we evaluate whether or not the prototypes were working? I decided that since most of our verification was coming from teachers, what we really needed to know from the students was whether or not they would play games like these and whether or not they were able to identify patterns in what they were doing within the games.

Based on that, I asked them if they were familiar with the key ideas the prototype would be trying to get across. If they were already familiar with the concept, after they played I asked them to identify what elements or actions in the prototype represented which computer science ideas. If they were not familiar with the concept, I asked them to explain what they were doing in the experience and what process they were following. If what they described corresponded to the concept we were trying to get across, I took that as evidence that the experience was on the right track.

Documentation

As the team member most comfortable with writing and communication, figuring out our documentation was my responsibility. We needed documentation that would enable someone else to pick up our project and continue based on our conclusions, our process, and our prototypes. We also needed documentation that could reasonably enable teachers to use our prototypes in order to argue that they could fit into a lesson plan and to help our client to continue demonstrating our prototypes if need be. Therefore, I split up our documentation by its intended audience: designers, developers, teachers, and general interested parties. I also wrote a one page instruction document explaining what each section of the documentation was, so that anyone using it could find what they needed without having to search through everything.

The digital structure of our documentation.

The general documentation included my overall analysis of the project and our conclusions and high-level explanations of each prototype. The prototype explanations included the goals, the original pitched design, the final experience (with video), lessons we learned, and what we would do if we were to continue working on it. Those explanations also included where to find the code for anyone who wanted to play around with the experiences for themselves.

For the teachers, we wrote step by step walk through guides for each prototype, including common problems and how to either fix them or work around them. These guides also included suggestions for how to present the experience and verbally guide someone through it, informed by our own experiences playtesting. In addition, I had the programmers on the team write pseudo-code to go along with each prototype. The pseudo-code was not based on the code that ran the prototypes but was instead a simple example of what each concept looks like in code form. My reasoning was that the mostly likely way for these prototypes to be used was in conjunction with code so that students could relate chunks of code to moments in the experience. Therefore, we provided an example of what code for a lesson like that might look like, annotated with what it corresponded to in the experience.

A page from a prototype walk through showing a gesture used in the prototype.

The documentation for developers was standard technical documentation detailing how the code behind the prototypes worked, ways of programming them that we tried and discarded (no point in having future developers make the same mistakes we did), and elements we wanted to add if had more time.

The documentation for designers included a design review where I wrote about what we learned, our advice for future development, and what we concluded about the role of VR in teaching computer science. I also detailed our process, how it evolved, and what could have been better, as well as the elements of the project that we discovered were more or less important or time consuming than we expected.

The end result was that we have detailed, extensive documentation with information relevant to multiple audiences, organized by who each document is most relevant to. I designed this system based on feedback from teachers about what would be most useful to them, and based on the idea that another project might need to pick up where we left off sometime in the future.

Button’s Journey (Narrative and Sound Designer)

I did the narrative and sound design for Button’s Journey, a game for the Kinect 2 that was developed in two weeks by a five person team as part of the Building Virtual Worlds course at the Entertainment Technology Center. Working on this game helped me truly understand both the value and difficulty of simplicity. In the game, guests play as a button who has been blown out of its home and away from its love by a fan and must navigate the outside world in order to return. It looks like this:

The biggest design challenge for this game was keeping things simple. Even when coming up with the basic story we tended to get bogged down by details we liked instead of settling on a core narrative. Finally, when we knew we wanted to use buttons but did not yet know what the story would be, my teammate asked me “What is the simplest story we could tell about these two buttons?” and I answered, “One of them wants to get to the other but things are in the way.” From that point on, we committed to keeping the story, and by extension the game, as simple as possible. As our narrative designer, I established a requirement that any new element had to support and enhance the story without distracting from it, and following that guideline effectively prevented us from adding too many random elements.

An image from our opening sequence – the button rolling across the table.

There were two moments in the game where the level design presented narrative challenges.The first was getting the button out of the tailor shop in the first place. The first draft of the story had the button getting knocked into a garbage can, taken out with the trash, and then falling next to the dumpster when the trash was dumped out. When we playtested the game, we discovered that guests were not understanding that series of events at all, and that it was far more complicated than it needed to be. After than we knew we wanted to change two things: we wanted to simplify the whole sequence, and we wanted the reason the button ended up outside to have something to do with the obstacles it faces on the way back. The most popular obstacle during playtests had been the vents that nearly blow the button off the roof, so I rewrote the beginning of the story to have the button blown out the window by a fan. That version was far easier to understand and ended up being quite effective.

The second moment that presented a narrative challenge was getting the button from the ground to the roof of the neighboring building. Our first iteration of the story had depended on the button seeing the surrounding landscape, so I had written the story to get the button up high rather than simply having it cross the street. We ended up removing the part of the story that required being up high, but we liked the fact that it made the gameplay more about balance and steering (trying not to fall from the edge of the roof) than about timing (dodging cars to cross the street) which we felt was more suitable for the Kinect. That meant that we still needed a way to get the button up to the roof, so I wrote in a bird that would grab the button and bring it to its nest on the roof about one third of the way through the game. Having the bird grab the button there actually turned out to be an even stronger moment than we had anticipated, because the bird grabs the button just as the tailor shop is coming into view for the first time and puts the button even further away.

The button is carried away by a bird after getting close to the tailor shop for the first time.

In addition to being presented to our professors and classmates as part of the Building Virtual Worlds class, this game was showcased at the ETC Fall Festival in December 2016, where family, friends, alumni, and industry professionals would be invited to come and experience this and other ETC projects. As part of the festival, each team was given a room to set up for their world. My team and I themed our room to look like a tailor shop and the street outside. This created an excellent opportunity for me to take advantage of my staging, construction, and prop making skills in designing and implementing our theme.

The Button’s Journey team in our room for the Fall Festival. From left to right: Beizhen Hu, Peilin Li, Griva Patel, myself, and Daniel Hua.

When it came to decorating our room for the Fall Festival, the primary challenge was arranging the play space in such as way that guests could watch the person playing without being picked up by the Kinect and interfering with the game. To accomplish that, I suggested that we use the back two-thirds of the room as the play space, with the screen and Kinect perpendicular to the doorway, and then use the front third of the room as a viewing area. To keep the guests in the viewing area from wandering into the play area, I built a large window frame that blocked the play area, leaving a gap for a single guest to enter the play area at a time. The doorway into the room and the opening into the play space were on opposite sides of the room to make it harder for guests to accidentally walk straight into the play space when they entered the room. To make the whole room fit with the theme of our game, we used props and decorations to make the play area look like the tailor shop and to make the viewing area look like the neighborhood outside the shop, so that guests watching the game seemed to be looking into the window of the shop. You can see the results below.

360 Video (Writer, Director)

In the fall of 2016 as part of the Visual Story class at the Entertainment Technology Center, I wrote and directed a 360 degree short film based on the Pixar prompt:

“Once upon a time…every day…until one day…because of that…because of that…until finally…and ever since then…”

We had a set of locations to choose from, so we decided to tell a sweet story that took place at a bus stop and a coffee shop. The narrative was our take on the simple “love at first sight” idea, using color to show connection and affection. I created the film with four other students: Michael Luan, Pradnesh Patil, Matthew Stone, and Anqi Yang. The actors are myself and Anqi. We used the song “Married Life” from the film Up.

Filming in 360 degrees presented some interesting challenges, especially coupled with the fact that we were not allowed to use dialogue at all. We needed to rely entirely on visuals not only to effectively convey the story but also to get the viewers watching the correct places to begin with. Luckily, I had some experience directing theater scenes with little or no dialogue, and knew some techniques used on stage to direct the audience’s gaze. The images on this page are scenes from the film in 360 degrees, so feel free to click and drag to look around the scene.

When writing the initial story beats, I made sure I was using simple, clear events and actions that could be easily communicated through body language and avoided trying to convey more than one idea at once. I used movement and gaze to direct the viewer’s eyes throughout the piece. For example, when a character is entering the character already in the scene looks up to show the viewers that something is happening, and a scene shift happens when the characters walk past the camera, so that the viewer’s natural inclination to turn and follow them leads them to look in the right place in the next scene. In addition, I used the amount of color in the scene to help convey the tone of the story. As the characters become more connected, more and more of the scene is in color. When one of them has to leave, the color fades again.

The Illusion (Assistant Director)

In the spring of 2016 I assistant directed the Luther College Visual and Performing Arts production of The Illusion by Pierre Corneille and Tony Kushner. As the assistant director, I helped to come up with the staging of the show and direct the actors in their roles. Additionally, I was solely in charge of the direction of the penultimate scene of the show, meaning that I handled the blocking and direction of that scene from the beginning. This experience enabled me to develop my sense of spectacle and to hone my ability to adapt my work to the style of my collaborators.

Leading up to the final moments of the scene, with the character who needed to re-enter the scene on the right and the character that brought her in on the left. Photo by Brittany Todd, www.photographybybrittany.com

In the scene I directed, the tone of the show shifts from farcical to dramatic as the protagonist finally has to face the fatal consequences of cheating on his wife with the prince’s wife. This is the scene where everything goes wrong, so I wanted it to feel sinister and not quite right. The idea was that by the climax of the scene no one but the protagonist was surprised by his death. To accomplish that, I designed the blocking to echo moments in earlier scenes when things were happier with different outcomes. For example, in one of the first scenes the protagonist gets down on one knee to declare his love to the character who later becomes his wife, and she leans down to kiss him. In the scene I directed, he again knelt to convince her of his sincerity and she leaned towards him, but this time she pushed him away.

Directing that scene presented some interesting challenges, the most obvious being the need to direct the scene in my own way without creating something that was noticeably different from the rest of the show. The primary way I accomplished this way by using the techniques favored by the director throughout the process, namely clowning tactics like red nose and gestures. That way even though I was directing my own interpretation of the scene, the methods I was using to do it were consistent with the rest of the show. I also dealt with this challenge by consciously echoing the blocking the director used in earlier scenes and twisting it to suit the new scene.

A moment in rehearsal when the actors were still wearing their red noses. Photo by Brittany Todd, www.photographybybrittany.com

The second major challenge was that the layout of the theater meant that the blocking had to be designed to ensure that the actors ended the scene in a very specific place so that they would be hidden behind the red curtain that would drop. To make sure that they ended up in the right place, I planned the blocking by starting at the end of the scene with the positions I knew they needed to get to and working backwards to the beginning of the scene. To keep the scene from looking cramped towards the end, I kept the character that would be exiting the scene before the curtain fell further away from the spot where the others were gathering.

The third challenge of that scene was subtler, and was one I did not actually solve until shortly before the show opened. One of the characters appeared to leave the scene and reenter later, but the script included no direction to that effect. She simply did not have lines during a conversation that clearly did not include her in any way and then suddenly had lines again at the very end of the scene. The question was, what was she doing in the middle? Initially, I had the actress try hiding from the other two characters throughout the scene, as if she did not want to get involved in their fighting but could not quite bring herself to leave altogether. That kind of worked, but was clearly awkward and gave the actress quite a bit of difficulty. When dress rehearsals started and I saw the scene on stage with the trees she was supposed to be hiding behind, I knew I had to come up with something else. There was no real reason for her character to stay, and it looked intensely awkward to have her hanging around upstage. At that point, the question became, “why does she come back?” Finally I realized that the solution was the character that entered the scene just before the end of the scene, who has been hunting for one of the others. If I assumed that she ran into him off stage, he could force her back into the scene by making her lead him to the others. All of the actors much preferred that version, and it was ultimately much more effective on stage.

Lost and Found Application (Designer, Programmer)

For my senior project at Luther College I worked with four other students to code a web application that will help building administrators track “lost and found” items. This was my first experience with a long term collaborative coding project, particularly one where we had complete control over our design and implementation. The application was primarily intended for building administrators, who would be able to easily add photographs of items that were turned in, as well as to look up those items later on when students came looking for them. As both a designer and a programmer, I learned a lot about aesthetics and usability.

The login page of the application. Guests could click on “Lost an Item?” if they were not building administrators.

My primary task was our guest user functionality, which allowed students to look up where their lost item is most likely to be. This feature presented an interesting design question. Building administrators need full access to the database of items in order to know if they have what a student is looking for, but giving the same level of access to students, or anyone who happened upon our application, would enable them to “shop” through the returned items and pretend to be the one who lost something they want. We initially did not intend to include any sort of non-administrator access, but that feature was requested so often that we decided to work out a compromise.

An early iteration of the guest search results.

In the end, the solution I developed was to require non-administrators to input information about a specific item in return for information about which buildings similar items had been returned to. Students using the application could input as much information as they wanted about a specific item they were looking for without ever getting back anything more than likely buildings and contact information. By not telling anonymous users anything about the item entries being matched to their query, I hoped to prevent them from gathering enough information about any item to believably pretend to be its owner.

Myself, Jessica Tan, Sergei Hanka, Kirby Olson, and Ales Varabyou presenting our application at the Student Reserach Symposium.

At the end of the year my teammates and I presented our project at Luther’s Student Research Symposium, where other students and faculty came to find out what we had to show after a year of work. In the interest of keeping the presentation fun to watch, we decided to show a video of the application in action and then do a live demonstration of some of the additional features rather than verbally explain the entire application to the audience. I wrote, directed, sound designed, and edited the following video, starring Hannah Miller and Josh Weisenburger, two members of Luther’s improvisational acting troupe, along with Teresa Flinchbaugh, an Administrative Assistant for Luther’s Computer Science and Mathematics Departments.