10/16-10-30: Prepping for Stability Week
I’ve had a lot of progress over the past two weeks. Here are my updates:
Tutorial System (7 hours)
A lot of my “in-engine” time this sprint was spent on the tutorial system. The tutorial system was a much more complex endeavor than I initially thought, and that’s because it involved a lot of systems, including:
A system to sequentially display tutorial “boxes” of information. These boxes can be in different places to ensure important information isn’t obscured. The system is a little rough but it does function well.
A system to allow tutorials to resume the game and let the player perform actions. For instance, a tutorial might tell a player to move a crew member to a specific room. The player needs to be able to perform this action in order for the tutorial to move forward, or else they won’t learn. The tutorial system waits for the player to perform specific actions in order to advance. Tutorial designers currently have over 15 different conditions to choose from.
A system to highlight certain elements in the game. A tutorial may need to highlight any number of elements on the screen, from UI to crew to certain rooms. A tutorial design can specify a highlightable object to highlight. In addition, there are special highlight keys, such as “/crew” that highlight dynamic elements, such as crew and rooms.
Below is the interface:
Bug Fixes (4 hours)
This week was stability week, so all programmers were fixing bugs. This includes me, and I was in the trenches fixing a lot of bugs. These include:
Fixing the game’s ability to play audio. I did a lot of investigating about why the game failed to play audio at certain points in-game. As it turned out, WWise did not have the sound effects and music loaded, so the audio just stopped. This was fixed by adding WWise components that load the correct soundbanks.
Fixed the laser weapon. The laser weapon could not be tested as it was developed due to various scenes being broken. When those were fixed, I was able to test out the laser weapon, and it functioned like a normal weapon and didn’t have the specifics of the laser. I spent a bit of time (~1 hour) fixing the broken implementation of this functionality, and I eventually got it to work.
Fixed Shop Upgrades not loading into the shop. When a player opened the shop, the shop would not have any upgrades and threw a bunch of null reference exceptions. I investigated and it turned out that the shop required each item to have its own prefab, rather than all using one, because of a recent refactor. I spent time making and spawning shop prefabs in the correct places.
Fixed the sonar system not working. When fired, the sonar system did not show enemy crew and systems as initially designed, and instead did nothing. I dove into the codebase and found that the sonar was expecting components on the enemy systems and crew that they did not have because the enemy crew was refactored from being placed manually to being spawned. I made changes to the enemy crew spawning system to ensure the enemy crew and systems have the necessary components, and the sonar now functions.
Programming Meetings & Office Hours (4 hours)
A lot of my time this week has been spent in meetings. There are two types of meetings:
The weekly all-hands meetings. This is where every programmer is required to come every week to meet with their squads and then meet with me to discuss their tasks for the week. These meetings can go on for two hours, as there are a lot of things to discuss and the teams are large. During these meetings, I go through my members one by one, discuss what they talked about in their squad meetings, and ensure they have good tasks.
Office Hours. These are a type of optional, opt-in work sessions that I host twice a week for an hour (I started this week). These are places where programmers can go to get help or work collaboratively.
Repository Management (4 hours)
I spent two hours this week on maintaining the repository, which involves merging pull requests, fixing Merge Conflicts and hotfixing the build when needed. I merged in 70 pull requests these past two weeks, which is probably the highest I’ve ever merged in. Much less of my time was spent giving feedback, as people were starting to get into a rhythm.
There were a lot more merge conflicts these past two weeks. The bug fixing and feature implementations tend to gain momentum in the later part of the week. Having that many people work on the game inevitably created merge conflicts. There were some merge conflicts that were hard to solve, either because they were large or had so many Unity-specific changes that they couldn’t be merged in losslessly. I spent a lot of my time fixing those and ensuring the game worked correctly.
Task Creation and JIRA (1 hour)
This week, I didn’t have to spend as much time on JIRA. Very few new tasks came in through the week (so I only made 5 or 6 new Jira tasks). However, I did have to spend a lot more time managing the bug fixes on Jira. In previous years, I used to have a policy of “just take from the backlog”. However, it never worked, and it’s only recently that I figured out why. People feel intimidated by the backlog, and don’t feel comfortable going through a list of 75 bugs and picking one that looks nice. I decided that I was going to assign the first batch of bugs to people, and if they completed those bugs they could pick more or they could ask me for more, and I would assign them. I also had to look for and keep track of duplicate tasks. Ultimately, this system worked out so much better, and I’m glad I was able to iterate on it a lot.