Welcome back to the Perry’s Pies producer blogs. We have wrapped up production for this semester and this has been quite a crazy adventure. As with almost everything, there were ups and downs through the past 7 sprints, and many learning experiences, both what to do and what not to do. Overall, this has been an extremely valuable experience and the amount of knowledge that I obtained this semester was substantial and invaluable.

What Went Wrong?

The primary thing that I believe was the most significant issue that I experienced through this semester was with the backlog. We had a rough start with having a backlog developed on a couple of fronts. Firstly, I was not able to get access to the Jira board before our first meeting, meaning that the backlog was just compiled in my notes at that moment. This made our initial kickoffs rough. This also meant that we did not have enough in the backlog at the very beginning. Another contributor was the lack of a detailed GDD from the beginning. This did stunt our initial development of the backlog and is something that I plan on prioritizing for future projects, as we were making significant changes to the GDD up through sprint 5.

However, one of the big things that contributed to not being able to keep the backlog full was struggling to keep up with the amount of work that was being done. This is something that will tie in to ‘What would I do Differently?’ For this project, we had 4 modelers, all of whom are extremely proficient in their discipline and can complete a lot of high quality work in a small amount of time. Over the course of the project, the modelers alone completed at least 478 of the points that were made. By the end of sprint 4, our initial asset list, plus some updates, were completely done. One modeler ended up completing over 40 points in a single sprint.

Another issue that we ran into was the order of the production pipeline. This was difficult to understand until the end, but it took a while before I got to a point where working software was the highest priority. We did not have an ‘official’ completely playable core gameplay loop until the end of sprint 5, which really hindered the progress that could have been made and is a large contributor to not having all the things we made put into the game.

The aspect of communication between developers of the same discipline ended up being an issue, particularly on the programming side of things. During this project, I did not emphasize enough the necessity of communicating with each other, rather than through me. Programmers were not sitting/working together, and there seems to have been limited communication between the two outside of class as well. This led to significant conflicts in the implementation of different features, which possibly could have been prevented through communication.

What Went Right?

There were a lot of good things that we experienced throughout this semester. One of the things that worked well was the system that I used when creating a series of cards, especially for the modelers. The way that I have user stories organized for modeling is split into 3 different sections (Model and UV, Texture, and prefab creation). This was something that I discussed directly with the modelers about how they want this to be split up.

Additionally, with the significant number of modeling user stories that we had, I felt like we needed a way to easily distinguish what each card was for. The way that I decided to work with this was by adding the key detail of the model in brackets at the beginning of the user stories (i.e. [Broken Chair] As a player, I would like…). This also proved to be an effective way to clearly communicate variations of models, as well.

Team meetings outside of class were also very effective. The issue with this is that with a team this large, it is difficult to get everyone to have the same time availability to meet. These meetings weren’t possible every week, but when people were able to join during these times, it was a good period of time to at least get a little work done and ask any questions, if they were needed.

What Would I Do Differently?

One of the most prominent things that I would do differently is make sure that I analyze the skill and efficiency of work being done by individual team members, or at least disciplines. With the modeling, even though I saw a ton of work being done, I didn’t really think about the fact that they would be catching up and eventually overtaking the number of assets that we had listed. So, getting ahead of the “problem” by looking at individual statistics and compensating for those by making sure that they have plenty of work to do from the moment I notice these patterns, will assist in allowing them to continually have work to do for each sprint.

Another thing I would like to adjust is starting the project with a designated file structure and procedures for working with version control. Something that took a lot of extra time to do was having to consistently reorganize the file structure of the Unity project when levels/assets were imported. This chewed up a lot of time that could have been prevented, as well as having to deal with version control issues towards the beginning/middle of the project. Establishing a set structure for these things so that everyone is on the same page will be very helpful in increasing efficiency in the future.

Additionally, I want to have scheduled meetings with all my programmers. I feel like there was a significant lack of communication over this project and I feel like encouraging collaboration through group meetings and emphasizing the importance of having them communicate with each other, without me being the middleman, would really help with the success and amount of progress that is able to be made.

This ties into prioritizing verbal communication over direct messages, preferably face-to-face, but at least verbal. I feel like this was lacking and I did not put a large enough emphasis on encouraging this with my team. Overall, things were still working well, but there are definitely conversations that should have been done verbally, rather than through direct messaging.

What Would I Do Again?

One of the best things that we did that I plan on continuing is establishing a central mode of communication for the team. For this project, I set up a Discord server where everyone has access to communicate with all team members. This was very effective for almost all the various disciplines, programming lacking a bit more, but the use and implementation of this system helped immensely with communication between team members.

Additionally, I would have a system for quickly distinguishing between user stories, especially if they have variations or similarities with others. This was very helpful in keeping things organized, but I plan on making a small change by looking at possible variations of how I can do this and ask the team how they would prefer for this to be done. I believe that this is an important aspect of how I organized cards for everyone, and it helped them have an general understanding of what the card was for at a quick glance, rather than having to go through each card and read each one to find what they wanted to work on. 

What Did I Learn?

I feel like one of the most important things that I learned through this semester is prioritizing working software. This goes along with making sure that I continue to develop and apply my understanding of Agile values and principles. It took a long time to get to the point where we had even a solid understanding of what we wanted in the game. In the future, I want to aim to have a playable prototype of the core gameplay loop, or at least the core gameplay elements/mechanics, by the end of sprint 1/2, or as soon as possible.

This includes having assets and features implemented as they are made. The use of placeholder assets lasted a very long time and actually made it more difficult and time-consuming to implement everything after the official assets were made.

Also, the idea that reliability correlates with having things done on time. With running into consistent issues of unreliability, I did not acknowledge those patterns soon enough. It is important to understand the behavioral patterns of the members of my team so that I can adjust things as needed. This also means that dealing with pushback and conflict is a skill I need to further improve, as well as being willing to adjust the responsibilities of individuals, if needed. Issues with the lack of builds made and testable hindered our ability to know the actual status of where our game was, in the view of the players. We had very limited playtesting due to the lack of playable builds, which had a significant impact on the outcome of the final build.

Overall, this semester was an incredible experience, and I have learned and grown substantially. As has been said, you learn the most through difficult and trying experiences. I had an amazing team, and they completed some of the most amazing work! Even though we had to work through problems, I am proud of my team and what we have cultivated! Thank you for joining us on this adventure!