On the Development of Bottles (Pt. 4 - Reflecting)
Looking back on the development of Bottles now after some time and space away from the project makes it easier to identify some of the biggest lessons I learned from the process.
Scope, Time, and Self-Comparison
Scope, scope, scope. Though I went into this project with the intention of keeping the scope as sparing as possible, even the most diligent developer can fall into overextending themselves or their team. In my case, I think the primary problem was less one of a lack of consideration, but more a misunderstanding of what it would take to bring a level to polish.
For example: post-Alpha my leads and I went to talk with my industry advisor. I was feeling like we had lost momentum, lost focus, and were having trouble moving forward according to our production plan. I expressed this to him and he invited us to his studio to talk through the process, one he was familiar with having been in our position years before. One thing that I found really enlightening was how he pointed out that our puzzle development process was inherently different from the one that some of my peers were working with. I had been trying to understand why we were moving slower, iterating less rapidly, but those projects I had been comparing myself to subconsciously were ones in which they had static building blocks they could move around to create as many new levels as they wanted. For Bottles, on the other hand, every level, every puzzle, every interaction was bespoke. Looking at it that way it only made sense we had a smaller volume of content. And furthermore, looking at other projects wasn’t a useful metric of comparison because even within “mobile puzzle game” there is a huge breadth of what a game can look like, and what a game can require to bring it to completion.
It seems so obvious now as I reflect on it, but at the time it was a logical inconsistency that I needed someone to point out to me.
Right Idea, Wrong Time
A recurring theme that surprised me throughout the Bottles development process was how often ideas we had used or pitched early on in the production cycle ended up being implemented later down the line in new forms.
Even though we went through so many iterations of the conceptual structure of the narrative surrounding the gameplay and had draft upon draft of ideas and levels and characters that were tossed out, organically details from those past ideas seeped in as we were editing and ideating on the final product. For example, when we were trying to decide how to end Shipwreck as we were re-designing it post-Alpha, someone brought up the idea of a hermit crab blocking the way towards the goal that the player must convince to move. This hearkened back to the subway station level era of the game we had been trying to make back in September/October of 2019 that had long since been scrapped. The context was entirely different, but the idea felt like it fit more organically with this change of pace months later that we couldn’t have predicted would happen in the fall.
This happened again and again. The idea of the Octopus as the main player character. Ideas around Adi always came up ,even when we had decided that she was not the main character of the story. The idea of bottles within bottles— all of these and more came into play long after their original inception. It confirmed to me something that I hadn’t actively considered, but deeply felt: sometimes it is not a matter of an idea being good or bad, but whether or not this is the time for that idea to be used. Judicious and conscientious deliberation became our best friend in developing this game, and never completely throwing away iterations past meant that the lessons we learned and concepts we created were open to us down the road.
Accepting Critique Versus Maintaining a Vision
My thesis had more people than most offering critique at every turn. Being both a thesis project and an AGP game, not only did I have a standard thesis committee but also a complement of twelve other professors, and also an entire cohort of MFA students all providing feedback and commentary. This meant that, as director, it was up to me to listen to their voices and sift through the suggestions to figure out what the “note behind the note” was, and decide whether or not we should act upon those notes in how we developed the game going forward.
I discovered early on that I had been taking feedback, particularly from professors, as an inherently weighty gospel that needed immediate addressing. I would return to my team and instantly start re-composing everything based on one set of feedback assuming I had made a directorial misstep that needed correction; particularly when I was talking to people whose voices I deeply respect, or whose work I admire.
Often I saw developers (both professional and student alike) who never took any criticism, who buckled down and got defensive as soon as anyone “attacked” their work by claiming it wasn’t perfect. I saw them when I was an undergraduate in a writing program, too, fiercely defending faulty prose or botched symbolism or unintentionally offensive content, and I had vowed I would never be that brand of creator who ignores constructive criticism.
However, In trying to avoid that bad practice I had overcorrected. It took receiving several sets of conflicting feedback for me to stop myself and really consider: this feedback is important, but is it bringing me closer to the vision of the game I want to create? From that point on I tried to take in every session with a conscientious mind. When faced with a volley of suggestions, corrections, and comments, it took more effort to go one by one and think critically about the value of the note in the context of my game; but it meant that I was able to walk the thin line between becoming a stubborn dictator of a director who would take no critique and bending my vision to every new piece of feedback thrown my way. Sometimes that was particularly difficult when faced with people I respect telling me that my directorial choices weren’t the right ones. Still, I feel like I took a big step forward in my evolution as a creative director by learning how to stand my ground.
Managing People is Labor
We learn a lot of “hard” skills in the course of study, but seldom do we focus on the practice of “soft” skills when it comes to game development. There were a few classes in which we addressed and discussed strategies for people management, interpersonal conflict resolution, and other kinds of team-centric disciplines (and I found those incredibly helpful and insightful) but I had never considered the weight of those tasks in the scope of “task management”, a la the way most development is handled. You have tasks for “create a 3D asset of a tree” or “program a button interaction script”, but how do you measure in work-hours the amount of time it takes to coordinate with external legal counsel and artists, or make design decisions based on feedback? Those things, when examined closely, are often hard to pin down in concrete ways.
At the beginning of the year I hadn’t thought much of it— I could juggle these “soft” tasks alongside more traditional content creation without thought. I knew how to manage writing design docs, creating pitch decks, and working on my prototypes. As my team grew and time went on, however, I spent less and less time implementing things in-engine, or drawing up hard assets for the game. As director my job wasn’t to micro-manage or change the hard work my team had put in, but to make sure they had the information they needed so that they could do their jobs to the best of their ability. For me, that meant stepping aside and relinquishing direct implementation to people who were far more technically-minded than I.
As someone who likes to have their fingers in everything going on with the project, it was a hard thing to accept. What work was I actually doing, if I didn’t have as many task hours on our tracking software? Was I being a bad or lazy director for not spending all my time in-engine alongside my team? Why was I still exhausted by the end of the day?
I asked my leads about how they felt, if they needed or wanted more hands-on support from me. They didn’t. I consulted my advisors and fellow MFA students, seeking advice; the answer I got back was uniformly “managing people is a full time job all its own”. And the more people to manage, the more time and effort it takes to keep everyone moving together. All those hours I spent in meetings and discussions with various disciplines on my team, all that time I spent getting up early to get everyone snacks before our five hours of team meeting every Sunday, checking in with advisors and fielding comments from weekly faculty check-ins— all of that was my labor. That was where my energy was going. And though that couldn’t be so easily quantified or broken down into sub-tasks to be checked off on a list, that didn’t mean that I wasn’t putting all my effort into making Bottles as good as it could be.
Dealing With Unforeseen Circumstances
One of the hardest things to deal with hands down was adapting to forces beyond my control.
COVID-19 swept in like a hurricane and tossed every carefully-laid plan for Spring 2020 aside; we had been rolling through with tasks post-Alpha, carefully scoping and pruning production so that we can make our Beta deadline, and then all of the sudden the entire world was turned upside down around us. No more team meetings in person. No more in-class talks. We weren’t special, either— the entire world had come to a screeching halt followed by a shy, tentative scooch back into the flow of work progress.
What ended up being one of the biggest surprise lessons of the Bottles production process was how to press on in the face of unprecedented, chaotic times. My entire team (myself included) was shaken to their core. I had to figure out how to keep up everyone's spirits and motivation, how to adjust to doing everything in a completely different workflow from home, how to get access to school-bound assets we were cut off from. We made it work. We met on Zoom, we pressed forward and improvised when necessary and made a complete build we can be proud of, come hell and high water. Having my team stick with me through all of that even while we all struggled was both incredibly humbling and validating as a director.
The only certain thing about game development, in my experience, is that no matter how big or small the project it is never a matter of "if" things will go wrong, it is always a matter of "when". Learning to adapt to that (in what is, I would argue, a greater magnitude of "things going wrong" than what most projects had to deal with in a pre-COVID world) is an invaluable skill.
Bottles' development has been one of the most challenging and rewarding undertakings of my life. The concept came a long way from the day I looked at a bottle of soda and said “wouldn’t it be fun if…?” Back then I had only fantasized about what leading a team as Creative Director might be like. There was no way to predict how much positive feedback I’d get on that initial pitch written at 1AM, or the overwhelming support from my peers and professors and team, or the wild rollercoaster of an experience this turned out to be.
The very name of a "post mortem" implies a completion, a finish, the apotheosis of a project that has already come to pass and the subsequent vivisection thereof. Instead, I would like to take a page from the book of a wise professor I once had who called reflections like this a “post-partum” analysis rather than a post mortem one. From where I am standing it feels far more like looking at the lessons I learned in the course of making this game that I will be taking with me into my future as a developer and a creator, not an autopsy of the past. Every step of the way, Bottles was a celebration of exploration, creativity, and wonder— a celebration I want to keep alive in my work for many years to come.