Natural Disaster: A Postmortem

 

Working on Natural Disaster: A Butterfly’s Guide to Mass Destruction was an amazing experience. It was a chance for me to finally put my project management and game production skills to the test in a big team setting. The development team featured 29 talented people working across all disciplines of game development, and I’m grateful I got to work with all of them. I also took on other roles based on the needs of the team, at times I was a designer and other times near the end of the project I was a full-on QA tester. This helped give me a fuller view of everything that was going into making the game as awesome as it turned out. As I mentioned before, I also learned a lot in this project. There are a few things that I would do differently. Here are some of those things.

1. Communication

On this project I learned and experienced how important communication is. Through my own failure to foster communication between departments, there grew some hostilities between some of our leads. With the help of the other producers on the team we set up a meeting for the leads to talk things out. Though it was uncomfortable for everyone, it helped immensely. Another example of the benefits of communication came from one-on-one interviews that I did with everyone on the team. It not only gave me the chance to learn about the skillsets of everyone on the team, but it helped me get to know all of them personally. That is something I will be sure to do for every team that I work with in the future: I will get to know them.

2. Organization

In this sense of organization, I mean how the team was organized. For the first two weeks of this project, I was working on a different game. After the prototyping phase was over and my game got canned, I chose to join the Natural Disaster team. At the time, the team was set up into departments by discipline. We had an art, and engineering, and a design team. This made me particularly uncomfortable knowing that in order to follow true SCRUM, the team needed to be split into interdisciplinary feature teams and the producers needed to act as SCRUM Masters. I raised this issue with the other producers, but they had a “isn’t broken do not fix” mentality, and I stopped pushing it. This was all good and fine for the first half of the project, but in the second the cracks started to show. There was a heavy imbalance of work between departments as certain tasks got stuck and couldn’t be passed to other departments until it was finished by another. This is what caused the arguments between departments mentioned above. Looking back now I realize exactly what we should’ve done differently. We should have taken the team and split them into three feature teams for the first semester. These would be a levels team, a character team, and a UI/UX team. Then, after being feature complete at the start of the second semester, we split the team into three path creation and implementation teams, and then have a fourth team assigned specifically to UI/UX and bug fixing. Then a month or so before launch when we have gone gold, we split into play testers and bug busters and make the game as polished as possible. Perhaps this would not be the perfect organization, but it would solve our problem with bottlenecks and communication. An example of these feature teams working came in the last month and a half of the project when we split the design department into “Machinima” and “Play testers”. Things started moving much more quickly and a lot more got done. The game went from a failure to a smash success in a matter of weeks because we split into feature teams.

3. Flexibility/Adaptability

 I learned very quickly that no two weeks would look the same while I was working on this project. That was because the needs of the team were constantly changing as people’s schedules changed. This was a student game after all so team members could only work ten or so hours per week at most. Early on in the project I was assigned to be a “floating” producer. It was my job to check in with all departments and offer my assistance where needed. Very quickly there came a realization that one of our departments was lacking a strong guiding voice, so I decided to change my role and focus on getting things moving in that department. Our three times per week meetings were mostly silent and nobody kept up with their tasks, so I realized that something needed to change. We quickly decided to move our online meetings in person so that it would be more difficult for people to remain silent during meetings. Thankfully it worked and everyone in that department was more engaged and started making progress on their tasks. Near the end of the project, when it was time to heavily focus on playtesting it was important for me to step up and leave a lot of my producer duties on the back burner so I could playtest. I had to put my pride aside and do what was best for the team. I am very glad that I did, because things have worked out great.

I’ll repeat again that I loved this experience. Not only did it solidify my desire to be a professional game producer for the rest of my life, but it gave me the chance to work on something that I am proud of. The game is experimental and didn’t take heavy inspiration from anything. We were left to answer a lot of questions about the game on our own. I am happy to say that we made a lot of right decisions and the game turned out great.

Written April 25, 2023, by Ryan Abney