With these words, my time at Champlain has almost come to an end. Last Friday was the Senior Show, an opportunity for all the seniors who are a part of the game major to present their work, both on their games and personal work, to faculty, other students, and visitors from several studios who had also come to watch the show. We turned in our final “Gold Master” build three days before that, and all our hard work came to an end.
I’m very proud to have been a part of Protocol Aurora, and I’m glad I joined the team. It gave me an opportunity to try my hand at being the sole narrative designer for the team, and I learned a lot about the process of making games. There are many aspects of the development process I’m very proud of, but also a series of mistakes I made that ended up weakening the end product of the game.
Here’s a quick summary of things that went well, things that could have gone better, and things that I learned.
This postmortem is a personal postmortem, rather than a team postmortem. For that reason, everything I talk about here will be focusing on things I interacted with or worked on directly, because I do not have a full understanding of the successes and failures of the rest of the team’s work. This means that the successes, and especially failures, are going to be focused primarily on my ability to implement a strong, cohesive, and engaging narrative, and will not take into consideration a broad number of outside factors that impacted the rest of the team. Please take that under consideration!
Things That Went Well
Meetings and Work Sessions, Oh My!
If there’s one thing I think went particularly well for Senior Production, it was the cohesion and dedication of the team towards the project, especially in our leads. I’ve heard before that it is good to have “work sessions” when making a project, setting aside common, dedicated blocks of time for everyone to work together in the same space. However, living off campus and generally not working well in loud group environments, I’d always preferred to do my work from home unless I was meeting with someone else to do something specific.
Grey Fire Games showed me that attitude was a bit of a mistake, as most of the work I did this semester took place in a work session, especially towards the end of the semester. Not only did it help me work better when I could turn around and ask someone a question as soon as it came up, I could also get my work checked while I was making it, not only once I was done, to make sure that I was on the right path, and wasn’t wasting my time doing something the team didn’t want or need.
Building A World. Literally.
Perhaps one of the aspects of the game that most improved from the start of this semester to the end was the levels, both in terms of quantity and quality. Scott, Jil, and I almost quadrupled the amount of playable space in the game, and we set up a really good system to get it done right from the start of the semester. At the first meeting, Scott and I sat down to collaborate on planning out the general level structure. Scott then took that, made a few level maps, before setting out to greybox out a level in-engine. Well, whitebox. This was taking place in the arctic, after all.
Once the first pass was complete and gameplay felt good, he and Jil would sit down to make a “highpoly” (not that anything in our game was truly high poly) mesh, which would be brought into the game, and would become the playable space in an all-but-finished sense. Once the terrain was in, I would take a pass at the level, adding environmental assets, setting up narrative “dioramas”, and adding veritable mazes of pipes. My goal was to add visual interest, and make sure the environment matched up with the lore, and gave the player cool spaces to explore. Once I’d done a first pass on asset placement, Jil would come through once more, double check that everything looked good, and tweak or add anything that needed to be fixed.
This pipeline allowed us to blast out a great deal of high quality content, and, at least from my end, the entire process seemed to go really smoothly.
Things That Could Have Gone Better
Rebuilding The Game
For good or for ill, Scott and the other team leads decided they needed to do a massive overhaul of the combat systems in the game, which involved all but remaking the player abilities and enemy AI. I’m not going to talk about whether or not this decision ultimately benefited the game, because I don’t know the reasoning behind making that decision in the first place. However, I will talk about how this decision, and the lack of communication regarding this decision, impacted me, and the narrative that got delivered into the game.
I, along with at least two other people who joined the team after last semester, assumed that everything that had come before was all-but sacrosanct. Those decisions had already been made, and were therefore immutable unless there was a very, very good reason to change them. I built the first drafts of the narrative under that assumption, shaping and twisting it to fit around what had already been established. While this didn’t greatly weaken the narrative I delivered, it did require a few sacrifices on internal coherency. Several of the most important aspects of the story felt thrown in, even to me, because not everything that had been established before fit together as cleanly as a hand-crafted narrative.
Most unfortunately, I now strongly believe that this belief was flat-out wrong, and if I had come forward saying I wanted to change everything about the backstory they’d written, I would have gotten approval to change it. I would have then been able to handcraft a story that fit around the systems and visuals of the game, and I think it would have been a much, much stronger experience for that. I wish Scott and I had taken more time to sit down at the beginning of the semester, or even the end of last semester, to work out exactly what the expectations on me were, and how much freedom I had to reach the game’s narrative goals.
The Game Needs A Narrative
When Protocol Aurora passed the cut during Capstone, one of the things the team was told the game was most missing was a narrative. One of the teachers described it as the game missing a “soul”. I was brought into Grey Fire Games to help give the game that soul, and everyone on the team repeatedly said that they knew what I was doing for the game was very important. I think they believed it, too.
Unfortunately, while the team leadership wanted to give me the freedom to come up with a good narrative, everyone’s focus early on in the semester was in overhauling the combat. And as planned weeks started stretching on into months, the focus remained on improving the combat. Anything narrative that I wanted in the game, I was going to have to put in myself, and despite my many requests for it, I never did get the “narrative sprint” I was promised, and that the game so desperately needed to finish tying the systems into the narrative.
Unfortunately, when this was combined with the fact that the code was being completely rewritten to emphasize optimization, I became unable to implement narrative systems by myself, even if I wanted to. The one time I tried to implement a simple system myself, I broke things so badly that the Unity Editor itself would crash when I tried to run the system in any scene but one.
This, in many regards, handicapped me. I shifted my focus towards environmental storytelling and dialogue at that point, systems that were already in place, but my inability to get much of anything new into the game, either by myself or with someone’s help.
Things I Learned
New Team Members
It’s really, really hard to bring new people into an already existing project. There’s a very strange balance between needing to bring the new members into the already existing pipeline and workflow, and shifting the pipeline and workflow to make sure that new members can exhibit their strength to the fullest. Either way, I watched, partially from the sidelines, as the actual progress being made on the game seemed to slow down to an almost snail’s crawl, despite the fact that everyone was putting in full hours every week, if not more.
It took us a lot longer than I would have expected to settle back into stride, and start to make good progress again. And, while I’d been told in the past about how adding new team members would always be a challenge, and had seen the charts about how productivity tends to rise and fall, it was still an eye-opening experience to watch first hand. I think I understand a little bit better now why so many studios are reluctant to bring on interns.
I almost completely had sole ownership of the narrative of the game. While in many ways that kind of freedom is very liberating, as it allowed me to make decisions that I thought were best for the game, and then dive into the work, it was also trapping. It meant that anything I couldn’t do likely wouldn’t happen at all.
Part of the reason I got into games to begin with was because I loved working collaboratively. I find the process of working with other people helps my own creative process, and it also allows the strengths of others to bolster whatever we are making. I’m surprised to realize exactly how little I like working on my own on something, even when it is something I enjoy working on.
I am proud of the work I did for Protocol Aurora, but that does not mean I consider the project as a whole a great success. I made several decision early on in the development cycle that nearly hamstrung the potential of the story, and the lack of resources and collaboration on the narrative meant that it never really got a chance to reach its full potential.
I do not think that Protocol Aurora had a bad narrative by any stretch of the imagination. The work I did for it was strong, and many people who have played the game really enjoyed following the story. Several people even re-played portions of the game to make sure they got everything, which was incredibly flattering. However, I also don’t think it had a great narrative, due both in part to my own decisions, and due to a lack of resources invested into the narrative.