In Tori, players fly as a bird through a mystical land interacting with the spirits of sound to bring life to the floating islands of Otokai.
Tori is a game where players fly as a bird through mystical floating islands channeling the musical spirits of the objects that once inhabited the land. By exploring and discovering these spirits, return life and music to the land.
With our relatively small team size, my role has changed by necessity to include programming, 3D modeling, and project managing on top of my primary work of designing. This has been truly valuable in furthering my understanding of what kinds of work each member of a small dev team does on a day to day basis. Many of the lessons I've learned in addition to this can be split into three main categories: working on a team, maintaining a vision while iterating, and adapting to challenges along the way.
One of the most difficult parts of working on Tori has been the everchanging team dynamic. The project started out with a team of four that never really planned on seeing the project through to release. After three of those team members graduated, I (with permision from the original project owner) repitched the project in an attempt to build a new team. Two people began to work with me then, and five more members have joined Team Tori since.
Before Tori, the longest I had worked on a single project was probably a couple of months, and I almost always knew the people that I worked with. I was scared out of my mind that working on this project for years with people I had never worked with would be impossible. And, to be fair, there were definitely bumps along the way. At the beginning of the project, myself and one other teammate simply could not get along. Not only was their vision of what the project would become drastically different from my own, but differences in the way we communicated stood in the way of us being open to each others' ideas. We brought in a friend from outside the project to help us talk things through, and it had a serious impact on our working relationship. Since that talk, we have become a lot more capable of working together toward what is best for the project.
Not all problems with teammates have worked out this smoothly. After a period of radio silence from one team member, the rest of the team decided to kick them off of the project. We reached out to them many times throughout this silence in an attempt to communicate concern rather than contempt and met with some of our Game Design professors to discuss ways of revitalizing that member's enthusiasm for the project, but nothing changed. It very difficult to remove them from our team and there were definitely hard feelings, but we have since repaired the relationship a bit.
A huge requirement of making development happen with a team of this size is an ability to communicate concepts that I did not have at the begining of this project. The place that this became most clear was in the process of working with a video editor to make the IGF trailer for our game. The video itself was filmed and edited during the two days leading up to the deadline for submission. So, we had to present the editor with a fairly clear idea of what the final video needed to look like. This gave me the chance to try my hand at storyboarding. I learned basics on how to communicate motion of objects, motion of the camera, and how to communicate a feeling through a sequence of images that have drastically improved my ability to quickly and accurately communicate my designs during meetings.
But it is in these meetings that I have learned the most about communicating ideas. We meet either four or five times a week, so I would have thought we would be running out of things to talk about all the time. This has not been the case. It seems that we are always hoping to discuss far more than we have time for, and this has necessitated us learning how communicate concisely. It has taught us the importance of keeping a record of our conversations and our ideas. Most importantly, it has taught us to always think passively about our ideas so that we can be prepared to talk about them at any time.
As a result of this, we are pitching our game all the time. I run our game concept by someone outside of the team at least once a day. I knew that this would make it easier to present the game in the future, but I didn't know that it would help me to understand when we are making decisions that are not right for the game. Telling someone what our game is forces me to have a pretty good idea of what is at the core the project, and that truly comes in handy when thinking about weather a change is right for the project.
As our team size fluctuated between three to seven members, so did our needs. My original goal for this project was to focus on the concept of the game. I wanted to work solely in the realm of ideas. It became clear that this was not going to be enough very early on in development when we lacked a programmer to implement these ideas. Though I am certainly not a programmer, I fell into the role of one for a short time so that we could test our ideas and iterate faster. At the start I was hesitant out of fear that this would change my role on the team and keep me from being involved in the conversations about mechanics, theme, and narrative that I had more interest in. Now that we have a programmer, I am very thankful that I ended up taking on those tasks as they have allowed me to better communicate with our programmer about new concepts we want implemented in the game.
More recently, our team developed a need for an environmental artist to model the floating islands for our bird to fly through. After having a conversation with our previous environmental artist, it became clear that they were feeling very burnt out on these tasks. Since they expressed an interest in pursuing character art instead, I offered to take on their tasks for a while to allow them to explore this interest. It has worked out for us very well. We've experienced a huge burst of increased productivity and I've learned a lot of new skills along the way.
Though it is the project that is most relevant to me as a designer, Tori isn't all I've made. Although most of the other work I've done hasn't seen the light of day, it has taught me many lessons.
Window is an interactive fiction that explores the role of perspective during the end of a relationship. In it, I experimented in limiting players' awareness of the effects they are having on the game's narrative. The game is loosely based on my experience of a breakup with a long-term partner.
It can be downloaded here.
In this project, limited control is given to players that are making their way through the narrative. As the story progresses, the only thing players are capable of doing is shifting focus between different reflections in a window. Doing so changes the outcome of the story without signaling to the player that any changes have occured. This allows for players to have control over the narrative while thinking that things could have never happened any other way. Only in discussing their experience with others will they recognize that they had played a part in directing their experience.
I made this game in a very emotionally difficult time in my life, and it definitely shows. The game is quite short and very unpolished, but it remains as my favorite completed project. The game explores the type of story that I find myself most interested in. It focuses on the world itself, the context for the players' actions. In doing so, it brings me back to the moment of my own breakup. It makes me remember the way I didn't want to look into the eyes of my former partner, the way I gripped the cover of the futon, and the slow, sad walk home.
In creating this project, I began to worry that players would find the story or the lack of action boring. To my surprise, however, it seemed that players were enthralled by the story that the game was telling through its mechanics. One player even began to cry (even if only for a moment).
I have loved games as a medium for producing more than just fun for quite a long time. This project really taught me that this direction of games moving from being consumable goods to works of art is something that is within reach. It is this realization that really convinced me to dive head first into game design.
Two Hundred Seventy Three is an interactive fiction where players take the role of an unaware audience member during a performance of John Cage's 4' 33". My goal in designing it was to push the lower limit of stimuli for player interactions.
It can be downloaded here.
For a majority of the two hundred seventy three seconds that this game lasts, nothing new is presented to the player. When information is presented to the player, it is done to encourage the player to sit still, take in their environment, and note that, in this moment, their choice to abstain from interacting with the game a way of interacting with the game as well.
I have loved the concept of 4'33" for a very long time now, and finding a way to make it into a game is one of the first ideas I had that was related to game design. I became fascinated by a game system just sitting there passively, doing nothing at all until the player makes a move. One way this is represented in the game is by text streaming out on a timer until the player rudely interrupts the show. Unfortunately, this didn't work as well as I had hoped. Players became quite confused about their role in the game, and tended to tune the game out. I hope to revisit this concept very soon.
Lacking Depth is a game in which players play a character trapped within a painting. Every few seconds the player will switch from platforming their way out of this painting to playing a top down adventure game and avoiding monsters scattered throughout the painting. Escape the frame to win.
It can be downloaded here.
This game was developed during Train Jam 2017.