How I Got Away With Murder



For the past couple months, I have been on a wonderful team creating a vertical slice of a game. The end result is a fully playable game called Getting Away With Murder (GAWM). GAWM is a 4v1 asynchronous multiplayer online game. There are four brothers who are trying to dispose of the corpse of their father that they recently killed. At the same time, the ghost of the father is trying to stop them. This has been the largest team I have worked on, 3 Programmers, 2 Designers, 2 Producers, and a single Artist brings the grand count to 8. Although this may seem small to many. Going from working with no other programmers to working with two others is a test of not working on each others toes more than anything else.


Being added to the team very early in this projects development, one of the first tasks was to get accustomed to how the project was structured. file-wise and architecture-wise. The original idea for the game was there was only one human who killed their brother for the inheritance. The game itself was very passive for both parties involved. All the murderer was able to do was pick up the body and place it on spike traps to safely traverse the incredibly linear level. Eventually we removed the traps from the level, due to not making any sense for the setting of the game, and abandoned mansion. The game probably reached its lowest point during this time. The game was very passive for both sides, and amounted to “Ghost finds the human ASAP, and then the game ends shortly after that. If the ghost doesn’t find the human, than the human would just win.” After receiving a wake-up call about how boring and bad our game actually was, we decided to completely overhaul how the game played. Out was the idea of 1v1, due to how large our mansion is. due to how large our level was, we added more objectives to the level in order to create the choice of banding together to find them all or each individual person searches on their own. On the ghost side, we gave them the ability to suck up furniture and be able to chuck them around. With smaller changes and polish in addition to these feature changes, the game came together to the finished piece.


Programming-wise, I see myself more as an aspiring Tools Programmer more than anything else. Being put onto this team that there was no time for creating tools, I contributed by laying the ground work for our features. When these features were presented, a more senior programmer on the team would then modify the base code to get it into what fits the idea of the game more. When it came to the end when there was just polish needed to be done, I spent time doing bugfixing.

However, for everything that went right, more things would go wrong.  During the middle of production, we were plagued with subversioning problems. As throughout the project, learning how to properly manage Unity’s files for proper version control fixed this. Between a combination of these articles, I was able to prevent prefabs and scenes from being improperly overwritten. These fixes however could not fix human errors. One of the most prevalent causes of bugs was that things were only being done on one client, and not being told to be done on everyone else’s copy of the game. Although it was nothing big that this problem showed up in, it did show up for the small things such as, sounds playing, particle effects happening, and disposing of gameObjects.


Over the course of this project, I have learned a bunch about my position on a team, what I need from a team in order to do my best work,  and how I work with other people of my discipline.  For my place on a team, I learned that I am much stronger in a position where I am in a support role for the other people.  This is slightly evident in the fact that I want to be developing tools, helping the rest of the team make their tasks easier and have a more integrated pipeline. Although I am still great at being at the cutting edge of the progress, I enjoy supporting the rest of the programming team in their work, and the more I enjoy what I am doing the more likely I am to work harder and longer on it.  I would much rather be the person in charge of running the supply lines than ordering the people at the front lines. In order for the supply lines to be run in a good, upstanding fashion, the one in charge needs orders from Command on where to allocate resources. In order to be at maximum efficiency and productivity, I need to know what needs to be done ahead of time. The best way to relate this to the game development process is to have an actual backlog of tasks that need to be done.  This did not happen on this project and my performance suffered because of it. However, Cody did assign us tasks to do for each milestone, after that was done, there was nowhere else to find what next to do, often asking the group what to do next, with idle thumbs in hand.


After all that is said and done, this game showed me much more what it is like to be on a development team than any other project I have worked on. The most important things that I took out of this is that team communication is one of the most important things to have. When a team lacks communication, than progress is made much slower and people lose motivation for the task at hand. Both of these things happened to our team, and it severely impacted our performance, but we managed to pull through in the end with a new spark of motivation and I am proud of the finished product, which can be downloaded here.