Week 6
Repository Issues and Unity Being Annoying
Last sprint, we ran into a lot of issues with the repository. This led to one of the programmers, Scott who is the repo manager, dedicating hours trying to fix the issues. Unfortunately, I still lost all of the work I did on level 2 and had to remake it as well as a bunch of other small conflicts that led to lost or broken work for other people.
First, when people pulled the branch that level 2 was in, the art wouldn’t show up for them. Just to test it out, I pushed the meta data (something that should be left out of commits since the file changes for each computer) to see if that would fix anything. Lo and behold, all of the art showed up and the level was playable. None of us can figure out why Unity suddenly needed those files to work. However, despite the fix, repo issues plagued us for the entire week.
The biggest issue that was happening was only occurring in my level after we merged the branch that had level 1 with the branch that had level 2. Since most of the updated work had been happening in level 1, there were a lot of merge conflicts with my branch, particularly with the art assets. The assets had been merged into the two branches at separate times. Therefore, when the assets were dragged into each scene without prefabs being made, the art in the scenes were referencing two completely different things. This made all of the art in level 2 disappear and show up as missing in the level hierarchy with no way to fix the issue besides just rebuilding the scene. It took us a while to figure out the issue since the work was spread across so many people and not really documented anywhere.
Level 2 before repo issues
Missing art
Though we fixed that issue, later in the week, we ran into more. The branch I had been working in got buried when all of the branches were getting merged into the main develop branch and got left out from the big merge. When I went to work on my level again, I was told to update my branch with the main development branch, but yet again there were merge conflicts since someone else had worked in level 2. Since I had spent more time on the task at hand, we had to scrap the narrative things that had been implemented so that I wouldn’t have to redo my work a third time. Oddly enough though, the art assets disappeared yet again but was fixed when I pushed the meta data. Finally though, all of the issues were fixed and I could work.
I was able to catch up with the work that had been lost, but hopefully something like this won’t happen again. While repo issues are bound to happen, I've found that there are two main ways to prevent such major issues from occurring.
Creating a Pipeline
Creating a working pipeline is very important to help prevent repo issues, especially with so many people working so quickly on a project. One of the hardest things to establish is the organization and who does what in a pipeline. I’ve noticed issues specifically with the art pipeline on many teams I’ve worked on since we haven’t really been taught the best practices but have had to figure it out ourselves which is still an ongoing process. What tends to happen most times is that the artists make the models and send it to someone else, usually a programmer to put into the build since they are unfamiliar with Unity, and then another person, usually a level designer actually implements the art. This can work well with the right amount of communication and strict organization but establishing a direct order of tasks for something and getting everyone on the same page can be difficult but is very helpful in making sure a step isn’t left out and everything works smoothly.
What we are doing from now on is having the artists make the models, implement them into the build, and then make prefabs of the objects immediately. This branch will then be merged with the level branches so that they are always referencing the same models and we won't lose all of the art from a level again. We’ve gone over this new pipeline to make sure that everyone is on the same page and started using it this sprint with no issues so far.
Additionally, what I’m going to start doing in the future, is having a pipeline checklist written up for everything like art implementation, level implementation, UI implementation, and systems implementation. They are rather broad categories and can be customized depending on the project, but for the future, I think that having a specific list of what needs to get done, where it will be done, and who will be doing it are the biggest things to know in a pipeline and maybe even written up each sprint for certain large features. This will not only help the process be streamlined, but it will also help in the debugging process if something goes wrong. With the same steps being taken each time and marked off each time they are completed, we can easily trace an issue back to its source and (hopefully) quickly fix it.
Communication
However, the most effective way to prevent repo issues (and just one of the most important things for a team in general) is communication. Each sprint, everyone should know what is going to be worked on and accomplished which is why we always do sprint planning as a full team and another great reason for daily scrum meetings. With this in mind, people should know what scene or scripts that others will be working in so that they can avoid working on it at the same time. Before starting work though, we also always try to ask if anyone has been working in the part of the game that we are planning to work in and making sure that they have everything saved and committed their work so that nothing is lost. Communication is key.
