2/5-2/19 - First Stability Push
I’ve had a lot of progress over the past week. Here are my updates:
Bug Fixes (7 hours)
Since the start of this devlog period was stability week, much of my time was spent on bug fixes. I fixed the following bugs:
Fixed a bug where the player was not able to move in the Tutorial. This was caused by the fact that the ground was not set to be a collider.
Fixed a bug where the player’s input was not processed in the build (but worked in the editor). This was caused by the fact that the player controller relied on the inventory manager to be initialized before the player controller is initialized. This fact is true in the editor, but not in the build. At some point, I would like a more permanent solution to this.
Fixed a bug where the Time Slow ability did not drain the player’s stamina. As it turns out, the stamina was drained correctly, but the stamina display did not update correctly.
Fixed a bug where the Time Slow ability could not be stopped by player input.
Fixed a bug where the player can get softlocked if they run out of ammo. This is solved by adding smash trash to the tutorial so that players can gain ammo easily.
Fixed a bug where the sword swings multiple times.
Fixed a bug where the player’s sprite is centered incorrectly.
Fixed a bug where the player’s attack cooldown was 10 times the value specified in design.
Fixed a bug where the player can move and attack while paused
Fixed a bug where players cannot move through checkpoint zones due to the layers being set wrong.
Stability Work (3 hours)
In addition to tangible bug fixes, much of my work as programming lead involves taking on tasks for stability:
Build Adjustments: To enable our playtesters to play the features in the game that only exist in test scenes (such as the first boss and the cone enemy), I made adjustments to the main menu. I created a test menu (meant to be deleted later) to enable playtesters in the build to try out the boss.
Additional Camera Functionality: To assist our level designers in placing transitions, I added editor gizmos to our existing camera scripts so our designers can visualize the transitions. I also added options to not move the player and to not show a black screen during the transitions.
Additional Console Commands: I added a console command to flip the nearest switch. This command has an option to flip all switches in the level. This command ensures that we can prevent the player from being softlocked if neccessary.
Pathfinding Graph Improvements: At the request of one of my members, I made some improvements to our pathfinding system. Our pathfinding system uses the A* Pathfinding Project; however, we made many modifications of our own to ensure it works with our system. These options include the ability to exclude diagonal connections and the ability to set a “radius” for nodes (i.e. a node won’t be spawned in a certain distance from an obstacle).
Documentation: To assist our designers, I made some documentation on all the console commands in the game.
Repository Management (4 hours)
I spent a lot of my time on maintaining the repository, which involves merging pull requests, fixing Merge Conflicts and hotfixing the build when needed. I merged in 64 pull requests this sprint (audio not included, as Gibby does most of that), which is the same count as the previous two week period. Much of my time was spent on solving merge conflicts, of which there were 9. Some of these merge conflicts were complicated, as they involved entire Unity scenes. Solving these conflicts involved advanced techniques, such as using transfer prefabs. Overall, the negative impact of merge conflicts on the team were mitigated.
Programming Meetings and 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 once a week for an hour. These are places where programmers can go to get help or work collaboratively. Only a few programmers have taken advantage of this, and I hope more do.