Team SAOS: The Root of the Problem


A Chinese philosopher once said, “千里之行,始於足下” , “A thousand miles begins with a single step.” This is true for both grand conquests and game production. Going back to the very formation of Team NAH, it was one that was never stressed. Some teams formed due to friendships, others formed from the remains of Production 2 teams, some were “formed” out of the leftovers. Team NAH in the beginning, had never worked with each other on a single game. We quickly formed as a team, and left it as that for months. It was not until halfway through the summer, that we realized that we should do some preparation/discussions about the coming semester. Still nameless at this point, we would suggest game ideas, usually tagged along with some joke or gimmick. When it came time to actually name ourselves, we were stumped. On a walk home from work one day, I jokingly said we should just call ourselves, “Names Are Hard.” We all liked the name and it somewhat reflected our relaxed nature of a team. It may have taken a couple of weeks to get the workflow going, but when it did, we were walking at a brisk pace. We planned everything in advanced so we know when things needed to be done, and what was needed from us for that to happen. By the end, all of us had a product that we were happy with. Even though we did not move forward into production, I feel like we all moved forward in our respective disciplines.

Individually, I believe that I am not a creative person at all. Aiding in the creative process of the team is something I can do in a roundabout way as a Programmer. Something I heard other Programmers talked about near the beginning of the semester was the “Programmer’s Veto.” In essence, the Programmer’s Veto is the idea that since you are the primary way to get ideas or mechanics into the game, then you have some extra say in how it exists in game. Now, some people would think of this as, “I don’t like this idea so I’m not going to do it” which is a toxic mentality, however, the Programmer’s Veto can be used in a positive light. Since I was usually closest to the game integration wise, I feel like I had a better sense of what was in and out of scope with the current state of the game/technology. This may sound like I was actually hindering the creative process instead of contributing to it, I can think of one time where I said “I don’t think we can do this with the time we have left.” After explaining to the team why I thought this, they agreed with me. The way I most often added to the creative process was the way I would add features to the game, sometimes sparking new ideas for other features.

There was one time throughout the development of The Root of the Problem where I had to think about how what I was doing was going to be used by other members of the team. Rewriting how enemies spawned came out of nowhere, and was a great way to spend a restless night. Previously, enemies could only be spawned with one wave, and in a very specific way, something that that needed to be changed so that spawning enemies could be done easier. When I was rewriting the system, the one thing I had in mind was, “What would be the easiest way for Scott [our Designer] to make interesting enemy arrangements.” After a couple hours of hacking away, I finally reached a point where spawning enemies was much simpler and more intuitive that the previous state it was in.

Some important key decisions that I had to make throughout the course of the semester was Git vs SVN, Unity vs Unreal, and The Root of the Problem vs our other prototype, Blind Faith. To be fair, the first two were questions that were raised before we even started development. The Git vs SVN debate is one that seems to be a foreign one to many of my peers. I know many teams that went with Subversion because they and everyone on their team already knew it, which are valid reasons. After talking with the team, they said that there was no preference between Git or SVN, so that might beg the question, “Why did you go with Git then?” The answer to that question is that over the course of the summer, I was growing accustom to Git and saw that it was being used much more than Subversion outside of the educational environment we were all used too.  It may have caused some troubles when everyone had to switch from the SVN mindset over to a Git one, but I still think it was the right choice.

The next major decision was Unreal vs Unity. One of the main reasons we were wanting to go towards Unreal was the fact that from the start we did not want our game to have the “Unity” look that so many games before it had. We wanted to stand out and have people think that our product was not made in Unity. The downside to Unreal however, was that very few of us had ever done anything in it, let alone make a game. After spending a couple weeks during the summer trying to navigate through Unreal’s, at the time, atrociously lacking C++ documentation, I told the group that if we were to use Unreal, we could make the same thing in Unity at a much faster pace, and it would probably be much more stable. In the end, the main way to not have a game look like an “Unity Game” is to create a unique art style that either abandons the Standard Shader, or uses it to it’s fullest potential.

The final decision was probably one of the hardest and most important decisions I, and the whole team had to make. We were all very into the idea of The Root of the Problem since inception, but most of the faculty we talked to did not like the idea and loved the premise of Blind Faith, a game where the player helps guide damned souls out of hell by creating a path for them. I vividly remember sitting at dinner one night with the team and we were all discussing what game we should go forward with. Whenever we talked about Blind Faith, it seemed we all had a much less passionate tone about the game, compared to The Root of the Problem, where we would all sound excited to be working on it. We all knew it would be the harder game to pull off, and we went forward with it knowing that. The deciding factor for going forward with The Root of the Problem instead of Blind Faith was that we all wanted to make a game we would have fun playing and have fun developing.

Moving forward into Production, there are a few things that I learned that are not nice to have, but rather required to have in order to have a functioning team. The largest one was camaraderie and communication. Throughout the course of the development of The Root of the Problem, I wanted to keep working on the game because I wanted to keep working with the team. Looking at our slack, you would see both channels where we would just spam gifs, while at the same time daily scrum channels. This allowed us, or at least me, to feel comfortable addressing any concerns that there was with the game.  Wanting to work with your team is probably the most important factor when it comes to game development.