I’ve had a lot of progress over the past week. Here are my updates:

Player Abilities (4 hours)

This sprint was our big feature push, and we wanted to get as many features implemented as possible. I chose to take on a few of the player’s abilities, and they are:

Chain Dashing. Chain Dashing is the ability to do multiple dashes in quick succession without facing a cooldown by pressing the dash button at the correct time. Dashing has a cooldown, so chain dashing is a way to reward skilled players with the ability to traverse further than with regular dashing. Since we already had dashing, this ability just involved refactoring the player’s dash controller to use more complex logic for state tracking (i.e. being able to differentiate between when the player is dashing vs when they cool down).
Energy Burst. The Energy Burst is a single-use ability that knocks enemies away from the player. It is intended to be used as a lost resort, as it is supposed to cost a lot of stamina. To create this ability, I built a framework for housing player abilities through inherited scriptable objects (this has the benefit of allowing designers to make upgrades easily). Once the system was created, I was able to build the Energy Burst ability without much trouble.
Mouse Dashing. Mouse Dashing enables players to dash in the direction of their mouse, rather than the direction of their movement (i.e. WASD or the left stick). It doesn’t make the player more powerful, but it allows them a new way to play. The actual functionality of mouse dashing is easy, as the Player’s API gives programmers easy access to the inputs. However, I wanted playtesters to be able to toggle this ability. I built a pause menu with a settings submenu, and enabled the player to toggle between movement dashing or mouse dashing.

A demonstration of the energy burst in a test scene.

Ammo Refactor (1 hour)

Another programming task I took on was the ammo refactor. The prototype version of the ammo, which was based on my hour-long playthrough of Hyper Light Drifter, only had whole increments of ammo. However, later guns in our case study enable players to have (and use) fractional amounts of ammo. As a result, design asked us to change this system to use fractional ammo. I refactored the system to use floating point values and refactored guns to track ammo in fractional values.

Guns are now allowed to have fractional amounts of ammo (hitting an enemy restores a full ammo bar, but hitting a prop restores a fraction of it).

Stability Work (3 hours)

In addition to feature additions, I took on smaller tasks for stability. These included:

Setting Up a Test Scene Workflow. I realized eventually that programmers will need their own environments to develop and test features. As a result, I created two scene templates to help them. One, called “Combat Template No Gap” is a minimal scene with just a player character and a basic environment. The other, called “Combat Template Gap” includes many more features (test dummies, keys, obstacles, a gap to dash across). I think this new workflow helped programmers.
Reogranization and Renaming. I took time to ensure that assets were implemented in the right place. This meant ensuring that non-temporary prefabs were moved from _Development/TempPrefabs into Prefabs, ensuring game ready art was in a different folder than non-temporary art, and ensuring that script files were placed in the correct folder (rather than dangling in the assets folder).
Integrating Features Together. There were several features that were developed separately but intended to interact. For instance, the encounter system was supposed to trigger the UI to fade in and out. However, the UI fading was completed before the encounter system, so the UI Fading was tied to a temporary key press rather than the encounter system. I switched out the code to trigger the UI once the encounter system was complete.

The new test scene workflow, enabling programmers to create development environments easily.

Designer Support (2 hours)

A bit of my time this sprint was spent on supporting designers in their role as they integrate assets into the game. A few designers, including the level and UI designers, were going in engine very early, so I wanted to introduce them to the systems. I hosted a meeting with Joanne, the level designers, and the UI designers to walk them through all the different features. This included where the UI lives, how to set up layers and tilemaps, and what features were available. After this meeting (which lasted an hour and was done in the middle of the sprint), the designers came to me throughout the week with questions on how systems worked. I spent a lot of time this week answering their questions individually on discord, and pointing them to the correct places.

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 definitely one of the highest pull request counts. This was largely caused by the speed at which my programmers were implementing features, which was very high.

In addition, I spent a lot of time providing feedback for my members on their code. I wanted to do more than just check if a pull request will damage the game (which has happened and has been prevented by my checks); I wanted to give members tangible ways to improve their code. I focused on telling them where their systems had scalability concerns, where it didn’t align with design, and where changes had unintended negative consequences. Programmers seemed to appreciate that I checked for these changes.

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.

1/22-2/5: First Feature Push