Communication is Key

Throughout all the materials I’ve read, or watched, to try and learn about better production practices, there have been two ideas which have persisted to be a focal points. Open communication and frequent meetings. When it comes to “open communication,” It seems every instructor took “communication is key” adage to heart, as they should. There really shouldn’t be an issue that cannot be solved, or at least have its impact mitigated, through communication. In the same breath, you have the subsequent “frequent meetings” which go hand in hand with this idea of communication. This idea of meeting frequently has been particularly drilled into my brain by all the materials that describe scrum’s best practices. This isn’t without reason, however. These two ideas help equip you for the overwhelming number of things that can go wrong on a project. The more you communicate, meet, and collaborate with your team, the more issues you’ll be able to diagnose and handle early on. This is no doubt along the lines of something you may have even read when studying for a scrum certification. While this information is valuable, and it is great that so many resources present it to those wishing to learn better production practices, there is no better teacher than experience. In this article, I’ll walk you through two projects I worked on. Both of these projects suffered from technical breakdowns in their final hours, however, their juxtaposition exemplifies the impact that communication and frequent meetings can have on how you tackle them.

First, let’s talk about Remasteroids. This was a project for my Game Production course where we were tasked with recreating an old Atari game over the course of two weeks. You can probably tell by the project’s title that we ended up going with Asteroids. The idea seemed simple enough. We had a programmer, an artist, and myself (flexible between art and programming). Early on, the programmer informed us that he had found a tutorial that didn’t seem too complicated. “Sounds good,” I said. I had faith in what he told me because I’ve had projects where I find a tutorial and I’m done in a couple nights. I may have to modify some of it to fit my exact needs, but nothing seemed out of the ordinary with what he was saying. Since he had the gameplay taken care of, we decided to get ambitious with the project. The artist would work on the background art and several asteroid models. I would be working on several ship skins which the player would be able to switch between in the main menu. The days progressed and we were heads down working on our tasks. We met a couple times a week during our class meetings, however, we never got demos to see how the gameplay was progressing. I decided to take my programmer’s word that everything was moving but moving slower than first perceived. I never really probed and asked further questions which is my own fault. I really hadn’t worked on many projects before, so I thought if something was really wrong, I’d be informed. This idea ended up not being entirely wrong. The project was winding down to the last couple of days and the team’s programmer informed me that he was running into some issues. Upon looking into the issues, I found out that the asteroids would infinitely break into many tiny pieces. This made the game unplayable for more than 6 seconds. This was in fact a major issue, but it didn’t seem insurmountable. I told my programmer I’d be able to work with him all night to assist in whatever he needed, so we could get some level of functionality. This was fine up until he was called into work and wouldn’t be able to do any work on the last day of the project. At this point I didn’t know what to do. I had a project filled with code that I didn’t write and no clue on how to fix it. I went to faculty familiar with Unity to see if they could help, but with my lack of knowledge on how the code actually functioned, they couldn’t help me out much. After several hours of attempting to troubleshoot the issues, I came to the conclusion that we were going to have to submit a broken build. This is where the story ends, right? Nope. When I get back to my dorm to submit, the project was corrupted, and I was locked out of Unity’s collaborator so I couldn’t even revert to an older, stable build! Luckily, I was able to get in touch with the team’s artist and he had access to an older build. After creating the final build, we managed to get a massively incomplete build of Remasteroids submitted on time. This one stung because it was the first time, I was the unofficial “producer”. I didn’t know much at the time, but I knew we needed a backlog of items which I made on google docs. I thought “surely, I’m doing this right.” I also knew that I should have been the one to establish clear lines of communication which could have prevented the late project meltdown. After this project, I really buckled down and studied the scrum framework and better overall production practices. I felt like I needed to do everything in my power to not have a similar situation repeat in the future or at least know how to deal with it next time it happened.

The semester continued and we reached our final project. We would all be working on original ideas created by our new teams. Our team had settled on an idea called The Child of the Forest(TCF). TCF was a puzzle game about a young witch that lost her cat, Luna, in the forest. She needed to use her magical abilities to solve a series puzzles in order to reunite with Luna, which was waiting for her at the end of the level. This one got off to a rough start because everyone was in the process of moving back home, due to the Covid pandemic, but things got on track pretty quickly. I was also lucky enough to have a co-producer on this project. This worked out well and we managed tasks based on which side of the project we were already working on (programming or art). I was in charge of the programming tasks and communicating with the programmers to help if there were any issues. One great aspect of this project was that we had established meeting times, which functioned similar to stand-up meetings found in scrum. This worked wonders for keeping tabs on progress and being able to plan based off of the current work being done. I found that this project, more than any others at this point, really practiced the “inspect and adapt” mentality presented in scrum. We often found ourselves changing tasks and weekly expectations based on the conversations we had in these meetings. Time seemed to fly by and before long, the project was due the next day. Luckily, we had planned a period of time for polish within the last two days of the project. However, in this last day when we were all working on polishing our last pushes, the git source control we were using started to act up. Pushes would take abnormally long to send, and pulls took somewhere along the lines of 20-40 minutes to download. This really interrupted the team’s workflow in the final hours of the project. At this point we had an emergency meeting and worked out a plan for implementing all the changes necessary for the final build on two PCs rather than having each member submit their own pushes and having to wait the long pull times to receive them. Though it wasn’t ideal, it allowed us to get all our work done in a relatively stress-free manner. We got the last two pushes in, built the project, and submitted it to the instructor. Later the next day, we demoed TCF in front of the whole class and it was a huge success! Our teacher and colleagues ended up being very impressed with the small game we put together. I came out of that experience with an immense amount of pride in the team I worked with and a lot of knowledge about how communications within teams can and should work.

The result of Remasteroids and The Child of the Forest were night and day. On Remasteroids, I failed to provide a structure for meetings and I also didn’t do a good job of emphasizing frequent and open communication. This lack of communication led to a breakdown in the final days that couldn’t be solved within the remaining time. This experience was dreadful, but I took my lumps and applied that experience to my subsequent projects. That experience combined with the studying I was doing for my scrum certification allowed me to be more of an asset on TCF. Though it took some work, I finally got firsthand experience which displayed the true value of communication and frequent meetings when creating a game with a group of very talented people. It doesn’t stop here either. Every day that I work on new projects, I’m constantly learning. Being a better communicator isn’t something that you just achieve one day, it’s something that you work at constantly. I’m nowhere near finished learning, but I feel like these projects in particular gave me a good start.