Next up in our series of games from the Spring 2009 semester is The Bridge, another arthouse game from Doris C. Rusch, the product owner of last summer's Akrasia. This game, a rumination on loss and mourning, is now available to play. You may want to check it out before reading the following reflection from Doris on the game's creation - there are spoilers ahead! - but definitely do come back and give the following essay a read, to share in Doris' experiences with game design as its own personally reflective, insightful process. -Geoff

The Bridge: Game Design as a Tool for Reflection and Self-Exploration

by Doris C. Rusch

The Bridge is a short, single player Flash game, made during the spring semester of 2009 by a team of students. I was the product owner and lead designer of this project. Although I have my doubts regarding The Bridge's qualities as a game (for which I take full responsibility), I still regard it as one of the most interesting works I've ever done. The focus, however, is on "work" as in "process", not the result. Working on The Bridge showed me what a wonderful tool for self-reflection and insight game design can be. The following is an account of how using the tools of my craft helped me and two of my team members to more clearly map out our emotional landscapes. Feel free to try this at home!

Guided by Images

Saying I wanted to make a game about "mourning" or the connection between "love" and "fear of loss" would be bullshitting (Def. bullshitting: terminus technicus for making a process appear intentional and focused in hindsight when it actually was not). So, let's just stick to the dirty truth of how it really went.

It started with an image of an empty tire swing that suddenly bubbled to the surface of my subconscious but never quite made it into the more analytical realm of my mind. The image didn't come with an explanation, only with an emotional overtone of loss, frustration and hoping against hope. A bit like a cone without ice cream, a tire-swing is a sad affair when it just hangs there without a child on it. Of course, one can take either image both ways: as a promise for future fun or as the memory of past pleasures. In the moment my mind decided to release the tire swing from its swampy depths, I gravitated towards the darker reading of it. But why a tire swing? Why not a more traditional metaphor for loss, such as a gravestone or a couple dressed in black, huddled together under an umbrella?

How I would love to be able to give a clever and coherent explanation now. But I vowed to adhere to honesty and will thus further refrain from bullshitting. The best I can do is share the stream of associations with you that (to me) accompanied the tire-swing metaphor.

Imagine being the one pushing the swing with the child on it. You push, you watch the swing perform the familiar motion, you wait for it to come back to you, and you push it again. The "here-gone" dichotomy strongly resonated with me. The necessity of letting go of the swing in order for it to fulfill its purpose (i.e. provide a pleasurable experience for the child) and at the same time distancing yourself from the precious freight it carries, experiencing a moment of anticipation (anxiety?) before the swing starts to come back, and the relief upon its safe return. But this relief is not really due to the return of the swing, but to the return of the child on it. In most cases, these two things are coupled. While the cycle of the swing will not be interrupted as long as one keeps pushing (what goes up must come down, right?), it is possible to lose a person forever. Fate is less predictable than physics. If the swing is "gone" it will transform into "here" again. A person, once dead, will remain gone. Child and swing - once fused together - are indeed separate entities; they can part ways. The stubborn mind, however, is reluctant to dissociate the two. The swing has always brought the child back, so maybe pushing an empty swing will magically return what has been lost. But some things cannot be changed, no matter how hard we push...

The Initial Idea

The interactive piece I initially envisioned (I wasn't even going to call it a game!) was strongly inspired by this crude image of an empty tire-swing and the foggy feelings of loss and mourning I associated with it. The player would enter an empty space with nothing but a swing in it and nothing to do but to push it. Pushing the swing would produce faint laughter and the transparent outline of a child would become visible on the swing. The implied goal would be to push until the child materialized completely. In truth, no such thing would be possible, though. The player would have to realize that all her efforts were for naught, that there was no way of bringing the child to life and that the only way to "win" was to accept that and walk away. In order to make this (emotionally) difficult for the player, every time she stopped pushing, the child would fade again, the laughing would grow faint at first, then maybe turn into whimpering (good audio would be required for this or instead of inducing guilt, the whining would create the wish to quickly leave the wretched child behind).

Using "The Tools" for Self-Exploration: A Conversation With The Inner Game Designer

When I talked to my friends Jaroslav and Eric about this initial idea - both very game savvy - they saw the potential for an emotionally compelling experience. However, they thought it should be more "gamey". I was reluctant at first. The simple tire-swing sequence felt so right that I wanted to do it exactly as I had described above. And then, they popped the Question (yep, it deserves the capital letter): "But what exactly is this about?" Mourning, clinging, loss, attachment - whatever I said to explain it didn't quite capture it. I couldn't put it in words. Since I'm strongly advocating purposeful design, not knowing my own mind was a problem. How can I purposefully create an experience for someone else if I don't understand my own feelings?

This had to change. I decided to follow my friends' advice and make it more "gamey". Because although the game itself can be ambiguous and allow multiple interpretations, coming up with the rules forces the designer to be precise and concrete. I started to explore what I already had in mind in terms of game elements. Here's a rough transcript of the dialogue I had with what I call my "Inner Game Designer" (IGD):

IGD: What exactly is the GOAL?

Me: To "let go".

IGD: A goal without CONFLICT makes for a lousy game. So what is the conflict? What makes "letting go" difficult?

Me: Attachment makes it difficult.

IGD: What creates attachment?

Me: Hm...love?

IGD: So, the way to overcome attachment is to overcome love?

Me: I don't think so. That would be terrible. Love is important.

IGD: Are you sure it is love, then, that bothers you? Maybe it's fear?

Me: Oh yeah? Well, what do YOU know?

IGD: I'm you, remember?

Me: Attachment and fear. Fear of losing love. You cling because you are afraid...

IGD: What exactly are you afraid of?

Me: Haven't I just said that? Afraid of losing love! Isn't that obvious?

IGD: Aren't you a bit negative?

Me: Don't play the Eliza trick on me!

IGD: All right, I'm sorry - couldn't resist. Seriously now, why would losing love be bad? It sounds like love serves a purpose.

Me: It protects...makes you feel good.

IGD: And since you don't want to lose what makes you feel good, love itself creates fear. It is both the curse and the cure, it seems.

Me: That's right. Fear creates clinging, you want to stay close to the "love object".

IGD: May I point out that you don't seem to have internalized love? It's this outside thing on which you depend. That attitude will always kick you in the butt.

Me: You're my inner game designer, not my freaking therapist.

IGD: Seems like pretty much the same thing to me...

I will spare you the rest of the conversation because it involved giant flying puddings and the monster with 14 toes, neither of which had any relevance to The Bridge. But you can see how the concept had dramatically evolved from the simple initial idea to a system that tackles the mechanisms of a certain kind of love and the problems that come with it. What was still lacking was an idea of how to overcome those problems, to get "unstuck" and break the pattern. Obviously, you had to fight your fears so you weren't dependent on your love object anymore and could love it in a more selfless way. And then what?

It was at the speakers' party at this year's Game Developer's Conference in San Francisco when Trey (the game's producer) and Jamie (code and animation) approached me with the words: "we have been thinking." Sitting in front of cocktails called "The Game Designer" or "Achievement Unlocked", they spoke to me of closeness, emancipation and sacrifice in a serious and insightful way. We pondered how the game could end. We knew the goal, we had grasped the conflict. Now we had entered the final stage of the process: finding a solution. What happened when you killed the monsters that represented your fears? What happened to the girl that represented your love object? What exactly would "letting go" look like? It was Jamie who dumped the solution in my lap: every monster you killed would help form a bridge across the river that divided the playground (the game's main space) from the untended field (representing an unknown future). I loved the symbolism that the road to a better future was paved by one's conquered fears. We further entertained the rather disturbing idea that the girl would sacrifice herself to complete the bridge, that her (self-inflicted) death would produce the last missing piece. We let this sink in. Nah...no good, since it would undermine the emancipation process which depends on taking responsibility for one's actions. So, maybe the player had to kill the girl before the bridge solidified? No, no, no! Not reconcilable with the idea of selfless love! We finally agreed that to win the game, one would have to kill all the monsters in the playground and refrain from "reclaiming" the girl on the tire-swing. The bridge would solidify upon the death of the last monster and one could cross it. Crossing the bridge would "free" the girl (she'd dissolve into a could of particles). This should not mean that one abandoned love itself, but had overcome functionalizing it.

The True Reward Was The Journey

My team had an equivalent of two 40-hour work weeks to develop this game. This is not a lot of time, but they did an amazing job. Our biggest problem, however, was that the theme was so personal. If a project is too big, you can always scope it down. But if you are very invested in the concept you want to convey, to do it justice and get it right, the problem starts much sooner than scope. It starts with understanding what exactly you want to model.

We tried something big with The Bridge. Too big, maybe, for the given timeframe. I felt bad for a while after our last official work session, because how can you close the book on "love" and walk away feeling like you've accomplished anything? Also, eighty hours of development time do not leave a lot of room for tweaking and polishing and thus many of the ideas in the game are still latent and could be communicated to players more clearly.

But then again, I have learned a lot. The process of designing this game made many things apparent to me, helped me map out some of my emotional landscape. In that regard, The Bridge was a huge success. It confirmed my belief that while making profound games that tackle the human condition is a worthy goal which I will keep pursuing, game design itself can be a wonderful tool for insight that greatly enhances our understanding of ourselves.

Posted by Geoffrey Long to News | Permalink | Comments (0)  

During the past academic year, I had the pleasure to work with a group of very talented students on a new GAMBIT game, Rosemary. It's been an exercise in nostalgia: nostalgia as a theme in the game, and nostalgia for a genre that had its heyday more than 15 years ago.

Rosemary is a point-and-click adventure game whose core mechanic is remembering events of the past in order to uncover a mystery. The protagonist, Rosemary, has discovered a photo of her childhood friend Tom, whom she had come to believe was imaginary. Determined to find out what happened to him, she returns to her hometown of New Rye. Her memories of the place are all she has in order to find Tom.

Rosemary is a game about returning to the place where one grew up, but haven't been back to in a long time. As in real life, buried memories resurface when the player revisits such places, changing how one perceives the location. Part of these game mechanics were based on Quintillian's Memory Palaces, where arranging one's memories in a space is what facilitates remembering people, events and facts in a speech. You can read more about the premise of the game and a short statement on the game's homepage. Rather than having me spoil the game any further, please just go ahead and play it. It's rather short, especially if you've played adventure games before.

At GAMBIT we research games, and we learn by making them and thinking about the whole process. What follows are four of the things that I learned while making Rosemary.

1. We Need to Support Story Tracking

When I proposed this game, I was well aware that we would not be able to follow the development methods and timelines that had worked well for previous games made at GAMBIT. An adventure game requires not only a set of mechanics but also a fleshed-out story, and that takes time. Having everybody in the team know the story well is an additional challenge. As the story grows and changes while the game is being developed, it becomes increasingly difficult to keep all team members on the same page, which is critically important since the story is intertwined through every aspect of the game. When a game is made by one person, or a small team of people working in close proximity, the unified vision is relatively easier to keep. When the developers are a team of students with disparate schedules who are only available to work 10 hours a week, maintaining a unified vision becomes a serious problem. Nobody re-reads the design document (remember: we don't have that much time), so the story evolves but not in a unified way.

I was lucky to work with a team of very talented and engaged students who not only lived up to the challenge but did a great job of working together and getting things done. However, there were some issues resulting from this work situation which could have been palliated with tools to keep track of the story of the world and its audiovisual representations. This experience has provided me with a new research goal: developing tools that will help teams working on story-based games by keeping track of the story and structuring and relating the information effectively.

2. Interaction Design and Writing are Related But Different Parts of Development

Over the course of development, our designer, Sarah Sperry, served as both writer and designer. Although writing and design go hand in hand in this genre, it was difficult to juggle between writing the story, designing the puzzles and working on the interface. I asked her to focus on the worldbuilding, because that was the main challenge of making the game at GAMBIT. However, given that we were trying to introduce new mechanics, we should have put more care in designing the interaction. The UI in our first playable was based on mock-ups, but the design document did not include a detailed description of how the interaction worked. Since I insisted on focusing on having a world that the player could interact with as soon as possible, I thought that the conventions of adventure games would help the player through. That meant that at least we had something to show as early as possible at the end of the Fall semester, which is still pretty late in comparison with other GAMBIT projects. The downside is that the UI still needed a lot of work. The remedy was having a UI pass in January (thanks, Marleigh!), which fixed a lot of issues. Improving the UI allowed us to get rid of an opening tutorial, which forced the player to solve two puzzles in a specific order before being able to explore the world.

As you play, you may notice that there are some things here and there that still need some polish, particularly in the photo album, but through playtesting we saw that players could make sense of what they had to do with little trouble (except for a few notable exceptions listed below).

What I've learned is that although related, separating the tasks of interaction design and writing may be a more effective approach in future story-based games. I also realized that relying on the conventions of a genre only goes so far. When the mechanics of your game are veering away from the conventions, as was the case here, interaction design bridges the gap between the convention and the innovation.

3. Players Can Make Sense of Very Broken Games

The version of the game at the end of the Fall semester was very broken. The basic puzzles were there, although the last module had been implemented in a hurry. I was also rather skeptical about a couple of the puzzles, because I did not think players would make sense of it. The UI still needed a lot of work. Some of the placeholder art assets were squiggles that Alec, our programmer, had drawn in 15 seconds with the mouse:

Instead of me telling the students how broken the game was, I wanted them to see it for themselves. So we used one of our Friday Games@GAMBIT sessions to invite people who were new to the game to play it.

Surprisingly, most of these playtesters finished the game in spite of the weird puzzles, the broken UI, and the squiggles. Of course, a couple of people gave up early, and a couple more got stuck, but basically around six people successfully finished the game. There was a catch – a couple of them were veteran adventure game players, who probably had endured twisted designer puzzles for years. Our playtesters were also players who gave elaborate feedback about what worked and what didn't (and gave suggestions about what to fix, which is an exceptional circumstance). So perhaps the game was not so broken after all.

I was ready to give up on the development of the game after one semester, because I thought I had enough evidence of all the extra challenges that we faced when making an adventure game. Seeing players complete this utterly broken prototype and, more importantly, seeing how the team was willing to take up the challenge to fix it, convinced me that it was actually worth continuing to work on it. If players had the patience to play through the game at that stage, what would they not do if it was actually fixed?

Lesson learned: do not underestimate the effort that your players are willing to put into your game. Players like challenges, and a broken game can be a challenge in itself.

4. Some Players Have Difficulty Understanding Adventure Game Conventions

Playtesting also revealed some interesting information about our potential game demographic. We realized that some 13-15 year olds were not familiar with the conventions of point and click adventure games. A couple of them started playing, and immediately said "It doesn't work!" They would then demonstrate how our game was "broken": they clicked on the verb 'walk' and said: "See? She doesn't walk!" They assumed a different model of how point and click worked, learned from games like The Sims, rather than following a pseudo-grammatical model to control the character. We had to explain to them that they had to click where they wanted the character to walk to.

Another eye-opening experience was a retired couple who came by our lab. We thought that they would like to play Rosemary because it's a puzzle game, and they found it intensely frustrating. The type was too small and it disappeared too quickly for them to read. They did not know what to do and wanted a tutorial (a tutorial that I was so proud of having cut before). However, they wanted to learn to play the game without spoiling the puzzles, because they still wanted to solve them. The best thing is that they really wanted to play, they loved puzzle games, and they felt frustrated that they couldn't find games that they could play. They showed us another exciting avenue for game development: games for players over age 65.

All in all, the development of Rosemary was a challenge throughout, but it was also tremendously enjoyable thanks to the wonderful students that stepped up to the challenge. Every discipline made wonderful contributions, making the game rich and enticing despite its brevity. The students were the ones who made this happen, and produced the game that you can now play. We hope you like it!

Posted by Clara Fernandez-Vara to News | Permalink | Comments (0)  

Keep an eye on the Load Game section of the GAMBIT website! Over the next couple of weeks, we're going to be launching the Spring 2009 lineup of GAMBIT games, including The Bridge, Moki Combat (v2.0), Rosemary, and the digital version of Tipping Point.

The first of these is Rosemary, which is an adventure game in the style of The Secret of Monkey Island that experiments with the idea of nostalgia as a game mechanic. Check it out now at http://gambit.mit.edu/loadgame/rosemary.php, then read game designer Clara Fernandez-Vara's postmortem of the game on the GAMBIT Updates blog!

In related news, we've also posted the bios for the Summer 2009 students – check them out now in the Credits section of the GAMBIT site!

Posted by Geoffrey Long to News | Permalink | Comments (0)