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!