i'm a queer and trans developer living in Oakland, California. i make and play weird games, skateboard,
build gunpla, watch one piece and serve coffee. if you're interested in working together, have a question about my work, or
just want to meet up - i'd love for you to reach out! :D
here's my resume, if you're into that kind of thing
Realm Defense
(Live Ops: Mar. 2019 – Mar. 2023)Realm Defense is a free-to-play tower defense and hero collector game for iOS and Android with 300+ levels, 20+ heroes, a weekly tournament, and has been downloaded over 5 million times on Google Play.
Links:
I joined the team at Babeltime Inc. to both design and implement heroes, levels, and systems during the third year of live operations of their first mobile game, Realm Defense. Realm Defense is a free-to-play tower defense game with light hero collecting elements. It has been featured many times on both the App Store and Google Play as a noteworthy offline game.
Working on Realm Defense has been my first experience of supporting a game post-launch. In the time since joining the team, my role has grown to include communicating with our most active players on social media, developing and balancing campaign levels, introducing new resources and meta-systems, and both designing and implementing unique new hero units.
Working to put out weekly patches of both content and bug-fixes happens at such a breakneck speed in the world of free to play, and i never could've imagined how much of a toll that takes before entering this position. However, the direct and actionable feedback from our player base allows for a thrilling amount of iterative polish and expansion that's difficult to oversell. The opportunity to have so many hands pushing the limits of my designs has helped me to see the importance of robust testing and the utility of complex, interconnected systems.
The fast-paced development of Realm Defense mixed with its long period of operation meant that the project was severely under-documented at the time of my on-boarding. By necessity, i developed strategies for researching across our commit history, social media, and player-generated content for clues about past design decisions to fill in the gaps where institutional knowledge came up short. In addition to researching and building out the project's documentation, i've gotten to build spreadsheets and external tools to assist in the analysis and generation of content of all types.
Tori
(March 2016 – April 19, 2018)Tori is a third-person flight and exploration game about interacting with spirits of sound to bring life to the floating islands of Otokai. It was the first commercial game i developed.
Links:
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, they return life and music to the land.
With our small, inexperienced team, my role changed by necessity to include programming, 3D modeling, and project managing on top of my primary work as a designer. Getting a chance to touch so many parts of the project was truly valuable in furthering my understanding of what kinds of work each member of our small dev team did on a day to day basis. Many of the lessons i 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 was the ever-changing 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 permission from the original project owner) re-pitched the project in an attempt to build a new team. Two people began to work with me then, and five more members joined Team Tori over the course of development.
Before Tori, the longest i had worked on a single project was a couple of months, and i almost always knew the people that i was working alongside. i was scared out of my mind that working on this project for years with people i had never worked with would be impossible. At the beginning of the project, this seemed to be confirmed when myself and a 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 ways we communicated stood in the way of us being open to each others' ideas. The road to fixing this working relationship long and winding, but I'm very happy with the work we were able to do together in the end.
Not all problems with teammates worked out this smoothly. After a period of radio silence from one team member, i and 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, yet nothing changed. It was very difficult to remove them from our team and there were definitely hard feelings, but we were able to restore a professional relationship with them in the end.
A huge requirement of making development happen with a team of any size is an ability to communicate a consistent vision for the project. This became most clear 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. This required presenting the editor with a fairly clear idea of what the final video needed to look like so no major revisions would be necessary. This gave me the chance to try my hand at storyboarding. i learned the basics of how to communicate the motion of objects, the 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.
It is in these meetings that i learned the most about communicating ideas. We met four or five times a week, and i originally thought we would be running out of things to talk about early in development, but this was certainly not the case. We were always hoping to discuss far more than we had time for, and this necessitated learning to communicate concisely. It taught us the importance of keeping a record of our conversations and our ideas, and most importantly, it 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 began pitching our game all the time. i ran our game concept by someone outside of the team at least once a day. While i knew that this would make it easier to present the game in the future, i didn't know that it would help me to understand when we were making decisions that were not right for the game. Telling someone our concept forced me to have a pretty good idea of what was at the core of the project, and that truly came in handy when thinking about whether proposed changes were ultimately good for the project.
As our team size fluctuated between three to seven members, so did our needs. My original goal for the project was to focus on developing the game's concept -- to iterate and expand upon the most energizing bits. Very early on, it became clear that this was not going to be enough when we lacked a programmer; so, i shifted to doing more implementation for a short time to enable us to test our ideas and iterate faster. Though this put some unwanted distance between myself and the game's direction, I'm thankful that i ended up taking on those tasks as they allowed me to better communicate with the team about new concepts we eventually implemented in the game.
Later in development, a member of our team decided to shift their involvement from environmental modeling to a focus on characters. To keep the timeline of our team on track, i took up some of their original work with the game's environments. Though I'm certainly not a 3D Artist, filling in worked out very well for our team and drastically increased the original Environment Artist's morale.
Game Jams and Smaller Projects
Most work that i've done has been of a much smaller scale through these projects i learned to experiment with interactivity, limit my scope, and collaborate with people that i'd only just met.
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 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. Finding some small amount of success in this with Window 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've loved4'33" for a very long time, and finding a way to make it into a game is one of the first ideas i had related to game design. 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 in the future.
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 with Danielle Benthien, Jacob Koonce, Jacob Rave, and Rush Swope. IndieHangover included Lacking Depth in their article "5 Fantastic Games from Train Jam 2017"