A glimpse into a small team that’s made a sizable game
Sometimes, when making games, you're on the big teams making the big games. You’ve got dozens of people all tugging on the same project, trying to make changes that don’t blow up the work being done by someone else.
On the other hand, sometimes, you have Jacks-of-all-trades who are doing everything for their small game - art, engineering, design, etc
I fall somewhere in the strange miasma of the middle ground, the solo engineer on a small team of a pretty big Unity game project, Nevermind.
Nevermind was once a pretty big game with a pretty big team and some very large ambitions with its sights set on biofeedback-enhanced gameplay. Its original incarnation was an MFA thesis project at the University of Southern California, developed across USC Cinema’s Interactive Media and Games program and USC Viterbi’s GamePipe program. I was the producer for the game at that time, managing a team of about half a dozen student programmers as well as a team of artists from another university. The game’s prototype was made, presented, and enabled the team to pass their class with flying colors. We all disbanded, being caught in the winds of internships and employment. It seemed that Nevermind looked to share the fate of so many student game projects, to be laid to rest in a quiet grave as the team went onto do new, different things.
Nevermind, however, rose from the grave and was determined to live. It came back, dusting off its funeral suit and presenting itself to the world as an experience meant to be taken further. And Erin Reynolds, the author of the original MFA thesis, asked me to rejoin the project as a programmer.
As its only programmer.
So a pretty big game that once had a large team of students behind it was now being re-imagined by a company with less employees than I have fingers on one hand. (I have the typical amount of fingers on both hands.)
Thankfully, we started with known territory. The original academic level was a solid design. There was no reason to throw it out. Thus, the first step was to bring it back with a vengeance, either through resurrection or reconstruction. I opted for reconstruction. Maybe all the code was there, but years and a few Unity versions had passed since anyone had looked at the original project. We also had an artist, one artist, who was going to be remaking all the assets from scratch. Better to start fresh. To toss out the old blood, sweat, and tear stained slate for a new one that would soon, itself, be stained with new blood, sweat, and tears.
There were calls that had to be made early on. Calls that, as the only engineer, were basically mine to make. It was like being a strange hybrid of engineering upper management and coding monkey. I could make the decisions, but then I had to bear the entire weight of those decisions. There were deadlines, milestones, and contracts that the company had to adhere to. There was no backup. Failure was not an option, because there was very little chance another engineer could step in, learn the code base, and meet the deadlines if I wasn’t up to the task.
So smart decisions had to be made. For example, I avoided physics like the plague. Physics is a beautiful thing for certain games, but for ours it was a heap of unpredictability. The original academic version of Nevermind used physics for player movement, but that lead to strange moments like our “catapult staircase.” Nevermind has a crazy spiral staircase. In the original version, the staircase rotated to let the player walk down it correctly. That rotation, however, would sometimes launch the player out of the level because of the strange propagation of force in the physics logic. As humorous as it was, it was not an ideal player experience.
So I avoided physics unless it was absolutely necessary, opting instead for a custom player movement system based on walk meshes, something Unity was able to support thanks to its incredible flexibility. It was perhaps an unorthodox decision at the time, but thankfully hindsight has proven that it was a good decision. It was reliable, predictable, and our player could walk upside down or on the walls without any concern. The artist had to do the work of generating the walk meshes, but in the end he prefered that to setting up all the necessary physics objects correctly.
Being able to make that choice is one reason Unity was our engine of choice in building both versions of the game. For the academic version, Unity was our fast-prototyping lab of mad, scientific experimentation into how we could make a game with biofeedback. For the current version, Unity still lets us play mad scientists, but it also allows us to make the choices necessary to ensure Nevermind is the best experience it can be.
Of course, sometimes you just don’t have a choice when it comes to systems. Nevermind is a game that uses biofeedback technology to enhance the experience. Thus, I had to integrate a variety of “non-standard” sensors and software to make this happen. Some sensors were easier than others. Some, like the Intel® RealSense™ technology and Affectiva’s Affdex technology had existing Unity plugins. Others had to be monkey wrenched in. If we were a larger team, different engineers could be assigned to different sensors with the instruction to develop custom plugins. Plugins that would allow the game to handle everything internally and in one coherent way.
I, unfortunately, didn’t have the time for that, especially with my minimal plugin development experience. Sensors that could be integrated into Unity directly were slotted into the game. Those that weren’t, or that were made incompatible by the decision to become a 64-bit application, had to live separately. Their new home was a separate companion executable that could run with the latest .Net libraries, could run as a 32-bit application, and could be developed visually with minimal effort.
The one high school programming class I took came back with a vengeance. Nevermind’s Heartrate Companion was born and lives today as a WinForms application. I have no regrets.
Despite not developing any myself, plugins still became essential to Nevermind. Maybe, given enough time, I could have coded my own solutions to some of the common systems the plugins covered, but that wasn’t the point. The cost of a asset store plugin became weighed against the cost of my time. Did the plugin cost less than the time it would take for me to make something custom? Were there higher priorities I had to focus on? Most of the time, the answer was yes, and it was a yes I took as a blessing.
Each plugin took a bite of work off my plate. In fact, some have become so intrinsic to my Unity development, I couldn’t imagine working on a Unity project without them. Why reinvent the wheel? Why not support other developers who offer their arguably brilliant solutions to basic problems like localization and input? Yes, sometimes your personal programming practices don’t mesh well with how someone has developed a plugin, but in a way, it gave me reminder what working on a larger programming team is like. The Unity Asset store was another team member for us, with a lot of its own personality, quirks, and strengths.
Nevermind was released on Steam in September 2015, but work still continues. We want to add new levels, more platforms, and even more sensors, and all of it keeps me busy. There’s always been talk around the office of bringing on more staff if/when the funds become available. An occurrence that would enable me to evolve into being a true lead engineer with a team. That is a day I look forward to, but I’m also not in any rush to reach either. Why? Because the pains and joys of Nevermind’s technical development have been entirely mine and my sense of ownership is strong. I may not have been the one that designed Nevermind. I may not have been the one that gave it beautiful art. But I am the one that got its heart pumping, its lungs breathing, its nerves firing, and its muscles flexing.
I’m the solo engineer to a pretty big game project, and I helped bring Nevermind to life.