Production Blog 6 - Postmortem

Hello everyone, and welcome to the final production blog of The Warfront From Intercepts, a puzzle, strategy game where the player sifts through papers to find the enemy’s battle strategy!  This blog will be a little different from the others, and I will instead talk about the development as a whole. Before we get into that, I want to say thank you to my team. They all rocked it, and it was amazing working with this group of people! Over the course of the project, our team of 10 developers completed 599 points of work. If you would like to hear about the overall design experience, you can read Justin's postmortem.

What Went Well

Many things went well during the production of this game, and one big one was communication. While our communication wasn’t perfect in every aspect, team members would frequently reach out for help or confirmation with their cards. The artists would frequently check in with their work to make sure they were going in the right direction for the designer’s vision. If anyone was confused about what a card was asking for, the team members would ask clarifying questions, which would sometimes lead to me rewording the card to help with clarity. Programmers would also frequently ask or tell each other which scene or branch they were in, and what scripts they were working on, which caused a lot less merge conflicts than there could have been. This made programming much more efficient than it would have been if merge conflicts needed to constantly be resolved.

Another thing that went well was the scope of the overall project. The scope of the game had to be adjusted throughout the development process. Still, the designer and I were able to figure out which features were more important than others, which left us with plenty of time to refine what we already had without worrying about new features. This not only was ideal for making a better game, but it also provided a sense of security within the team, relieving a lot of stress.

An important thing that went well was how the division of labor worked. Each person had a sort of “expertise” in a specific feature. Each battle stage was created by a single modeler, providing consistency within the individual stages. The programmer became the main programmer for a specific programmer, such as having one person in charge of paper handling and the camera, another person in charge of the battle logic and war map, and a final person handling the chemical station and the sound effects.

What Could Have Been Better

There are some shortcomings we came across during the development of the game. One did involve the division of programming work based on the feature. While it was nice that everyone had an area they were in charge of, it wasn’t organized in a way where all programmers had an equal workload. One person being the master of the battle logic and war map caused a lot of work for that single person which was also very important for the core loop of the game. This was, unfortunately, built into the nature of the game’s development. Breaking it down into two separate jobs, such as the war table being done by a different person than the one doing the battle logic, would have only caused a lot of cross-over in scripts, leading to many conflicts in possible bugs, and having two people work hand in hand would have made the logic difficult to follow.

Another thing that could have gone better was the wording of my cards. There were many times when I had to reword the cards I assigned. While I was always quick to make the changes and communicate with the confused team members, production would have gone more efficiently without that extra step.

Lastly, the obvious thing that could have been better is having fewer bugs. The nature of game development in such a short period of time is that bugs will exist, and it’s very hard to avoid completely. No matter how much each developer may beg a plead for the game to be flawless, something will always slip through the cracks. The huge upside of this is that the bugs we do have are very minimal, and that’s the most any developer could ask for!

What I Will Change

One thing I will change is planning out the programmer’s features focus better, so the workload is more even between them. While there are times when it wouldn’t work out perfectly, like for this game, it’s worth taking the time to plan that out ahead of time as best as I can to avoid someone getting overworked.

Another thing I will change is how I write the cards. Card clarity is very important to keep everything going smoothly, so I need to try my best to practice making clear ones. I should also ask if the person being assigned the card needs any clarification at kick-off, rather than having them get to the card in the middle of the sprint and needing me to change it. This will come with experience that I hope to continue having the opportunity to have in the future.

What I Will Do Again

The biggest thing I would do again is to have everyone feel open to communication. Not every team will communicate as openly as this one did, and asking for help is a huge time saver. Having the communication we had in future teams would make any development experience so much easier. I want to harbor that culture as best as I can, so I can bring it to any future team I work in.

The next big thing I would do again is have the same programmer or modeler work on the same feature, rather than having multiple people working on the same one. This kept a lot of people from getting blocked on their cards, which made for efficient sprints. This is especially important for programmers because there was minimal need for them to have to learn the other person’s scripts to do their own. The crossover between scripts and features wasn’t completely gone, but it was minimized in a way that avoided many possible problems or bugs.

What I Learned

The last game I shipped, I learned that things will be cut from a designer’s perspective. For this game, I learned this same valuable lesson again, but from a producer’s perspective. While the lesson is fairly similar in both aspects, there are some differences in how it’s handled. As a producer, my job is to know what can and can’t be done, and I have to be the bearer of bad news to the designer because most of the time that last feature cannot be done. Despite it being my job, I have learned that no matter how confident I am at the beginning of production about what will make it in and what won’t, I am most likely going to be wrong. This isn’t because of poor planning skills on my part, although I know they can still be improved through experience, but it is because you will never know what will happen during production. In an ideal world, everything will just work, but that’s not realistic. We’ve had bugs that we had to fix, which took up time that could have been spent on another feature. At the end of the day, a producer needs to be there to always have a plan a, plan z, and everything in between when things go awry.